Sound familiar?

It is all about the Scrum team. Feature teams. Every team needs a PO! Self-organizing team. Team activities/rituals. Help the team. Serve the team! Protect the team. Focus locally! Be a shit umbrella!In this post I’m going to argue that we shouldn’t focus on “The Teams”, until the conditions for effective teams are in place.

Most Agile methodologies/frameworks focus myopically on “the teams” (front-line teams of individual contributors). Meanwhile, organizational dysfunctions (those causing 80% of the drag)

persist. This is not for lack of warning. Scrum calls out the need for independent teams explicitly:

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.…but somehow this is not considered a pre-requisite for “doing Scrum”.

In practice, certain roles — Scrum Master, for example — actually see their job as “protecting” the team from these realities and resolving them on the side.

We don’t want our developers worrying too much about this. We need them in a bubble. We need them focusing on delivering value to realize the promise of all this. Continuous improvement is the job of the [manager] and the [manager] to work this out behind the scenes.We hire human load balancers (aka project managers, program managers, managers ) to address dependencies between teams. We hire Scrum Masters to “remove blockers and impediments” (beg other teams to do things) while The Team works dutifully on delivering value and playing Scrum. We hire massively complex scaling frameworks, release train managers, and even more managers…to “coordinate the work of hundreds of developers”. The end result? Teams remain torn and hobbled. In theory they have support, but they have their hands tied by dependencies, handoffs, and layers of “supporting” management.

Here’s the problem…

If you have 20 teams that are struggling with a web of dependencies, handoffs, and constraints…. then no amount of assigning the teams a Product Owner and Scrum Master, pretending they “own a product”, running standups and retrospectives, and giving them their own whiteboard, will really move the needle. The reality is that you have a 150 person “team”. You’ve got to deal with that.

Why do we start at the team level? It is easier, and does not rock the boat! Teams are malleable. And in many cases the organization has created a convenient narrative that the teams were/are “the problem”. This is rarely the case. Ask any coach working in the business. Team challenges are a symptom of “the problem”. They (the coaches) rarely get to attack the root causes that sit outside the teams.

And those layers of management — those connective roles meant to solve the problem — somehow (for some reason?) never seem to move on and reimagine their roles. Just as you expect, they form kingdoms where they remain indispensable. The end result is that the teams don’t become any more autonomous and self-organizing. The organization never realizes its potential.

In my mind, this is one of the biggest (if not the biggest) problem when it comes to truly becoming more agile in a deep, lasting way. We start with what is easy, but don’t ever get around to changing what is hard. The teams are always to blame for not adopting [the way], when it is impossible to adopt the way. They barely have a moment to even address continuous improvement.

The dreamland utopia of “The Business” and “The Developers / The Teams” just working it out over mugs of coffee … is ultimately unfeasible in any org — with >1 teams — that simply tries to graft something like Scrum on to their existing structures, dependencies, and project culture.

So …. wild thought:

Forget about Agile and Scrum on the team level. Start with the org. Visualize the work as it is really happening … with all the gnarly dependencies. Have 150 person stand ups if that is the true size of the team. Have 150 people vote up the blockers that really matter, and swarm to fix those blockers. Face the mess head on, iterate, and improve. Rapidly rotate and reform teams to dynamically address the biggest blockers. Don’t hire human load balancers to preserve the status quo. Focus on DevOps, tooling, infrastructure, and unraveling the political bureaucracy that over-burdens and overutilizes the teams.

Will these meetings be harder? Yes. But that is reality. You can’t hide.

When you have autonomous, self-organizing teams … then introduce Scrum. Until then, use program-level / business level Kanban to see things as they are and work it out.

This is the hard decision we tend to back away from. Make it!