Interested in understanding what more than 900 product development professionals had to say in the 2nd Annual Product Portfolio Management Benchmark Survey and how your organization compares? Join me, Carrie Nauyalis of Planview, as I present for the Georgia Chapter of PDMA's event, Bagels and Brains on February 15th. I will explore key trends and takeaways revealed via the survey, and understand answers to questions like: How has the recession affected the product development process? What are the biggest challenges for today's product-driven company? What tools are product development executives planning to use? How do your peers integrate the voice of the customer into the product development process? What changed from 2009 to 2010? You won't want to miss this session.
On the surface, portfolio management and agile programming are not that similar. Look deeper, and there are some interesting parallels.
I learned about Extreme Programming and the Agile Manifesto seven or eight years ago when I had the pleasure of reading Kent Beck's book, Extreme Programming Explained, and by happy serendipity, was able to work with him. I quickly became a huge fan of Kent and Extreme Programming and have used it on every project since then. Extreme Programming, which I consider a synonym for Agile methods for all practical purposes, is built around four principles: Communication, Simplicity, Feedback, and Courage. As expressed in just four words, this sounds like faddish obscurantism. But if you have ever run a troubled software project, you understand how Courage applies, and if you don't understand the value of Simplicity, you have never run a successful software project. Communication and Feedback are, and always have been, the key to feedback, leadership, and customer happiness.
What might be seen as the flip side when I read Taming Change with Portfolio Management coauthored by Planview's CEO Pat Durbin, I saw that the two systems really attack problems of different scales from the same basic principles.
One of the most striking statements in Taming Change is a very agile one the exhortation not to try to plan too far in the future, or at too fine a level of detail. The time scale that Durbin recommends is 6 months to 18 months, which is clearly very different than the 1-2 weeks for a Sprint in Extreme Programming. I think, however, it represents a reality: large organizations cannot (yet) be planned on a weekly scale. Nonetheless, the organization that constantly becomes more agile by constantly improving its ability to change its plans and to plan on a smaller time scale will ultimately succeed against less-agile competitors. Note that nimble planning does not mean detailed planning; it means just-the-right-amount of planning.
Allow me now to draw some analogies between the two systems. Time precludes me from giving full definition of these terms, but if you study them in Taming Change and the lore on Agile Methods I think you will agree the analogy between the two systems is striking:
|Portfolio Management||Agile Methods|
|Portfolio Management Officer||Scrummaster|
|Executive Staff||Product Owner|
|Organizational Transparency||Personal Communication|
|Project Status||Customer Feedback|
|Planview or Portfolio Management System||Big Visible Charts Taped to the Wall|
It is clear to me that the founders of the two systems shared similar principles, and built functional systems out of them:
- Honesty and transparency lead to good decision making.
- Metrics and abstract metrics help to keep us honest.
- Organization machinery is valuable to the extent that it helps an enterprise adapt to change, and an impediment to the extent that it doesn't.
Climbing out of Spreadsheet Hell (109 KB)