Autonomous Scrum Teams are like powerful responsibility magnets
They pull in 4 key responsibilities.
Autonomous. Self-organizing. Self-managing. When I hear these words, it reminds me of a magnet — a magnet for attracting responsibility.
Scrum requires this responsibility magnet to be powerful. To deliver a working product, Scrum Teams pull all responsibilities into their force field. Take this excerpt from The Scrum Guide:
“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
The Guide is not bashful in its target model for Scrum Teams. It applies no half-measures. Scrum Teams are to own everything on the lead time spectrum from concept to cash.
Pulling all responsibilities into the team seems simple at first. But it is far from simple. The hard part hits when we realize our current culture has built high specialization. All at once, team autonomy can seem like a tall mountain to climb.
I’ll address later how we can approach scaling this mountain. But first, let’s discuss the key responsibility pulls you need to build team autonomy. My experience shows four we need to consider.
1–Pull down: Management and direction
The best way to show you are serious about building autonomy is to pull management down to the team. Scrum defines the Scrum Team around this concept.
They (Scrum Teams) are also self-managing, meaning they internally decide who does what, when, and how.
— The 2020 Scrum Guide
Self-managing teams solve problems on their own. They manage how they deliver product Increments to meet their customer needs.
This is a shift from the traditional role of management to direct and control a team. We make this shift because directing a team on how to work, when to work, and what to work on strips it of control.
This shift requires a manager to become an Agile leader. An Agile leader supports teams, removing obstacles, coaching new skills, and enabling success. X and Y management theory from social psychologist Douglas McGregor demonstrates this shift well.
Theory X has tight command and control where management directs a team. This crafts a stagnant culture with limited innovation. Teams in this culture wait for those in control to tell them what to do.
But Theory Y pulls management to the team. Managers support rather than direct teams — feeding empowerment like oxygen to a fire. This style of management enables growth by creating a safe place for teams to figure things out.
Most folks don’t characterize themselves as needing Theory X management control; their internal drive is fed by the Theory Y style. As McGregor says, Theory X makes workers feel like, “a cog in the wheel.” Managing as if teams need top-down control to be productive is a big misunderstanding of what motivates teams.
Agile leaders build autonomy. Top-down management and control sap it away.
So pull management down to be owned by the team and flip managers down to act as a support layer for the team. Then, sit back, and watch autonomy shine.
2–Pull right: Strategy, research, and design
Output-driven feature factories result when you isolate teams from strategy, design, and customers. If not careful, we can fall into this trap.
Feature factories emerge when we have a separate team figure out what to build and how to design it. In this mode, an upstream team engages with stakeholders and customers. This team creates specifications and throws them over the wall for a Scrum Team to deliver. The result: a robot team following a recipe, disconnected from its customers and with no input to the solution.
But for those of us who dare to connect teams with stakeholders and customers, magic awaits. Teams are closest to the work, and they know what works and what doesn’t. Plus, when you have all team minds contributing to the solution you get a rich tapestry of ideas.
A team involved from discovery to delivery has steadfast meaning and purpose. Having a purpose is a critical building block for high team engagement.
“I think people get satisfaction from living for a cause that’s greater than themselves. They want to leave an imprint.” — Daniel Pink
An engaged team is self-driven to build the “right” thing. Don’t miss the power of pulling strategy, design, and customer empathy right into the team.
3–Pull up: Lower levels of architecture
Cross-functional teams. T-shaped team members.¹ Paint-drip people.² Comb-shaped team members.³ Full-stack developers. Vertical slice ownership. All these terms speak to a team’s capability to deliver a working product on its own.
Imagine a team only capable to deliver the front-end layer of the architecture. It must rely on a services team to deliver a service. The services team might depend on a data team to construct a data model.
When a team depends on other teams, it can’t own a feature end-to-end. Each team has its specialization and none can deliver customer value on its own. Absence of control results in delays, wasteful coordination, avoidable rework, and late learning.
Mastery of craft when developing a product is not isolated to a single layer of the architecture. Rather, mastery is about collaborating as a diverse team to build a working product feature.
A working feature does not result from a layer of the architecture. We produce a working feature with an integrated vertical slice through all layers. A vertical slice targets learning. A slice through all layers aims to enhance the user experience or refactor the underlying architecture.
Pulling all layers of architecture up into the team allows the team to deliver working features without hand-offs. And teams find this high level of control over their work to be refreshing and motivational.
Getting things working and done on your own beats waiting in line for another team’s help any day.
4–Pull left: Testing and other downstream activities
The term Shift left has been in common use in Agile circles for some time. I remember someone once saying to me, “When things don’t go right, shift left.”
Shift left concerns where a team sits in a typical waterfall delivery model. In traditional methods, teams hand off code downstream for testing, deployment, and support. When shifting left, a team pulls these activities left into the sphere of the team.
Building the product “right” takes on new meaning when downstream activities get pulled left. When a team owns testing, deployment, and support, it has the motivation to build in quality from the start.
This quality mindset drives an intolerance for defects in all team members. Quality assurance takes precedence over quality control; prevention becomes a priority over detection.
Teams who are successful in pulling downstream activites left will move with quick, easy grace. They don’t have piles of unverified code, stacks of defects, or queues of support tickets to slow them down.
Owning its product end-to-end makes a team stronger.
How does all this come together?
When it comes to pulling these four responsibilities into the team, the size of the change is daunting across an organization. I mentioned earlier I have a way to approach this mountain of change. Let’s discuss how I have seen it work.
We could try to do all four pulls to all teams in an organization at once. But this is too much change for us to consider in one large move. The blast radius is too scary. And the risk freezes us in our tracks.
Another approach could apply one responsibility pull at a time to all Scrum Teams. But this often fails because many external dependencies remain in the other responsibilities not applied. These remaining dependencies tend to outweigh any control gained by the applied responsibility.
There is a better way: limit the experiment by applying all four responsibility pulls to one team at first. This minimizes the change chaos. And it allows you to prove the model as a whole at a smaller scale.
When one team succeeds, it becomes a model for others. Proof with one team reduces doubt, increases courage, and builds momentum.
Scrum Teams are magnets for responsibility. When one team proves it can own a product end-to-end, it becomes a strong magnet. Its strength also attracts other teams to try. I find it ironic how this parallels the process to build a stronger magnet.
How do you make a stronger magnet?
Place your weak magnet next to a much stronger magnet. This will realign the electrons in the weaker magnet. To do this, hit the weaker magnet with the larger, much stronger magnet.
A team successful in pulling all these responsibilities won’t actually hit the other teams. But the striking autonomy of one team will provide a compelling example to other teams who are skeptical. Proof the model can work will hit against mental obstacles in other teams.
When other teams and management see the model work, my experience shows they gain the courage to give it a try.
Build your strong team magnet
Scrum Teams are unstoppable when true autonomy takes hold.
Be deliberate about pulling responsibility to the team. Autonomous teams are like strong responsibility magnets. They are:
- Autonomous and self-managing with the support of Agile leaders
- Motivated to solve for a purpose, strategy, and customer they intimately understand
- Capable of building complete, working product features with their own hands
- Responsible for customer delivery, testing, and support
The journey may be daunting to build autonomous teams across an organization. But approaching this task one team at a time makes it manageable. One team’s success builds momentum and courage for other teams to try.
Let me leave you with one parting piece of advice based on my experience. Being controlling is the the main thing to avoid when building autonomous teams. Controlling a team weakens the autonomy responsibility magnet, rendering it useless.
So let go, and see how strong the responsibility magnets of your teams can become.
For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.
Related Posts
Read related posts to this one from the author below:
References
- “The hunt is on for the Renaissance Man of computing,” in The Independent, David Guest, September 17, 1991.
- “Paint Drip People”, facebook.com, Kent Beck
- “Building success in the future of work: T-shaped, Pi-shaped, and Comb-shaped skills,” rossdawson.com, Ross Dawson
