Quick Tips To Improve The Autonomy Of Your Scrum Team
Spark small and incremental change in your Scrum team, with our community-driven actionable quick tips
All quick tips are included in the Scrum Team Survey. With this free product, Scrum teams can diagnose themselves with an extensive, scientifically validated survey and receive detailed results and evidence-based feedback upon completion. Give it a try, and receive quick tips for each of the 30 topics the survey contains!
For some time, we hosted a quick tips workshop for our Patreon community. Its purpose was to use all our personal experiences and creativity, to identify quick tips around the topics of the Scrum Team Survey. It always resulted in many great ideas, insights, and actionable quick tips. In a series of blog posts, we share the outcome of these workshops with you. This article is focused on quick tips to improve the autonomy of your Scrum team.
So, what are quick tips?
You can compare quick tips with 15% Solutions. This is a Liberating Structure intended to trigger big change by starting small. A 15% Solution is any first step that you can take without approval or resources from others and that is entirely within your discretion to act. It is something that you can start right now if you want to. It might not be the ultimate solution, but it’s definitely a good first step in the right direction. Or, as Kent Beck puts it in his book Extreme Programming Explained: “under the right conditions, people and teams can take many small steps so rapidly that they appear to be leaping.”
Within the Scrum Team Survey, we call these 15% Solutions “Quick Tips”. The purpose of quick tips is to spark small and incremental change in your Scrum team. Small steps in the right direction to remove impediments, improve collaboration, manage risk, and deliver value sooner. A good quick tip is short & concise, actionable & specific, bold & courageous, easy to use & try.
What we mean with team autonomy
Research shows that Scrum teams with high autonomy are also more likely to improve their process continuously and to work more closely with stakeholders. By ‘autonomy’, we mean that teams can make decisions about how to do their work, in what order, and by whom. Indirectly, autonomy contributes to how effective Scrum teams can be. And this makes sense. Teams with more autonomy also feel more ownership over their process and their product.
Many organizations still limit the autonomy of Scrum teams and effectively cripple their potential success. For example, Scrum teams may not be given control over what goes on the Product Backlog and in what order. Or decisions about team composition, task assignment, and velocity are entirely outside of their control. Finally, forcing a work method or framework (like Scrum) onto teams is also a sign of low autonomy.
So, the more freedom your team has to shape its work, the more capable they will be to improve their process, remove impediments and deliver more value. High autonomy is at the root of successful Scrum teams. It means that teams are free from rigid and strict external rules, policies, and constraints. And also that they are free from internal skill-based constraints in how members can work together on tasks.
An interesting personal experience
In my work as a Scrum Master, I’ve gathered numerous experiences with autonomous Scrum teams. Some were positive, many mostly not. The less positive experiences always started the same. Management declared Scrum the holy grail with autonomous teams at its heart. To give autonomy a boost from the start, obviously, everyone had a say in team composition, right? Wrong! Many times, management composed the teams, reshuffled “resources” until it seemed most optimal, and announced the new teams at a large kickoff meeting. It’s no surprise that autonomous teams never really took root at these organizations.
Luckily, I’ve also encountered some positive experiences. One of my best experiences was right at the start of my Scrum career. About a decade ago I worked as a Scrum Master at a web agency. If you want to full story, check the article “My Journey As A Scrum Master” that I wrote a couple of years ago. In my first years, we experimented with Scrum, but it was mostly cherry-picking. In hindsight, it had many similarities to Zombie Scrum. We were going through the motions of Scrum, had most parts of Scrum in place, but somehow it never really took off. Slowly, the excitement we felt at the start of our Scrum experiment faded away, and we started to wonder what this “Scrum fuzz” was all about…
It changed when we discovered how Scrum teams should be self-managing, cross-functional, and autonomous. So far, this was definitely not in place in our teams. Although the company was quite small, there was a lot of bureaucracy and processes in place that crippled the teams. Many decisions that impacted the team, were made by people from the supporting organization: team composition, tooling, processes, performance reviews, finances, budgeting, progress reports, customer acquisition, etc. As a result, the teams were mostly focused on writing code. For some developers, this was perfectly fine, yet the majority of my team started to see the negative consequences. We faced many dependencies because we had to ask for permission for almost everything. This not only slowed us down but also resulted in frustration. Mostly because we felt perfectly capable of making decisions on our own.
So, when another project was going in the wrong direction again (unhappy customer, low quality, scope creep, and budget tripled), we started a small revolution. We wanted to be truly autonomous, meaning: we fully decide how we do the work, in what order, and by whom. But also: from now on, we wanted to have sales conversations with potential new clients. We wanted to be fully responsible for our own team composition. Meaning: we did the “hiring & firing”. And we also wanted to do the performance reviews as a team. Over time, we even became responsible for our own profit & loss. We became a mini-company within the larger company.
This small-scale organizational revolution became one of my fondest memories. And I have to say: management fully supported us. This doesn’t mean we didn’t have many tough conversations, but everyone noticed the potential and also saw the enthusiasm and excitement of the team members AND our customers. Customers enjoyed talking to our developers, and not only with our sales department. And most developers liked to talk to customers as well :)
Eventually, the biggest change that autonomous teams triggered was the feeling of shared ownership. A strong feeling of ownership, responsibility, and accountability towards the products we’re building for our customers. But also the responsibility to resolve conflict within our team ourselves. Previously, we would have asked the HR department to help out, or simply ignore the problem. But because we’ve selected our own team members, we also stepped up to resolve any conflict. And this feeling of responsibility impacted all areas: product quality, customer & team happiness, profit & loss, and the way we worked as a team. We still faced many impediments, but instead of being dependent on others to resolve them, we had the autonomy to act quickly and find solutions to the toughest challenges. And the feeling of having the freedom to act without the need to ask for permission first is awesome! It might sound weird, but we finally were treated as “adults”…
In total, I’ve worked for 5 years at this company. We started heading in the direction of autonomous teams after about 2 years, so the short summary I gave above is actually a 3-year period. And once I left the organization they took “autonomous teams” to a completely new level. In a good way! Just check some of the articles the company wrote about it (in Dutch). If you move in the direction of autonomous teams, you’re never really “done”. There’s always something to improve. But luckily, if you really have autonomous teams, you don’t have to do it alone, that’s the primary advantage of truly autonomous teams :)
Quick tips to improve team autonomy
So, now that you know what team autonomy means and how it can benefit your Scrum team, what are quick tips to start improving? This is where you can benefit from the experience, knowledge, and ideas of our community. Together we identified the following 5 quick tips:
- Quick tip #1: In the next Sprint, identify 1 area where you’d love more autonomy as a team and ask a responsible manager to create that space with you.
- Quick tip #2: In the next Sprint, make 1 decision that would normally be taken by someone outside the team. Inform this person afterward.
- Quick tip #3: In the next Sprint, at least 2 team members pair on at least 2 substantial items on the Sprint Backlog — regardless of skills.
- Quick tip #4: Make a pledge with your team that all job interviews for new team members are attended by at least two team members from now on
- Quick tip #5: Make an agreement with the team that the next time a stakeholder brings in a new request, the Developers decide what to do with it.
Closing
In this blog post, we shared 5 quick tips to improve the autonomy of your Scrum team. These quick tips might not be the ultimate solution, but they will help you spark small and incremental change in your Scrum team. If autonomy is something you want to improve with your team, consider trying one of our quick tips. Also, make sure to read the previous articles we wrote about self-management and cross-functionality. Together, they help you improve team autonomy on an, even more, deeper level. We’re also eager to learn from your experiences, so if you have other ideas: feel free to share them. Let’s learn and grow, together!