Here is an update on the agile happenings at the PMI that I have been involved with. The pilot program for the PMI Agile Certified Practitioner filled up fast. 2,649 people opened applications for the program, a record for the PMI, and the full launch in October is looking like it will be very popular. Item writing for the exam questions is on track and Registered Education Providers (REPs) are in high-gear readying their courses.

The PMBOK v5 Guide continues to move forward too. My work is on Chapter 6 (Time Management) and we recently reviewed and incorporated the second round of approved comments. There was a meeting this weekend to review all chapter comments along with the updated Inputs, Tools, Techniques, and Outputs (ITTOs). I have suggested some agile content I am not able to discuss under the NDA, but I am hopeful it will survive the approval process. Other Chapters have agile content being suggested too. This is a slow process though and the PMBOK v5 Guide is not expected until late 2012.

I was also recently contacted about working on an Software Extension to the PMBOK Guide. This really excites me and is something I looked into leading a few years back (before I discovered the full extent of the work involved). There has been a call for Agile experts to help develop the new extension.

If you have ever looked through the Extension to the PMBOK Guide for Construction, you will know that the extension does more than add a bunch of industry related practices. It also suggests changes to the existing PMBOK’s outlines. So, for instance, instead of creating a detailed WBS, we could suggest creating a candidate feature backlog. Many of the suggestions for change to the PMBOK Guide have to be tempered with the fact that the guide has to remain industry agnostic and suitable for any project manager. An extension for the Software Industry allows us to go much deeper into agile techniques. I am looking forward to this work and learning who else is involved.

Finally the PMI Agile Community of Practice continues to grow and develop. I learned that Michele Sliger’s recent webinar had over 500 people in attendance. This is great and a sign of the levels of interest for agile present in the ever expanding PMI community. Taking agile to the PMI that used to have this “evil empire” feel felt audacious eightr years ago, now it seems natural and if anything, belated. People have strong opinions and the PMBOK Guide work has shown me that many people still dismiss agile methods, but it feels like the tide is coming in and neither King Cnute or the diehard traditionalists will stop it.

The 2011 Agile conference goes back to its roots this year, returning to Utah 10 years after the creation of the Agile Manifesto there in 2001. I won’t be there this year, since I’ll be taking advantage of Canada’s short summer to take part in the TransRockies mountain bike race.I was disappointed to be missing out on the conference, but am more excited by this multi day race through my backyard mountains.

Then, last week I heard of some other agile events that I can attend. The DSDM consortium is holding Agile roadshows in Cambridge and Newcastle. It will be great to catch up with Steve Messenger and others from Napp Pharmaceutical. Then there is “Agile on the Beach” happening in Cornwall, where I grew up, this September. So for me this year, I will not be joining my usual North American agile friends for their back to their roots conference, but will be embarking on my own back to my roots agile conference tour. Likely lower key, but I always manage to learn something new and make some good connections.

Washboarding is an instability that occurs when vehicles move on dirt roads. What starts off with a small bump turns into a whole series of small bumps as vehicles travel the road. Washboard roads are more dangerous than smooth dirt roads and have to be driven at lower speeds. All these bumps are a pain in the rear (literally) and make you go slower.

We see the resourcing equivalent of washboard roads in projects too. Traditional projects staff early with business analysts to do the bulk of the requirements gathering and then bring in developers and finally QA people. These peaks and valleys of specialization not only look like a washboard road, but they have the same effect, they are a pain in the rear and make you go slower.

 
Because the BA’s, devs, and QA’s are not used evenly throughout the project, they are brought in for a short period and then transferred to the next project. People try to share BA’s, QA’s and other roles between multiple projects and pretty soon most people are working on multiple projects. This is very difficult to schedule efficiently because projects rarely sync up exactly or stay on plan. Worse, task switching between multiple projects is time consuming, prone to errors, less satisfying, and a slower way of working.

Just as preventing washboarding on a road is difficult once it has started, breaking the resource washboard anti-pattern can be difficult too. A concerted effort and decision to staff whole team projects needs to be made. Acknowledging that it is impossible (or at least extremely unlikely) that all the final requirements can be captured up front, keep the BA’s around. Engage the QA team early so they hear from the business firsthand what they should be testing for, and encourage developers to work with the BA’s and QA’s beyond coding. Whole team staffing breaks down silos and prevents throwing things over a wall to another group that is inefficient and error prone.
 

Bringing the whole team together at the beginning of the project allows them to work collectively on vertical slices of the solution through to completion. Multidisciplined teams can help each other to minimize resource constraints and since the team swarms around solving small increments, there is no task switching penalty when asking for help.

Just as the advantages of smooth roads over washboard is clear to everyone, so too are the benefits of dedicated, collaborative teams. Dirt roads and small bumps lead to road washboarding, as specializations, functional groups and matrix management leads to resource washboarding.

Executive management are the best bulldozers, they can mandate the change and pave the way as it were. If you do not have that level of commitment, break the bumpy cycle on the projects you can control. Recruit combined BA/QA staff and keep them throughout the project, get all roles in the design sessions, and business discussions, resist task switching and prioritize projects. Then see how much faster you can go.