I am often brought in to coach teams who are new to agile software development. Frequently, I find they want to map new Agile ways of working onto their old work paradigm. They want to understand who's in charge of what under the new order, who has authority, and how they will be ranked against each other. I try to resist being dragged into naming which role should be in charge. Here's why I dig my heels in.
When we look at work to be done from the perspective of which role should pick up the task, we miss one of the fundamental principles of Agile development, self-organization. Focusing in on standard roles from a methodology distracts our team from thinking about what we need to do in the unique situation we face. If all the work to be done is neatly divided up into his job or her job then we start to lose sight of our shared goal and teamwork suffers.
The hard part is that it feels natural for us to specialize, to get good at one skill and for others to rely on our special abilities (and to rely on them to do their special thing too). Specializing comes at a high price. We have less need to talk to each other, as we each work away in our own separate worlds. But this approach soon starts to falter when we attempt to deliver software every few weeks. Unless, the balance of work remains steady, bottlenecks soon appear, where some team members are overloaded and others are waiting for them. To break this cycle, the team needs to reflect how they approach the work. Encourage team members slow down and learn how to take on a wider range of tasks and rethink them. They'll need to get creative to work this out.
When we have a person on the team whose job it is to do certain stuff, the rest of the team only notices how important doing that stuff is when they can't keep up. That's often the hardest time to slow down and rethink things because work is piling up and it's difficult to get people to think rationally when they're under pressure. So if specializing causes bottlenecks then defining a fixed set of roles on the team can suffer from the same problems? Well, maybe so. I notice that where a team starts with strict role definitions, it takes longer to break out of those roles later on. If a team insists they must have roles then I encourage them to work through the responsibilities of these roles as a group so they are understood by everyone on the team. And, ideally, more than one person on the team knows how to play that role.
Now we get to why presenting a team with an agile "person in charge" role bugs me. Setting up an agile as a system that depends on a "leader" role clashes with the principle of self-organization. Every team member needs to engage with decisions rather than deferring them to management and passively becoming dependent on the leader.
I first heard from George Dinwiddie that "self-organizing" can be broken out into self-managing and self-directing behaviors. However I'd like to see team members become comfortable to do both. To manage their own work and also to contribute to product vision and direction. It's wonderful to see team members get truly engaged, dreaming up new product features and selling them to their customers.
I believe that all team members need to grow their capability for leadership rather than working under a single leader. This does take time and coaching rather than leadership. I now believe that the job of leaders is to establish the conditions for teams to flourish. They place fireworks in a sandbox, light the blue touch paper and then step well back.
When we look at work to be done from the perspective of which role should pick up the task, we miss one of the fundamental principles of Agile development, self-organization. Focusing in on standard roles from a methodology distracts our team from thinking about what we need to do in the unique situation we face. If all the work to be done is neatly divided up into his job or her job then we start to lose sight of our shared goal and teamwork suffers.
The hard part is that it feels natural for us to specialize, to get good at one skill and for others to rely on our special abilities (and to rely on them to do their special thing too). Specializing comes at a high price. We have less need to talk to each other, as we each work away in our own separate worlds. But this approach soon starts to falter when we attempt to deliver software every few weeks. Unless, the balance of work remains steady, bottlenecks soon appear, where some team members are overloaded and others are waiting for them. To break this cycle, the team needs to reflect how they approach the work. Encourage team members slow down and learn how to take on a wider range of tasks and rethink them. They'll need to get creative to work this out.
When we have a person on the team whose job it is to do certain stuff, the rest of the team only notices how important doing that stuff is when they can't keep up. That's often the hardest time to slow down and rethink things because work is piling up and it's difficult to get people to think rationally when they're under pressure. So if specializing causes bottlenecks then defining a fixed set of roles on the team can suffer from the same problems? Well, maybe so. I notice that where a team starts with strict role definitions, it takes longer to break out of those roles later on. If a team insists they must have roles then I encourage them to work through the responsibilities of these roles as a group so they are understood by everyone on the team. And, ideally, more than one person on the team knows how to play that role.
Now we get to why presenting a team with an agile "person in charge" role bugs me. Setting up an agile as a system that depends on a "leader" role clashes with the principle of self-organization. Every team member needs to engage with decisions rather than deferring them to management and passively becoming dependent on the leader.
I first heard from George Dinwiddie that "self-organizing" can be broken out into self-managing and self-directing behaviors. However I'd like to see team members become comfortable to do both. To manage their own work and also to contribute to product vision and direction. It's wonderful to see team members get truly engaged, dreaming up new product features and selling them to their customers.
I believe that all team members need to grow their capability for leadership rather than working under a single leader. This does take time and coaching rather than leadership. I now believe that the job of leaders is to establish the conditions for teams to flourish. They place fireworks in a sandbox, light the blue touch paper and then step well back.
It takes a special kind of leader that foster collaboration and self-organization.
I do think leaders are needed on Agile teams, they just need to be the right kind. Why? People need direction and guidance when asked to do new behaviors and practices. Otherwise, you have the great big: "Yeaaa! We're Agile! [pause] What are we supposed to do now? I don't know...you finish that spec (test case, design doc, use cases...whatever)?" Leadership is there to help people learn how to get from on set of behaviors to the next.
Posted by: Carlton Nettleton | 08 October 2009 at 12:14 AM
I'm not arguing against support for the team through an agile transition. The special kind of leadership you are talking about has a big overlap with coaching, a coach can provide guidance in how teams get started with new ways of working. However, the key is to grow leadership skills in all team members rather than concentrating them in one individual.
Posted by: Rachel Davies | 08 October 2009 at 10:18 AM
I guess you are talking about roles on a development team here, and I fully agree -- leadership will emerge as appropriate. But in the bigger picture I believe there is a need for two specific types of leadership: servant leadership and vision leadership.
Servant Leader: Good development teams need people to field the crap, to navigate the corporate landscape and initiate change. This is not "doing things for" this is creating an environment for personal growth.
Vision Leaders: These people are few and far between, and when you have one to work with, listen to this person! There is nothing wrong with being led by ideas, but be careful, it is the ideas that matter, the principles, not the personalities.
Posted by: Tobias Mayer | 09 October 2009 at 12:51 PM
You are touching the subject of is a self-organizing team self-created. I believe it can be.
I also believe that a team can become self-organizing quicker with the right management/leadership/coaching.
If you look at the team phases (Forming-Storming-Norming-Performing) a team needs a lot of directions in the forming phase.
So depending on where your team is, they might need a more formal decision in the beginning.
I do agree that all teams will have certain things they think they can not change.
With the right amount of leadership they wil quickly realize they can change anything.
I'm convinced that showing them there are no limits (when they are ready) helps more then "forcing" them to decide on things they are not ready for yet.
As always things vary (depend on the situation and team).
Posted by: YvesHanoulle | 09 October 2009 at 12:54 PM
The team coaching "role" should be shared as much as possible. If a team is using Scrum, I do believe this role falls more on the Scrum Master than anyone else, but everyone should do their part in being transparent, setting direction consistent with the business objectives, getting things done, and holding each other accountable.
Posted by: Paul Boos | 09 October 2009 at 01:04 PM
The word [should] associates with ethical judgement.
A judgement is a form of belief and beliefs filter reality.
So in practical terms, if you tell someone what they 'should' do, you are associating with a held belief about what they 'should' do.
That belief might filter you perceptions, preventing you from observing objective reality and/or "what infomation the environment is offering now."
This cognitive bias has broad applicablity to all kinds of coaching.
Dan Mezick
Posted by: Dan Mezick | 22 October 2009 at 06:50 PM