But, It Just Had to Get Done… Didn’t It!?
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.
Comments (14)
Agile Scout
Completely agree with this. Teams (hopefully) need to be able to say “No” or enabled to do so. This builds trust within the organization from the stakeholders down to the development teams.
I think that saying “yes, when” builds more trust than saying “no” ;-)
Derek Huether
Mike, just for the sake of the conversation, were the team members taking on additional work that was to be completed in a future sprint (in the backlog)? Or, were they refactoring code or doing something completely out of scope? Did they do the unplanned work due to inspiration (self motivated) or obligation (feeling pressured by someone)?
I’ve had developers take on extra work for a multitude of reasons. Though I was never able to completely stop it, the more approachable I was (by everyone) and the more I talked to everyone, the less it happened.
Does it matter?
To me… in Scrum… the sprint commitment comes first. If they need to refactor… that should have been planned in the sprint. If they were done, and pulled more work in, that should have been planned as a team event. If they decided to do something due to inspiration, that should have been planned as a team event. If it was a totally new feature introduced by the PO, that should have been planned as a team event.
The only time I might want to break this rule is when we have some percentage of capacity allocated to support. I don’t think of these as team planning activities, but some awareness in the stand-up should be there. The whole reason you do time-boxed sprints is to remove the variability from each time-box so the team can make and meet a commitment, and measure how much they were able to get done.
I’m pretty intolerant of excuses on this ;-) If change is the norm, then I’d consider explicitly going to a Kanban… but this was related to discipline and predictability rather than continuous flow or change. It was a learning experience… and on the whole, not a huge deal (it was Thanksgiving week too, so things were a little crazy ;-)
Said another way… the are all kinds of ways to handle legitimate change in sprint scope. Forcing the work to be planned by the team, and visible on the board, is a way to make sure that we are making intentional and necessary, scope trade-offs. But again, the root of the problem is the now-based SLA due to the team’s inability to make and meet commitments (that’s a generalized comment, not related to the team I’m working with directly)
Michael Dubakov
The real problem is that work was not visualized. They took some hidden tasks and now it is impossible to tell what was going on. If all work is visual, it is less problematic to find the root of the problem. It is technical side, but on human side I personally don’t understand why they took work that was not planned or intended to complete. It is just impolite and breaks team agreement. Such things can’t be tolerated. It may be OK for the first sprint, since all teams fail 1st sprint. But in future sprints it should be avoided completely.
I don’t agree with predictable cycle time in Kanban. You can have stories that varies. You can have a story that have a cycle time = 1 day. And you may have a story with cycle time = 2 weeks. If you speek about predictable cycle time for stories of a similar size – then I agree :)
Yes… predictable cycle time on like-sized-stories. Thanks for the clarification ;-)
Derek Huether
In the end, no, it doesn’t really matter. But for me, looking at this from a 22 line blog post perspective, I wanted to understand what motivated them enough to risk feeling your wrath.
I agree with each of your points. I get your if-thens. I’ve been there. But, as a commenter, I wanted to propose the questions.
I’m glad it was a learning experience for them. Hell hath no fury like a Cottmeyer scorned.
;-) Dude… you are killing me.
The team was awesome. I had a fun day coaching with them, and looking forward to going back. No wrath involved. I just wanted to talk about the concept in general of making commitments and being predictable.
I guess I need to watch my tone of voice replying to comments!
Bob Williams
My IT team doesn’t have any problems telling me ‘no’. Sometimes I wonder if it’s a recording. :-)
Sridhar
Interesting discussions.
Pitching in late – my experience has been that estimating story points is tricky and so the teams either tend to overestimate or underestimate, especially if the application is complex functionally. Another challenge I have seen developers struggle with is dependency, since business processes sometimes are not designed with modularity in mind.
With SOA, it becomes much more complicated, as services are supposed to be independent and self-aware. I always advise Agile teams to take 1 refactoring and 1 defect fixing story in their iteration/scrum scope. As the development progresses, there will always be something that needs change due to downstream work.
Your experience may be different though and it would be good hear them.
Hi Sridhar, thanks for the comment. I’m going to blog around this over the next few days/weeks. Complicated problems and uncertainty are at the root of much of this.
Rich Eaton
I often see this as analogous to cheating on a diet. Doing it once in a while simply erodes and delays progress on the goal. Falling off the wagon frequently means that you are just wasting your time pretending that you are on a diet. In some cases, the rewards for falling off of the diet seem soooo satisfying. I’ve seen business areas that give high accolades for “out-of-process” work while at the same time not really being concerned that the sprint was impacted. What would any reasonable person do in that case? As one scrum trainer told me once, sometimes people like to feel like they are “sticking it to the man” by circumventing the process.