Last week, I had an interesting conversation with one of the development teams I’m working with right now. A few weeks prior, we had gone through a story mapping and iteration planning exercise, and I was coming back to coach them through their first review and retrospective. The team had delivered a good amount of what they signed up for, but like many teams delivering their first sprint, they didn’t get everything done.
At one point during the retrospective, we learned that several team members had taken on additional work that wasn’t supposed to be part of the sprint. The work hadn’t been brought to the team, wasn’t written as a story card, wasn’t visible on the story board, and certainly wasn’t a shared commitment amongst all the team members. While we were discussing the impact the unplanned work had on the sprint, one of the team members said “but Mike, what did it matter? The work just had to get done.”
Interesting insight… the work just had to get done. I asked the question… what happened to the work we agreed HAD to get done during sprint planning? It didn’t get done, did it? What about all of this unplanned work, did it actually get done? Well come to find out, it didn’t get done either. As a matter of fact, our QA folks didn’t even know the new work was coming. So I challenged them, if the work HAD to get done, why didn’t you get it done? It didn’t get done because they ran out of time.
But you told me the work HAD to get done… why didn’t you do it?
The reality was that the work didn’t really have to get done… otherwise it probably would have gotten done. The reality was that the team either couldn’t say no, or didn’t know how to say no. Lot’s of companies are in a situation where the only SLA that’s meaningful is ‘right now’. The teams are so unpredictable, everything has to be done immediately… it is safer to say ‘yes’ (and not deliver) than to tell the business ‘no’. The irony is that the work doesn’t actually get done immediately… the team just has to agree they’ll try.
In the absence of a predictable delivery cadence… this is almost an unsolvable problem. If you are using Scrum or XP… that means that you have to have a stable velocity. If you are using Kanban… you have to establish a predictable cycle time. Unless you can reliably tell me when something will get done, everything is always going to have to be done now. Once the team has become predictable, you put the organization in a better position to respect your overall capacity.
Most people can wait a few weeks if they know you’ll actually deliver.