Jeff Sutherland believes that the biggest problem with Scrum teams, the most frequently encountered problem, is that the Team does not have working product at the end of the Sprint.
This is fundamental to Scrum. And, in my view, fundamental to being successful.
So, why is this so important?
The first thing I want to say is that working product enables the empirical process, it allows the people to inspect. And, having much better information, the people can then adapt far better, or are certainly more likely to.
One way of saying this is: "In theory there is no difference between theory and practice. In practice, there is." Which, in one interpretation means: The creative people who work on new products always think they have a good idea. It is only when one asks them to make it work in the real world, that one finds out all the problems with the ideas. It is typically in the real world of trial and error that we learn the most.
Looked at another way, working product enables us to measure progress far more effectively than, say, the documentation deliverables that were used in the waterfall days. One reason it is important to measure progress is to get a better prediction on when the product can be put in the field. A very important business decision (and very important to all customers, who always want it yesterday). As we can see plainly in the tablet market just now.
Going a bit further, it is good if the Team has a better prediction of how many 'stories' it will complete with done-done product. This enables the (mostly Technology) Team to build trust over time with the Business side. Which means the Business side will become more willing to collaborate with Technology to solve the difficult trade-offs in new product development.
Some steps toward fixing the problem
There are other reasons for having working product at the end of each Sprint. But let's now turn to solving the problem. How does your team get better at doing it consistently?
First: are you convinced yet that this problem is important enough to aggressively attack? I hope so, but maybe not. If not, then stop and try to 'smell' how important it is. If you cannot feel the importance, your actions will be ineffective.
None of the following suggestions is a silver bullet, but in our experience as a coach, many teams can benefit from each of them. You will have to judge which ones will help your team the most.
For most teams, the goal should be for the Team, about 9 times out of 10, to fulfill at least the commitment it makes in Sprint Planning to deliver (done-done) X number of PBIs or stories. Note: Our work is difficult to predict and some times it will 'explode' on us; so the team cannot always fulfill its commitment in Sprint Planning. And some teams doing 'bleeding edge' work will be less 'reliable' too.
I welcome your advice on yet better action steps. Please tell us.
This is fundamental to Scrum. And, in my view, fundamental to being successful.
So, why is this so important?
The first thing I want to say is that working product enables the empirical process, it allows the people to inspect. And, having much better information, the people can then adapt far better, or are certainly more likely to.
One way of saying this is: "In theory there is no difference between theory and practice. In practice, there is." Which, in one interpretation means: The creative people who work on new products always think they have a good idea. It is only when one asks them to make it work in the real world, that one finds out all the problems with the ideas. It is typically in the real world of trial and error that we learn the most.
Looked at another way, working product enables us to measure progress far more effectively than, say, the documentation deliverables that were used in the waterfall days. One reason it is important to measure progress is to get a better prediction on when the product can be put in the field. A very important business decision (and very important to all customers, who always want it yesterday). As we can see plainly in the tablet market just now.
Going a bit further, it is good if the Team has a better prediction of how many 'stories' it will complete with done-done product. This enables the (mostly Technology) Team to build trust over time with the Business side. Which means the Business side will become more willing to collaborate with Technology to solve the difficult trade-offs in new product development.
Some steps toward fixing the problem
There are other reasons for having working product at the end of each Sprint. But let's now turn to solving the problem. How does your team get better at doing it consistently?
First: are you convinced yet that this problem is important enough to aggressively attack? I hope so, but maybe not. If not, then stop and try to 'smell' how important it is. If you cannot feel the importance, your actions will be ineffective.
None of the following suggestions is a silver bullet, but in our experience as a coach, many teams can benefit from each of them. You will have to judge which ones will help your team the most.
- The Team understanding better why working product is so important. (See, for example, our comments above.)
- Smaller Product Backlog Items (PBIs) or user stories. My standard is about 8+ stories in a 2 week Sprint, all of roughly equal size.
- "You have to go slow to go fast." One reason: If you understand this principle, then you understand why the Team should invest the time to get to smaller stories. Smaller stories are extra work, but the extra work is worth it.
- Better Release Planning. The main reason this helps is that we have smaller PBIs coming into a Sprint.
- Agile Specifications. Just enough, just in time documentation. So that the implementors don't spin during the Sprint.
- A clear(er) Definition of Done. That the Team agrees to and actually follows.
- Faster responsiveness by the Product Owner and the business side when questions arise. (< 24 hours is ok; < 1 hour is far better)
- Better Release Plan refactoring. In overly simple terms, in Release Plan refactoring, we get the stories ready-ready 'one sprint ahead'. Better defined, acceptance criteria, clear and agreed, story pointed, BV points, agile specs, etc. And the Team agrees each one is 'ready' before Sprint Planning.
- Fixing a host of technical impediments around better configuration management, continuous integration and better automated testing. IMO, the biggest problem in this area is understanding why solving these technical impediments is so important.
- 'Single piece flow.' This is a standard lean idea. In software in a 7 person Scrum team, this typically means no more than 2 stories in process at the same time. Each story is driven to completion, and then, once completed, a new story is put in process. Any exceptions to this are considered serious problems, and are addressed rigorously.
- The Team must (learn to) be realistic about how many Story Points of work it can deliver (done-done) in the Sprint period. I see far too many teams who over-promise every time.
For most teams, the goal should be for the Team, about 9 times out of 10, to fulfill at least the commitment it makes in Sprint Planning to deliver (done-done) X number of PBIs or stories. Note: Our work is difficult to predict and some times it will 'explode' on us; so the team cannot always fulfill its commitment in Sprint Planning. And some teams doing 'bleeding edge' work will be less 'reliable' too.
I welcome your advice on yet better action steps. Please tell us.
1 comment:
Excellent set of tips, thank you for taking the time to list these out. One of the biggest issues I come across in Scrum is the Release Planning misconceptions and readiness. Then of course the Product Owner's readiness and response time. Just to pick out two of the all valid points you have made.
Post a Comment