Who should fix Impediments?

In the Certified ScrumMasters LinkedIn group, Michael asked: Who should fix impediments, the SM or the Team?

His own answer was: Both. And then he discussed.  This topic has drawn a fair number of comments.  Here was one of mine.

***

1. Michael is right, that who should fix the impediments and how much the Team should be involved is not a simple question. I think this discussion has brought out the issues.

2. I like what Mike and others said about changing the mind-set of the Team.

3. Clearly, getting the Team involved in impediments is important. To me, the first thing is getting the Team better at identifying the top impediments (imagining that real change can happen), and then better at giving the SM information about how to prioritize them.

4. Clearly the SM should always be working on something, although I do think "observing" is important and hard work. (It can identify some people impediments, for example.)  Working to get others to complete the fix of an impediment is also important.  And the SM should also actually fix some impediments, where he has a decent ability to do so. (If an SM does not know what CI means, I would not have him work on Continuous Integration.  I think.)

5. The list of impediments is endless, in some sense, because never do we have even one thing running perfectly. So, in theory, we could spend all of our time fixing impediments. I think spending about 1/7 of our time on impediments is reasonable.  (This is a bigger issue, but relates to this conversation.)  There are definitely limits to how much the Team should work on impediments.  We want them mostly doing 'real work'.

6. I have never seen a Team reach optimal productivity. Never. They may get to 5x or 10x, but they still have not max-ed out.  I don't believe Michael Phelps has swum his fastest possible race.  In fact, most Teams can't win the Super Bowl the next year...they can't even stay at that high level. Never, never, never send out a team without a 'coach' (without an SM).

***
Comments?

More on: The Product Owner and the Team

There has been some interesting discussion on this topic recently.

Two things I wanted to add to my prior post.

1. The business side cannot force the Doers to "do all that I say" in the Sprint.

This is of course a well-known rule of Scrum. But this rule does eject the PO from the Team.

So, in one scenario, the PO cannot force the Team to do all X stories that he or she wants done in the Sprint.

But even before that, the PO should want reliability, meaning, if the Team commits to 8 stories, then at least 8 stories will get done (or done, done -- if you prefer) in that Sprint.  The PO does some of the 'real work' (in the form of providing information about the stories and feedback, mainly), so the PO has a say about what he/she can or cannot do to support the Team that Sprint.

What I usually find in the real world, is that the Doers (eg, the coders and testers) want to over-commit.  And the PO (at least) should be saying "no, let's not over-commit -- I and we need to predict for the customer, and we need to know what the Team can really do at sustainable pace".

But at least the Business side (often in the person of the PO) cannot force the Team to do 8 stories when, in their professional judgment, they can only do 7. As an example.

Exactly how the Team self-organizes to reach that judgment is up to each team, but ejecting the PO is not an option.  The PO has at least some lights on the problem, and so should be heard, just as, for example, the junior tester has some lights on the problem.

There are many possible scenarios, but these are the basics.

2. The issue of whether the PO is part of the Team (yes!) is far greater than just the issue of Sprint commitment.

Yes, Scrum teams have problems with the Sprint commitment. All kinds of problems, with multiple root causes. This was partly discussed (indirectly) in a recent post.

But in the shorter term (eg, intra-day) and in the longer-term (eg, release), the PO is an important part of the (full) Team.

Let's take the Release, and the use of Pareto's idea of the vital few.  So, the whole team must be optimizing the 80-20 rule at every level of work (tasks, stories, epics, etc.).  And discovering how to do the least amount of work to deliver quickly the best possible product. (See the Agile Principles.)  This is a Team effort, led in large part by the PO.  But still a full Team effort.  The key related idea is cost-benefit analysis (hey, there's another new one!)... how to get the most benefit or business value for the least effort.  Again, a joint effort by the full Team.

When troubles arise (and troubles in some sense always arise), who is the Team that will address them? ....well, both the Business side and the Technology side together must collaborate to address them.  We might too easily say that in general, both sides must compromise.  Each side must accept "lack of control" but high "power to influence", and create some modus vivendi....some way out of the problem together.  How do we do this in a practical manner?  The simple way of saying it is that the full Team (with the PO) must figure it out.

Again, there are many scenarios, but those seem to us the basics.

***
Yes, I know there is much 'legacy code' in our wetware (our brains, etc.).  But this I think is the way forward.

We must have working software at the end of the Sprint!

This is a common failing (not enough working software).  Jeff Sutherland has said this is the biggest problem in the Scrum community, that too many teams don't have working software at the end of every Sprint.

If we include cases where 1or more PBIs (Product Backlog Items) or stories are not completed, this is a very big problem. And very common.

So, how do we fix it?

Well, the root causes at your place or your friend's place may be very different from mine.  But here are some likely suggestions.

1. A better definition of done.

First, have one. Second, let it actually be what people are committed to doing (rather than just some pretty words on the wall). Third, put in a process format rather than an "end-state" format. Show how the team will get to done.

To me, a minimum definition of done for a software product includes the following: Requirements (of course), Coding (of course), Unit Testing (typically by the coder), and Functional Testing (by a qualified professional tester, of the functionality in that PBI, at least), and Product Owner Review (ie, the PO likes it once 'complete').  And all bugs or problems are fixed.  And re-tested.  This is the minimum, IMO.

2. Your testers are used to slow manual, non-agile, testing. 

They may not say it out loud, but they don't really understand agile. They are still expecting to do it the old, waterfall way.

3. Lack of good automated testing, and automated testing frameworks.

This could include a lack of people who understand automated testing, why it is needed, and how to do it well.

4. Smaller stories.

It is very common not to complete stories of one or more stories (or PBIs) are too big.  One rule of thumb: If the Sprint is two weeks (10 business days), then any story that takes more than 5 ideal person days of effort is too big.  And the average story should be in the 2.5 ideal person days range. Total for all people working on that story.  Put another way, I want at least 8 stories in each 2 week Sprint. All about the same size.

5. The Team is over-committing in Sprint Planning Meeting (or being over-committed later).

This is very common.  They should not take on more work than they can do. Period.

6. The Team does not understand well-enough why working software at the end of the Sprint is important.

Often, they forgot.  They knew 3 months ago (when the trainer told them), but they have forgotten since then.  Not all of them, but maybe most of them.

Often they will admit to one of the 1-5 root causes (or some others), but they won't put much energy into fixing it or them, since they don't really agree that the problem is all that important.

***

Well, if you can identify the problem, the root cause, usually you are more than half-way to fixing it.

More on the fixes to these problems later....