An introduction to Agile Project Leadership – Part 1
Update on PMI Dinner Talk ‘Agile Project Leadership”

An introduction to Agile Project Leadership – Part 2

Pmi_apln_logos_1 In Part 1 I explored the humanistic side of leadership and two leadership practices:
1. Modeling desired behaviour
2. Creating and communicating a vision

In this post I will explain three more practices:
3. Enable others to act
4. Willingness to challenge the status quo
5. Encouraging each other

And wrap up discussion of the presentation “Agile Project Leadership” I will be delivering tomorrow evening.

3) Enable others to act – We need to foster collaboration by building trust and strengthen others by sharing power. When we have a trusting work place people can be more productive since people need not fear reprisal or ridicule if they make a mistake. I visualize it like this, if you need one hand to cover your rear it only leaves one hand free to work. When we can create an open, forgiving work environment, without the need to CYA, people are much more productive.

We can do this by setting an example. Admit mistakes publicly to the team, show people it is good to learn and move on. Hold information sessions to share knowledge, we want an abundant mentality to information not a scarcity based model where people protect knowledge. Ask the team searching questions such as:

  • Do you have what you need?
  • Where do you think we are vulnerable?
  • Where are we not meeting goals?

Get the team in on risk management and the things that the traditional project manager has to worry about individually. Not only will people feel valued for being consulted, but a slew of valuable input will be created.

Task boards are a great way of sharing power and enabling others to act. By switching from Gantt charts to task boards and getting team members to select tasks for the next iteration based on their ability, passion, and capacity better planning will occur.


Having team members select work themselves creates more ownership for the task than if it were just assigned. Also, with this typically happening in a team setting, it also creates a form of social contract where people will work hard to fulfil since pride is high and the work was selected in the presence of peers.

4) Willingness to Challenge the Status Quo – We need to continually search for innovative ways to change, grow and improve. We do this by experimenting and taking risks by constantly generating small wins and learning from mistakes. Agile methods have the well established concept of iteration retrospectives and adaptation of process, but this is new for many traditional project managers.

On software projects, where the true requirements are uncertain and/or the technology is new, we need to regularly review what is working and what we can change to get better. At an iteration review session we can ask the team:

1) What went well?
2) Where do we have opportunities for improvement?
3) Recommendations for the next iteration?

For question 2, I used to ask “what did not go well?”, but later realized that for some people this is too confrontational and we get more suggestions and input if it is reworded as opportunities for improvement, so hey, “opportunities” they are.

Another tool we can use is an Action Wheel. Drawn on a white board the quadrants of a wheel are labelled: “Do More Of”, “Do Less Of”, “Start Doing”, “Stop Doing” as shown below:


Action_wheel_eg Then canvas the team for entries and record them in the relevant quadrants. It is similar to the three questions, but appeals better to visual thinkers and can sometimes generate additional insights when responses to the usual three questions has dried up.

It is important that we collect and leverage these lessons learned throughout the project. Traditional project management has the concept of lessons learned at the end of a project, but this is frankly too little, too late. We should capitalize on improvements as they emerge to get the benefits on our current project. Plus, asking people more frequently reduces the chances of items being forgotten. Asking people to think back over the last 2-4 weeks will yield better information than asking them to cast their minds back 9 months to the requirements gathering phase of a traditional project and recall what went well and where we could improve.

Regular review is not confined to the agile domain. The Toyota production system emphasises the concept of “Hansei” which means reflection or review. Toyota employees regularly make time to look back and see how things are working, they think and reflect on how things can be improved. Likewise, After Action Reviews (AARs) are commonplace in the military where the team looks back and analyses events when returning to base. To create a learning organization reviews are a critical activity that should be scheduled into any endeavour.

“The Army’s After Action Review (AAR) is arguably one of the most successful organizational learning methods yet devised” – Peter Senge

Expect most insights and improvements to come from the team rather than external consultants or books. Much is written about Toyota’s capacity to innovate, but nearly all of it comes from the incorporation of many small internal suggestions. In “The Elegant Solution: Toyota's Formula for Mastering Innovation” author Mathew May describes how Toyota implements over 1 million employee suggestions per year, that is about 3000 per working day, a truly staggering number.

Suggestions are graded and then tried in small, controlled environments before wider roll-out. On agile projects this is equivalent to trying something for one iteration. Only then if things still look promising are they adopted on a wider scale. This follows the Scientific Method, of Plan-Do-Study-Act, popularized by Edwards Demming and sometimes called the Demming Wheel.
Obviously not all suggestions or new approaches will be successful, but given the limited impact of a small, short trial, even unsuccessful approaches can bring useful learnings. The key point is to continue to experiment, take small risks and capitalize on successes.

“When my employees make mistakes trying to improve something, I give them a round of applause.”     - Jim Read, The Read Corporation

5) Encouraging each other – We should recognize contributions from the team by showing appreciation for individual excellence. We also need to celebrate the values and victories of progress by creating a spirit of community. The knowledge workers on software projects are largely driven by morale, since visible and tangible inventory of work is small. Put another way, people can not easily see the progress they are making so we need to remind them and thank when they are delivering exceptional business value.

In fact saying a sincere “thank you” to a team member must be one of the most cost effective yet under utilized productivity tools available. We can spend thousands of dollars on team building exercises, fancy chairs, or off-site strategy sessions, and get far less return for our investment than the 20 seconds or so of time it takes to find a deserving recipient and thank them for their hard work. A justified and heartfelt “thank you” even as succinct as “Thank you for doing X, it has meant that Y is possible/achieved, and I am very grateful for your contribution” can do wonders for a team member and spread a ripple of self esteem and motivation out through the team. Giving praise does not weaken a leader’s position of power, it reinforces it and strengthens the desired behaviour traits we discussed in Part 1.

Treating staff as volunteers is another useful way to regarding the team. When we work with volunteer groups our primary recognition and motivation tool is thanks. When you think about it, all staff are volunteers anyway, all that paying them does is pretty much guarantee that they will turn up for work. Once there, their contribution varies on the spectrum (we have seen before), anywhere from a net drain to a huge value add.


By recognizing contributions and encouraging commitment we gain tools to help draw people to the right-hand side of the spectrum.

We also need to celebrate achievements frequently. It is little use thinking we should save any kind of team celebration until the end of the project when all the work is done, because if you wait until then your chances of completing successfully are slim. Recognition, celebrations and thanks are momentum building exercises; they are needed throughout a project to build the energy required to break through barriers and obstacles that might otherwise stop a drained team.

“Ceremonies, celebrations, and rituals are not about the event. They’re about touching the hearts and souls of every employee.”  - Victoria Sandvig, Charles Schwab

The PMI talk tomorrow
I plan on wrapping up my talk with two pitfalls to avoid, “Mismatched motivators” and “Not enough structure” and end the presentation with a collection links to APLN resources for people to get more information.

Some of this material was taken from the Leadership course I am building for Quadrus and I am looking forward to getting a sense of how it is received. Is it just touchy-feely fluff, or useful information for improving performance? By this time tomorrow I should have a better sense for peoples reactions to it.


The comments to this entry are closed.