Try this exercise with your team to identify, overcome, and avoid potential project “gottchas”.

Get the team to write a project obituary; ask them to imagine the project is nearly over and has failed; their job for the next 45 minutes is to describe all the things that went wrong contributing to its eventual demise. Often people who are difficult to engage in regular vision exercises relish the opportunity to list all the things that could go wrong. Perhaps given a slightly pessimistic slant on life, they can generate an exhaustive list of possible, albeit gloomy, outcomes for the project. These might include communication failures that lead to mismatched expectations, vendor delays, team morale issues, etc, anything that could negatively impact the project.

Run the session as you would a brainstorming session with someone in a facilitator role recording the ailments on a white board or via sticky pad notes and prompting submitters for more detail to clarify understanding where required. If you used sticky notes, group related problems under broad categories. Review the lists with the group and then ask people to quietly think through potential solutions to these problems and take a break for 15 minutes.

Then, after the break, solicit solutions (vaccines) to each of the problems (ailments) from the team. Usually there will be more than one suggested solution for each problem so make sure you have plenty of white board space, or wall space if using stickies. Creating solutions for problems is an energising process and often generates many creative and unanticipated suggestions. For example, on a past project, if I had suggested a 10 pin-bowling social with the Finance group I am sure it would have been met with groans of objection from my team, but when they came up with the idea, it had instant approval (it was their idea after all!) and I was happy to oblige and organize it.

The whole obituary idea sounds a little morbid, and there may be instances when it is not appropriate for a team. However, by asking people to consider problems and then how each could be avoided, the team creates a mental image of overcoming likely issues. So then if any occur on the project they already have some sample solutions in mind. As the old saying goes: “forewarned is forearmed” i.e. we will be ready for it.

This exercise is related to the Merlin backwards planning exercise I described earlier and is also used in the Toyota Production System. Toyota used the obituary approach when creating their “Toyota University” program and engaged the team in a larger exercise to create a full report entitled “The University of Toyota calls it Quits; A Requiem for a Noble Concept”. In the book “The Elegant Solution” author Mathew May describes how the article detailed the path to failure. Created as an expose set three years in the future, it described a corporate university that was everything management didn’t want the University of Toyota to be with fat brochures and academic papers. It worked. The university team clarified the main issue that could be their demise: failure to align to around real business needs. The article was a call to arms that set imaginative wheels in motion. The group redrafted the article, not as an obituary, but as a front page story trumpeting the success of the university and created the framework for its success.

So, when next starting a project (or corporate) endeavour consider the obituary exercise. It might be just the tool for giving the naysayer’s their voice and then uniting the team around appropriate risk mitigation and avoidance strategies. I really believe the team has all the best answers; we just need to create opportunities for them to be heard more.

My last two posts outlined a talk I was preparing for the Calgary PMI chapter. The presentation went well, the event was full at 125 people and the audience was very receptive to the message. This was pretty much expected, as nothing was meant to be confrontational. I positioned leadership as the human-centric extension to management that I believe it is. We had some good questions after the talk and I was invited back by the organizers to present at their PMI Conference in November which was a nice endorsement.

(I enjoyed the event, but need to get faster at creating these presentations. I use a lot of graphics and team-room photographs and these currently take me much too long to create, organize and turn into presentations. I keep thinking that I will get quicker as I build up a library of collateral, but every time it takes me days to prepare. I think it’s time to seek some help and I will chat to Ole Jepsen about this when we meet for the APLN planning meeting in Salt Lake. He used to create courseware for a living and apparently has a method or system for created them that saves lots of time – I will see if he can help me.)

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.

On Thursday 25th I will be presenting on “Agile Project Leadership” at the PMI Southern Alberta Chapter. These sessions normally attract a diverse group of project managers from a variety of industries. I am looking forward to the opportunity to spread the word about agile leadership and plug our local Calgary APLN chapter.

Not everyone will be familiar with agile methods so I will quickly run through the W5 (what, why, when, who, where) of agile and then hopefully spend the bulk of my time on the leadership portion of the talk. On trying to create a 5 slide overview of Agile, I stumbled across a nice value proposition summary on the VersionOne web site.

I have seen all the graphs individually previously (Rational have been using the Risk graph for > 8 years), but I was drawn in by the symmetry and clarity of information transmitted by just a few curved lines. I think it is a great summary, looking like bowls and nuts.

After the introduction to Agile, the basic storyline for my presentation goes like this...

The Venn diagram shown here (click on it for a larger view)was created to help explain the context of agile project leadership (shown in orange). It is intended to illustrate the inclusion of elements from the Agile Methods, Leadership Theory and Traditional Project Management domains. The dots within the regions indicate a non-exhaustive list of example topics that fall in that realm. For instance Agile Methods often contain guidance for testing techniques that fall outside the everyday province of agile leadership, while servant leadership is common to Agile leadership and regular leadership theory.

The model is not ideal, you could consider visioning or risk management as part of agile methods and while the activities of agile teams certainly create a guiding vision and mitigate risk early by iterative development. These activities are principle based and do not fully embrace the full spectrum of visioning and risk management activities so I moved them.

Models have limitations, the intent here is to visualize context and promote discussions. If it generates a debate about where a topic should really reside or how the circles actually overlap its primary purpose has been served. As always I welcome everyone’s feedback.

What should the Agile Alliance be focussing on? What can the APLN do to change how projects are managed? I will be attending the Agile Alliance directors planning meeting in Portland, Oregon at the end of January and the Agile Project Leadership Network directors meeting in Salt Lake City, Utah in February to discuss these topics and welcome ideas and suggestions from readers,

The Agile Alliance has a large (and growing) membership of supporters and with proceeds raised from events like the Agile 2006 conference in Minneapolis, memberships, and corporate sponsorship is able to fund research into Agile methods and other ventures. What areas of agile research are most deserving: distributed team techniques, new testing techniques, or the wider use of agile outside of IT projects?

This year’s Agile 2007 conference will be held in Washington D.C., but where should the 2008 conference be held? Given the rise in attendance figures, the 2008 conference could have between 1,500 – 1,800 people. Which cities would make good candidates for a conference of this size? The conference is intended to be the premier event in the Agile community for North America so perhaps it is time for a trip to Toronto, Canada or Cancun, Mexico?

What about the APLN, should we be working closer with the PMI to form Agile Special Interest Groups (SIG), or rent booths at the PMI Global Congress to promote the APLN, how about extensions to the PMBOK for Agile projects?

I’d be pleased to receive your suggestions for how these groups could best serve the needs of their members as agile methods continue to evolve and their adoption expands.

The next Calgary Agile Project Leadership Network (APLN) meeting will be on Monday January 15th when I will be talking about “Agile Suitability Filters”. Here are the details:

Event:                          Calgary APLN: “Agile Suitability Filters”
Presenter:                   Mike Griffiths, Quadrus Development Inc.
Date:                            Monday January 15, 2007
Time:                           12:00 PM – 1:00 PM (registration will commence at 11:30 AM)
                                    Light beverages to be provided
Location:                     5th Avenue Place – Conference Room
                                    Suite 202, 420 – 2nd Street SW

Topic: “Agile Suitability Filters”

Agile methods can bring many benefits, but are they appropriate for all projects?  In this session Mike will outline several agile suitability filters and discuss their application and roles.  Project characteristics and organizational characteristics to assess will be analyzed along with strategies for interpreting and acting upon the results.

About the Speaker:

Mike Griffiths is a project manager for Quadrus Development Inc.  He helped create DSDM in 1994 and has been using agile methods ever since; he is active in the agile community and has authored numerous journal articles.  Mike serves on the board of the Agile Alliance and the Agile Project Leadership Network (APLN) and is a frequent contributor to agile conferences.

To register, please send an email with your contact information including name, company name, and telephone number to [email protected].

Following this session we have some great speakers lined up.

• On February 21st Robin Robertson of RCR Consulting will be presenting on “Working with Different Personality Types”
• On April 10th Ross Martin and Lynn Harrison of Black Tusk Leadership will present on “Team Motivation”.

The pro’s and con’s of certification in Agile Leadership are being discussed on a few Yahoo groups at the moment. Some people believe any kind of certification is inherently evil and I can appreciate this point of view, but the idealist in me wonders if it can be done right?

I am involved in an APLN sub-group to create a proposal for an accreditation scheme. I thought long and hard before joining the group, but it became apparent that other groups and training companies were discussing the creation of alternative schemes and so my feelings were that if it was going to happen anyway, then I would like the chance to steer it towards a decent goal.

The current situation
It appears that people are eager for direction and recognition in agile project management. We can choose to step aside, avoid the nasty politics, ego’s, monetary issues, and bureaucracy that often go with it and risk witnessing other groups implement poorly directed schemes. Or, try to create what an accreditation (I’m avoiding the term “certification”) scheme should be and steer the industry towards, what we believe, are the right goals.

My certification observations
Like many others, I have been through the ScrumMaster, PMI, and DSDM accreditation schemes and observed the following: ...