Part 2: Agile Project Leadership

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:

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

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.

I am not comparing agile methods to alternative medicine, instead I’m just pointing out that zealots who fail to acknowledge alternative views can do a lot to damage their profession. As proponents of agile methods, I believe we can make a stronger case for agile by acknowledging strengths of traditional approaches and explaining how agile can help common challenges, rather than by dismissing traditional techniques.

Encouraged by other recommendations, I visited a different chiropractor and received great benefit. He did not attempt to undermine traditional medicine, instead he explained how he might be able to help and we took it from there. My symptoms got worse before they got better, but I stuck with it since his explanations seemed reasonable. My “conversion” moment came when he also relieved some additional injuries I had been suffering with for many years.

I do not think I am alone in appreciating a considered approach. Most of the people I deal with in the business community are smart, conscientious professionals who are looking for successful projects. Yet, we see the actions of zealots and as a believer it is easy to be caught up in their damaging behaviour.

The following list outlines some common examples of how biased thinking can undermine the value of agile methods and offers some advice to ambassadors of agile methods for avoiding these pitfalls.

Running down the PMI, PMPs and the PMBOK