Agile Team Leader or Project Manager?
A recent post on infoq has prompted this follow up. There are many folk who believe in the ideal of a self managing team – one that follows Agile practices rigorously and delivers a constant stream of benefit to the business. I’m not one of those people. I believe that a certain amount of specialisation leads to people having a higher sense of responsibility for what they do. If it is always the team that decides, and always the team that succeeds or fails then the role of the individual is diminished.
There will always be people on teams who need some form of individual recognition or responsibility to perform at their best. This is especially true of larger teams where many different personalities make up the mix – it may be possible to get a small group of people to truly work together but it is much harder to do when more people are involved. A team’s culture or set of ethics become diluted with each new person that comes on board.
When Agile projects fail it is often because the team has lost touch with broader business needs, or acts “inwardly”. They may be being efficient and they may be improving internal efficiency but this will eventually come unstuck unless someone is paying attention to, and actively fostering, the macro or external view. To do this effectively, someone needs to be “responsible” for it. The team may well cope for a time, and indeed if the team is made up of extremely experienced, articulate, broad-minded individuals then they may well handle many “external” situations that arise. Most teams, however, are made up of people with a variety of skills, specialisations and experience. People are chosen for their expertise.
It’s true that an Agile project manager should not make all the decisions. They should not “command and control” the day to day running of the project. Agile gives us a very good, very empowering set of tools that allow the team to do this themselves. Agile does not always give us a good set of tools for dealing with vagaries and political to-ing and fro-ing. Logic is not always the answer.
In his post on infoq, Mike Bria provides a summary of Patrick Wilson-Welsh’s post on this subject. His summary of the characteristics of the “new leadership” is as follows (and I’m reproducing it because I like it a lot and think it should be circulated):
- Continuous Leadership
Understanding the team’s place in the organization’s goals, being a single point of leadership (for the team) and accountability (to stakeholders), building a “safe container” for the team to work within, growing trust and respect between team and stakeholders, and continuously improving team cohesion. - Continuous Planning
Ensuring the team become increasing capable of meeting their own established commitments, ensuring everything remain “big and visible”, manages metrics, making “the plan the bad guy” (as opposed to the people), and ensuring the “plan changes with demand/supply”. - Continuous Execution
“Monitoring/managing team velocity/throughput”, securing resources, removing and escalating blockages. Ultimately, “keeping flow, momentum and focus in the team”. - Continuous Risk Reduction
Identifying risks and making their “potential impacts big and visible to the right people”, ensuring risk reduction occurs, and quantifying risk management effectiveness. - Continuous Improvement (Agile Coaching)
Driving the “improvement of the overall Definition of Done”, sensing and drawing attention to performance breakdowns, facilitating team improvements in the right areas, and helping the team learn emerging practices from outside itself.
I don’t agree with everything here. I think this slightly overstates the role of the team in deciding who should take ownership of the roles defined. It also implies that it is one person and this may not be the case. Having said that, this is one of the best distillations I’ve seen that describes a relevant set of objective for an “Agile Team Leader”.
Importantly, Patrick Wilson-Welsh acknowledges that the Agile Team Lead may delegate to a technical lead or some other specialist. I’d go further and suggest that the team will work better if this is the norm rather than the exception, especially where the team has strong experience.
This is an important line of thinking as Agile becomes more mainstream and is adopted by more organisations. It may, however, be uncomfortable for many traditional project managers and not everyone will want to adapt in this way.
I think that Patrick is beginning to articulate what we have probably “assumed” about leading an Agile team for a long time. The combination of the traits or responsibilities he has defined are as good an articulation of what I think the role should be (and I agree with him that it is essentially 1 role). One of the issues I think we’ve faced with Agile is that we know this role needs to be filled (even if it is by the “many” as some suggest) but haven’t had a place to hang it. Traditional (waterfall) PM’s often have trouble finding their place in an Agile team. Dev’s / Testers / BA’s often have trouble transitioning to the kind of leadership being described here. I’ve known highly qualified scrum masters who tend to focus internally and this can be blinkered and end up hindering a team.
I think this kind of thinking brings us closer to understanding the kind of “leadership” that an Agile team needs, and does nothing to detract from the internal leadership shown by experienced and/or committed folk within the team (leading by example or leading from within **UPDATE** I’ve just found the term “Servant Leadership” that describes this idea very well). I think there are differences between what Patrick describes and typical scrum masters although I haven’t quite found the way to articulate that – I suspect it lies in the areas of Leadership, Risk Reduction and (sometimes) continuous improvement sections identified. This view matches what I would aspire to be (as a current “Manager” of Agile teams).
