An impediment is anything that is slowing down the Team. (The Scrum Team)
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 soon. (I do typically recommend a simple risk log for each Scrum team -- but that is an add-on to Scrum, not part of the bare framework of Scrum.)
Anything.
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.
Some people say that blockers and impediments are different. I say no. 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.
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 ScrumMaster to manage (on behalf of the Team). And the SM should always be driving the top impediment to completion. (To some mitigation, where it is no longer #1, and something else becomes the #1 impediment.)
Some types of impediments:
It turns out that usually each Team will feel improvement as soon as the agile adoption is 'complete'. Hence, agile adoption gets on the same list. (This maybe 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 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 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.
8. Who decides which is the Top impediment? Ans: Ideally, the Team. Certainly, it is form 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. Although for the bigger impediments addressed in the Retrospective, the SM should force the Team to agree to the ordering of the Top few impediments. Which still might change by the next day.
9. In prioritizing the impediments, what kinds 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 benefits 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, not without coaching, usually. We recommend giving the Team a 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. By seeing the ordering, Team members can know when it is useful to give input on changing the priorities (and when it is only wasteful).
c. Everyone, including the SM himself (herself) knows what the SM is working on. The top impediment!
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 soon. (I do typically recommend a simple risk log for each Scrum team -- but that is an add-on to Scrum, not part of the bare framework of Scrum.)
Anything.
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.
Some people say that blockers and impediments are different. I say no. 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.
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 ScrumMaster to manage (on behalf of the Team). And the SM should always be driving the top impediment to completion. (To some mitigation, where it is no longer #1, and something else becomes the #1 impediment.)
Some types of impediments:
- Blockers (for a user story)
- People issues
- Technical issues
- Lack of knowledge
- 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)
- Business or customer issues
- Culture and waterfall attitudes
- Impediments to faster Scrum/Agile adoption
- Etc Etc
It turns out that usually each Team will feel improvement as soon as the agile adoption is 'complete'. Hence, agile adoption gets on the same list. (This maybe 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 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 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.
8. Who decides which is the Top impediment? Ans: Ideally, the Team. Certainly, it is form 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. Although for the bigger impediments addressed in the Retrospective, the SM should force the Team to agree to the ordering of the Top few impediments. Which still might change by the next day.
9. In prioritizing the impediments, what kinds 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 benefits 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, not without coaching, usually. We recommend giving the Team a 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. By seeing the ordering, Team members can know when it is useful to give input on changing the priorities (and when it is only wasteful).
c. Everyone, including the SM himself (herself) knows what the SM is working on. The top impediment!
No comments:
Post a Comment