What are impediments? Definition of Impediment

Definition of Impediment is anything that is slowing down the Team.  (The Scrum Team)  Anything!

In PMP words, it is any kind of issue. And it may include risks as well, but typically only high probability risks that are likely to occur fairly soon. (I typically also recommend a simple risk log for each Certified Scrum Master Workshop + team — but that is an add-on to Scrum, not part of the bare framework of Scrum.)

Anything can be an impediment.

Even things beyond our control.  A hurricane in NYC. A tsunami. A people issue. Lack of a babysitter.

In fact, since nothing we do is perfect, every team has at least 900 impediments, things that can be improved somehow.  The only real question is, what are the top 20 things to improve?  Or problems to address.

By the way, how is it useful to identify impediments that are ‘beyond our control?’  Actually, even though we can not solve the impediment, we can almost always mitigate its impacts on us.

Some people say that blockers and impediments are different. I say no, put them in one list.  First, blockers are usually defined as a thing (eg, lack of knowledge) that keeps a User Story from being completed in a Sprint. This is an ok definition. But blockers are just one type of impediment in Scrum Coaching.

Just as there is only one Product Backlog for a Team, there is only one impediment list for a Team.  Thus, there is only one list for the Scrum Master to manage (on behalf of the Team).  The SM should always be driving the top impediment to completion.  (Maybe only mitigation. But in any case, that item is no longer #1, and something else becomes the #1 impediment.)

Some types of impediments:

• Blockers (for a user story)
• People issues
• We (anyone on the Team) is not skilled or knowledgeable enough
• Technical issues
• Lack of knowledge
• Less than perfect skill (in one area)
• Operational issues
• Managerial Issues
• Organizational issues
• Process issues
• Outside disruptions (outside means from outside the Team)
• External things (weather, riots, war, etc)
• Problems that the Pigs have at home (eg, lack of babysitter)
• Lack of positive things (eg, the Team needs its own Coke machine or ping pong table)
• Business or customer issues
• Culture and waterfall attitudes
• Impediments to faster Scrum/Agile adoption
• Etc Etc

Remember the human tendency to think ‘I am perfect’ and all problems come from ‘those people over there or at least somewhere else.’

Many of these can be big categories with useful sub-groupings.

It turns out that usually each Team will feel improvement as soon as the agile adoption is ‘more complete.’  Hence, agile adoption gets on the same list. (Maybe this needs more explanation in another post.)

Anything (anything!) that would lead to the Team going at a higher velocity (at a sustainable work pace) is an impediment. So, the lack of positive things (Coke machine) is an impediment.

An FAQ:

1. How often does a Team start with impediments?  Ans: Always.

2. Can the Team do some work even though it has many impediments?  Ans: Almost always.  Except the velocity would be higher if some were mitigated (well, in general, the more mitigation, the higher the velocity).

3. Can a Team be completely stopped by one impediment?  Ans: In theory, of course — yes.  But in practice, this seldom happens.  Or the duration of the stoppage is not terrible.  Two main points:
a. The Team does not get to use the impediments as an excuse for doing nothing.
b. Someone should always be working on the top impediment, and the firm should always be making a reasonable investment in helping the Team get better.

4. Should the Team stop working if some impediments are not fixed?  Ans: In general, this seems …. not the most mature approach. But in some companies, to break certain patterns, this threat or even this action for some time might be useful and necessary.  To make a point.

5. Should we fix all the impediments before we start Sprinting?  Ans: NO!  First, by definition there are always more imperfections to work on, and we have never seen a real team that could not improve.  Second, Scrum helps the Team see the next most important impediment to work on.  Thus, you must be Sprinting to get that information.

6. Who fixes an impediment?  Ans: It depends on the impediment. Obviously, the best person or persons should fix the impediment.  “Best’ is a multivariate equation. In practical terms, some are fixed by the SM. Some by the PO. Some by the Doers in the Team. Some by people outside the Team.

7. One can imagine that some technical impediments (eg, inability to do continuous integration) or organizational impediments (a tollgate process built for waterfall) could take many months or longer to fully fix.  Is this reasonable?  Ans: Yes, very often this is the case. So, break up that elephant into digestible pieces.

8. Who decides which is the Top impediment?  Ans: Ideally, the Team.  Certainly, it is from the whole team’s point of view.  And the SM should force the Team to decide. It is acceptable if the Team decides to let the SM decide.  For the bigger impediments addressed in the Retrospective, the SM should force the Team to agree to the ordering of the Top few impediments.  This might change by the next day.

9. In prioritizing the impediments, what kind of factors should come into play?  Ans: Well, for beginners let’s say this. Impediments, like large user stories, must be broken down into digestible chunks.  The (expected and actual) impact on velocity is key. Cost-benefits analysis is important. Sequencing is important (eg, for technical impediments).

10. How quickly do we want to benefit from work on impediments?  Ans: About every Sprint, at least.

11. Could the ordering of the impediment list change from day to day?  Ans: Yes. And often not every day, but on many days, for many reasons.

12. Does the Team always identify the best impediments?  Ans: No.  At least, usually not without coaching.  I recommend giving the Team a challenge.  Say: “We need to double the velocity of the Team in 6 months, without anyone working more than 8 hours per day. Ever.  So, what do we need to change?”  If they see it as a reasonable challenge, they often get more creative.

13. Is a public impediment list useful?  Ans: Definitely!

14. Why is a public impediment list useful?  Ans: Many reasons. Here are my favorite three reasons.
a. By seeing everything on the list, Team members can know when it is useful to add things to the list.
b. Seeing the order; Team members can know when it is useful to give input on changing the priorities (and when it is wasteful).
c. Everyone, including the SM himself (herself) knows what the SM is working on.  The top impediment!
d. It’s hard for the SM to continuously work on impediments unless he has a list of impediments to work on.
e. It’s refreshing to tell the truth to ourselves.

 

« « When would I not want to do Scrum? || At first, when Scrum and when Waterfall? » »