Painting The Spots
If you do a little reading about Scrum one of the first things that you learn are the 5 basic values of Scrum:
Courage
Focus
Respect
Committment
Openness
I’d like to examine one of those values that I watched a team wrestle with recently: commitment. These were really great folks. They were bright, energetic, friendly and passionate about the work they were doing. Within the team they took a lot of pride in their ability to “be agile.” They seemed to be doing a lot of good stuff.
However, I was hearing some disconcerting things from other parts of the organization. Other teams characterized this team as flakey. Managers expressed frustration that they didn’t deliver. I wasn’t sure what the story really was. Was it a cultural thing? Was it petty jealousy at work? I really had no idea.
An opportunity came along to do a little coaching with the team in question, so I was eager to find out more. Here’s what I found:
Optimism at the start: So the team said that they were prone to overcommitting to the amount of work they could handle in a sprint. During sprint planning, they would realize the balance of the work was unequal and that there would be team members left idle. So they would take on more “overflow” work to make sure that everyone on the team has something to do during the sprint. It’s great that they were aware of this problem. This pattern of behavior was leading the team to consistently overload their sprints with more work than they could achieve. The team told me that their typical velocity was 27-29 points per sprint. When I asked them what they had committed to in the last sprint, the answer was: 44 points. When I pointed out the obvious discrepancy, they admitted that they had overflow work from the previous sprint that they felt they had to get done. So then I asked them if they were going to deliver on all 44 points. And the survey says: No. The good news? This injury was self-inflicted. The bad news? It didn’t sound like they were entirely convinced they had a serious problem. A pattern of failing to reliably deliver sprint objectives can lead to a crisis of trust with a team’s stakeholders. The stakeholders start to doubt whether or not you will deliver on your sprint commitments. This can be a corrosive influence on the relationship with the very people who are signing the team’s paychecks. The solution? Stop overcommitting. This means that the team has to face some awkward issues about how to manage balancing work within their ranks. These are issues they were able to hide from by overloading the team with work. I got some grudging buy-in at this point, but I could tell that there was still work to be done.
Carry over matter: Since they are overloading the sprint, they are almost guaranteed to have items that are not completed and those get carried into the next sprint. I took the time to point out that this sort of issue is a problem, but you can skate by when you are simply going from sprint to sprint. However, when you are trying to work to a release plan with multiple teams and multiple sprints, then carry over is a total deal breaker. If you are working with other teams and you have a pattern of failing to deliver stories, the other teams are very quickly going to learn that you are not a good partner to work with.
Transparency: So I asked about this because I wasn’t sure what the problem was. Apparently they were concerned that they were being asked to track their time and their tasks in a time tracking tool to a level of detail that was making them uncomfortable. As we talked about it someone said, “I don’t think they trust us…” I could tell that this person was a bit upset by this perceived lack of trust. Of course I put on my Mr. Sensitivity hat and replied…Of course they don’t trust you! You don’t deliver committed work on time!
Well, I don’t think I said it exactly like that, but it was some polite variation on that theme. Now people were upset, and finally my message was getting through. The product owner for the team, gave me loud and vigorous support at this point. You could tell that we had stumbled on a fundamental assumption that people on the team were realizing was dead wrong. The scrum master articulated the invalid assumption for me: The whole purpose of having a sprint goal means that you can achieve the goal without having to deliver specific stories. You focus on the goal rather than the stories. That is an interesting, but completely incorrect interpretation of how commitment works. Apparently much of the team was operating with this model in mind. Once I pointed out that other people were depending on those specific stories being delivered, not some abstract goal, then you could feel the resistance immediately start to evaporate.
The other thing that was a little disturbing about this situation is the blind spot that the team had when working with other teams. They had explained away their inability to deliver as due to their own superior understanding of what it means to ‘be agile.’ No one else understood how awesome they were because the other teams weren’t as agile as they were. Now there is no doubt that they were doing a lot of things right. Like I mentioned in the beginning, they had a lot of good things going on. However, they had managed to paint over the ugly bits of their process without examining them and addressing them. Their ‘agility’ was their excuse for not delivering commitments. This sort of failure is not unusual – I’ve seen it happen in plenty of other teams. Dealing with these sorts of issues is hard for a team to do. Sometimes it takes an outsider to see them and point them out. So be careful about declaring your own agility. Doing so can sometimes hide some ugly spots.
This is What I Do
I provide innovative agile coaching, training, and facilitation to help organizations transform to deliver breakthrough products and performance. I do this by achieving a deep understanding of the business and by enabling the emergence of self-organizing teams and unleashing individual passion.
To learn more about the services that I offer or to arrange for an initial consultation, please see thomasperryllc.com