Why I Would Never Go “Enterprise Scrum”

April 19, 2011 1 Comment

I’ve had some recent debates regarding whether we should start an “enterprise Scrum” initiative, i.e. WE WILL BE A SCRUM SHOP.  I would have completely supported this several years ago.  Now, I am completely against it.

In an organization of any significant size or age, there typically have been methodologies that have been introduced, pushed, then they fade away into the far recesses of everyone’s memories.  One characteristic of these methodologies is that they have very specific rules.  You can’t add to, change, or remove any of the rules.  Why?  Well, because you wouldn’t be “doing” X methodology!!!

People have a habit of dogmatically following whatever methodology management makes them follow.  Now let’s say we are doing “Enterprise Scrum”.  This means that you are performing the following ceremonies:

  • Release Planning
  • Sprint Planning (every sprint)
  • Daily Scrum (every day)
  • Sprint Review (every sprint)
  • Sprint Retrospective (every sprint)
And, you have the following roles:
  • (1) Scrum Master
  • (1) Product Owner
  • Team (self-organizing)
And you will have the following artifacts:
  • Product Backlog
  • Sprint Backlog
  • Burndown/Burnup charts (some say Scrum requires these, I don’t think it does as it’s not clearly articulated and varies by source)
So we’ve gone enterprise Scrum.  We’ve introduced this “by the book” Scrum.  However, we’ve also preached “inspect and adapt”.  But, in Scrum, the above items are non-negotiable…you can inspect and adapt all you want, but you can’t change the ceremonies, artifacts, and roles.  Can you add to them?  Sure, but you can’t “change” them.  And, in reality, making “inspect and adapt” a cultural “habit” is spectacularly difficult and rarely truly attained.

What if we have a Scrum team that wants to do a retrospective every other sprint instead of every sprint?  Blasphemy!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.  Really?  What if the team, Scrum Master, and Product Owner are all cool with it?  Now we have a bunch of stress, spinning, and politics because we want to make a change to our enterprise standard Scrum.  In reality, this is perfectly okay.  However, since we’ve pushed “Enterprise Scrum”, we have totally boxed ourselves in.  There will even be people who will not want to add techniques because “Scrum doesn’t say so”.  Do those people truly understand the essence of Scrum?  No.  But they will cause disruption and waste

What if you don’t want to do iterations?  What if you want to deliver continuously instead of iteratively?  No Iterations?!?!  Blasphemy!!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.

You know all of this could have been avoided?  By NOT saying we are going “Enterprise Scrum”.  I believe the best way to roll this out is by pushing Agile and Lean and what makes sense on a project by project basis.  Along with this there should be some foundational elements that are standard regardless of the methodology/toolset that is used. In addition, there needs to be a COE that can ensure that consistency is maintained without bureaucracy, and that knowledge gained is effectively utilized to continuously improve.

Please don’t misunderstand my intention here.  I am not bashing Scrum.  I LOVE Scrum.  I always use Scrum when I execute projects.  However, I’ve had rare cases within the same company where Scrum was NOT optimal, but Kanban was.  I was very thankful that Scrum was not the required standard.

Advertisement

Filed under Agile, Process, Scrum

Your Scrum Team Might Be Too Big

January 4, 2011 Leave a comment

According to the ways of Scrum, the optimal Scrum team size is between five and nine people. Interestingly, I’ve seen this as a point of concern (sometimes contention) when I’ve coached people on Scrum. Please note that this is not a rule that must be followed at all costs. God gave us a brain, so we should feel free to use it.

While I know it’s rare, I personally have seen successful teams that consisted of 10-15 people. I belive that if a team consists of any more than 15 (or so) people, you are reducing your velocity.

Now you have a bloated team.  What should you do?  Well, first thing you should consider is to take some ideas from Kanban. Visualize the work, make the process and policies explicit, limit work in progress, measure/minimize cycle time, etc. (read more on Kanban here)   The purpose of all of this is to gain clarity on what kind of work is actually taking place.  In addition, you will gain insight into the quality of the deliverables and where the bottlenecks are.

Once you have this information in hand, you then have three choices.

  1. Split the team into multiple teams.I have seen large teams have several very distinct types of work occurring. If there are distinct types of work, i.e. completely different categories of stories/requirements with different goals, and the team is forced to act as one, then there is waste. For example, during the standup, there will be members of the team that have to endure hearing the updates about requirements that they have no interest in, nor can they contribute to the delivery of those items (usually). This is likely the optimal choice.
  2. Reduce the number of people on the team.This is the tricky one. You may find that there are people that don’t have the necessary skills, or you may find that there are too many people with one very distinct skill set. If one (or both) of these scenarios holds true, and you are sure that these folks can’t contribute in other areas, then make haste and remove the people from the team. Everyone (including those let go from the team) will end up happier and more productive.
  3. Keep everything the way it is.This is a very, very unlikely choice. I have never personally experienced a time when it was a good idea to keep one team larger than 15 people. I would love to hear from others where this has worked…well.

If you are a Scrum Master, and you are experiencing team bloat, then it is your responsibility to recognize it, determine if it’s an impediment towards improvement, then handle it.

Filed under Agile, Scrum, Teams

Tips on Knowing if Your Daily Scrum Sucks

October 18, 2010 3 Comments

Below are some tell-tale signs that your daily Scrum sucks.

  1. The team members stand at attention and salute the Scrum Master.
  2. There is an infestation of clucking chickens.
  3. You have a hard time hearing everyone over the loud yawning.
  4. There’s lots of very descriptive, helpful answers to “what did you do since the last meeting?” like “stuff”, “things”, or even better…”nothing”.
  5. The team members who did nothing since the last meeting happen to be the “rock stars” pre-Scrum…oh, and they never, never, ever, ever have anything standing in their way.
  6. Every meeting reminds you of the movie “Groundhog Day”.
  7. The first 5 minutes is spent waiting for the projector to warm up.
  8. You get to meet a new member of the team almost everyday, while never having a chance to say goodbye to the dearly departed.
  9. Most’s answers to “what are you going to do today”,  are “get sign-off”.
  10. Big Brother is there to make sure the team is “on track”.
  11. Most meetings consist of discussing episodes of “Fringe”.
  12. The meetings are typically very lonely, as you are the only one that shows up.
  13. Bullies are allowed to…well…bully.
  14. Everyone has their laptops open IMing each other about “how stupid this meeting is”, while the Scrum Master or Product Owner is assigning tasks.
  15. You get to hear intriguing, long presentations about each and every detail on things like how to install and set up subversion, or maybe even if you’re lucky you may hear why Lisp is the best programming language in the world!

While many of these are a bit tongue-in-cheek, they actually represent the many dysfunctional daily Scrums I’ve attended.  And yes, I’ve been guilty of participating in the dysfunction.

So, let’s hear from you guys!  What kind of signs have YOU seen that your daily Scrum sucks?

Filed under Agile, Meetings, Process, Scrum

How Does a New Scrum Master Learn the Mastery of Scrum?

September 28, 2010 Leave a comment

Learning to be a Scrum Master is hard. But what’s the best way for a new Scrum Master to learn to be a Scrum Master?

I had it easy. When I learned, I had an awesome team. They were open, engaged, and always wanting to improve. The Product Owner was awesome also. Again, open and engaged. The thing they all had in common was that they wanted to learn Scrum. I introduced Scrum to our department. I read a little, implemented a little. Screwed up, tried again. Read a little more, tried a little more. And so on. It was basically a self-study program with help from blogs, books and the team itself.

For me this was easy. I was never really a “command and control” person anyway. Sure, I had my tendencies, but pretty mild. I knew that my team were the ones that “really” knew what to do anyway…so why not give them the tools to empower them and help them be focused on quality and value? There wasn’t a lot of “unlearning” that had to take place for me.

After that first (great) experience, I became an agile coach. Now it was my time to help teams transition to Scrum by educating the team, Product Owner, and Scrum Master. Well, admittedly, I was winging it for a while, but through trial and error I fell into a pretty good groove.

What I’ve done recently is come up with three options/approaches to helping others become Scrum Masters.

  1. The coach leads

    With this approach, the coach plays the role of the Scrum Master, while the soon-to-be Scrum Master watches, and helps. Then, after a while (depending on their comfort level), there is a switch, and the coach becomes the observer/helper.

  2. The coach observes

    Here, the new Scrum Master will be the acting Scrum Master. However, the coach will be there to observe (and help) while the new Scrum Master is facilitating. The coach would only correct/advise/encourage in private.

  3. The coach advises

    In this scenario, the coach is not directly involved in any of the ceremonies. They are only there to advise. The new Scrum Master and coach would regularly meet to go over gotchas, issues, etc.

  4. Coach? What coach?

    This is how I learned. We didn’t have a coach. But, we were completely free to do what we needed to do to be successful. And, there was complete buy-in from the team and leadership. Oh, and we were allowed to make mistakes. And, I think what really made it work was that none of us had any “baggage” from other environments. I recently had change careers (retail to software), and most of the folks on the team were relatively fresh college graduates. After working with many teams, I’ve found that this is indeed a rare situation.

I give my team (and anyone else in the organization who wants to be a Scrum Master) those three options. #2 is the most popular. However, I just had someone pick #3.

So, which the best option? It depends. It depends on the experience of the new Scrum Master and of the team. It also depends on who the coach is in the organization. For example, I am a manager where I work. I don’t have the word “coach” in my title, even though this is something that I am responsible for. As with most organizations, having “a manager” present may send the wrong message, no matter how cool you think you are! There are some teams where there would be no issue, but there may be others where it might be questionable. You have to be aware of this, and make your decision accordingly.

As an independent consultant (coach), who is brought into an organization to introduce Scrum, then #1 is typically the best. If the coach is there to help “improve” their implementation of Scrum, or if maybe the organization is backsliding, then maybe #2 is best. When there are experienced Scrum Masters that are experiencing new situations and need to just bounce ideas off of someone, then #3 is best.

As far as #4…I’ve heard about many teams that tried to “do it on their own”, and completely tanked. They didn’t have that utopian environment that is oh so rare. So, if you do decide to do it on your own, start reading. Read, read, read, and read some more. Blogs, books, and user groups. Ask questions on these user groups…you will find a wealth of knowledge and people who want you to be successful. Also, twitter will be your friend. Personally, I have gotten so much out of following Mike Cottmeyer, Alan Shalloway, Ron Jeffries, Scott Ambler, Mike Cohn, and Esther Derby (to name a few). They post awesome information and articles that are thought provoking and hard to find otherwise.

I would love to hear from others on this topic. What are the approaches you have taken in coaching, or have seen others take? How did YOU learn to be a Scrum Master?

Filed under Agile, Scrum

When Should Waterfall be Used Instead of Agile?

March 9, 2010 1 Comment

I just read a thread on the Scrum Development yahoo user group about when it would be appropriate to use agile and when waterfall would be better.

This brought to mind all the conversations I’ve had over the years regarding “when to use agile”. There are many folks in organizations that believe that waterfall is best suited for some projects.

So, I’ve been searching for those “types” of projects.

Now, let’s be clear. I am using the term “waterfall” in the strictest sense which means that:

  • Requirements have to be complete and signed off before technical design begins.
  • Technical design has to be complete before development begins.
  • All coding has to be complete for testing begins.

If we “kind of” follow this, then it is chaos.  The question we have to ask is … is it even possible to meet the strict requirements of waterfall?  My answer is NO for software projects, or any projects with a large amount of unknowns or required creativity and flexibility.

Can you ever successfully elicit and document a complete set of requirements at the most granular level?  This is what waterfall requires after all. If there is even a remote chance that a) the customer isn’t sure what they want, b) the customer may change their mind on what they want, or c) there is even a small amount of complexity, then it is very, very high risk and just not very smart to use waterfall. You just can’t…stop kidding yourself.

So, is there ever a reason why you would want to use waterfall? Sure! Here they are:

  • The culture is not ready to work cross-functionally.
    • Any agile methodology requires a cross-functional team. If the culture cannot sustain cross-functional work then you are forced into communication by documentation. Yeah, good luck with that. You should think about coming up with a strategy to make people hunger for cross-functional collaboration.
    • Not everyone “wants” to work in a cross-functional team environment. They need to either be coached up or coached out.
  • Management makes you use waterfall.
  • You can confidently define everything up front, there is little or no chance there will be changes, and there are no unknowns.

Let’s not pretend anymore that waterfall is actually appropriate for any complex software project with humans working on it.  With complexity come unknowns, and with unknowns, the amount of bureaucracy necessary to handle “change management” is ludicrous.  I have yet to experience any software development project that did not have at least some kind of complexity.  If you say “agile doesn’t work for all software projects”, then you have a misunderstanding of what agile truly is.

Filed under Agile Tagged with ,

Creating the Sprint Backlog in New Scrum Teams

December 28, 2009 1 Comment

If you’re new to Scrum, here is something you need to know about teams first trying it out…ready??

…drumroll…

The team doesn’t know what they need to do

There, I said it. Whew, glad I got that off my chest.

In Scrum, we ask team members to break product backlog items (typically stories), into tasks that take 16 hours or less to complete. You will find that, most of the time, the team will have incredible difficulty in doing this, and they will likely come up with tasks such as “analyze, code, test”. Bleh. Those are B.S. tasks that really don’t mean anything. It’s hard to define “DONE” for those types of tasks. You may have to accept those tasks in the beginning, but it is your responsibility as a Scrum Master to coach the team into creatively thinking through task definition.

Here are some reasons I think teams may have a hard time defining tasks.  It is best to look at all of these as impediments, and your job as a Scrum Master is to remove them.

  • Lack of Empowerment
    Teams under the tyranny of “traditional” development are rarely empowered. They are used to being told what to do. While creating solutions, team members will actually do what needs to be done and then move on to the next thing. The problem is that they’ve never had to articulate the steps they take to complete what they need to complete.  And, to top it off, managers rarely understand what it “really” takes to deliver a solution. 

    This will not be a quick fix.  You will have to work with leadership and come up with a strategic plan on how to empower people.  In the meantime, even though you tell the team “your empowered’, if the rest of the organization does not support it, there will be constant struggle.  However, as a leader, it is your job to work both sides of the fence, i.e the team and the organization.

  • Fear
    In an extreme command-and-control environment, people lose all common sense. They are not confident making any decisions, let alone actually thinking for themselves. 

    Here, the team will need lots of praise and protection.  If they know that you have their back, they will, over time, come out of their shells.

  • Lack of Knowledge or Skills 

    If the team is new to that domain, or the team just does not have the skills, i.e. a Cobol programmer “trying out” Java development, there is no way they can effectively decompose stories into tasks.

    This is one of the toughest situations to deal with.  If the team is just the wrong team, the only thing that can be done is to escalate this impediment to leadership.  This one is particularly hard because I guarantee that there will be others who think some of those on the team DO have the knowledge and skills, likely because those folks are “well liked” or popular.  Just remember to be honest always, and over time, change will happen.

  • “The Dominator” 

    Sometimes there is one person on the team who holds the key. They know the domain, they know the technology. No one else does. THEY are the ones who define the tasks. If the tasks aren’t good enough, who cares, as long as “The Dominator” is okay with them. This is a tricky one. It is your responsibility to either a) get them off the team or b) clearly set the expectations and time-box the needed change in behavior.

If you are a Scrum Master or coach on this team and you don’t have “tribal” knowledge, it will be a true test of your patience.

But, hope is not lost! A while ago, I was in this situation. I was in a sprint planning session, and I saw the familiar signs emerging…”Ummm…yeah…we need to analyze”. “Oh, I suppose we need to code too”. UGH. I was helpless. Luckily, there was a strong technical lead attending that understood the domain and technology. He patiently walked the team through the decomposition of the stories into “real” tasks. It was a real humbling experience for me. I thought I could get ANY team to decompose stories into meaningful tasks. Boy, was I wrong.

So, if you’re in this situation, determine the “root cause” of why the team can’t decompose stories into meaningful tasks. If it’s an impediment, handle the impediment. If it’s because you are lacking the knowledge necessary to coach the team, find someone there who can.

Filed under Agile, Process, Scrum Tagged with , , , ,

Agile – It’s All About the Principles

December 6, 2009 Leave a comment

I’ve been talking with a lot of folks lately that claim to have been working with Agile for a long time.  When I talk with them, they boil agile down to a few things such as; delivering faster, iterations, and stand-ups.

What troubles me is that very few people talk about the principles.  I like focus on the principles first, and look at the practices (retrospectives, stand-ups, iterations, etc.) as “how” to bring those principles to the forefront of everyone’s mind.
You aren’t “doing agile” because you put index cards on a wall, or because you stand up for 15 minutes a day in a meeting, or even if you have iterations.  Practices without focus on the principles will get you nowhere.
As teams inspect and adapt, new practices will emerge.  As these new practices emerge, we need to do our best to make sure they don’t impede the agile principles, which are honestly good principles no matter what approach is used.

Filed under Agile Tagged with ,

Just in Time or Just in Case?

December 3, 2009 Leave a comment

A huge form of waste that many people don’t talk about are those things that are built “just in case” we might need them some day.

I think that those involved in building a product often times forget that everything that is built costs something.  Nothing is free.  Who’s paying for it?  The customer is.  Everything we do must deliver some kind of business value, either by reducing risk, meeting compliance, cutting costs, increasing revenue, etc.
There are certain phrases that I listen for like “it would be cool if…”, “someday we  might want to…”, etc.  Some tend to want to build to accommodate edge cases that are (many times) so ridiculous that they would never happen.  Now what gets really tricky is when there is only one SME in the product group, and no one else really knows that domain.  In those cases, God help you!  That SME has the power to make you do things that you look back on and say “WHAT HAVE WE DONE?!?!?”.  The only way to get around this is to fearlessly and relentlessly ask “why?”.  In these situations, there is typically a touch of fear that compels the team to bow down and say “yes master, whatever you wish” instead of asking probing questions.

There are some Scrum Masters (and Project Managers) that typically stay out of those kinds of details.  Yes, the team is self-organizing.  Yes, the team has to learn by making mistakes.  However, the Scrum Master has to be involved enough to not allow the “just in case” methodology from taking hold.  If it’s allowed to go on too long, you will have found out that what you have delivered in the end is not what is  valuable now.

Filed under Agile Tagged with ,

Bringing Agile to the Organization

November 16, 2009 Leave a comment

Almost all of the literature out there recommends the first step being finding a “pilot” project where you can use an agile methodology.  The project can’t be too complex, too simple, too large, too small, too critical, or too unimportant. 

I’m starting to wonder if we’re over-thinking this.  Why don’t we decide what to use depending on the project?  If RUP fits REALLY well, then why don’t we use that?  If Scrum fits REALLY well, then we should have the option of using that…right? 
In reality, the only thing that will ever hold back a true agile adoption on a project or an organization is the culture.  And, the other reality is that most organizations have a culture that does not support an agile framework.
But, how do we change the culture?  Do we change the process first and hope the culture changes with it?  Or, do we try to change the culture ahead of a process change?
At my current place of employment, agile methodologies are accepted, along with any methodology that makes sense.  There isn’t a “corporate” methodology.  I really like that.  Imagine if a company was by-the-book Scrum.  No other options.  Imagine having to beg for permission to “pilot” Kanban…ugh.
My point is this…maybe we should stop the notion of “piloting” Scrum, or Extreme Programming with the intention of rolling it out and making it the “approved” delivery methodology.  Maybe we should instead focus on sound principles that we know are true, universal, and also happen to be highly valued in agile and lean.  Principles such as:
  • The primary measure of progress is working software
  • Business and IT working together daily
  • Face to face communication
  • Reducing waste
  • Building quality in
  • Delivering as fast as possible
  • Delivering working software frequently
  • Self-organizing teams
  • Welcome change
  • Sustainable development
  • Technical excellence
  • Keeping it simple
  • Continuously improving the process
 As long as we let these principles drive our process, and people are empowered and allowed to make mistakes which will in turn promote learning, the process will work.

Filed under Agile Tagged with , ,

The Cross Functional Team vs. the Functional Community

November 9, 2009 1 Comment

An agile team consists of everyone it takes to deliver value to the customer.  The typical team consists of analysts, developers,  and testers. Of course the team is not limited to these roles.  The team could also include technical documenters, DBAs, or whoever else has a hand in creating value.

In traditional organizations, “team” is defined as a functional group.  The development “team”, the “testing” team, the “analyst” team, etc.  This makes sense in a traditional, waterfall-ish environment.

In an agile, cross-functional environment, it is not helpful to define “teams” around functions.  Okay, “maybe” its okay in a production support capacity, but that’s still pushing it as there will still need to be cross-functional work with production support.

Teams have a common, unified goal. Functional “teams” do not.  For example, a functional “team” that consists of a dozen Java programmers, with each programmer on a different project, can hardly be called a “team”.  They have no common goal, other than to adhere to the (hopefully) high development standards that have been put in place.

I propose that instead of calling these functional groups “teams”, we call them communities.  Here’s a simple definition of community that I found on dictionary.com: “A group of people having common interests“.  The Java “community” will work together to make sure that they have common standards of excellence, share knowledge and experiences, and provide each other guidance as needed.  However, these people will have different goals, depending on the project on which they have been assigned.

Filed under Agile, Roles, Teams Tagged with , , ,

← Older posts