Join the Mastering Agility community!
Photo by Icons8 Team on Unsplash
“From the first Sprint on, this Scrum Team is self-managing! You’ll be deciding why, what, and how to work. There won’t be anybody telling you what to do exactly any, no more micro-management!” said Peter, the CEO of a high-tech organization. Just like that, autonomy was given and no one was telling what the people in the Eagles team would work on.
The Eagles themselves felt relieved. The micro-management of the past is finally over. Still, John comes by regularly and asks questions about what they’re doing. The former Program Manager drops in whenever he feels like it to see what the team is up to. He would love to see the team realize his input in the Product Backlog. Rather yesterday than today.
The problem with his input in the backlog is that is not related to the Product Goals of the Eagles. Yet, they’re keeping it in there to please John and keep him from starting a rant again on how important it is to do that.
The next Sprint Planning, Shruti, Product Owner of the Eagles, brought the Product Backlog Items related to John forward as being very important this Sprint. “I know this is not what we want to be working on, but let’s pick it up. He’ll be pleased with the work done. It’s good to have him on our side.” Still hesitant, the developers pull in the PBIs and put them on the Product Backlog.
As the Sprint progresses, Shruti adds more to the Sprint Backlog. “We don’t even have the time to finish the items that were there in the first place. How do you expect us to get all of this done?” one of the developers noted. “Well,” she replied “you’re self-managing. You guys decide how to get it done. I just need it by the end of the Sprint, as we really need it for the Sprint Goal.”
They had no real clue how to get things done. This was openly discussed during the Daily Scrums. Progress toward the Sprint Goal was hampered due to the items for John, as well as the new ones. Shruti got word of this and asked a befriended colleague from another team to fix the issues they were facing.
There was a huge separation within the Eagles. This came out during the Sprint Review. It appeared that the items were done on the outside, but when asked about the maintainability and state under the hood, it appeared that corner-cutting was used to get the features out. Technical debt was all-around.
Needless to say, this made both Shruti and John unpleasantly surprised. After a mud-throwing contest, the team took the situation into the Sprint Retrospective. And I’ll tell you what happened next.
This may seem like a very exaggerated story. Can’t be real, right? Well, it is. I came into this team (with different names, of course). Almost at the end of the Sprint. It would have been easy to point to a lack of trust here, but that wasn’t the case. After having done a proper analysis of the situation (also by involving John, on request of the team), I found two things happened here that happens more often than not:
- No one has a clue what self-management means
- Autonomy is not given from one day to the other
I have seen organizations that literally placed posters on the wall, summarizing the expectations of all the new roles and accountabilities that came with the agile transformation. Hundreds and hundreds of people were sent to courses so that everyone understands the framework. Highly intelligent people, on another level when it comes to technical expertise, but failed to discuss and align on the concept of what it means to be self-managing. Where the team felt like John’s behavior was absolutely horrendous, and Shruti was wrong for putting new work into the Sprint Backlog, both John and Shruti felt they were doing the best given the situation.
If they would have started out by discussing what self-management means to them, and what is expected of each other, they probably wouldn’t have been into such a severe split. This brings me to the second point.
Autonomy is not given overnight. It’s the same with teaching my kids to ride a bike. What would happen when I would give my three-year-old a brand new bicycle, expecting them to ride off on their own on the spot? They would instantly dumble over, crying in panic, and me getting upset about the scratches on the expensive, brand new bike.
Foto door Tatiana Syrikova via Pexels
I’m almost positive you feel this hypothetical situation is rather stupid. And you’re right, it is stupid. But is the exact same thing a lot of organizations are doing when transitioning to self-managing teams. “Enjoy being self-managing from now on, good luck!” And off they go. It doesn’t work like that. Becoming self-management, like learning to ride a bike, require training wheels.
Self-management is like a stool
Professional Scrum Trainer Simon Reindl and Stephanie Ockerman wrote a great book called Mastering Professional Scrum. Besides that it is a great book in general, I really love the clear picture they describe on self-management.
They describe it as a three-legged stool, where effective self-management (or self-organization as called by the Scrum guide) requires all three legs to stay balanced. The three legs are:
- Shared Goals
- Boundaries
- Clear accountabilities
As can be seen in the scenario at the beginning of this article, the balance was completely lost. There were no shared goals, as the Eagles didn’t understand the connection between John’s wishes and the Product and Sprint Goals, yet did it anyway. Shruti pushing in work and getting someone else to fix the issues of the developers shows that the boundaries were not understood. And everyone was working with mixed accountabilities. It was a mess.
Start by getting on the same page
My twins are currently learning to ride their bikes (literally, as I’m typing this article, I can hear them in the backyard). They understand that they need training wheels, that gradually will be elevated to make it a bit more difficult. But that gradual approach is part of empiricism as well and helps them find their balance. They know only then they can move on to the removal of their training wheels. They understand because we discussed it, multiple times. They also noticed it when they hopped on their older brother’s bike and got scared of falling over.
By no means think that I feel Scrum Teams are like kids with training wheels. But Scrum Teams and the organization around them need a gradual, guided approach, too. Start by getting on the same page, and understanding those shared goals, boundaries, and accountabilities. Set yourself up for success, instead of failure. Make sure that everyone involved understands what is expected from them in the beginning, and consistently inspect and adapt to improve it.
I’m curious to learn how self-management looks in your organization. Have you ever discussed it?