Can commitment be a bad thing?

We know that commitment is essential in Scrum – but commitment to what? We also know all about commitment based planning. Both of these are good things, but when does incorrect application of the term commitment drive negative behaviour?

Recently I worked with an offshore delivery team because the client was convinced they weren’t getting value for money – although they could not quantify this. It did not take long to identify that the root cause was around the usage of the word commitment and fear of failure. There were a number of bad smells about the relationship that was driving negative behaviour. Here are a few:

• The contract demanded a minimum number of story points per sprint (with penalties if these were not achieved) but nobody knew what a story point meant.
• The contract demanded an increase in the number of points delivered per sprint.
• The contract demanded that stories were estimated (in points) in advance of being prioritised by an estimation team (not the team that would be doing the work).

Ok, ok it was not all about the contract but this doesn’t sound like a great place to start. On to the team. A huge emphasis was placed on commitment and commitment based planning. The biggest ceremony on the calendar was the commitment meeting where the team committed to the client what would be delivered in the current sprint. They also spent the first THREE DAYS of every sprint on task breakdown and hourly estimates. That’s right, 3 full days where zero value was delivered. The commitment meeting happened after this. The client meticulously took notes and recorded the task based estimates. They had access to Rally and wanted to ensure that they were getting maximum value for money by comparing actuals to estimates so they could use this information to beat up the vendor at the end of the sprint. Hmmm – so now we’re measuring estimation accuracy. If that’s all you want its easy. All you need to do is pad your estimates and stop working when you are done (because everyone knows under estimation and over estimation are equally bad). And that’s where the fear of failure came in. This was clearly evident in that every time an impediment was encountered the first action of the team was to use it as a negotiation point to reduce their commitment – sometime even before work began. The most extreme example of this I saw was a team trying to reduce their commitment because of a traffic jam which meant everybody was late for work on a particular day (I kid you not).

For completeness:

• It was unheard of that a team should exceed its commitment
• It was very rare that a team actually met its commitment (impediments as the reason)
• If a story was cancelled another was never picked up, conversely if a late story was added or a story proved more complicated than expected they were lightning fast when it came to dropping a similar (or higher) value story.

My first tack was to suggest to the delivery manager that we replaced the word commitment with planning. Fairly obvious but its ok to aim high when you’re planning and to adjust your plan. Failure to meet your commitment is, on the other hand, a very bad thing. If we don’t make them commit what incentive do they have to deliver what they said! Yup – he clearly gets this whole agile thing.

Time for drastic measures. Here’s what we did.

Firstly I made a personal commitment to the delivery manager that I could increase the velocity of the two teams working on the project in question by 50% in 2 (4 week) sprints. I explained that I could do a report highlighting the issues I encountered and providing recommendations or he could trust me to do as I chose with the teams, of course I also committed to keeping him informed of what I was doing and seek his approval. He was happy to agree to this, and also agreed that it was ok to break their own procedural rules.

The first sprint in the graphs below was the baseline and velocity achieved reflected the historical trend. During this iteration I provided coaching on relative sizing, planning, backlog grooming and pro-active use of sprint burn down chart. We did not change anything in this sprint which was prior to my personal commitment.

In the second sprint we followed the existing estimation process and commitment ritual. Once this was complete we re-estimated all of the stories in the sprint backlog using a completely different scale. This was deliberate so that the team would not be hung up on the original commitment or on comparisons to other teams who were not part of this project. (That’s right – the vendor and client used metrics to compare team performances against each other – just another bad smell). The team (and client) then agreed that we would completely ignore the commitment and plan using weekly timeboxes. Changing the sprint duration was something we could not do but we treated each of these timeboxes as a sprint in its own right: i.e stories must be done within the timebox and we would only plan one week at a time (ignoring the full sprint commitment).

The results of this sprint were so encouraging that I was able to go to the client project manager (who knew what we were doing) and persuade her that for the next sprint we would not provide task level estimates. We still did these but did not provide the details for the ritual post sprint witch hunt. She also agreed that we drop the commitment ritual. She and the PO were naturally invited to our planning meetings. It should be mentioned that the lady in question was a committed waterfall PM and very public and vocal about her dislike of anything agile. I have a collage of quotes in my office at home and in pride of place is the post it with [her name] really likes waterfall  - elicited in the what did we learn section of our first retrospective. By this time we had worked our way through the backlog and estimated it using our own scale.

I could spend a lot of time describing the results – instead I’ll just show you the graph

So only two points to mention:

• Story points on the graphs are using the companies standard scale and not the teams (these were estimated outside of the team) so are comparable
• My assignment was as an agile coach, working within the teams as a BA, so other practices were changed and / or introduced along the way.