Month: October 2020

Autonomy

Autonomy is a topic that is in my mind for a while. How come that in some environments it’s so simple to let it grow and some others are so much struggling with it. The more I think about it, the more I feel it’s about trust or fear of losing position, power, or comfort. And environments with no trust are not places where agile is much successful. In order to allow autonomy in even a small group as a development team, the trust must be there. I’ve seen the companies which were struggling to allow teams to choose their own name. “What if they choose something offending?” Like really? Now if you deal with such low trust, there is no way Scrum can work. I’ve seen organizations where they track when people are in the office and have so many restrictions that their computers become useless. “What if they don’t work and play games? Or not coming to work?” Isn’t that funny? The more restrictions you create, the more time people spend on breaking them or the more demotivated they are. Neither will help you to create successful products.

“Trust is prerequisite, transparency enabler, and purpose of the driving force for autonomy.”

Building trust takes time. Start small, don’t be afraid to be vulnerable. Ask yourself what is the worth thing which can happen. Ask what are those people around you scared  and how can you help them to feel more confident. The second ingredient in the mix is transparency. Being transparent about what needs to be done, what the success looks like, and what are the things we want to avoid is crucial. People learn by doing. Be transparent with the feedback. Perfection is not useful, it’s all about learning from small failures. Finally, the third ingredient in the mix is a purpose. Autonomy without a purpose only creates chaos. The higher the autonomy, the stronger the purpose needs to be to glue it together. To give everyone the same goal, belonging, identity, the reason for why they are there.

Imagine a kid’s camp. The Red group is defending the castle, the Blues are trying the take it over. Kids are naturally forming small autonomous teams, making their own decisions on the fly. They share information as they move forward. They don’t need any detailed instructions, any KPIs, any manager to give them process. All they have is a strong purpose. Your organization is not any different. Trust is a prerequisite, transparency enabler, and purpose of the driving force for autonomy. Building such an environment requires a portion of agile leadership.

ScrumMaster Mind

Great ScrumMasters are patient, can give space and dedicate their time to help other people grow. They are servant leaders and Catalysts. It sounds simple and not conflicting at first look, however, the real disconnect people feel at first, when they came across the role, is often about their ability to let things go. As a ScrumMaster, you are not responsible for the delivery. As a ScrumMaster, you need to let them fail. As a ScrumMaster, you can’t make a decision for them. “But I need to make sure they deliver the Sprint!” people often say with fear in their eyes. “I need to make sure they are efficient!”, “I need to tell them … ”.  Not that quite. Being a ScrumMaster is a very different role than being a Project Manager. They actually can’t be more different from each other. Project Managers are responsible for delivery, they shall manage, make decisions. ScrumMasters are coaches, they help other people to grow. They are facilitators, help the conversation to flow, but don’t interfere with the content. The team is responsible for delivery, the team is responsible for organizing themselves, and the team is also responsible for improving their way of working. ScrumMaster can help them, but not push them. The ultimate goal of the ScrumMaster is to do nothing – or if you wish to build great self-organizing teams.

ScrumMaster builds self-organizing teams

For example, imagine a team, which is super confident that they are going to finish all the parts they planned for that Sprint. In the middle of the Sprint, you can see from the board that they are not in the middle of the work, not even close. They started many items but didn’t finish much. It seems to you that they are not well organized, abandoning problematic tasks and not collaborating. What are you going to do? When I ask this question at the classes, most people feel a strong need to guide the team, tell them how they shall organize, and when we talk about the fact that as a ScrumMasters they have no power to decide for them, they are very uncomfortable. “But I have to make sure they deliver it”, they say. “I can’t let it go, what my manager would think?”.  And it’s very hard for them to accept the fact they can’t push them. They can try their best to coach the team and show them what can possibly happen, but if they are still confident and don’t see that as a risk, eventually you need to let it go and let them fail. Failing one Sprint is not a problem. At the end of each sprint, there is a Retrospective and that’s the time where you can help them reflect on what just happened and come up with action steps on what are we going to the differently next time, so this will never happen again. ScrumMasters are not responsible for Sprint delivery (the team is), ScrumMasters are not responsible for the product delivery (that’s Product Owners job), but they are responsible for making the team self-organized and improving. It’s not that hard as it looks. Try to let things go next time, failure is a good thing. Fail fast, learn fast.