Recently I volunteered to help write the PMBOK v5 Edition and encouraged other agile project managers to get involved in the initiative also. Well, last week I heard back that my application to serve on the PMBOK v5 Core Committee was not successful.

The email explained that because they “…had received over 250 applications from a highly qualified group of candidates.  Unfortunately, we had more qualified candidates than available positions…” but I can’t help wondering if my “PMBOK v5 - Raise a Little Hell” post might have set off a couple of alarm bells with them too.

Anyway, apparently they are still looking for people to work on the Content Committee and Review Committee so perhaps I will get a spot there; I hope so since I enjoyed my involvement in the PMBOK v3 Edition.

I would be really interested to hear from anyone in the agile community who was successful in gaining a spot on the core PMBOK v5 committee. I hope there are some agile proponents represented. So please drop me a line if you were successful.

As one door closes another one opens, and Gantthead.com the online project management portal and recourse site with >470,000 members, has launched an agile newsletter called “Agility Now!” and have asked me to help.

I have been writing for them for a couple of years now as part of Doug DeCarlo’s eXtreme Project Management department and so was thrilled when they offered me the role. Each month the newsletter will contain new articles on agile project management and highlight agile blogs, tools, and events of interest to agile project managers.

Fellow PMI Agile Community of Practice cohort Jesse Fewell will be contributing a regular “Agile People” article too and I am looking forward to seeing how it develops. To sign-up go to Gantthead.com, My Account, Subscriptions and Notifications, and select the “Agility Now!” Newsletter.

Back in 1994 when we were defining DSDM, I remember our experiment of getting the user community engaged in the application architecture. (Not a successful experience!) It was at Data Sciences in Farnborough, UK and we were working on a project for a government client called ECGD. Following ideas from Enid Mumford on Participative Design we were testing how far the benefits of closer business engagement went and discovered a limit.
 
For us at least, having the business closely engaged in scope discussions, screen designs, and planning was extremely positive, but having them engaged in our architecture sessions was a net negative experience. They leapt to implementation ideas, disregarded IS strategy, and did not know enough about the architectural issues to be helpful in the discussions. We got frustrated, they got frustrated, and no body seemed better off.

So we discussed it with other DSDM Consortium members and agreed business involvement should not extend to architecture. The DSDM framework was updated and we carried on with our experiments and evolution of the method. For me this was a transformational moment, it was my first time of witnessing a failure and adaptation of a process within DSDM and how we learn and adapt. We just changed the methodology; there was no sacred cow, just good old scientific experimentation.

Business involvement in GUI design: Good
Business involvement in architecture design: Bad.
Therefore, involve them in GUI design, but not in architecture.

If you don't like
What you got
Why don't you change it?
If your world is all screwed up
Rearrange it

The PMI is calling for volunteers to help write and shape PMBOK v5 Guide Link. Here is your chance to inject more recognition and support for agile methods. I was involved in The PMBOK v3 Guide rewrite and got two small changes accepted in 2004 when agile methods and the PMBOK were hardly being talk about and I was a bit of a lone voice at the party.
 
If you don't like what you see
Why don't you fight it
If you know there's something wrong
Why don't you right it
 
Since then the tides have changed and now the PMI Agile Community of Practice is the largest and fastest growing PMI community. In the last PMI Network Magazine sent to members there were two full articles on Agile project management. Of the PMI’s 340,000 members an estimated 65% are in IT and the demand for agile guidance that has proliferated in other disciplines of IT (development, analysis, QA) is very apparent to the PMI, who need to serve their members.

In the end it comes down to your thinking
And there's really nobody to blame
When it feels like your ship is sinking
And you're too tired to play the game

For the last 25 years I have been learning about high performing teams and trying to create high performing teams. Well, I finally got to work with one for 3 years solid and I totally loved it.

For the last 3 years I have been working on the IPS project at Husky Energy with the best team and project I have experienced or reviewed. More of a program than a project, we rewrote a number of legacy pipeline control and billing systems in .NET and removed a clutter of spreadsheets and Access applications that had sprung up to fill the gaps left by difficult to upgrade legacy systems.

I had worked with great people before, I have seen the difference good executive support, and engaged business representatives make. However, as the cliché goes, when you bring them together, and add enough freedom to make big changes, the result is much more than the sum of its parts.

Why So Successful?
Freedom to reset and redo - This was a project restart. After several unsuccessful attempts to kick-off the project and then a failed experience with a vendor to out-source it, the project was brought back in house and restarted. I was fortunate to join at a time when management was open to fresh approaches. Already $1M behind budget and 2 years delayed, we were able to introduce changes into an organization receptive to hearing new ideas and changing process.

Executive Support and Business Champion – These terms “Executive Support” and “Business Champion” are often just titles, mere names or nouns. For our project they were verbs that described their everyday jobs. The sponsor fought to retain our budget during cut backs, the business champion repeatedly went to battle to retain resources, gain exceptions from harmful processes and ensure we had access to the very best business resources.

An experienced, pragmatic team – Most of them had “been there and done that with pure agile”, they had seen the benefits and costs associated with pure TDD, XP, and Scrum. They knew all the theory and had heard the theological debates and just wanted to work now. They were exceptionally strong technically, with mature use of design patterns and layer abstraction. Mainly experienced contractors and some experienced full time staff, humility was high and ego’s low.

Great domain knowledge – We had an insider, an architect from some of the original systems we were replacing on our team. The bugs, the flaws, the big chunks of tricky logic from the original systems could all be highlighted and explained rather than rediscovered, a great time saver.

Embedded with our business users – Being away from the IT group and in with the business was critical in learning their day job and building rapport. By seeing their business cycles, busy days and deadlines we were better able to plan iterations, demos and meetings. Being face to face and sharing a kitchen helped with conversations and quick questions too.

Right Process – Way behind our people’s influence on success was our process, using a relaxed interpretation of agile, we worked with two week iterations, daily stand-ups, user stories, and empowered teams. Given we were replacing existing required functionality it meant prioritization and detailed task estimates were less valuable. From a perspective of minimizing waste we naturally gravitated to do less story point estimation and lighter iteration planning sessions. It was reassuring to hear David Anderson in 2008 talking about Kanban and viewing estimation and iteration rigour as waste. We were not just being lazy; we needed a certain fidelity of estimation for planning, but beyond that got diminishing returns.

The Outcomes
High Productivity - The last release contained over 1400 function points that were developed in one month by 6 developers. This is approximately 12 function points per developer per day, over three times the industry average and other releases had similar productivity. This was despite the domain being complex, we had a full time PhD mathematician SME (subject mater expert) on the team to define and test the linear programming, and iterative calculations being used.

Personas get little mention in project management guidelines, yet they can energise the dullest of requirements and remind us of absent stakeholders. So I was pleased we Mike Haden suggested the topic for our next Calgary APLN meeting. Here’s the outline:

Title: "Using Persona to Move Your Project Forward"

Outline:
The use of personas has received scant attention in project management literature. First utilized in the late '90s as a tool of business analysis, a persona is a detailed description of a fictional end-user including how they use and perceive the product you're delivering. However, personas can have a strong impact on projects by providing a project team with a human face to enhance otherwise abstract data about customers. From streamlining communications, to managing stake-holder expectations, to maintaining the team's alignment with the project goals, personas can engage your team and enhance your capability to move the project forward rapidly.

This presentation touches on the origins and definitions of personas, the benefits and criticisms of their use, and includes a case study of persona implementation on a complex application development effort. Focused on how personas can galvanize a project team into action, it is an engaging, interactive presentation lasting of interest to all members of systems and application development teams.

Bio:
Mike Haden is an independent consultant with over 20-year's experience in Application Development, Project / Product Management, and Global Product Development. Throughout his career, he has delivered complex data analysis tools to the demanding Canadian oil and gas industry. Mike has experience in bridging the business and technical domains, balancing the communication needs of multiple stake-holders, and aligning project teams to the end-user.

While working in commercial software firms leading development teams that utilize agile project methods, Mike gained valuable experience in delivering application development projects ranging from true R&D through new commercial developments to replacements of “industry-flagship” applications. His current role at EnergyIQ is focused on a new data analysis product for the US oil and gas industry, developing business processes and technology to support distributed product development.

Mike is a Project Management Professional, a Certified ScrumMaster, and a Six Sigma Green Belt. He is presently the VP Communications for the Southern Alberta Chapter of PMI. He dreams of eventually finishing the rejuvenation of a 100-year-old house and having more time for his outdoor pursuits in the mountains near Calgary.

Date: Wednesday April 28, 2010  Noon-1:00pm

Location: Fifth Avenue Place (Conference Room) Map

Register: Attendance is free, but please register in advance to guarantee your spot.

This article summarizes my “Lessons Learned in Project Metrics: Are your Metrics Dumb or Smart?” presentation. It covers the following six topics

 

2010 is shaping up to be a good year for training courses and events. I have the following public enrolment courses available through the PMI.


March 10-11 Anaheim, CA

April 13-14 Scottsdale, AZ

September 15-16 Las Vegas, NV

November 10-11 Scottsdale, AZ

December 15-16 San Diego, CA

 
My private courses are available year round, see here for a list and course outlines, and I am also hoping to head back to Alaska this summer to teach a class for the PMI Alaska Chapter there again.

As normal I’m keeping the bulk of the summer free to take full advantage of the short, but fantastic hiking and mountain biking season we get here around Calgary. I was hoping to attend the Agile 2010 Conference in Nashville, but the dates August 9-13 clash with the TransRockies Mountain Bike Race August 8-14 that comes right through my backyard of Kananaskis and is too good to pass up.

Instead of the Nashville agile conference, I hope to attend another agile conference in the fall, perhaps the Agile Business Conference in England again, or a Scrum Gathering event. Then of course there is the PMI Global Congress conference in Washington, DC in October. With the PMI Agile Community of Practice now the largest PMI community with >1700 members there will be a large Agile contingent attending and many great agile sessions to go to. Once again so many events and so little time!

On February the 16th I will be presenting at the Calgary Software Quality Discussion Group. This was the first group I presented for when I moved to Calgary nearly 10 years ago and I am very happy to go back and talk about a topic I really care about: Project Metrics. I care not in the sense that I think they are fantastic, instead I care because I think the majority of common metrics are counter productive and misguided. Here’s the outline:

Lessons Learned in Project Metrics - Are Your Metrics Dumb or Smart?


Collecting and reporting effective metrics can be a tricky business. Einstein captured it well when he noted "Not everything that can be counted counts, and not everything that counts can be counted".

Software projects have a history of measuring irrelevant and even counter-productive progress tracking metrics. The "Hawthorne Effect" should teach us that we will influence what we measure, yet companies continue to overtly track things like hours worked and lines of code written, unaware that they send the message of valuing long hours over results, and discourage simplifications and healthy refactoring. Quite often the metrics we want to track are intangible and subjective and so people tend to shy away from them.

More fundamentally, why are we even tracking these metrics? Is it to report on what has already occurred or help steer our future course? Often an imperfect view of the future is more useful than a perfect view of the past. In the real world, rear-view mirrors are much smaller than windshields for good reason, yet the accuracy of hind-sight and our attraction to certainty often creates too much of an emphasis on lagging, already occurred measurements compared to leading metrics. So we get fancy graphs of project spend and defect rates, but no better insights into what we should be doing differently in order to meet our goal.

In this presentation I will review many common project metrics and explain why they are largely misguided and counter productive. An alternative set of "Design Factory" metrics will be presented that are "simple and relevant to the true project goal", these metrics leverage the Hawthorne effect and focus on leading metrics to support smarter decision making.
 

Registration Link

I have just started my second season of mentoring for our local PMI chapter. This week’s launch workshop was facilitated by Right Management and they introduced a great model for building (and rebuilding) Trust and Respect that I would like to share. It was used to help explain how to build trust and respect with those we are mentoring, but it is a useful model that has much wider applications.

Establishing trust and respect can build tremendous support for goals, and likewise losing trust and respect puts us back at the beginning in a relationship or even further behind and the process has to start again. I am sure we have all experienced it, I know I have. Trust is a slow process to build and can be quickly eroded by a single bad deed or poor choice, as shown in the graph below.


 

While this is common sense stuff, what I liked about the workshop is the Howard Jackson Model for systematically building trust and respect. It is a repeatable series of steps that build on from each other in sequence to establish better collaboration.
 

 
In this model we start at the bottom of the pyramid with Straight Talk, and move through the steps of Listening for Understanding, Making Commitments, being Reliable, creating Trust, and then finally earning Respect.

Straight Talk  - Open and direct communication is the first building block for trust and respect.

Listening for Understanding – Focus your attention on understanding the meaning behind what people are saying. There is a big difference between waiting for your turn to speak and really listening. Hear, Understand, Interpret, and then Respond.

Making Commitments – Be clear about what you will do. Agree on the What, By When, By Whom, and How steps. Communicate your intentions and stick to them.


Reliability – Do what you say you will do without fail. If circumstances have changed and it no longer makes sense to do what you said you would do, communicate back and explain why, and discuss and agree on the new steps.  Follow through over-and-over, be reliable, unfailing, dependable.


Trust – Trust results from the firm belief that another person can be relied upon. Trust is the result of straight talk, making sure you understand and are understood, and keeping confidences as well as commitments.


Respect – Although there are many levels of respect, the respect that follows trust leads to deep esteem for another person. We value their thoughts and input, and we know we can count on them because they have proven themselves out to us.

Why so much focus on soft skills for an Agile PM Blog?
When I started this blog in 2006 I wanted to explain the new techniques used on agile projects in an easy to understand format, with real life examples. Now I find myself writing more on soft skills than agile techniques.

This is because people are the engine that drives a high performance project. Without a good team that embodies trust and respect, the best process and tools in the world will not help you. I am as geeky about process as the next agilist, I love experimenting with Kanban and Lean and know that they offer better ways of executing projects. However, bigger improvements can be had from the people side of things.

Another passion of mine is mountain biking. I lust after lightweight exotic bikes like the Super Fly 100 and S-Works Epic, imagining how much faster I could go, the hills I could finally climb. I am sure they would help, but the advantages are small, a good rider will dwarf the performance gains of the machinery and it comes down to the person powering the bike not the bike its self. It is like this with people and process too. Yes we can tweak and improve the process and I encourage you to, but the biggest gains come from within the team. From trust and respect comes great commitment and creativity which cannot be made up for with tools and processes. We undoubtedly need a combination of soft skills, tools, and process, but when considering where to focus effort I believe the biggest payback is on the people side.

"From trust and respect comes great commitment and creativity which cannot be made up for with tools and processes."

As we start 2010, the second decade of the 21st century, project managers really should be embracing 21st century technologies and approaches. While developers and other project members have been benefiting from improved communication and collaboration via new technology in the last 10 years, project managers have been slower to adopt them.

The plus side of being a late adopter is that most of the kinks get ironed out before you experience them and all the features you may need have probably already been developed. So, time to get with it. Perhaps it can be a New Year’s resolution to at least examine these tools and approaches if you are not already using them on your projects.

The World Has Changed – Why Haven’t Your PM Tools and Approaches?
In the last 10 years many changes have occurred in the world of managing IT projects, yet we still see the same tools and approaches being employed. Is this because they are classic and timeless? Are the traditional PM approaches so successful that they do not need to be dragged here and there following trends and immature technology fads? No, I fear it is more that people are creatures of habit, and the usually more mature project management community, are worse than most at evaluating and adopting new approaches.

Also, project management is a largely individual activity, teams of developers and business analysts are far more common than teams of project managers, so peer-to-peer learning and tool support is almost nonexistent for project managers. Plus, project management can often be a reputation based market and to some people fumbling around as a beginner in a new approach is very uncomfortable to them. Well it is time to get over it, this is how we learn anything, and if you are concerned about looking foolish, just imagine how foolish you will look when everyone else has moved with recent trends and you are in the last stand of dinosaurs.

Solving problems with innovative solutions is fun, exciting and rewarding. Yet, being told what to do is generally boring and not very motivating, but why is this? Why exactly do some ways of working seem enjoyable and satisfying while others the total opposite? Well, the explanation involves chemistry and electricity.

I had coffee today with Dr Michael Aucoin, author of Right Brain Project Management, that I have discussed previously. He has been in Banff working on his new book and we chatted about empowered teams and productivity.

He explained that simply presenting work as questions rather than statements can engage mental models that make work more engaging, rewarding and in turn productive. More and more research on the brain is showing that we are hard-wired to reward ourselves for solving problems. Thinking about this, it makes sense, evolution rewards problem solvers and so an appropriate response is to make it feel good so that we continue doing it.

When we solve a problem and get that “ah-ha” moment, pleasure circuits in the brain light-up and endorphins are released that give us the buzz of solving the problem.  We also generate ownership for the solution and motivation to make it work, even if we encounter obstacles during the implementation. Contrast this level of enthusiasm with the prospect of having to do mandatory administration tasks or form filling. It is no surprise people enjoy working on empowered teams more than being directed exactly what to do, and some teams are orders of magnitude more productive than others.

So, as a project manager looking to increase productivity and motivation, is it simply a case of posing all work as questions and problems to be solved?  Obviously not, asking “Can anyone get our time recording entered?”, “Or, how can we write up these meeting minutes?” is likely to elicit the deserved response of “Yes, you need to stop wasting our time with dumb questions and do it!”

However, most projects could greatly benefit from engaging people’s problem solving skills and the motivation from solution-finding. Rather than over analyse difficult problems and prematurely decompose complexity into simple tasks, instead invite the team to find solutions. Make use of people’s problem solving skills and increased motivation it brings to create a more rewarding environment.

Is this manipulation, a mind trick to get people to work harder? I don’t  think so, instead a more insightful and respectful way of engaging a team. After all “We manage property and lead people. If we try to manage people they will feel like property”. Research on the brain is helping us understand what we instinctively feel. I am looking forward to Mike’s next book and learning more about working smarter.

What characteristics do you look for when hiring for an agile team? Our next Calgary APLN meeting is a panel discussion on the topic and looks set be a great one.

 

Some broad characteristics identified in the planning emails for the panel include:

Characteristics of a high performing team:

• Collaborative / effective communicator
• Willing to cross boundaries
• Work side by side / discuss work out problems real time
• A lot of face to face communication required
• Humility - accept feedback
• Able to compromise / support team decisions
• Able to reflect back on events and provide insights (critical for retrospectives)
• Always looking to improve
• Think about things rather than blinding moving forward…..
• Pragmatic - Knows what “just” enough is, Do what it takes
• Adaptive / Flexible - Change direction as required
• Takes initiative / self motivated
• Willing to try new things (may be evident by a desire for continuous learning)
• Can figure out the most important thing to do next. Doesn’t need to be told what to do.
• Risk tolerant – able to make a decision and act based on the information known
• Able to work in fast pace / intense
• Willing to work in a team room – little privacy, very noisy, no prestige
• Can challenge ideas in a respectful manner
• Work incrementally - Willing to revisit work
• Accepting that the big picture will evolve over time

Detecting these characteristics:

• Behavioural descriptive questions – tell me a time when….give me an example of….
• Interests / desires may be evidence of the characteristics
• Informal references from prior projects / peers etc.
• Auditions – pairing on an activity
• Trial periods

The panel members have also identified a set of technical requirements based on the various roles (developer, test, architect, etc), but I am most excited about who we have on our panel...

I attended the Agile Business Conference in London this week and presented on Tracking Project Performance. I missed this conference last year and so it was especially good to catch up with people again and hear what they have been doing. Also, after working in London for six years, but then living in Canada for the last nine years, it is always interesting to see how things have changed since my last visit. This year it was video screens replacing all the paper billboards going up and down the escalators on the Underground that caught my eye.

 

The conference was very good, and had the general theme of “Agile Grown Up”, focussing on the organizational impacts of using agile. This may not have been as much interest to technical people, but was right up my street. On Tuesday there was a great session about agile at Nokia where 1800 software developers are using agile to develop the Symbian mobile phone platform. They are using a version of Dean Leffingwell’s “Agile Train” approach for scaling agile to such a large team and most agile practices, but not pair-programming or emerging architecture. However, the main emphasis was beyond the technical process scaling and more on the ongoing coaching, mentoring and training that is required for such a large undertaking. In a discussion with the presenter Simon Buck after the talk I learned that they aim for one full time coach/trainer for each set of 5 Scrum Teams (each about 7 people). Quite the undertaking.

For the attendees of my recent Las Vegas course, below is a link to the PMBOK v4 to Agile mappings we discussed. My previous course material mappings were based on PMBOK v3, and before that the 2000 edition, which are out of date now.

 

Quite a lot changed from the PMBOK v3 to v4; all the processes were renamed into the new verb-noun format. Six of the old processes were merged into four new ones, two processes were deleted, and two new ones added. So it seemed like time to redo the mappings and post them online this time.

 

Cautions

Process guidelines and templates are not an acceptable replacement for common sense, thought, dialog, or collaboration. A fool with a tool is still a fool, but can be especially dangerous since they give the impression that they have a potential solution to tricky problems. Beware of simply following any project guidelines that seem counter to your objectives.

 

So, why would you want to be mapping the PMBOK v4 to Agile techniques anyway?...

The Calgary Agile Project Leadership Network (Calgary APLN) 2009/2010 season kicks off this week with a social at the Barley Mill in Eau Claire, Thursday Oct 1, 4:30 – 6:30pm.

“To help build a vibrant Agile community in Calgary, we would like to invite you to a networking event. Come out and meet other Agile Leaders within Calgary, swap stories and share some laughs. Agile Recruiting has graciously sponsored the event by providing appetizers. Cash bar will be available.”

This is a chance to meet and chat to other people in the agile project leadership community in Calgary. We have a limited capacity so register to reserve a place. I hope to see you there.

On Tuesday I was in Chicago for the PMI Agile Community of Practice launch event. It was hosted by Thoughtworks and kicked off by Martin Fowler and Jim Highsmith. Jesse Fewell and I introduced the community and outlined the goals.

With getting on for half a million PMI members worldwide, many in the knowledge-worker domain, agile methods have a lot to offer this already huge community. It is set to get larger too, PMI member growth progresses at about 20% per year, and PMI research indicates there are up to 20 million people engaged in knowledge-worker projects worldwide.

The spread of agile ideas to the PMI is inevitable and already happening on many fronts. I was concerned that it would be adopted incorrectly, fail and then be dismissed. This is still a risk, but with the launch event at Agile 2009 and an open invitation to Agile Alliance members to get involved and drive the initiative, the hope is that the initiative will succeed.

For an event that proposed bringing agile and PMI groups together, there was surprisingly little conflict or debate. But, then I suppose those people opposed self-selected and chose not to attend. Besides, few people subscribe to a purely agile or purely traditional approach to all projects anyway. We have to be pragmatic and chose our approach based on project and organizational circumstances.

The “PMI-Agile Community of Practice” is a free to join group aimed at “Equipping PMI members with Agile knowledge and skills".  For more details see the community wiki.

OK, I'm back and I really need to post here more often. Summers in Canada are so short that I try to pack a year’s worth of adventures into 3-4 short months. We (hopefully) still have plenty of summer left, but I intend to post more frequently as there is lots going on in the agile project management space too.

In a couple of weeks we have the Agile Conference in Chicago and I’m looking forward to the PMI-Agile Community Launch. (See this week’s GanttHead article). In September I’ll be teaching my 2 day class in Las Vegas (Sep. 14-15). In October I’ll be presenting at the Agile Business Conference in London (Oct 11- 15). Then training again in November in Savannah (Nov 7-11) and San Diego (Dec 12-16).

 

This summer’s silly idea was to try competitive mountain biking. A sport in which I quickly progressed beyond my ability and paid the penalty with crashes and injuries. So for now, I’m keeping the extreme to the projects and would like to thank Kelly Waters for pointing out that my site needed some long over due maintenance (one link was now an “off-topic” site.) Kelly runs the great site www.allaboutagile.com check it out if it is not on your regular list of sites.

The “PMI Agile Community” will be officially launched at the Agile 2009 Conference in Chicago, August 24. This has been made possible by Jesse Fewell and the strong team of volunteers pushing through the red tape of the PMI and the help from supportive PMI members.

For over eight years now I have been promoting taking agile principles to the PMI. In 2001-2003 my proposals for the PMI Global Congress conference (that were pretty derogatory of command and control approaches) were rejected. It was not until 2004 I smartened up and was successful in getting my paper (Using Agile Alongside the PMBOK) accepted and went to Anaheim to present at the PMI conference.  That was the only agile presentation that year at the conference, but year on year since, there have been more and more agile sessions at the PMI conferences. In 2007 when I met Jesse at the PMI Global Congress in Atlanta (where I presented on Developments in Agile Project Management) there were about 10 other agile related sessions.

This year I had decided to skip the Agile Conference, only because August is prime hiking, biking and climbing season in Canada’s short summer in the mountains. Yet, I cannot miss this launch; it has been so long coming, so I’m flying in for a couple of days for the community kick-off. I am glad to be attending, if only for a short time.

The PMI Agile Community is a grass-roots initiative between a group of Agilists and the Project Management Institute (PMI) to create a new Agile Community of Practice (CoP) within the PMI, with the stated purpose "to equip PMI members with Agile knowledge and skills". To read more about the PMI Agile Community see the Community Wiki. 

Thanks to the Scrum Alliance for sponsoring our launch event and the Agile Alliance for helping us kick this off at the best event of the year, the Agile Conference . I am looking forward to it.

2004 PMI Paper - Using Agile Alongside the PMBOK

2007 PMI Paper - Developments in Agile Project Management

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.

This past week I have had an opportunity to experience some hospital process control and contrast it with traditional project process controls. In doing so, I saw many instances of where today’s projects that exhibit uncertainty could be better managed via prioritization and collaborative decision making than preset plans.

How did we get to Traditional Project Management?
Project management is a fairly young discipline, yet because its repeatable process scales so well, and is easy to duplicate and automate; it rapidly became the dominant process for running projects. Frederick Taylor published his studies on “Scientific Management” in 1911 outlining the process of decomposing complex work into simpler and simpler steps until localized labour could be employed to perform each simple task. Embraced by Henry Ford and others, Scientific Management became the prevailing way of problem solving for entire industries.

It was not until the 1950’s when Peter Drucker and then later Michael Porter convinced the world that centralization and command-and-control structures were flawed. Respect for workers and a holistic value based view of systems can produce better results and more sustainable organizations. Yet traditional project management persisted.

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.

“To deal with complex projects there is an increased need for agile and flexible project management… In future, ‘people’ and leadership skills will be viewed as more important than technical skills.”

Statements like these hardly seem surprising to regular readers here. This is what I have been advocating for years. However, these recommendations do not come from me, but instead from this month’s PMI Today magazine. Couple this with the announcement last week at the PMI Global Congress in Denver that the next PMI Virtual Community to be created will be for Agile Methods and we begin to see a promising trend.

I reported previously that the PMBOK v4 Guide due out later this year has more iterative lifecycle coverage. Then today I heard that my Agile Project Management course has been added to the PMI Asia Pacific Congress 2009 conference in Kuala Lumpur, next February. So, while agile methods “crossed the chasm” into mainstream development a couple of years ago, I think we are only just witnessing this shift in project management.

Why has it taken so long for the managers to catch up? Well, as the popular stereotypes go, perhaps we are just a little slow, or have more change inertia, or more practices to change before embracing the new approach. Regardless, I am just glad things seem to be moving at last in the right direction.

I am looking forward to the PMI Agile Virtual Community as a great platform for bringing agile methods to project managers worldwide; (Virtual Community is the new PMI name for a Special Interest Group (SIG)). Congratulations to Jesse Fewell and the rest of the PMI Agile Board for pushing through the red tape and making this new group a reality.

The PMI Agile SIG is gathering speed. This Special Interest Group (SIG) is set to be launched later this year and is very timely. While currently the interaction between agile and traditional project management approaches in most organizations may be small.

This intersection is set to expand. The agile community knows that interest and adoption of agile is on the increase. We need only look at the attendance figures for the major agile conferences over the past few years to see how usage and interest is on the increase.

    

Yet, at the same time the PMI is seeing dizzying growth too. Fueled by demands for tighter controls and better governance, along with a seeming insatiable demand for the PMP certification PMI membership has seen strong growth over the past 10 years.

The PMI Agile SIG will be a group made available to all PMI members who want to learn, contribute, and discuss using agile methods. It will examine the best ways to manage such projects and should be a powerful voice for driving agile related practices into the PMBOK Guide and other PMI standards.

As both agile and PMI adoption increases we will see far more overlap and iteration on projects.

Agile methods are being used increasingly beyond the software domain and rather than dismiss traditional approaches as not applicable I think it is better to work with them and help shape a better set of standards for the future.

I have written on introducing agile into the PMI several times before (here, here, here) and often end up discussing the IP concerns of working with the PMI with people. My take is that I'd rather be on the inside trying to make changes rather than outside taking shots. That's why I present on agile at the PMI Conferences and teach an agile project management course for PMI SeminarsWorld.

So, for those that want to help change the world of project management, the PMI Agile SIG is a good place to start. We are actively looking for members, anyone interested in joining can send an email to PMIAgileSIG@LeadingAnswers.com

Just what the PMI Agile SIG can do will be limited only by the enthusiasm of its members. I do know that there is a PMBOK Extension for the Construction Industry published by the PMI. It is for people in the Construction industry wanting to use PMBOK processes in their unique domain. Rather than the name suggests of just extending the PMBOK it actually says: "if you are in the construction industry, forget these processes from the standard PMBOK and instead replace them with these ones…" Longer term, a PMBOK Extension for the Software Industry that removes static planning and substitutes some agile methods would be very useful.

The APLN Seattle Leadership Summit is shaping up to be quite the learning event. Here are some of the highlights:

• Collaboration Games by Luke Hohmann and Allan Shalloway
• Kanban by David Anderson and Corey Ladas
• Scrum by Brent Barton and Lance Young
• Getting Started with Agile by Mitch Lacey and Julie Chickering
• Writing Agile Contracts by Bruce Eckfeldt and Jim Benson
• Agile Program Management by Mike Griffiths and Mike Cottmeyer
• Real Option Theory by Chris Matts and Olav Maassen
• Agile User Experience by Arlen Bankston and Jeff Patten

The program also includes two leadership keynotes by:

• Lisa Haneberg, author of seven books including 10 Steps to Be a Successful Manager and Two Weeks to a Breakthrough.

• John Yuzdepski, a partner at Management Concepts LLC specializing in product transitions and commercialization of new technology and a veteran of the mobile communications industry.

While I am involved in facilitating a session on Agile Program Management with Mike Cottmeyer, my real motivation for attending is to hear the other speakers present.

I am a big fan of Luke’s work on Collaboration Games and posted on it previously here. As too with David’s work on Kanban here and Jim’s work on Agile Contracts here. I know Mitch Lacey does a great job of explaining agile and I was introduced to Real Options as a reviewer of Preston Smith’s Flexible Product Development book and want to learn more.

(I’m sure Mike Cottmeyer can handle the session by himself, I think I’ll be sneaking out to attend some the other sessions!)

So, if you can get to Seattle July 17-18 I recommend the event as the best value agile project leadership training you will find this year. $300 for two days of leading edge knowledge and experience is excellent value (plus you could claim 16 self-directed-learning PDUs too, if you need PDUs).

On May 15 I presented on “Decomposing large programs into agile projects” and “Mapping the PMI Processes to Agile Best Practices” at the Calgary APLN meeting. I have uploaded the slides in PDF format and also a zip file containing the hyperlinked Process Groups / Knowledge Areas mapping to Agile practices. (You will need to unzip the PowerPoint slide and Word files into the same directory for the hyperlinks to work correctly.)

Calgary APLN May 15 Slides.pdf

PMI Agile Mappings.ZIP

The timing of the presentation was very close to Michele Sliger and  Stacia Broderick’s release of their new book “The Software Project Manager's Bridge to Agility”. I was hoping we could give a copy of their book away as a door prize, but the book was available about a week too late. However, I received a copy this weekend (thanks Michele, Stacia) it looks good and I look forward to reading it. We also have some copies on order as door prizes for future meetings.

I recently returned from the Agile Alliance Board meeting in Boston. Three times a year we meet as the board to review progress, plan Agile Alliance programs, conferences and member services. This latest meeting was my favourite. Not only did we get lots done in the two day period, but the process (mainly open space) worked really well and rather than committee work being frustratingly slow, it progressed well, and I came away energized by the whole experience!
We had many good discussions including:

Conference 2009 Update – Next year’s agile conference will most likely by in Chicago, at the Hyatt downtown hotel. Options are being kept open and the venue would work well with between 1200-2400 attendees.

  <Todd Little explains the dynamics of conference venue selection>

Click the "Contine Reading..." link below for more updates.

At the next Calgary APLN meeting I will be discussing how the PMI framework maps onto Agile best practices. Yikes, what brought me to this!

Well, back in October at the Calgary APLN planning meeting we asked attendees what they would like to hear about this year. People made suggestions and voted on the topics, the top 5 were:

1) Using Agile on distributed teams
2) Team collaboration / motivation / accountability
3) How to decompose large programs into agile projects
4) Mapping the PMI Framework to Agile best practices
5) Fitting agile into the constraints imposed by the business

The first two have been covered; last November Jane Robarts spoke about her first hand experience of managing distributed agile teams and in February Gerard Meszaros spoke about team collaboration. Both were excellent talks and we have an experience report based on topic 5 “Fitting agile into the constraints imposed by the business” scheduled for June.

This leaves “3) How to decompose large programs into agile projects” and “4) Mapping PMI Framework to Agile best practices”.

Not surprisingly, we had no volunteers for the PMI to agile mapping so on May 15 I have the dubious pleasure of presenting on these two topics; weaving the risk reduction concepts of smaller, more agile projects with the connects-and-disconnects of PMI to agile processes.

When I saw the topic “Mapping the PMI Framework to agile best practices” my first thoughts were; “Don’t” and ‘Why would you want to?” it seemed akin to mapping horse-and-cart operating tips to car driving tips. They are just different and have divergent philosophies.

However, I can see that asking for mappings helps provide a familiar context for new knowledge. It also reassures people that everything in our old process is covered-off in the new process and there are no gaps. So, to help provide context, but not to imply equivalence, mapping the PMI framework to agile methods will be explored with the connection points and gaps identified. I will be careful to emphasize the viewpoint shifts in addition to the process differences.

If you can, please join us for what I hope will be an informative and entertaining presentation. Spaces are limited so register in advance to reserve your place. www.calgaryapln.org. For those that cannot attend in person, I will post the slides and resources here after the presentation.

Phew, I am done! We had over 120 submissions for the Agile 2008 “Leadership and Teams” stage which is a great response. However at about 5-10 minutes each to read the bio’s, proposal and submit a review it adds up to a large evaluation effort. Here’s how the stages and numbers broke down:

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.

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.

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.

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:

I have just got back from the 2007 PMI Global Congress conference held in Atlanta, Georgia. It was a good conference and while I may question the applicability of traditional project management approaches for software development projects; for organizing a conference it is hard to question the results. I experienced no line-ups; good speaker support and a well thought out and organized conference.

My presentation on “Developments in Agile Project Management” was over subscribed and I was asked back to do an encore presentation which is a great endorsement for the level of interest in agile project management, especially from within the traditional PM community. When I presented on agile methods at the 2004 PMI Global Congress in Anaheim, I was the only presenter on agile methods there. Since then I have seen an increase year on year. Last year I counted four agile topics and this year six, which is a promising trend.

I met up with Mitch Lacey and Stein Dolan who were also presenting on agile methods at the conference and it was great to chat and discover we had a similar philosophy. This is that agile methods are merely additional tools for the project toolbox that work well given certain circumstances. They do not replace traditional methods, but instead can exist alongside them and can be used very effectively when the circumstances warrant. This is what Jim Collins calls” The Genius of the And” and the “Tyranny of the Or” by using a smart mix of traditional methods And agile we can better respond to project challenges and avoid the limitations of “either / Or” thinking.

It is good that the PMI is incorporating more agile content; lots of of today’s projects really need these techniques to be successful. Yet many agile practitioners are reluctant to take their message to the PMI, and prefer to focus on agile conferences. However as Henry David Thoreau reminds us “For every thousand hacking at the leaves of evil, there is one striking at the root” Not that the PMI is evil, but if we are to change the world of project management, then the PMI is a great place to start.

LWOK
My talk covered what’s new with Agile Project management and I was glad to be able to announce the Agile Project Leadership Network (APLN) LWOK program approved just a few days before.

While the PMI has its Project Management Body Of Knowledge (PMBOK) as its core set of agreed practices, little exists yet for agile project leaders. There are great resources scattered around different web sites, but no place we can point people to and say “go and start here, it will get you on your way”.

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.

   

I’m heading off to the Agile 2007 conference in Washington DC next week so you can probably expect a short gap in postings here as I take in the sessions and events there. This year’s conference sold out early as it was capped at 1100 people due to venue capacity. Next year’s conference will be in Toronto and there has been a good dialogue on the Agile Alliance board recently regarding the objectives for the 2008 conference including optimal size and format.

An element I have suggested for inclusion is a stronger community involvement. On agile projects we let the users prioritize the requirements and I would like to see a similar approach used for Agile 2008. Agile Alliance members could be encouraged to suggest a conference theme and asked to vote on the splits for conference tracks (development, testing, project management, etc) as well as the formats (presentation, Open Space, workshops, etc).

The same could work for selecting presentations and papers too. Why not employ the Wisdom of Crowds and Participation of Crowds in choosing presentations also? Rather than having only a selection committee, give members the facility to vote for presentations using modern web 2.0 collaboration tools. Or if that is too radical and a selection committee is required to ensure a balanced mix of programs across the spectrum of agile methods, at least give 50% of the voting power to the agile community.

The tools to allow such mass collaboration are already available and being used by Amazon in UnSpun and Cambrian House in RobinHoodFund. I’m sure Agile 2007 will be a great conference and with more user participation, Agile 2008 can break new ground in user driven content.

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

I’m presenting a beginners session on Agile Project Management entitled "...But it's not on the project plan!" at the Agile 2007 conference in Atlanta next month. It is targeted towards traditional PMI based project managers and I thought it might be fun and perhaps even useful to give them an Agile to Traditional language translator.

So, like a French / English : English / French Dictionary here are some translations to help the two camps communicate. This dictionary is also available as a PDF for download, the link at the end of the article.

Agile to Traditional

Adaptive - Frequently responding to changes and learning’s on a project by changing the plan, priorities, and/or approach. Agilists believe changes are good!

Agile Methods - A set of development methodologies characterized by being iterative, adaptive to changes and learning, value driven, low ceremony, and encouraging empowered teams.

Backlog – The prioritized list of stories, features, or requirements that the project works it’s way through. The closest thing to a list of requirements a traditional PM will find.

BDUF – Big Design Up Front a condescending term given to large efforts invested early in the project to define requirements or design before building some functionality and getting feedback from the user community.

Burn Down Graph – a project reporting trend graph popular in Scrum used to show the progressive reduction in features or estimated work remaining on the project.

Burn Up Graph – a project reporting trend graph that shows the total number of stories (or features) delivered to date on the project.

Continuous Integration – the process of building and testing the system upon the check-in of any code. Examples of continuous integration tools include: TeamCity and CruiseControl

This site has been included in the latest “Carnival of Agilists”, a bi-weekly collection of agile related posts, that introduces people to agile sites they may not be aware of and probably produces some Google page ranking uplift due to all the cross referencing.
   

Anyhow, the collection is well worth checking out and I particularly enjoyed the overview of the new Certified Scrum Coach proposal posted by Pete Brehrens and the list of Top 10 Agile Development Web Sites posted by Kelly Waters.

Kelly writes such snappy, engaging posts; I need to learn how to do that! Enjoy.

Here’s the last instalment from my Developments in Agile Project Management Paper. Last time I wrote about Accreditation and Generation Y. Today I cover Leadership, Lean and Six Sigma, and Tool support.

    

You can download the full paper with the additional intro to agile and post-agile sections at the end of this post.

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

Earlier this year I submitted a presentation proposal for the PMI Global Congress conference held in Atlanta this October. I called it "Developments in Agile Project Management" and wrote up a pretty seductive outline that got accepted. That is all well and good, but now the accompanying paper is due and I have to decide what to write about!

I felt a little guilty submitting a proposal when I did not know what I was going to talk about, but in the agile spirit of delaying decisions to the `last-responsible-moment` it gave me the flexibility of including some late-breaking new discovery or trend that may have been missed by locking-in early. Plus, it is not as though I have nothing to present, rather that my choice of topics had not been finalized.

So, in this and my next couple of posts I will outline some of my thoughts on "Developments in Agile Project Management" and offer an open invitation for readers to provide feedback and suggest alternative topics.

The Audience
The typical PMI conference attendee is not very familiar with agile methods. While the title will likely attract those who do know about agile, the majority will still only have a passing awareness of what it is all about. So I will have to keep the content fairly basic and prefix it with a quick tour of agile concepts to provide context. I`d love to present on something like `EVA to Andons: Mapping traditional metrics to agile-lean indicators`, but only a few people would understand it and many others may leave with the impression agile is just mumbo-jumbo and not for them. So, I think the topics should remain fairly basic to engage a large proportion of the audience.

Outline
My thoughts on the structure currently go like this:

Introduction

• Agile methods have been gaining in popularity for software development projects
• As they are becoming more popular, new people are expanding their boundaries and application areas

Why software development is hard to manage

• The intangible nature of software
• Difficulty articulating true requirements
• High rates of change
• High complexity, sometimes R&D based, unprecedented

How Agile methods help

• Incremental delivery provides frequent checkpoints
• Iterative development reduces technical risk
• Lifecycle supports late breaking changes

How Agile methods work

• Business Prioritization
• Timeboxed iterations
• Communications and constraint removal
• Reviews, Retrospectives, acknowledgements and adaptation

Then once this overview is out of the way, introduce the topics that can be thought of as "Developments in Agile Project Management":

Accreditation – Like when children grow up and progress from playgroup to school and start experiencing exams, accreditation and certification in agile methods are increasing as we leave the kindergarten.

Redesigning the workplace to attract and retain Gen Y`ers – how the new generation who “grew up digital” and are now entering the workforce demand: inclusion, collaboration and empowerment – handily the approach promoted by agile methods.

Recognizing the link to leadership – how agile project management is more closely aligned to leadership best practice than traditional project management.

Support by tools and processes – How a new segment of agile project management tools and processes have emerged to support agile projects.

Integration with adjoining fields such as Lean Six Sigma and the Theory of Constraints – How the boundaries between agile and these highly compatible fields are disappearing as a broader audience adopt agile and bring their own contributions and links.

This is probably more topics than I should attempt to cover in a paper or presentation but I wanted to get my ideas out there and ask for alternatives. If you where giving a presentation on "Developments in Agile Project Management" what would you include and why?