I don’t know what it is lately, but I’m encountering way too many agile teams with challenging work environments. Ones where the dynamics the team are trying to deliver software in are, in a word, crazy. For example:
- Teams are knowingly committing to more work in each sprint than they have capacity for;
- Teams are knowingly committing to specific date targets without having clear velocity data and/or without doing a modicum of agile release planning;
- Teams are ignoring the reality of their environment in (interruptions, multi-tasking, fire-fighting, knowledge & skill level gaps, etc.) and are pretending it won’t happen;
- Teams have shared team members or team members with limited capacity, but they’re ignoring this in their commitments.
This would be like your home builder knowing that it’s going to take them 5 months to build your house because of their teams’ capacity constraints, the complexity of the home, and the seasonal weather constraints, BUT they commit to 2 months anyway.
My reaction to all of these is the same: Are you crazy? And more importantly, how is this approach working out for you?
A Story
I’ll give you one example from about a year ago. I was doing a Product Owner class at a client in the mid west. We were in the middle of the class when this conversation came up:
Class: But Bob, we have a lot of challenges around being asked to do too much. Our sprints are always overcommitted and we seem to be perpetually behind.
Bob: What happens during the sprint that derails things?
Class: Well we get interrupted with bug fixes, customer support issues, and other fires. Usually about 40% of our time is spent doing this. And we don’t have the option of “saying no” to these things. They’re usually customer-centric, very visible, and very important.
Bob: Well, did you plan for it in your Sprints? I.e., commit to roughly 60% of your time being able to work on features and 40% of your time in reserve to handle these unexpected interrupts?
Class: No, we can’t do that. We need to plan our work (feature work) at 100% every Sprint. There no other way we can achieve our overall release roadmap and customer commitments. Even then, we weren’t involved in the planning, so we know it’s not achievable.
Bob: So, let me get this right. You plan at 100% of your capacity…knowing that you’ll be getting a 40% interrupt rate. So you’re over-committing each Sprint at 140% of your overall capacity. Right?
Class: Yes.
Bob: And this pattern has been repeating for?
Class: Over a year since we’ve started with Scrum.
Bob: Have you ever successfully met a Sprint commitment? I.e., delivered at +140% of your plan?
Class: No.
Bob: How is your morale? You seem to be very stressed out about this pattern. I would be too. And have you brought it up in a Sprint Review? Seriously, this is an impediment and the teams need to be more honest with themselves and leadership about their capacity. And then commit to less.
Class: Morale is terrible and we’re exhausted.
Class: We’ve never felt empowered to tell leadership about this, so we’ve sort of “sucked it up” and continued trying. The Product Owners now feel like leadership “can handle the truth” so they’re going to start managing this better in the reviews and communicating real capacity. Keep your fingers crossed for us…
Epilogue
I know that the teams took an immediate and different approach right after the class. They really hadn’t been acknowledging the dynamics of their organization within their agile planning and execution. This went as low as the daily standup in each team and as high as their roadmap plans and release train commitments.
Everyone was working as absolutely hard (and as long) as they could. But they were not making the expected progress from the perspective of their organizational leadership. And the fact that they were “churning” so much was actually slowing them down by:
- Increasing the error rates and rework;
- Creating too many hand-offs and delays;
- Causing a lot of work to get into 90% done syndrome, but never quite get completed;
- Wasting time with too many meetings to talk about getting more done.
So they acknowledged this with their leadership team and began to plan on a more achievable and realistic capacity. In other words, they stopped lying to the business and themselves and were more open, honest, and transparent. This had the effect of engaging the leadership team in making priority-based decisions given the teams actual capacity and trade-offs along the way.
So they at least began on this path. Is it still working for them? I don’t know, but I sure hope so…
Wrapping up
What’s causing this phenomenon out in the “wilds of Agile”?
Well in the story above, the initial feeling across the team was that it was leadership’s fault; that they couldn’t handle the truth or didn’t want to face their real capacity and team constraints. That they instead simply wanted to be agreed with and have their goals met…no matter what!
And I sort of “get that”. But leadership had also asked the team to “go Agile”. And in that effort, the teams had a reasonable measure of responsibility too. Including a responsibility to build high quality products, a responsibility to have courage and be transparent, and a responsibility to stay healthy as a team. So the team was playing an equal part in this unhealthy dance. They were confusing effort, hands waving, keys typing, and chaotic movement with sustainable and healthy results.
Don’t do that!
Again, what causes it? I don’t know exactly. I think its part old habits, part fear, and part sticking our heads in the sand and hoping for the best. I also think its HARD to have these conversations. But I think it’s HARDER to pretend things are going well and waiting to the last minute to face reality. I’d much rather, and I think most leaders would as well, face it one day at a time and as early as possible.
But hey, that’s just me. Stay agile my friends,
Bob.