Agile methods are best suited for small projects. Women are not suited for extreme endurance events like marathons and ultra (beyond marathon) races. Oh, how conventional wisdom seems ludicrous after being proven wrong time and time again.

“The heresy of one age becomes the orthodoxy of the next.” - Helen Keller

I have been doing more trail running this year, and some ultras. It is great to see the sport is not male dominated and many events are won outright by women. Before the 1980s, there were no women's distance races in the Olympics at all; 1,500m was the furthest race distance allowed for them. Before 1972, women were barred from the Boston marathon and most other marathons.

Pam Reed beat all the men in the Badwater 135-miler two years in a row. Local girl Ellie Greenwood, often beats all the guys in her ultra races. Scientists believe women may metabolize fat more efficiently than men for better fuelling and that estrogen may delay mental weariness. I just know there are lots of ponytails passing me on the trails, and am good with that.

As women go from being thought of as too frail to run marathons to kicking major butt in ultra marathons, so too do agile methods. First described as “light weight” and only for small, co-located teams, we are now seeing more and more use of agile methods in truly huge, distributed, complex projects.

At last year’s Agile Business Conference in London I learned about Nokia’s massive agile roll-out where 1,800 software developers are using agile techniques to develop the Symbian mobile phone platform. This immensely complex endeavour is tightly coupled to quickly evolving hardware, divergent phone standards, and a variety of different cell providers worldwide. Using a variant of Dean Leffingwell’s “Agile Train” approach they are scaling agile to tackle a very complex domain and produce rapid, high quality results.

At this year’s PMI Global Congress last week Richard Spires CIO of the Department for Homeland Security (DHS) spoke about his role overseeing $6.5 billion of IT focussed spend annually. He has 91 projects greater $50M in his portfolio. So, how does he and his team manage it all? “With more and more adoption of agile methods” he said. It is the only way to keep up with the complexity and high rates of change required for this massive portfolio of projects.

Agile started small, and this is still my recommendation for companies looking to adopt it, but do not limit its application or growth there. Command and control structures get heavy and slow to change as they scale up. The weight of the control system seems to over burden the operation of the functions. Perhaps the lighter weight of agile methods can actually be an asset to solving truly huge projects by not smothering operations as they expand?

I think we will be seeing more accounts of ultra sized agile projects in the future.

I will be at the PMI Global Congress in Washington D.C. next week presenting on “Reoccurring Resistance to Agile Adoption and Lessons Learned” for successful implementation. Later in the week I will be teaching my SeminarsWorld 2 day Agile Project Management Class.

I am looking forward to the conference, it will be an opportunity to reconnect with members of the PMI Agile Community and attend sessions from the Agile Track.

With all this PMI stuff I have reported recently, you could be forgiven for thinking I have crossed over to the dark-side, but this is not the case – it is just where the action seems to be at the moment.
This last week I also presented at the Agile Tour Calgary event and attended the Calgary Agile Project Leadership Network (CAPLN) season kick-off event to maintain some agile connections too.

The camps are finally blurring now, there are so many agilists with a great understanding of traditional project management and traditional project managers experienced in agile. I really hope in 5-10 years the terms agile and traditional will be obsolete and dropped since everyone will be using a smart new mix of lean, kanban, agile, TOC + whatever better comes along.

Q: How do you write a new version of the PMBOK Guide? A: Very carefully

Development of the PMBOK v5 Guide is underway and I was on the content creation group for Chapter 12 Procurement as explained previously. However, I was transferred onto the group for Chapter 6 Time Management. Apparently, I am a last minute swap to bring an agile perspective to Time Management. All I know is I am very grateful to be there and will likely learn a lot.

I am bound by NDAs to not reveal any content, but Chapter 6 is interesting since the current PMBOK v4 edition contains the processes of:

6.1 Define Activities
6.2 Sequence Activities
6.3 Estimate Activity resources
6.4 Estimate Activity Durations
6.5 Develop Schedule
6.6 Control Schedule

From an agile perspective, the way these processes are currently outlined seems to assume a certainty of final scope from the outset that is at odds with some of the evolutionary concepts of agile. So it will be interesting to see how development of these concepts progress.

Predictably the Time Management group seems a deadline focused bunch and we have had a couple of long conference calls already. Before suggesting new content for the 5th edition we are first reviewing the suggested changes that were made against the 4th edition, but for whatever reason (timing, complexity, knock-on impacts, etc) did not make it into the 4th edition.

Reading the PMBOK text, reading the suggested change, and then discussing as a group the merits of the change is necessarily slow, but really illuminating for me. Our facilitator has a great knowledge of previous editions and can describe the changes from version 2 to 3, version 3 to 4, and can explain why the previous changes were made and some of the likely impacts of the suggested changes we are discussing.

Some interesting considerations focus on clarity. Because the guide is translated into so many languages and that the English version is read by people whose first language may not be English, there is a strong emphasis on being clear. Also, terms that may be common place in IT like “technical dependency” are apparently not common place in other project management disciplines and so not used.

So, it is a journey, with collaborators from all over the world which makes it more fun. Who knows how much agile content and ideas I will be able to introduce, but I will be trying.