The Biggest Problem

August 16, 2011

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.

Why is this so important?

First, working product enables the empirical process; it allows the people to inspect.  And, having better information, people can adapt or are certainly more likely to adapt.

One way of saying this is: “In theory there is no difference between theory and practice. In practice, there is.”  In one interpretation: The creative people who work on new products think they have a good idea.  It is only when asked to make it work in the real world that one finds all the problems with the idea.  It is typically in the real world of trial and error that we learn the most.

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 of 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 in the tablet market 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 attack aggressively?

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.

For taking action, none of the following suggestions is a silver bullet, but in my experience as a coach, many teams can benefit from them.  You will have to judge which ones will help your team the most to get all stories ‘done’ by the end of most sprints.

  1. The Team understanding better why working product is so important.
  2. Smaller Product Backlog Items (PBIs) or user stories.  My standard is about 8+ stories in a 2 week Sprint, all of roughly equal size.
  3. “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 in this case (it leads to less work overall).
  4. Do better Release Planning.  The main direct reason this helps is that we have smaller PBIs coming into a Sprint.
  5. Add Enabling Specifications.  Just enough, just in time documentation. So that the implementers don’t spin during the Sprint.
  6. A clear(er) Definition of Done that the Team agrees to and actually follows.
  7. Faster responsiveness by the Product Owner and the business side when questions arise. (< 24 hours is okay; < 1 hour is far better.)
  8. Better Release Plan refactoring. In Release Plan Refactoring, get the stories ready-ready in the prior sprint. Better defined, with acceptance criteria, clear and agreed upon, story pointed, BV points, enabling specs, etc.  And the Team agrees each one is ‘ready’ before Sprint Planning.
  9. 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.
  10. ‘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.
  11. 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.

There is more to say, but these 11 action steps should give most Teams with this problem plenty to improve on.

For most teams, the goal should be for the Team, about 8 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 sometimes it will ‘explode’ on us; so the team cannot always fulfill its commitment made in Sprint Planning.  Also, some teams doing ‘bleeding edge’ work will be less ‘reliable’.

I welcome your comments on better action steps.  Please tell us.

 

« « The Michael Phelps Attitude || Better Retrospectives » »

Posted in: Better Agile, ScrumButt
Tagged: Tags: , , , , ,

One thought on “The Biggest Problem”

  1. Matt

    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.

    ↓

Leave a Reply