What defines project success? On “time and budget”, or “to specification and quality requirements”, maybe all of these? No, we are missing some less tangible, but critical components; how do people feel about the project once it is done.

On May 12 the PMI-SAC Awards for the best projects and the best project managers will be held in Calgary and Captain James Lovell, Commander of Apollo 13 will be giving the keynote “Apollo 13 – A Successful Failure”. This year I am a judge for the awards ceremony and in reviewing the applicants I have been thinking about what constitutes a successful project which prompted the recollection of some famous projects...

Apollo 13
Let’s consider Apollo 13. The third manned mission by NASA intended to land on the moon that experienced electrical problems 2 days after liftoff. An explosion occurred resulting in the loss of oxygen and power and the "Houston, we've had a problem" quote from Lovell (that is widely misquoted as, "Houston, we have a problem".)

The crew shut down the Command Module and used the Lunar Module as a "lifeboat" during the return trip to earth. Despite great hardship caused by limited electrical power, extreme cold, and a shortage of water, the crew returned safely to Earth and while missing the main moon-based scope, it was a very successful rescue, allowing future missions. “A Successful Failure”

Titanic
(The 1997 film not the original ship). This film was six months late, massively over budget and finished with a bloated 194-minute running time. Seemingly not a good performance given the original schedule, budget and scope requirements. Yet the film turned into an enormous critical and commercial success, winning eleven Academy Awards, including Best Picture and became the highest-grossing film of all time.

After returning from teaching a PMI class in New Orleans, the PMI have added some additional venues for the course later in the year. This is a good sign for agile methods within the PMI community; the course sold out quickly which hopefully indicates that many companies are still able to invest in training.

My 2 day Agile Project Management courses will be offered:

• September 14-15 Las Vegas, Nevada
• November 9-10 Savannah, Georgia
• December 14-15, San Diego, California

Of course PMI events go on throughout the year (full schedule), but this year I have deliberately kept the summer free from work events to enjoy some outdoor things closer to home. I am currently signed up for the Police Half Marathon, Calgary Marathon, Canmore 24hrs of Adrenaline, The Canadian Death Race, The TransRockies Bike Race, and Half Moon Adventure Race. Time will tell if I survive them all or stub my toe on the first one and miss the rest – hopefully not! I will report any remotely work related news back here.

Other agile events that look interesting this year include:
Atern Road Shows in the UK: London May 14, Bristol June 18, Manchester June 25.
XP 2009 Sardinia, Italy May 25-29
Agile 2009 Conference, Chicago August 24-28
Agile Business Conference, London October 13, 14

So many events, so little time!

Next week I’ll be teaching a two day Agile Project Management course for the PMI in New Orleans. The class sold out quickly; I only teach 3 or 4 times a year for the PMI and I wondered if registration numbers would be down this year. The fact that it filled up so quickly is very positive and perhaps more people are tuning to agile as a way to get more work done with less budget.

This year’s Agile Business Conference in London has the theme of “Driving Success in Adversity” and I have submitted a presentation outline and plan to attend. There submission system states “This year we invite presentations and tutorials emphasising how Agile practices promote efficiency in project delivery, guarantee business value and optimise return on investment.” This seems a great theme, agile is all about maximizing business value, and I am looking forward to the conference.
 
Meanwhile, in New Orleans next week, I am keen to hear how organizations are currently using agile methods within their organizations to add value. (I am also looking forward to sampling the food and feeling some warmer weather after a long Canadian winter!)

Many skills go through a familiar progression:
1) Poor Performance
2) The Point of Realization
3) The “Sucking” Phase
4) The Advancement Phase

I went through this with TDD, then with a switch from management to leadership, more recently with learning to ski down hill in control on cross-country skis.

1) Poor Performance – Some things you just cannot do, or you have a lack of recognition about. The end result is that performance is poor.

2) The Point Realization – this is when you realize what you are supposed to be doing and the “a-ha” moment occurs. It feels good to now know what you need to do, but usually we are not practiced at it and still continue to fail for a while.

3) The “Suck” Phase – We know what we should do, but despite our best efforts we fail at doing it. This is because we have had no practice and we have not developed our skills yet. It can be frustrating that after making the mental leap that our performance hardly improves at all. From an external view observers may see no discernable improvement between before and immediately after the Point of Realization. Yet the seed has been sown and with practice we will get better.

4) The Advancement Phase – Now at last we start to make progress as we practice, continue to make mistakes, but get better and better. Our performance improves, we still fail occasionally, but less often and we get longer periods of high performance in between.

Applied Behavioral Analysis Science
My latest Point of Realization came during a presentation by Tony Parrottino at a recent PMI-SAC meeting. Tony was talking about Applied Behavioral Analysis Science as outlined by Aubrey Daniels.

Bob Johansen author of “Get There Early: Sensing the Future to Compete in the Present” outlines the challenges of VUCA projects. VUCA is a military term used to describe environments characterized by:

Volatility
Uncertainty
Complexity
Ambiguity

In such environments standard Command-and-Control processes are not effective.

I recently attended a great presentation by Denise Caron who outlined Bob’s description of VUCA challenges and the new leadership models that lend themselves to these circumstances. Many of today’s software projects exhibit Volatility, Uncertainty, Complexity and Ambiguity and there are numerous parallels between agile leadership and the VUCA leadership model.

Low complexity, fixed targets and “knowable” problems can be solved with a Command-and-Control approach. Here careful upfront planning and then methodical execution pay dividends. However, projects with high complexity, moving targets and initially unclear end-goals cannot be planned in detail upfront and then simply executed. This is where the advantages agile approaches come into play gaining the benefits of adaption over a traditional “Plan-the-work, work-the-plan” approach.

Johansen brings some useful parallels to the agile model, focusing on the role of a leader when faced with a dilemma involving Volatility, Uncertainty, Complexity and Ambiguity. He highlights a Foresight to Insight to Action cycle as shown next...

Come and see Jennitta Andrea present on how to reinvigorate your retrospectives at the Calgary APLN meeting this Friday 27 February.

From the outline:
“You know you should be performing regular retrospectives, but you can't convince management or the team that it's a worthwhile investment of time ... Your team has been performing retrospectives every iteration, and they have become monotonous and have stopped producing valuable insights ... You've heard about retrospectives, but don't even know how to get started ...”

Jennitta is a thought leader in the agile community and serves on the board of the Agile Alliance. I am sure the talk will promote many ideas to make retrospectives extra productive.

To register for this free event visit the Calgary APLN Site

The week before last I was in Regina teaching a two day Agile Project Leadership course for the Regina .NET User Group. One of the side conversations we had there was about Agile Organizations. Companies who not only embrace agile principles on their projects, but also within the behaviour and execution of their entire business. There is a big difference between running projects in an agile way within a traditional organization and orienting an entire company around principles that match agile values. Here are four well known and some not so well known examples:

1) Toyota
Toyota’s lean approach is well publicized. Through their passion for worker-led continual improvement they review, learn, adapt and improve at an impressive pace. Much has been written about Toyota’s capacity to innovate and 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.

There is no big prize for the best suggestion picked each month. Instead all suggestions are valued equally and thanked in a small way. Toyota believes the biggest improvements come about from implementing thousands of small improvements, not waiting for the next big idea.

How do we learn from this? By creating ways for people to contribute, canvas their ideas frequently and recognize all suggestions for improvement; whether they are ultimately successful or not.

The next Calgary Agile Project Leadership Network (APLN) meeting will be on Wednesday November 26 at the 5th Avenue Place Meeting room.

At the meeting Mike McCullough from Quadrus Development will be presenting  a re-run of his Agile 2008 conference session “Learning Games For the Agile Practitioner”. At the Agile 2008 conference the session was voted back for a re-run and was very popular. I hope you can make it out to the event.

To register for this free event visit the Calgary APLN site here.

Local APLN member Edgardo Gonzalez, has kindly offered a Planning Poker card template for readers to download. (No longer are we tied to the decks generously given out by Mountain Goat Software at conferences; now we can print our own!)  Based on the Fibonacci sequence, these cards print on standard Avery stationery and can be used by team members to estimate story points. (Post on Agile Estimation Techniques)

Thanks Edgardo for your gift to the community.

Download Planning Poker Cards.doc

There are some great books on agile team dynamics nowadays. My personal favorites include:

• Collaboration Explained by Jean Tabaka
• Agile Retrospectives by Esther Derby, Diana Larsen, Ken Schwaber
• Right-Brain Project Management by Michael Aucoin
• Great Boss Dead Boss by Ray Immelman
• The Blind Men and the Elephant by David Schmaltz

The problem is that most people do not get the time they want or need to read about these topics. So, I have created the following: Top 10 Team Practices list and one-page printer friendly version to remind us of some of the basic points.

If you lead a team then print the sheet and post it somewhere visible and do a mental inventory of the practices from time to time. If you are a member of a team that could do with a boost, print a copy and post it on your manager’s wall, I am sure they will thank you for it! (actual results may vary.)

1) Empower them – By giving control for local decision making and work sequencing to the team we gain the advantages of additional insights, better motivated teams, and more practical plans with less waiting. 

2) Listen to them – The team is closer to the technical details of the project and also best placed to determine the most successful solutions to project challenges and problems. Encouraging the team to solve the project problems has two main benefits. It demonstrates they are valued for their insight as well as their output, which makes people feel more involved and appreciated. Also, solutions suggested by the team are more likely to be embraced and executed with enthusiasm. It is better to have a 70% optimal solution executed with 80% enthusiasm than a 100% optimal solution executed with 40% enthusiasm.

Last week’s Calgary APLN meeting was on Team Collaboration and afterwards an attendee volunteered a really neat and useful team assessment questionnaire. Gerard Meszaros (author of XUnit Test Patterns) who also has strong project management and team collaboration knowledge, presented on “Using Collaboration to Build Team Commitment”. It was a great presentation and referenced some of the Jean Tabaka’s work from the book “Collaboration Explained”.

I have known Jean since her facilitation work with DSDM in the mid 90’s and she really knows about teams, motivation and working effectively with people. Chapter 4 of her book talks about characteristics of high performance teams. After the presentation, Edgardo Gonzalez sent me a spreadsheet based on these criteria that allows quick and easy team assessments.

As seen from the screenshot above, the tool is a one page Excel sheet that assesses the team’s abilities in:
• Self Organizing
• Empowered to Make Decisions
• Belief in Vision and Success
• Committed Team
• Trust Each Other
• Participatory Decision Making
• Consensus-Driven
• Constructive Disagreement

In our example of a fictitious project, four people completed the questionnaire. The collective team score is shown on the left hand radar chart (indicating a weakness in the “Consensus Driven” field) and the individual scores are shown on the right hand radar diagram. Colour coding flags areas as “Red” for concern, “Yellow” for warning (“Trust…” in the example), and “Green” for good.

Not only is the spreadsheet an effective team diagnostic, but a good lesson in Excel spreadsheet formatting and validation. Thanks Edgardo for agreeing to make this available to everyone and to Gerard and Jean for their work in this important field.

You can download the spreadsheet for your own use below:

Collaborative Team Assessment.xls

Last week I taught the “Agile Project Leadership” course with Sanjiv Augustine in Manchester, UK. The course went really well and we were looked after by Ian and Dot Tudor our hosts from TCC Training and Consultancy. They have a number of training facilities around the UK and ours was Aspen House, a converted church that retained all the arched doorways and high vaulted ceilings you would hope for.

It was a rare treat to teach in such nice surroundings and the church setting made evangelising agile all the more fun. In truth we were “preaching to the choir” as most of the delegates were already familiar with the benefits of agile and were looking for practical tools and more leadership techniques to move their organizations to the next level.

Do you really need those pesky users on your project, forever changing their minds and requesting new functionality just as you are about to be done?

When I was at school, my physic’s teacher was fond of telling us that, "if it were not for the students I would enjoy teaching." The same is true for users, they may cause us issues and headaches, but they are the reason we are there and developing software in the first place.

Why we Need User Input
The truth is that on agile projects we do not want user input we actually need user input in order to be successful. Agile projects are deliberately light on capturing initial requirements because we realize that requirements are likely to change, and evaluation of an emerging system will surface new requirements and improvements to existing requirements that we want to encourage.

This year’s Agile conference in Toronto this August will be structured slightly differently. Following a music festival structure, the conference will be divided into “stages” to cover different topics. I was able to visit the Agile 2008 conference venue in December when the last Agile Alliance Board meeting was held there and we toured the facility with the Agile 2008 Conference Committee.

Johanna Rothman and I are the “Leadership and Teams” chairs for the conference and we have been allocated a great venue; a large, bright ballroom with high ceilings and lots of natural light. This year the conference has much more space and larger mingling areas both indoors and out which I am sure will help.

On the “Leadership and Teams” stage we are looking for submissions on, you guessed it, leadership and team focused experience reports, research papers, tutorials, and presentations. Now is a great time to submit a proposal, so take a look at the submission system and propose your ideas.

The other element I am excited about is the submission system selection process. I have written previously about encouraging the agile community to prioritize our proposal backlog (list of submissions) and this year it is happening. On the Drupal based submission system anyone can write a review for a session and “up-vote” or “down-vote” a proposal. The cumulative scores for proposals help determine what gets selected.

This will not be a totally crowdsourced selection (like ideagora: Cambrian House), instead panel review will still be involved, but it is great to see the conference users (attendees) involved in prioritizing the features (proposals) for the event.

So, head over to the submission system and up-vote your buddy’s submission, down-vote anything from that guy that won’t return your emails (only kidding) or better yet, submit something valuable on Leadership and Teams for the conference, we would love to see it.

On February 4-5th I will be co-instructing with Sanjiv Augustine our new “Agile Project Leadership” training course in Manchester, UK. Sanjiv is the author of the excellent “Managing Agile Projects” book and fellow APLN board member.

This is a fast paced, practical focussed course that covers agile project management, leadership, and avoiding common agile project pitfalls.

You can find further details including a course outline at here.

I have written a few posts now on estimation and so I thought it was time for a summary. Also, I am planning to create a series of one page best practice summaries / cheat-sheets for agile and this seemed like a good candidate.

(I am a real fan of one-pagers; there is special value in getting everything visible and presented on one page that brings unique scope comprehension and clarity.  Toyota and other lean organizations make heavy use of A3 reports, a one page summary of an issue, its root causes, countermeasures, and verification steps to summarize problems and planned solutions - they are powerful tools.

Incidentally, when I first started work I had a wise and cantankerous project manager who was full of oxymoronic proverbs. One I remember was “If you cannot summarize it on only one page, you need to go off and learn more about it!” An astute paradox.)

Anyway, here’s the summary; if you want more explanation on any of the points, refer to my previous posts (Upfront Estimates, Estimation Techniques, Estimate Ranges) on agile estimation.

Is agile about new tools and techniques or more a mindset? Philippe Kruchten asserts “agility is not a technology, science, or product but a culture”. This makes sense to me; innovation comes in waves (object oriented programming, business process engineering, lean production, etc); and while they all have their merits, most fail to deliver the full potential of their benefits because people concentrate on the process rather than the mindset. At the heart of agile is a mindset not a toolset.

I was speaking to Christopher Avery today, author of “Teamwork is an Individual Skill” and he shared some thoughts on personal agility and team motivation. Christopher is great for this since he approaches agility and team work from a psychological side whereas my thoughts are usually based on observation and trial and error.

We were discussing motivation and how to motivate peers who you do not necessarily have positional power over. Bosses may try to create motivation via carrot and stick approaches, but these are weak and short lived. People grow tired of such manipulation and find ways to break the system.

Instead, Christopher talked about “Intrinsic Motivation”, a more powerful motivation that comes from within.  People want to be on a winning team, but are not sure how to find or create them. The secret lies in understanding what “winning” means for others and then creating wins around you. In practical terms this means asking people “what is in it for them?” i.e. what is it they would like to learn, do, or gain (beyond a paycheck) from the project and then provide opportunities for these things to happen.

At first this sounded a little odd to me, a bit too touchy-feely. Asking people what they did over the weekend is one thing, but asking them what they want out of a project seems, well, invasive, too personal. However when you think about it, that is backwards, after all the project is something we all have in common. What they did with their spouse over the weekend, now that could be personal!

Telling someone what you really want to get out of a project might seem a little odd too, but fears of doing so indicate a ‘scarcity model’ to information. Why should we worry if people know what we really like to do or gain, chances are they will make opportunities available for us to do them. Helping others get what they want from projects creates an upward spiral of support and co-operation, which when you think about it, is the heart of a winning team.

Chatting to Christopher is always refreshing, he shares so much useful information that I struggle to retain it all. Fortunately for us Chris has recorded a free tele-seminar on Mastering Personal Agility. I heartily recommend it, the people side of projects have the greatest leverage, even small improvements here can yield large benefits; be sure to check it out.

In the last post we covered the importance of engaging the right people in the estimation process and the need to use more than one estimation approach. Today we will look at some examples of team based estimation approaches and practical ways to combine estimate result sets.

Estimation approaches (agile or traditional) can be divided into Heuristic (expert judgment based) and Parametric (calculation based) approaches.

Heuristic
• Comparison to similar systems
• Expert Judgment
• Activity Based (top down)
• Task Based (bottom up)

Parametric
• Function Points
• Use Case Points
• Object Points

Both sets of approaches have some merit, but they are also have their limitations and are open to misuse and over reliance too. For instance Activity Based (top-down) estimating is the most commonly employed estimation approach, but has been found to be the least accurate. Capers Jones in his book “Estimating Software Costs” instead recommends task based (bottom up) estimating approaches that tend to yield better results by encouraging a more thorough investigation into the likely tasks.

Involving many stakeholders
We should ask the people who will be doing the work how long they think it will take. Not only are they closest to the technical details and therefore theoretically in a better position to create a better estimate, but also because of the psychological benefits also.

If someone just hands you an estimate for your work and tells you it should take two weeks, you can either comply and try to get it done in two weeks or rebel and either finish it early or explain why it will take much longer to illustrate the poor nature of the estimate. Even complying and doing the work in two weeks can be a problem; given two weeks work will expand to fill the time. If a solution is found early time will likely be spent finding a better solution or refining the existing one. We do not get enough of the early finishes to cancel out the late ones. As Don Reinertsen observes in “Managing the Design Factory” in engineering we get few early finishes.

Last week we had the planning session for the 2007/2008 Calgary APLN Chapter. The goal was to create a prioritized list of topics to explore this season and demonstrate some of the values and practices of agile project leadership along the way.

We started by using the Speedboat game in small groups to identify impediments and propellers towards our goal of “Connecting, developing, and supporting great project leaders”. Speedboat is a group exercise for “Issue” and “Enabler” brainstorming that can be used with any group. It helps people to clarify goals, air their concerns, and suggest options for avoiding risks and moving forward. My colleague and co-host for the session, Janice Aston, wrote up these useful notes on using Speedboat and the outputs from the group.

Download Speed_Boat_Instructions.doc

Download Session_Results_10-17-07.doc

I previously wrote an account on Speedboat and other Innovation Games in an earlier post.

Following the Speedboat exercise we brainstormed presentation topics for the upcoming year. The thought process was: “Given the issues and enablers you just identified with agile leadership, what are the topics you would most like to see presented and discussed this year?”

Each group wrote ideas on sticky notes and we then posted them on the wall. Went through an affinity grouping exercise that sorted them into themed groups and removed duplicate suggestions. We all then went through a dot voting exercise where we assigned three votes among the topic suggestions. The topics and votes counts (shown in brackets) are shown below:

Last week I attended an excellent presentation on “Right-Brain Project Management” by Dr Michael Aucoin. I attend lots of presentations during the course of a year, mainly at North America events but a sprinkling of international conferences too, and few presentations stand out as being excellent. This one was exceptional from the content (that connected some loose ends in my Agile-Leadership-Project Management mental model) to the materials and delivery.

So, what was so good about it and what does it have to do with Agile Leadership? Well it outlined a parallel view of project management that supports and reinforces agile leadership and fills in some gaps along the way.

Michael started off by talking about today’s Stretch projects. He defined a Stretch project as a project that causes traditional project management challenges. They are characterized by:

• Schedule challenges and resource challenges
• Ambiguous specifications
• Dealing with new technology, new groups, new people
• Dispersed teams
• Many mid-project scope changes
• Challenging people issues

In these circumstances the old project management approaches that are good for predictable projects break down. Michael did not use the words Traditional and Agile, but he might as well have been giving an agile presentation because through his research he had arrived at the same conclusions, but interestingly, offered additional insights.

Why Does Project Management Fail?
Many people are frustrated by the mismatch between project management theory and its application on real-life projects. This is due largely to trying to employ approaches designed for predictable projects on today’s Stretch projects and seeing them come up short.

Yet, in many walks of life outside of project management, people succeed in unpredictable environments everyday. Doctors, farmers, and teachers all work in difficult to predict environments yet, on the whole, are successful. So why do project manager’s struggle with stretch projects? There are three main reasons.

1. Mismatched project model and environment
2. Projects lack emotional involvement
3. Personal challenges created by stretch projects

Let's look at each in turn...

Last night I gave a talk on “Agile Project Leadership” at the Calgary Agile Methods User Group (CAMUG). I like giving these because the questions raised make me re-examine elements of leadership and last night was no exception.

One question raised was basically “We hear about these ideas and they sound good, but in our projects the same old stuff keeps happening. How do we get real results?” I responded with some explanation about encouraging servant leadership, but in retrospect I think the underlying question was more about making the switch to authentic leadership rather than shallow imitations that bring poor results.

Some subsequent discussions with a couple of attendees have helped me straighten out my thoughts on the issue further. “Cargo cults” is the term used to explain the phenomenon of blindly replicating outward behaviour with the hope that it will yield positive results. It originates from a few scattered instances of Pacific Island tribes recreating replicas of the war time aircraft runways, control towers, and radios out of wood in the belief that they would bring back the cargo planes that brought Western goods during the war.

The equivalent cargo cult leadership pattern would be to practice techniques like team recognition in the hope that it improves morale and productivity without understanding the work undertaken, or by presenting phony “well done’s” and insincere praise. People have excellent BS radars and phony praise is quickly recognized as attempts at manipulation and has the opposite effect as desired. Likewise mechanical-only attempts at creating a common vision, challenging the process, or creating empowered teams will fall short too. These activities require deep conviction or else they will falter and fade, making genuine attempts harder to introduce later as an “antibody effect” of mistrust develops in the team.

While your initial reaction may be “none”, I would assert that your whole team are actually volunteers and we can benefit from recognizing this and treating them accordingly. All that paying people does is ensure that they turn up (hopefully) and then once they are at work they must want to contribute or else very little will be achieved despite all the outward appearances of them “working”.

Attending the Agile 2007 conference in Washington and witnessing the passion of people engaged in something they truly care about and volunteering on programs with likeminded people got me thinking again about the productivity of volunteers and paid team members.

Team member contribution varies on a scale ranging from being a net drain on the project, all the way up to passionate innovation.

On the left hand side of this spectrum we have instances of people actually negatively impacting the project. Either intentionally or through misguided objectives and actions, their presence on the team actually has a net drain on project productivity.

The next region “Passive Compliance” people do generally work on to-do items, but without much thought and without any passion for the task or goal. Unfortunately “Passive Compliance” is an all too common category for team members in large organizations who feel like “cogs” in a machine they have very little say in.

In September I will be co-instructing with Sanjiv Augustine the new course “Agile Project Leadership”. Sanjiv is a fellow APLN board member and author of the excellent “Managing Agile Projects” book. I’m really excited because a) we have an excellent course that will stretch attendees while engaging them, and b) co-teaching with Sanjiv will be a blast since he is such a knowledgable and personable expert.

Our first course offering will be in Manchester, UK on September 10-11th. You can find further details including a course outline at Agile University here

In my last post I outlined some thoughts for an upcoming PMI presentation. Today I’ll introduce the first two concepts: “Accreditation” and “Appeal to Generation Y”, then will cover the last three topics in a later post and attach the final paper with the “Why Agile?” introduction.

As always I welcome feedback and suggestions for improvements.

Accreditation
Where traditional project management has certifications like PMP and PRINCE2 Practitioner, agile methods are adopting more formal accreditation schemes also. Currently the agile methods: Scrum, DSDM, and FDD have accreditation schemes and recently there have been discussions about additional programs and multi-disciplinary (not just one agile method) accreditations.

However, this is not without great debate and consternation, as for many people in the agile community, certification represent the centralized control that agile methods liberate workers from. For these people creating accreditation schemes represents: commercialization, profit chasing, and rewarding the wrong behaviours. Yet for others, it provides an opportunity to demonstrate their level of knowledge and agile methods experience, it can also provide a study program for self directed learning, and perhaps a low benchmark for hiring decisions.

The Agile Alliance and the Agile Project Leadership Network (APLN) are two volunteer lead groups that promote agile methods, organize conferences and help steward the successful application of agile methods. The boards of both groups are populated by experienced agile practitioners and have discussed the idea of endorsing certification schemes. The Agile Alliance decided not to get involved in the agile certification business and instead issued a statement that “…employers should have confidence only in certifications that are skill based and difficult to achieve.”

Within the APLN, the board has been split on whether or not to lead the development of such a program. However, at the Salt Lake APLN board meeting in February 2007 a motion made by Alistair Cockburn “The APLN commits to lead and support the creation, implementation, and evolution of an accreditation program for Agile Project Leaders based on design criteria including the DOI, with a draft proposal published by August 15, 2007” passed 10 votes to 3.

It was felt that if more agile certification was inevitable then the APLN was well positioned to do it right.

Weaknesses in current schemes were examined which included:
• lack of a difficult test
• lack of peer review and endorsement of candidates in the assessment process
• a closed models to the body of knowledge

I am looking for an experienced .NET 2.0 developer to join our team at Husky Energy. This is a challenging role on an established agile team building a complex oil pipeline management system. The skills we are looking for include:

Must Have

• NET 2.0 (advanced)
• OO/design patterns skills (advanced)
• Experience in enterprise application development (advanced)
• SQL (intermediate)
• Unit testing (intermediate)

Nice to Have      

• Crude Pipeline knowledge
• ReSharper
• MSBuild
• Subversion
• iBatis
• Developer Express suites
• WCF

The role is a contract position for one year. The project has 18 months left to go so an extension is likely. We are using a practical set of agile techniques and have the benefit of three full time users dedicated to the project – which in my experience is rare.

Candidates with strong .NET development abilities, a passion to join a high performing agile team, and availability to work in Calgary should send their resume to me at mike.griffiths@huskyenergy.ca

The team will be doing the technical interviewing so expect some code reviews and coding assignments in the interview. We have a great team in place that work well together so we are particular about finding the right person. Fit is more important than availability, we will wait up to a couple of months to accommodate the availability of the right candidate.

If you have analysts working ahead of development, or have testers working significantly behind development, then you may have “Pipelining” problems.

Pipelining is the term used to describe the situation when business analysts are working ahead on the requirements for a future iteration; the development team is working on the current iteration, and the test team is engaged on a previous iteration.

In some circumstances analysis may be several iterations ahead and testing several iterations behind. To some people this may seem an efficient use of resources with each group running at their optimal speed, unfettered by the co-ordination constraints of different groups. However from an agile and lean perspective this is problem, a bad-smell that needs fixing.

Here are the problems with pipelining:

Three teams not one – in a project where pipelining is occurring we do not have one cohesive team we have three teams (or more). It is hard enough co-ordinating the members of one team towards a common goal aligned to business benefits. When there are three teams it is just too easy for people to claim that they did their bit and problems lie with other groups. Yet, the fact remains that if the software does not meet business satisfaction then it is everyone’s problem.

Increased Work In Progress (WIP) – Requirements whether they are in the form of user stories, use cases, or formal specifications all represent work invested that has not delivered value to the business. The same goes for code, until this functionality has been tested to the satisfaction of the business it is not valuable. As the time increases between capturing the requirement and finishing the last test two problems occur. The first is classic accounting, money have been invested for no return yet and there is a risk associated with future returns. The second is that requirements decay; the longer we keep requirements around for, the higher the likelihood that they will no longer be required or will have to change.

Increased time from defect injection to defect remediation – the cost of change increases the longer a defect goes undetected. In a pipelining project, defects introduced by faulty analysis could take months to be detected in testing or user review. Fixing the problem after this period of time will entail refactoring far more code (for the work happening in the interim) than if it was detected earlier, and will increase technical debt...

A couple of weeks ago I wrote a post called “The True Role of a PM on Agile Projects”. An attribute I did not include was “Be Enthusiastic – it’s Contagious” one reason for this omission is that it is a skill that I struggle with and I did not feel qualified to talk about. My style is more reserved and I have to go outside of my comfort zone to outwardly project my eagerness. However, the fact remains that it is an important role. 

If the leader of the project does not appear to show a passion for the cause then why should the other team members? Also the “- it’s contagious” portion is very important, as a social group team members easily feed off of each other’s energy levels. This is demonstrated by the presence or absence of those rare individuals who have the personality to be able to lift a group. When they are present everyone feels the lift and buzz, when they are absent there is hole, and everyone comes down a notch.

By introducing a positive, enthusiastic approach we nudge the team mood in the right direction. Nobody wants to work in pessimistic drudgery. We are happier, get more done, and overcome obstacles easier when people are enthusiastic. Obviously, it needs to be genuine and in character with your true nature. Some phony “Woo-hoo’s” will fool no one and undermine your credibility, but even if you tend to be quiet, true enthusiasm can be conveyed in the way in which you engage with the team and other stakeholders.

The reason I’m writing about this today is something I picked up last night from the PMISAC awards. Tana Goertz, finalist from “The Apprentice 3” gave a keynote speech that provided the tip “fake-it until you make-it”. Now I know I have just said we should not be fake when showing enthusiasm, but that was not her point. Tana’s message was that if you realize that something is important then you should do it, even if you struggle, until you can do it well. By practicing this awkward, but important skill, it will become easier.

Another take on this is, is “if something is worth doing, it is worth doing badly”, it took me a while to understand this oxymoron. However, it means if something is good and important we should try to do it (even if we are bad at it) because at least a little is better than nothing at all. (Another favourite oxymoron truism is “You lead people by standing behind them”, physically impossible, but correct in principle.)

So, if you are a little like me and struggle to project enthusiasm give it a try, do it anyway. Be sincere and express it in your own way, enthusiasm is contagious and brings the energy to push through setbacks.

All projects face problems, but fortunately your team members have the best solutions.

Projects rarely go exactly to plan; they have a nasty habit of uncovering gnarly problems that were not anticipated, but need to be solved. This is illustrated nicely by Doug DeCarlo in his book Extreme Project Management.

The top black line depicts the planned approach moving in orderly fashion from start to finish. The lower blue line depicts how projects really progress with side tracks and setbacks as obstacles are encountered and overcome.

Yet, in attempting to solve these problems project managers too often overlook the best source of solutions, the project team. In this post I will outline why the team has the best practical solutions even when they may not be the best theoretical solutions. An example will probably help about now.

While managing a government project during an IT vendor change, we needed to quickly build rapport with the business users of the system and subject matter experts (SME) in order to maintain the development pace from the previous team. The problem faced was how do we get to know the business folks better and connect the team members and SME’s . Rather than contriving some project social event and trying to get buy-in from the business and team I presented the problem to the team in a planning meeting.

After some back and forth a team member suggested, that since quite a few of the business people went 10-pin bowling, then perhaps we should arrange a bowling social event. Others concurred, ideas for mixing the teams up (not us vs. them) were brainstormed and we ran the event. It went really well and led to other activities all of which greatly contributed to a strong relationship and a successful project.

As the PM I could have instead consulted the PMO, HR, or social psychology experts to determine the optimal team building event, but then I would have had to have sold it to the team. Here lies the first power of team solving:

Team Solving Power #1: By asking the team for a solution we inherit consensus for the proposal

So, what does the PM do on agile projects? If the team self organizes and selects their own work from the prioritized feature list, should the PM just buy pizza and keep out of the way? Well they are short changing the team if that is all they do. Rather than a fear of role erosion, PM’s should be maximizing business value delivery and looking to broaden their skill set with more leadership practices.  This post outlines four core roles and ten core principles managers of agile projects should practise. 

Working in Parallel
Before we start, the transition to agile does not happen overnight. There will be a long and sometimes awkward transition period as all the project stakeholders adopt a more collaborative and empowered approach to work. Some people will be quicker than others to make the transition and the PM often has to continue with traditional PM activities, behind the scenes, to ensure no balls are dropped on the project.

Ideas not new to agile, just a renewed emphasis
The Agile PM traits of a downward serving model and Leadership rather than Management were not invented by Agile guru’s. Instead agile teams found that the management styles that favoured people over process, collaboration over command-and-control worked best on agile projects. Leadership that moves the emphasis from doing-things-right to doing-the-right-things is a better complement to agile methods than the detail oriented task management popularized by modern project management. Interestingly, project management (emphasising achieving things through task control) is a relatively new phenomenon based on Fredrick Taylor’s Transformation View of task decomposition (1900). Whereas Leadership (emphasising achieving things through collaboration and shared vision) is as old as human collaboration itself. "When the best leader's work is done, the people say, We did it ourselves." - Lao-Tzu (604 BC)

Agile PM Role 1: Obstacle Removal

(Chop those large projects down to size)

When I started out as a PM and had a few successful projects under my belt, I wanted to manage larger and larger projects. Now I’m looking for ways to make them smaller and limit the functionality initially tackled. This is not just laziness or a lack of ambition on my behalf, instead it is a realization that delivering business value comes from successful projects and that large projects are inherently risky and more likely to fail.

Jim Johnson of the Standish Group presented some interesting metrics at the PMI Global Congress conference in Toronto a couple of years ago that confirmed my suspicion. From a study of over 23,000 projects it was found that the success rate dropped as project duration increased.

From the graph we can see that most (over 50%) of the 6 month projects surveyed were deemed successful, dropping to 23% of 12 month projects, and less than 10% of 24 month projects. Now, we need to understand what “Sucess”  means here. The criteria was quite strict and defined as within 15% of cost and schedule and to customer defined functionality and quality standards.

I expect a large proportion of these “failed” projects merely missed the 15% cost or time criteria and the picture would not be so bad with a wider margin. Predicting costs over long periods is notoriously difficult as even labour rates and inflation predictions elude the best market ecconomists. However the trend is still true, larger projects carry a much higher probability of failure for a number of reasons we will see...

Control vs Communication

When you first learn to ride a bike it is normal to grip the handlebars really tightly and look at your hands or feet as you concentrate hard on the new “riding” task and try not to fall off. The problem with looking at your hands or feet while cycling is that you will not see the rock or pothole in the road ahead until it is too late and so, despite your best efforts, you will fall off. It is actually safer to relax, loosen your grip on the handlebars a little, and look further up the road to spot obstacles in plenty of time to avoid them.

The same goes for project management, when we are new to the role it is normal to focus on the project plans, progress against the plan, and budget consumed too closely. We focus so much on these project management tasks that we fail to see the issues and risks (rocks and potholes) the project is headed towards, until it is too late. While plans, progress and budgets are all critical elements, we can bring more value to the project by releasing our obsession on these project metrics slightly and focussing more of our attention down the road to items like sponsor satisfaction and team morale. There is little point having a perfectly executed project plan and a full set of EVA metrics if the project gets cancelled or half the team quits.

Specification vs Collaboration
Closely linked to Control and Communication is Specification and Collaboration. We can try to specify everything down to the nth degree of detail and then hope we got the spec right and whoever is developing the product develops exactly to specification. Or, we can explain our goals at a high level and then work in closer collaboration with the developer to achieve our desired results.  Agile methods recommend the second option, getting the customer working in closer collaboration with the developer to ensure the right product gets built. This works well for many types of software project where it is difficult to fully articulate the complete requirements upfront. However, it is not just the software world that is switching to collaboration over specification.

Today’s aircraft are highly complex networks of sub-systems, parts and software; and Boeing’s new 787 Dreamliner is about as big and complex as commercial aircraft currently get. From its ground breaking remote diagnostics that communicate component usage, wear and failure statistics to the ground in real time via satellite communications; to its novel composite material wings that save weight, the aircraft is new and extremely complex.

When Boeing sent the specifications to the electronics supplier for the 777 (the predecessor to the 787) the document was over 2500 pages. The equivalent specification document for the 787 is a mere 20 pages, how is this possible? Boeing, who are experts in specification and control, learned that to tackle a project of this magnitude they had to form closer relations with their suppliers and learn how to co-create and collaborate like never before. While it would be wrong to say: “Gone are all the detailed specs” the major shift is to increased collaboration with suppliers and less reliance upon specification.

Many industries are tapping into the benefits of increased collaboration over contract negotiation that are also embraced by agile methods. With increased collaboration comes shared decision making as well. In the past, Boeing gave the orders like a drill sergeant, and suppliers complied. Rarely did it matter if the supplier had a better idea – Boeing wanted components built exactly to specification. This time, Boeing has given all of its partners a vote on matters that affect them. Boeing and its partners are reaping the benefits as they work together on solutions and adapt to realize unanticipated benefits.

So, if you get a chance to fly on a new 787 Dreamliner any time soon, consider the new collaboration process that enabled its creation (and let’s hope they did not lose any of those story cards!)

You can read more about emerging trends in collaboration and Boeing’s new work practices in Wikinomics: How Mass Collaboration Changes Everything. By Don Tapscott and Anthony Williams.

In this post I outline some really useful techniques for planning releases and iterations. They are adapted from a great book called “Innovation Games: Creating Breakthrough Products through Collaborative Play" by Luke Hohmann

Some thoughts on the term “Games”
I have never been a fan of suggesting the use of “games” in the enterprise workplace, as in XP’s “Planning Game”. The term does not sit well with some traditional-type folks; to them it sounds unprofessional and not serious enough for important work. Yet the Innovation Games described by Hohmann are high performance facilitated workshop exercises that produce great results. If the project is serious enough to engage busy stakeholders then I think we owe it to the business to use the most effective tools at our disposal. If calling them “facilitated workshop exercises” eases their acceptance then I’m all for it, because it is the results I’m really interested in, not so much what we call them.

The Games
In Luke’s book, he outlines a number of games (exercises) that can be used in a variety of settings. Some like “Design the Product Box” and “Buy a Feature” are probably familiar to many people working on agile projects, others will likely be new. To keep this post a reasonable length I will focus on adapting three exercises for use in release and iteration planning.

The three we will look at are “Remember the Future”, “Prune the Product Tree”, and “Speedboat”.  I use slight variations on the last two, I call them “Shape the Product Tree” and “Sailboat” and I will explain the differences when we get to them...

(Achieving successful change)

In Part 1 we looked at the W5 (Why, Who, What, When, Where) of introducing agile methods into an organization.
Part 2 dealt with why change is difficult, resistance to change, and when people do accept changes.

Today in Part 3, I will introduce a change framework to effectively implement agile methods (or other organizational changes) with less opposition.

Let’s recap the circumstances where people will accept changes:

• When the change is seen as a personal gain: in security, money, authority, status or prestige, responsibility, working conditions, achievement

• Provides a new challenge and reduces boredom – when we create more interesting work

• Opportunities to influence the change initiative – when we involve people in the changes

• Timing: the time is right for organizational change

• Source of the change initiative is liked and respected

• The approach of the change and how it is implemented appeals to us – when they buy into the approach being taken

These are the conditions we need to establish in order to stand a chance of having our change accepted. It is interesting to note that they are all personal, human-centered circumstances. There are no “When the change is awesome”, “When the change will reduce production costs by 60%” type conditions. Yet these are the types of drivers people try to use to introduce agile methods and then fail.

Mistake #13: Missing the personal side of the change initiative.

As a logical, rational person it pains me to acknowledge it, but as with making purchasing decisions, we make up our minds in our hearts first, and then rationalize it with our brains. The same goes for accepting changes, we must first go for the hearts by crafting a caring, inclusive, compassionate change environment and then follow it up with some sensible changes.

"...we must first create a caring, inclusive, compassionate change environment and then follow it up with some sensible changes"

(Weird cults and religions learned this years ago, if you are nice to people and actually pay them attention (love-bombing), they will be grateful and a certain percentage will even give you all their money. However with cults, most people later realize they have been “had”.)

I am not suggesting we use love-bombing or subliminal messages to introduce agile methods. We do however need to understand that a key component for change acceptance is the human side of introducing the change. The best changes in the world will meet resistance and take longer to accomplish if they are implemented without regard to the human side of change.

A Roadmap for Effective Organizational Change
So, we need to consider both strategic and human related steps and follow a proven route to effective change.

(Understanding Resistance to Change)

In Part 1 we looked at the W5 (Why, Who, What, When, Where) of introducing agile. Today in Part 2 we will look at Challenges and Resistance.

In Part 3 I will introduce a change framework to effectively implement agile methods (or other organizational changes). However, before I get to that we need to look at why change is difficult and why people resist change.

Change Challenges
As a believer in agile methods and someone who had witnessed the benefits they can bring and the great buzz of an effective agile team, I used to think rolling out the methods would be a no-brainer.

Mistake # 8: Underestimating the resistance to change.

Wrong, achieving successful lasting change is difficult. Changing processes is even harder because a process is a system designed to resist change. Think about it, if every new type of requirement or defect that came along required a change to our development process we would be in trouble. So processes are these abstract funnelling techniques that were deliberately designed to resist change, which makes throwing them out or morphing them, more difficult than changing, say our time recording system.

“…a process is a system designed to resist change”

In fact there are a number of challenges:

Achieving lasting changes is difficult

• While people may be willing to try something new, it is a whole other story to get them to switch to it completely. Many a promising start has reverted back to the old way of doing things.

People are unlikely to blindly accept new approaches

• People need to be convinced of the benefits of a new idea before they are willing to invest the effort of having to learn it. Many adults do very little learning, they just want to understand the easiest happy-path through their regular work day and stick to that. For some people, asking them to think, learn and adapt to new methods in addition to doing their job is like increasing their work load while keeping their pay the same – not that appealing.

Resistance to change is normal and healthy

• We are bombarded by so many new ideas, goods and services it would be anarchy if we just adopted every new thing that came along. We need stability, standardization and norms to function properly. This also acts as a filtering mechanism that saves people from having to think about every new thing. They believe that the good stuff will stick and the poor ideas will fade away. Unfortunately some organizations are good at marketing crap, and some great ideas miss their mark, but on the whole we get by.

So we need to plan for resistance and have strategies in place to ensure worthwhile changes occur. Just explaining how agile methods are better is not going to ensure the whole scale rollout and adoption by an organization.

Mistake # 9: Think people will want to adopt agile methods because they are better.

(Understanding change)

I was contacted by a reader recently who was enquiring about practical ways to introduce agile methods into their organization. I suggested the book "Fearless Change: Patterns for Introducing New Ideas" by Mary Lynn Manns and Linda Rising as a good reference for successful change introductions, but drew a blank with blogs on the subject. So I thought I would write up my experiences and suggestions in a short series of posts.

Having being involved in the creation and roll-out of DSDM in 1994 and engaged on agile projects ever since, I have been exposed to a wide variety of process change initiatives, many of which had some pain-points. It is probably fair to say that if there are process introduction mistakes to make, I have made them, but I am (slowly) getting better and think I can guide people around a lot of the common pitfalls now. So, if you are currently introducing agile methods to an organization save yourself some grief and at least learn to avoid the problems I encountered.

Part 1 will introduce the W5 (Why, Who, What, When, Where) of introducing agile.
Part 2 will outline change challenges and explain why people resist change.
Part 3 will explain a cohesive strategic and human oriented change process and provide introduction tips.

Why Change?
First of all, with any change initiative we should clearly understand why change is necessary. If an organization is having success with their existing process (be it formal or chaotic) I would question the need to introduce a new methodology. Instead perhaps our efforts could be best used addressing incremental improvement. I’m not an agile zealot who will not rest until the world adopts agile everywhere. I think it is a much better way of working for most organizations and projects, but no panacea or silver bullet. Switching to agile because your CIO read a magazine article on Scrum, or because it is cool, is not a good reason and a weak driver to push beyond the inevitable obstacles of a successful, complete implementation.   

So, Mistake # 1 is: Introducing Agile without a clearly understood, agreed to, and articulated need. 

Last week I attended a great presentation by Don Tapscott author of “Wikinomics: How Mass Collaboration Changes Everything”. It was organized by Cambrian House (full disclosure: a company I have an investment and advisory role at) and spoke to the rise of peer collaboration over command-and-control management shown by the explosion of user-generated content sites and new work models. For me it generated some “ah-ha” moments and connected several ideas related to agile methods and new organizational structures.

Don Tapscott writes ahead of his time (either that or I’m just slow on the uptake), in his previous book “Growing Up Digital: the rise of the Net Generation”, he explained how modern generations are growing up comfortable with new communication methods. Instead of gamers and internet junkies having poor communication skills and few friends, most youngsters who use the internet have stronger social networks, large groups of friends (Facebook, MySpace) and can readily connect with others of similar interests. As I wrote in my post on Verifying Motivators the Gen. Y and Millennial generations value “feeling in on things” and “social values” more than say, “job security” and “good working conditions”.

People (especially younger workers) want to work on agile projects because techniques like empowered teams, increased communication, and shared leadership better match their internal values of inclusion, openness, and equality. When we align working practices with individual values we getter better involvement and commitment. Try to engage team members with a misaligned model and you will see poor commitment, detachment, and resistance. This is not just naive idealism either, youngsters have a healthy scepticism and a good radar for BS, spotting phoney claims and representations that often fool the majority of older workers.

Another of Don’s books “The Naked Corporation: How the Age of Transparency Will Revolutionize Business” addresses how tools like the internet make it almost impossible for organizations to hide dodgy dealings and bad behaviour. People communicate and share information more than ever and organizations will need to be more open and transparent in their practices in order to prosper in the future. Innovative companies like Semco described in "The Seven Day Weekend", use worker empowerment, collaboration and total transparency to attract the best talent and successfully blaze trails into new markets.

Agile projects practice "naked metrics" and process transparency. No longer is project status hidden behind process phase names like “in analysis” or “75% through coding” that mean little to most project stakeholders. Instead business features are delivered and demonstrated at the end of every iteration. The customer and business are included within the team and development process. To some this can seem good and bad; good when things are going well as the business can sing the praises of the project, but bad when things go wrong or progress is slow. However, we all know that sharing bad news, while hard, is best done early too. When project velocities indicate that the project will not be done on time, or unanticipated feature complexity is causing rewrites and problems, often the business folks on the inside have power and credibility with the project sponsors that is hard to achieve. Once they see that the team in not jerking around, but working hard and some stuff takes a long time, they can be great allies in scope and budget discussions.

How quickly we make decisions and the team member’s level of agreement to these decisions impacts project performance and team cohesion. Software development is an exercise in information exchange and decision making. Also, since software projects have no tangible, emerging product moving down a production line, the communication and decision making process becomes more critical to keep everyone informed and engaged.

Agile methods utilize many tools to promote effective communications including: co-location, daily stand-up meetings, planning workshops, retrospectives, etc, but less is written or taught about decision making. However, if team members are not canvassed for their opinions we run the risk of alienating portions of the team leading to reduced levels of commitment and participation, and potentially missing an important new perspective that could help avoid pitfalls further on. This post outlines the importance of team based decision making and outlines a couple of simple tools to get you started.

Agile methods favour more team empowerment and less command-and-control direction. This increases satisfaction and productivity, but raises the need for effective decision making. Without a project dictator, how do teams make decisions and move forward?...

The next CAMUG meeting looks very interesting. Jonathan Kohl will be presenting "Don't Drink the Kool-Aid! Avoiding Process Pitfalls". Here is an excerpt from his presentation outline:

“… merely applying an Agile (or any other) process is not a guarantee of success. As with anything else in life, there are trade-offs, and unintended consequences when applying a tool or process. This talk will explore some common Agile process practices that may work well in some contexts, and have unintended consequences in others.

The intention of this talk is to encourage us all to keep striving to build the best software we can. It's tempting to think we have the formula for success, but in a rapidly changing industry, we must adapt and change accordingly. “

Amen to that, there is no standard recipe for successful projects, instead, as the DOI advises, solutions need to be “context specific”, or as Alistair Cockburn reminds us, a new methodology per project.

This is not to say we should discourage passionate implementation of agile methods. Following my Agile Project Management Assessment Quiz post I was contacted by Simon Baker of Think Box who scored an impressive “Uber Agile” score. You can read an account of his project team practices and successes following the quiz and I commend him and his team on their work.

Rather, the point I want to make, is that our intent should focus on successful stakeholder engagement and better software. If this is achieved via agile methods then great, or if, say, via better communications, then so be it. We run the risk of ignoring the “Individuals and Interactions over processes and tools” value if we focus only on process.

For the last couple of months I have been reviewing draft chapters from Preston Smith’s new book “Flexible Product Development” due to be published later this year. I met Preston through the APLN board and I have learned a lot from reading the draft chapters. A portion that really hit home for me was his description of people over process...

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...

Yesterday I attended a great presentation on Team Leadership given by Robin Robertson of RCR Consulting. The presentation covered the topics of self-knowledge and emotional intelligence but then moved onto leadership techniques for different age demographics.

Robin outlined 5 commonly referenced groups:

Traditionalists – who lived during war times and experienced scarcity and loss
Baby Boomers – who grew up after the war and lived to work
Generation X – who saw their parents live to work and decided they would work just to live
Generation Y – the new workers, expecting benefits and have not experienced adversity
Millennium Kids – yet to enter the work place

Obviously classifying people based on just when they were born is a flawed model. (I know some young immigrants to Canada who have experienced great loss and adversity in their lives already.) However, where Robin took these generalizations was interesting and valuable.

She spoke about a study by Glenn Tobe into expectations and motivations between managers and team members from different generations. A manager from the baby boomer generation was asked to rank what they believed the Top 10 motivators they had at their disposal to encourage their team.

Agile teams are picky when it comes to the adoption of high-tech tools. On the one hand they seem positively geeky in the adoption automated build and testing tools. Yet on the other, absolute “luddites”, spurning technology, when it comes to project scheduling and tracking tools; favouring cards and poster sized graphs over computer based tools.

Why the schizophrenia over tools? When you dig deeper behind the reasons for these choices, some interesting facts emerge. Rather than relying on Work Breakdown Structures and Gantt Charts it is more common to see agile projects tracking work and progress via Big Visible Charts and task boards to track projects.

Work Breakdown Structures and Gantt Charts have many technical advantages over cards and corkboards. They can illustrate very deep hierarchies of tasks, support task dependency integrity checks, and allow the calculation of interesting metrics like slack, sub-assembly costs, and resource utilization. Yet, therein lies part of the problem, and the principle reason agile methods avoid these techniques. The math, statistics and reports that can be produced with these tools belies the volatile nature of what is being analyzed: tasks and estimates.

When we use tools that perform scheduling calculations and forecasting two problems arise...

I recently finished reading the “The Starfish and The Spider”, a business book bestseller which explains the benefits of distributed organizations and I was surprised by the many parallels to leadership and agile methods. The unusual title illustrates a key difference between networked organizations and traditional organizations. While they may look similar, a spider has centralized systems and if you cut it in half it will die; cut a starfish in half and it will not die, but instead re-grow into two separate starfish (apparently). Without a single head, distributed (starfish) organizations are very resilient and hard to compete against.

Examples of networked entities include Alcoholics Anonymous where each chapter is independent and new chapters can be started anywhere, and peer-to-peer file sharing programs such as eMule that are open source, freely distributed and employ no central registry.

The Agile Angle
A key advantage to networked structures is that they are extremely resilient to breaks in communication channels. A local AA Chapter does not have to rely on instructions from a central body in order to operate. It is empowered to help alcoholics as it sees fit following the vision of the original AA 12 Step Program.  Having this freedom to help others as best you can, AA circle members are effective at solving problems where “experts” often fail.