One of the four value statements from the Agile Manifesto states:
Individuals and interactions over processes and tools.
Two principles supporting the Agile Manifesto are:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
These statements attempt to change the way teams work and interact in an agile environment. These statements also require Leadership to focus on teams in a very different way than the command and control style of traditional methodologies.
This blog is not about iterations, burn-ups, velocity or the other mechanics of agile project management. This is about how to effectively lead a team in a fast paced, constantly changing environment so they can become an effective, productive, self-organizing team.
Let’s just clarify some of the Leadership roles on a software development project.
- Program Manager
- Project Manager
- Iteration Manager or Scrum Master
- Tech Lead
- BA Lead
- Test Lead
- Infrastructure Lead
If you are responsible for folks working together towards a common goal, then I believe you are a Leader. All of the following blog can apply to any leader, but I’m really focusing on the Project Manager and Iteration Manager here. The difference between the two being, that Project Managers are typically outward facing, focusing on stakeholders outside of the core team. The Iteration Manager is typically focused in to the core team. This isn’t necessarily two people, but definitely two focuses.
Teams go through many levels of maturity. Bruce Tuckman describes the four stages of Forming, Storming, Norming and Performing. Patrick Lencioni takes us though the 5 Dysfunctions of a Team. Teams just don’t start day one as a productive, self-organizing team. They go through a process. There are bumps and challenges. The Agile Project Manager and Iteration Managers are responsible for getting the team through these phases with as little pain as possible. Even after a team gets to a mature stage, the slightest change can revert the team to a former, less mature stage. team gets to a mature stage, the slightest change can revert the team to a former, less mature stage.
Here are a couple of recommendations to begin your quest of moving from a traditional command and control management environment towards a more Servant Leadership style.
Don’t go too far to the right!
In the US, the politically ‘right’ believe that there should be as little government as possible for a successful economy. The leadership spectrum noted below reflects leadership styles. And if we head to the far right of this spectrum we see Servant Leadership, a term coined by Robert Greenleaf and advanced by several authors such as Stephen Covey, Peter Block, Peter Senge, Max DePree, Margaret Wheatley, Ken Blanchard.
Some folks think that agile means as little Project Management as possible. Well, that is just not true. Agile software development is very faced paced and in order to accommodate change effectively, it is very disciplined and requires constant attention to the process, the results and the team in order to stay on track. Agile methodologies describe many practices that guide us through the mechanics of building software in an agile fashion. But we have to also address the changes required in leadership style in order to see the benefits we strive for by adopting agile methodologies.
Some new agile PMs take such a strong ‘hands off’ approach that the team struggles to get through the first couple of phases of team maturity and agile appears to fail.
You must find ways to get the team members to know each other, then they can start to trust each other, then they can learn how to communicate, solve problems, have good debates and make decisions. Facilitate and encourage this process throughout the project.
Some techniques for getting folks through the early phases of team maturity are:
- Inception or planning activities
- Informal social events
- Team building events
- Remember the Future activity
- Team Health checks
Do your homework on your team members.
There are many tools out there to understand a person, how they think, how they are motivated, what communication style works best for them, what management style works best for them. Predictive Index, Strengths Finders, Myers Briggs to name a few.
Get to know the people on your team and identify if there might be an outlier. If its clear that you have folks on your team that may be missing the characteristics of a self disciplined individual, then you should take every chance to coach those people as much as you can or make the difficult decision to remove them from the team.
Self disciplined individuals have the following characteristics.
- Accept accountability
- Confront reality through rigorous thinking
- Engage in intense debate/interaction
- Willingly work within a self organizing framework
- Live the values
“How do you make team members trust each other?“ “You trust them first!”
(Quote from Johanna Rothman at Agile 2008.)
Facilitate getting the knowledge about each person out to the entire team. If you care about building good working relationships, then as a team member you should be open to learning as much about your team members as you need to operate effectively.
Learn how to use Collective Wisdom effectively.
There are many decisions to be made and questions to be answered regularly on an agile project. Prioritization of functionality, estimation of requirements, determining how much work a team can get done in an iteration, the definition of done. How do these decisions get made? You are not making decisions unilaterally. You have to learn how to utilize collective wisdom effectively.
What is collective wisdom? James Surowiecki makes the case in his book, The Wisdom of Crowds that under the right conditions a group will most times make a better decision than one expert. What are the right conditions? Surowiecki says:
- Diversity of opinion
- Member independence
- Aggregation of opinions
And how do we accommodate these conditions on an agile team?
- Diversity of opinion
- when all roles participate in writing acceptance criteria
- when developers of different experience levels and backgrounds estimate
- when customers participate daily to direct functionality, prioritize and provide feedback
- Member independence
- By using planning poker for estimation
- By having folks independently write retrospective items before discussing
- By allowing the customer to have their own test environment after the showcase
- Distributed teams often have different thoughts and opinions about process, tools, etc.
- Having regular cross project role based catch-ups will allow for information to be shared in an effective way
- Aggregation of opinions
- Prioritization drivers such as trade-off sliders
In closing, there are many new leadership challenges introduced by the methodology called agile. Project managers and Iteration managers have to take a different approach to leadership on agile projects than on traditional command and control style projects.
Make sure you are facilitating your team through their maturity stages. Identify blockers to building a self-organizing team and resolve them quickly. Monitor your team’s health regularly.
Make sure you know your team members as people and professionals. Understand what their skills and capabilities are as well as their communication style, their cultural background and their personal experiences. Facilitate that understanding throughout the team.
Make sure you understand and seek out opportunities to benefit from collective wisdom without getting stuck on the need for consensus. Sometimes as the PM or IM, you have to make a call.
As part of the Training team at ThoughtWorks Studios, we have drawn from our experience on Agile projects to offer interactive, lab-based workshops such as Agile Project Management and Agile for Executives that seek to enable you to make the most out of Agile with a focus on the business perspective.