How to support self-organization as a manager (and how not to)
In my previous article I wrote about some striggles common to forming agile teams and how to deal with those. I’d like to follow-up on that topic because there’s more to it, especially for managers.
Self-organization in principles
Imagine a department with a dozen or so agile teams and a bunch of Product Owners. These PO’s are working with a product portfolio which gives them insight in a single line of priorities and all the expected outcome for a coming months. Of course new priorities are coming in often and the PO’s are thus busy reordering their portfolio items.
So far so good, isn’t it?
Now of course the expected outcomes need to be created in order of priority. That’s where the teams come in. And that’s also where the trouble starts. More about that in a minute.
Let’s first agree on two basic agile principle written in the Manifesto for Agile Software Development:
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The best architectures, requirements, and designs emerge from self-organizing teams.
Yes, I repeat myself from my previous article. For a reason, because these principles need to be understood, especially if your “agile transformation” is causing you some headache.
Now back to the expected outcome which is to be created. Let’s assume all existing priorities in the portfolio are being worked on by the teams. Suddenly a new priority comes in, shaking things up. Now what?
We EXPECT initiative from the teams. We EXPECT that they self-organize to give the new priority its proper place on the portfolio and among the teams. But that’s just NOT happening all the time. And then, as a manager, your hands start itching. And from there, everything agile goes down the drain.
Let’s first look at what NOT to do as a manager and then find a better alternative.
What NOT to do as a manager
What often happens is that one or more line managers start talking among themselves about the recources or the capacity they need to get a new priority analyzed.
Let’s identify all the bad stuff in this one sentence:
- Line managers are often doing this instead of Product Owners, which makes us doubt whether PO’s are even owning their products.
- They talk among themselves instead of immediately involving the people who usually do the work and would probably know a lot about the priority at hand.
- They talk about resources and capacity, which makes us believe that they see people as pawns that should be moved around.
- To get the priority analyzed, which is not a bad thing in itself, but the though behind it is often that you need individuals to make sense of what the priority actually encompasses instead of that also being a team responsibility.
So these line managers select some people they believe can do the analysis stuff. These people are then pulled away from their teams, leaving those teams crippled for a while and often unable to live up to their commitments for the iteration.
The next step after the analysis is done is to see if the new work to be done can be given to a team. Given, instead of a team pulling the work in. Evangelic agilists are now shivering. Personally, I regard giving work to teams as a lesser evil, even though I am shaking while confessing that. It’s still evil!
But it gets worse.
If it occurs that the new work cannot be given to an existing team (or teams), then…some managers tend to TEAR UP existing teams and create a new temporary team, dedicated to deliver the new priority. Without involving the team members of the affected teams much. And IF they get involved, they usually seem to have not much more choice than to admit that there is no other choice than to form a new team.
And then the new team quickly starts blasting away on the new priority. The affected teams are however left licking their wounds. Unable to live up to their commitments they throw transparency in the bin. At the end of their iteration they make a merry demo of all the work they could do and never mention the stuff they could not. Then they retreat, puzzled about how the heck they will ever be able to do their next work with lesser brains and skills AND unchanged expectations about productivity!
You can imagine that repeated scenario’s like these wear people out and make them wish to leave. And to their defence: I am often amazed how loyal people are to their abusing environments by staying around, despite all the harsh complaining which is going on!
The underlying cause at work here is both a lack of trust managers have in their people AND a serious lack of knowledge about (or disregard for) agile principles.
As a manager, you should now start to understand why Jeff Sutherland and other agile proponents often state that management is the number 1 impediment to agile change. And why clever people like Barry Overeem publish about Zombie Scrum.
But there is hope: you are not a moron! So read on.
What to do as a manager?
You can start by making sure alle the teams understand what self-organization means to your organization. What responsibilities which used to be in the hands of line management are now in the hands of the teams? Which mandates but also obligations come hence?
A team that doesn’t understand what is expected from them with regard to self-organization will act either confused or reluctant. They were always brainwashed to be told what to do, weren’t they? So start a dialog with them and create new agreements together. Basically that means that the team comes up with solutions, both with respect to outcome AND how to organize to create those outcomes. When teams get used to doing that, they can advance towards taking responsibility for identifying problems and even setting priorities.
During this MAJOR adventure, teams will run into typical challenges like:
- A new priority cannot be pulled in by an existing team because no team has all the required knowledge, skills or authorizations.
- A new priority can be given to a specific team, but then that team has all the urgent stuff while other teams work on lower prios.
In the first challenge, the team can still accept the challenge as long as they up their game at the same time. They need to also make a priority of quickly acquiring new knowledge, skill and authorizations. You can support them in that. The result will be that a stronger, more capable, more mature team is created.
In the second challenge, apparently one specific team has the appropriate knowledge, skills, authorizations. The quick and easy way would be to overburden that team by having them do the work for the new priority. Alternatively another, less capable, team could pick it up while bing assisted by the more capable team. Then the benefits mentioned in the previous example would also be harvested.
Take this in mind: working in an agile way often REQUIRES you to make team learning a priority. Your organization will only be more agile (i.e. adaptive) if the people who work there also become more agile.
But there’s something else you have to take into account. Sometimes, the way teams are currently organized just isn’t the best possble way. Sometimes the teams will be challenged to reform and build new teams. That’s also unavoidable while playing the agile game. So as a manager you can motivate the teams to find alternative structures instead of creating them yourself. Just tell them that they have the freedom to reorganize and be amazed at what happens next!
Summarized, as a manager you are very clear about the expectations concerning self-organization, you and the teams create agreements around those expectations, and you continuously assist and challenge the teams in organizing themselves, stepping out of the way everytime you see an attempt at learning.
This may not be easy stuff. I don’t expect you to succeed at once. So keep reflecting on what you do (and especially: don’t do) as a manager.
Just remember: you can do it, because you are not a moron!
Directive management as a last resort?
There are some situations which give you the opportunity to revert to directiveness and control. Here they are, from most to lesser evil:
- You intend to sabotage your organisation in order to protect your self-interest.
- You desire a command and control environment and love to shove people around having the freedom to do so from your superiors.
- The organization you work for has no need for much agility and everybody is fine with that.
- When, in particular cases, immediate results are of utmost importance and there is chaos.
- Your employees prove not to be able to self-organize after serious attempts in which case and for the sake of urgency and company survival you take over this time, but make sure the case is thoroughly reflected on with everyone involved afterwards.
I find situations 3 to 5 plausible. You too, because you’re not a moron.
As a manager, it is essential that you know your options. You should both know and understand the principles behind agile and decide if you want them. If you are unsure how to apply these principles, start experimenting. Don’t hesitate to ask for help. Because it can be tough as a cookie.
For closure I give you a hint on two management behaviours for helping teams self-organize and grow in maturity, all from careful observation in the past years:
- Be visible and available for the teams. You aren’t always needed, but when you are, be there.
- Once in a while ask the teams what they need. You won’t always get an immediate answer. Wait for it and then follow up on their eventual answer.
It works miracles.