Mar 10, 2008

A Commitment is not a Guarantee

When using Scrum for the development process a team begins an iteration by sitting with the Product Owner and working through which items from the product backlog they can complete by the end of the iteration.  The team then makes a commitment to deliver on those items and gets to work.

What sometimes happens is that a Product Owner will assume that the commitment by the team is a guarantee that everything will be delivered.  Even if they know better, when a team has delivered a number of successful iterations in a row it's very easy for a Product Owner to lapse into this thinking.

The commitment by the team is a statement that they are devoting themselves to getting all of the items in the sprint backlog "done".  But it is not a guarantee - a guarantee is a statement along the lines of "if we don't do this then we will ..." with some sort of remediation or punishment clause at the end.  So if a team guaranteed delivery then they would also be saying that there are potential remedies for not delivering, but what could those be? Docking of pay and/or working overtime? There's not much else is there? And the thing is, by the time an iteration concludes there isn't any more time left - overtime just eats into the next iteration and overtime itself doesn't resolve every problem, almost always creates new ones and gives birth to a tired team that makes more mistakes and takes longer to get things done.

So what does a Scrum Master do when a team has been unable to deliver on all their items?

First - do a retrospective and see what lessons can be learned.  Did the team work cohesively? Were there external dependencies that impeded the team? Did anyone on the team slack off?  Were there things forgotten during estimation? Unseen gotcha's? Ask the team - learn what you can, and take those lessons into the next iteration.

Second - talk to the Product Owner and adjust expectations for following iterations.  Explain to the Product Owner what went wrong, and what changes the team are making to address them and then reduce the teams velocity.

Note: punishing a team for missing a delivery is generally counter-productive.  They'll already feel bad enough for missing the target so don't pour more salt on the wound as it can be a demotivator.  Talk to the team, keep encouraging them, find out what happened and see if you can help them make the changes they want to.  Help them learn their lessons, communicate with the Product Owner and stakeholders about expectations and move on with delivering on the next iteration.

1 comment:

  1. Great advice Richard, especially the last note. Very applicable to my current client.

    ReplyDelete