Self-organization is a fundamental concept in agile software development. The Agile Manifesto includes the principle, “The best architectures, requirements, and designs emerge from self-organizing teams.” Yet a common misconception is that because of this reliance on self-organizing teams, there is little or no role for leaders of agile teams. Nothing could be further from the truth. In The Biology of Business, Philip Anderson refutes this mistaken assumption.
Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.
Self-organizing teams are not free from management control. Management chooses for them what product to build or often chooses who will work on their project, but they are nonetheless self-organizing. Neither are they free from influence. Early references to Scrum were clear about this. In “The New New Product Development Game” from 1986, Takeuchi and Nonaka write that “subtle control is also consistent with the self-organizing character of project teams.”
A Scrum team’s job is to self-organize around the challenges, and within the boundaries and constraints, put in place by management. Management’s job is to come up with appropriate challenges and remove impediments to self-organization. That being said, the fewer constraints or controls put on a team, the better. If leaders overly constrain how a team solves the challenge given to it, self-organization will not occur. The team will shut down; because it has already been told so much about the challenge and how to solve it, it will wait to hear the rest. So how does an agile leader achieve the subtle balance between command and influence?
Suppose you are a ScrumMaster for a team. You’ve noticed that one team member, Jeff, is domineering and no one is willing to stand up to him. This team has self-organized—it has chosen to let Jeff make all key decisions. As the ScrumMaster for this team, though, you recognize that if Jeff continues to make all the decisions on his own it will impede the team’s efforts to improve. You consider having a private conversation with Jeff, but that is unlikely to change much. You contemplate stepping in and overruling some decisions he makes, but if you do it once the team will expect you to continue to do so, which won’t be good.
Then you begin thinking about subtle control and influence. Perhaps you decide to change the team’s dynamics by asking management to add someone new to the team, someone who is likely to stand up to Jeff. Or maybe you suggest to the enterprise architecture team that someone from its group attend key meetings—someone with the experience and background to challenge Jeff. No matter the specific problem, if you see that the team has self-organized in a way that impedes it, it is your responsibility to find a way to agitate, stir up, or otherwise disturb the status quo, so that the team adjusts, hopefully reorganizing in a more productive way.
There is more to leading a self-organizing team than buying pizza and getting out of the way. Leaders influence teams in subtle and indirect ways. It is impossible for a leader to accurately predict how a team will respond to a change, whether that change is a different team composition, new standards of performance, a vicarious selection system, or so on. Leaders do not have all the answers. What they do have is the ability to agitate teams (and the organization itself) toward becoming more agile.
For more details on how leaders can help teams and their organizations grow more agile, see Chapter 12 of Succeeding with Agile.
Great article Mike, this is an area that takes a lot of coaching from mangers/SM and a lot of discussion among the leaders to help each other understand the challenges of self-organization. I try to listen and observe all the time the interactions among the team and bounce ideas of other leaders as to next steps and any ideas we can do to turn up the heat from a simmer to a boil to maybe help change.
Thanks, Derek. Learning to lead a self-organizing team was one of the hardest things for me. Ask anyone who knows me well enough and you’ll discover I’m not a patient person. (“Where’s that waiter? I ordered my drink 30 seconds ago???”) So there were times when I had to “wait” for a team to figure something out and I just wanted to yell “do it this way.” I learned in those cases to silently count in my head: 1, 2, 3,…. It game me something to do and that kept me quiet while the team solved their own problems. (And came up with better solutions than I would have shouted out.)
Great Post Mike,
I recently watched this presentation http://www.infoq.com/presentations/coaching-self-org-teams
by joseph Pelrine and your post crystallised for me what Joseph was saying. Recently I had a situation where a senior team member wanted to be in charge of the solution architecture of the team (he is newish to Scrum) the rest of the team told him that as they were self organising he was not allowed to take charge (i did try to hide me laugh). What I said to him was to go for it but to try and take the team on the journey with him and that by wanting to take the architecture on he was self organising (filling a need based on the environment we had given the team). After reading your article (as per usual) I feel that I could have done better, I would welcome any advice.
Great post addressing one of the most common misconceptions with Agile and Scrum. When project managers ask what they will do when part of an Agile team, it’s as you describe – remove impediments, work with management to prioritize what needs to be done. In many organizations, those two duties are a full-time job.
[...] Cohn a écrit sur son blogue un article aujourd'hui qui donne quelques trucs pour les gestionnaires qui doivent composer avec des équipes [...]
Hi Mike–
Thanks for the links to Joseph Pelrine’s presentation. I will have to watch that as I’m a big fan of his because of the unique perspectives he brings.
When a team member tries to control how the team organizes their work, I will usually either sit back and see how they respond. My hope is that they push back a bit, or if it’s right that the one person do whatever it is, I’m fine with it if the team is. But if I sense that this may not be the right direction and if I sense the team may not yet have reached a point where someone is comfortable bringing it up, I will ask non-threatening questions like, “Are there other approaches that we should consider?” or “This sounds like it might work but before we settle on it as the best, let’s come up with at least 3 alternatives, just so I feel we’ve explored our options.” I want to try to ease the team into those discussions in many cases.
Hi Robert–
I got a great email a few days from a ScrumMaster who had emailed me a month before. Her initial email was something like, “My boss wants me to do nothing but ScrumMaster full-time but it’s not a full-time job. What do I do?” I don’t remember what my advice was but she emailed a few days ago saying how much she now loved being a full-time ScrumMaster and how much she’d found to do. I thought it was a great story. She was one of the best ScrumMasters I’d seen before starting to do it full-time so I’m anxious to see her in action full-time someday. I’ll see if I can talk her into chiming in here now, too.
As a Senior Software Architect at an organization that is primarily waterfall, but moving slowly to agile, this is especially a challenge. At organizations like mine, there may be a strong expectation that certain people are going to fill a particular role. In my case, that role is to create and communicate the changes that will be made to a number of systems. It isn’t usually too difficult to get team members (developers, testers, etc.) to guide or provide input into those design decisions. But the next hurdle is much more arduous to overcome – Getting ALL of the developers and testers to communicate and become self-sufficient at the same time. That is, all of the team members need to be focused on the same project at the same time.
By the way, really looking forward to finishing your book, Mike. I am still in Part I, but it is one of the best agile books I have read. It’s hard to find resources that give really practical advice for agile adoption so it is a pleasure to read.
Terry–
Indeed. These are some of the hardest challenges. People look to senior people or those with big titles for answers—and giving them is part of the job description. But, as I’m sure you know, saying “Here’s your dictate…” and leading them to realize that dictate themselves (and buy into it) are very different. And yes, getting some to do this—not so hard. Getting all to do it–very hard.
Thanks for your kind words on Succeeding with Agile. I appreciate it and am glad you’re enjoying it.
This problem emphasizes the fact that every organization making the agile transformation needs an agile coach present. ScrumMasters may not be enough as they are often labeled with their own history and previous position within the organization (which is another common problem when transforming).
An agile coach could supervise the situation outside. Being able to see and watch how people interact and what are the relations between different roles. This enables swift and neutral interventions when things start to go awry.
Hi Angry Poodle–
An outside perspective can be very helpful. During a lot of my coaching engagements, the boss or whoever brought me in says something like, “I can’t believe it. They listened to you. But that was the same thing I’ve been saying for six months. Grrr.” And we talk about how sometimes a team needs to hear it from outside. Thanks for sharing.
The reason we like to have the team self-organized is that the truth we discovered lately that we can not tell team members what to do. We can not impose the methods or techniques. We rather may coach and inspire. We also can facilitate so that they are focused on their work without disruptions or waiting for external input. Sensitivity with dealing with the team as a human unit with all its non-predictability is a high-valued trait for the team leader. If a powerful member prevails, then, the behaviour of the team is skewed which may not lead to the satisfactory results. I think team training about the rules of engagement and work ethics at the start of the project can help to gain team member commitments on valued behaviours. I suggest that the leader should assume facilitating style which is high in relationship building and low in task assignment. This style coupled with the up-front team training (not on Scrum) would help the leader to establish a campus and direction on team performance. Finally if team members have pride on their craftsmanship, they would self-adapt to improve.
Mike,
I’m reading ‘Succeeding with Agile’ now, and the format is very readable. You write about being a scrum master (and former tech lead) and in meetings you wouldn’t answer their questions and would just start counting, letting the team make decisions instead of contributing (so they don’t rely on you to “lead” them). I agree that’s a useful strategy and I’ve used it (just recently). But is that a policy or just a strategy when needed (when the team needs to muscle up a bit)?
Thanks,
Matthew
Hi Matthew–
It should not be a policy that the ScrumMaster must remain silent. There are obvious examples: “Hey, Mike, you met with the client earlier this week. Do you think they are even slightly flexible on this UI they showed us? I ran into some problems when I started implementing it. Should I bother calling them?”
In my mind, if the team is already very comfortable with agile/Scrum and team members are behaving as you’d expect of such a team, the ScrumMaster can act like any other team member. When I’ve been with such teams I’ve willingly chimed in with “Why don’t we design it this way….” even though I would never say that with other, newer teams. The newer teams would have taken my suggestion as a dictate (“The ScrumMaster has spoken. Let it be so…”)
So, adjust your silence or participation to the maturity of the team.
Mike – thanks for the quick response. I agree wholeheartedly and I’m glad that’s your experience too (I might have read that section of your book too fast).
I’m finding that my strategy applies beyond just me. In meetings “leaders” seem to rise up (which is great) but sometimes the team then steps down (which is horrible). So when I say “I’m not voting on this” or “Don’t look at me, this is *our* problem”, I also find I have to find ways to make sure others who step up don’t start leading the team without letting the team think for themselves. The leader-follower is an interesting dynamic.
Hello All,
I’m responding to a post from Mike on January 7th at 5:18 p.m. I’m the ScrumMaster he’s talking about.
I used to be the ScrumMaster, Office Manger, and HR. The Management Team decided to hire a new person to be Office Manager and HR and put me into a full time ScrumMaster position. At first I was scared to death. After all, I’m working with a mature, self directed team who has been doing Agile for many years now. I didn’t feel at the time that the role of ScrumMaster was a full time job. How was I going to fill my time?
After some very good guidance from my supervisor, I have come to realize that it is indeed a very full time job.
Here is a list of *some* of the things I do, which keeps me very busy.
1. Gather matrix – information about the sprint
2. Chart things on big visible charts – burn down, threads of the sprint – could be a whiteboard)
3. Manually test so things so I’m “in the weeds”, file bugs.
4. Follow up on bugs I find.
5. Talk to story owners throughout the sprint (daily if necessary)
6. Conduct daily Scrums
7. Conduct successful estimating meeting
8. Conduct brainstorming meetings and keep people on pace with developers and story owners (don’t let them wonder into implemntation discussions)
9. Fix impediments that happen during the Scrum.
10. Keep everoyn on track with Agile techniques
11. Find and introduce new ideas – continually find new ideas to improve the team.
12. Communicate, communicate, communicate, with all parties involved.
13. Be the basic babysitter for the whole team and keep it running like a smooth and graceful machine that we know we can do.
The manual testing has been a really good contribution to the team. Once I test something, I can then take screen shots, or use a projector to show the things to the story owners – before the Sprint Review. I often get feedback early and am able to get the developers to make any changes before we release. The story owners seem to like this type of communication and it keeps everyone in the loop.
Lisa
Excellent list, Lisa! Thanks for sharing it and your realization of how full-time being a ScrumMaster can be.
[...] Mike Cohn, auteur de nombreux livres sur l’agilité et membre fondateur de l’Alliance Agile, revient sur le rôle des managers au sein d’une organisation de type agile. Un des principes forts des méthodes agiles est la mise en place d’une équipe auto-organisée, où il n’y a théoriquement plus de chef de projet. Cependant, Mike nous averti qu’une auto-organisation ne veut pas dire les développeurs font tout ce qu’ils veulent. Au contraire, Mike explique que des managers ont tout à fait leur rôle à jouer dans ce type d’organisation. Ainsi, il développe l’idée d’une influence subtile et indirecte des managers sur l’équipe. C’est alors au fur et à mesure des challenges, des échecs et réussites que l’équipe évolue d’elle-même vers l’organisation la plus appropriée. Les managers sont néanmoins là pour poser certaines limites et contraintes. A la fin de son article, Mike nous présente un exemple concret d’un scrum master au prise avec un développeur, qui est un peu trop solitaire, et nous expose comment il pourrait résoudre ce problème de manière subtile. Le scrum master peut être alors vu comme un agitateur au sein de l’équipe pour l’aider à devenir plus agile. Et, c’est là l’un des plus gros challenges d’un scrum master, qui consiste à naviguer entre un subtil mélange de contrôle et d’influence. [...]
[...] The Role of Leaders on a Self-Organizing Team [...]