The Agile PMO

Two New Resources for the Agile PMO

I am always on the lookout for additional resources related to Agile PMOs and I have a couple of new ones to share with you.  

The first resource is an updated webinar from Sally Elatta called, Tranforming to an Agile PMO.  Sally is the President of Agile Transformation, a company I've begun working in January of this year.  She is also the Agile Expert for the PMI Learning Education and Development Community of Practice and that is where she delivered this webinar on March 7, 2012.

I love this webinar!  At just over one hour, it would be a good use of time for anyone interested in understanding how Agile can impact not only the PMO, but the entire organization.  I plan to do a more thorough review of Sally's webinar in my next post but wanted to get it out to you now for your enjoyment. 

The second resource is a whitepaper by Kevin Thompson, Phd called, The Agile PMO.  Dr. Thompson does a good job of laying the foundation for the analysis of how Agile (mostly Scrum) impacts projects, programs and portfolios.  It is a rather ambitious undertaking, and while he makes a good dent in it, he falls a little short of fully addressing the topic. Still, it is well organized and a valuable resource.

One thing I really like about the paper is the framework Dr. Thompson sets up for reviewing project management, program management, and portfolio management.  Taken from the PMBOK Guide and the standards for Program and Portfolio management, his framework provides a clear way of looking at the differences of projects, programs and portfolios in a well organized manner.

Dr. Thompson sees the greatest impact for agile at the project level, with less impact at the program and the least impact at the portfolio level.  When he looks at the impact of agile, he's really looking at Scrum and Commitment Based Project Management (CBPM).  In any case, I think his conclusion about the impact at the project level understates the impact on the program and portfolio.  This is the main area where I feel that his paper comes up short.

Agile processes have less effect on the practices of Portfolio Management than for Project or Program Management. These effects are limited to the details of what information is gathered about current projects, and how that information is gathered, rather than prescriptions for how specific Portfolio Management practices are to be conducted.

Applying agile and lean thinking to the portfolio is an area where many agile thought leaders, including Sally Elatta, see a huge potential for improvement. By adopting lean portfolio techniques, and prioritizing and limiting the number of projects that are underway at any one time, organizations are actually able to get more work done with the same number of resources. 

The situation in a recent consulting client illustrates the point.  The IT team had significant resource constraints and most resources were already allocated to 2, 3 or more projects at the same time.  All of the projects were critical, and none could wait.  At the same time, little true progress was made on most of the projects, and key deadlines and milestones were routinely missed.  In response to demand from the business stakeholders, the IT group continued to launch new projects, fully aware that they were continuing to re-commit the same people who were already committed to other projects.  This provided the illusion of progress, though the reality was just the opposite. 

The antidote to this crazy behavior is to allocate resources to dedicated teams, prioritize the project work into a ranked backlog, and then have the dedicated teams complete the backlog as quickly and efficiently as possible.  Thompson makes brief mention of this approach in his paper, though I think he significantly understates the potential improvement for most organizations.

Although specific practices of agile processes do not prescribe how the day-to-day work of a PPMO are performed, the concept of Portfolio Management is well aligned with the Agile Manifesto, and especially the core principle of valuing “responding to change over following a plan.” Agile processes frequently re-assess the value provided by near-term deliverables, and optimize value delivery by selecting highest-value items for implementation.

Portfolio Analysis does essentially the same thing, but for longer time horizons (quarters to years), and on a project or program basis. Viewed in this light, Portfolio Management is analogous to managing the “Product Backlog” of an agile project, with projects and programs taking the place of Stories and Epics .

Thompson makes it a point to state that Agile makes the biggest difference at the tactical level - a statement that I don't necessarily agree with.  While there are significant improvements to be gained from applying agile at the project or tactical level, if applied properly as described above, agile helps to prioritize the organization on the projects that are most important or strategic to the organization.  By reducing the number of projects underway, and focusing on what is most important to the strategy of the organization, I think you can state that Agile actually helps achieve the organization's strategy.

One thing I do agree with is Thompson's closing comment.

One of the benefits of the development of Agile processes is to provide a unifying theme for how to view and plan for the future, one which goes all the way from the portfolio level down to the project level.

Give Thompson's paper a read and let me know if you agree.  And tune back in to the next post so that you can see what I write about Sally Elatta's webinar.

Cheers!

Anthony

Complacency kills!

I was reading a recent article from The Economist about the recent decline and near death of Kodak.  The article is called "The last Kodak moment?" and the subtitle is, "Kodak is at death’s door; Fujifilm, its old rival, is thriving. Why?"

It is an interesting read, especially the comparisons drawn between two organizations with the same core business and different strategies for survival.  Fujifilm is alive and well and Kodak isn't, and the reason seems to be the decisions made and the level of urgency with which they addressed the threat to their core business. 

Reading the article, I couldn't help but think of the typical PMO, in response to the growing popularity of agile methods.  I am not suggesting that agile methods will put the PMO out of business, but it does change the need for the PMO, the role of the PMO, and the role of project managers in the organization.  PMOs need to adapt and leverage the new methods and concepts that agile offers.  The alternative is to resist change, to justify and focus energy on current methods, and to ultimately become an impediment.  Agile enthusiasts know what happens to impediments.

I've recently seen the ugly face of resistance up close.  In a recent agile transformation project, the biggest resistance was seen from a PM that had transitioned from the PMO to be a scrum master.  Unfortunately for this individual, she continued to focus on the priorities of the PMO (budgets, status reports, and related projects) rather than their new duties of scrum master (coach and facilitate the team).  I don't know whether this was a fallback to the familiar and comfortable, hostility toward the agile introduction, or simply a resistance to change.  Whatever the cause, the result was an ineffective scrum master who was holding back her team.  She became the team's impediment.

Harvard professor John Kotter published a book in 2008 called A Sense of Urgency.  You can get a taste of the book from Kotter's 11 minute video interview called The Importance of Urgency.    He talks about the rate of change in the world today and the importance of leading change in organizations with a sense of urgency.  Organizations that don't change and adapt fall behind.

Kotter also noted a natural tendency for individuals and organizations to become complacent.  He suggests that we need to guard against the tendency for complacency.  Kotter claims that all organizations are at risk of growing complacent, even those as progressive as Google.  Even the largest and technically advanced firms fall prey to complacency.

Is your company, department, or team complacent?  Is your PMO complacent?  How do you think they would compare to Google or Kodak?

Complacency kills.  Be a change agent instead.

Anthony