Scrum PPM: Agile principles applied to Project and Portfolio Management

Here's a good video on how to incorporate a Cost/Benefit Analysis (CBA) to an Agile development process:




As I have just recently acquired my ScrumMaster certification from a workshop presented by none other than the co-founder of Scrum, Jeff Sutherland, I am now trying to find a way to realize the full benefits of Agile/Scrum especially as it applies to fields outside of software development that it derived its roots from and is closely associated with.

One area in particular that I am especially interested in applying Scrum to is PPM and portfolio management and optimization in particular. I ran across this article on Scrum Alliance and it outlines the basics of what I have in mind:

Treating your project portfolio like a backlog of stories means you are able to say, “no” to projects earlier, releasing resources to other projects. That’s good; but what’s better is that, instead of a black or white world, where projects are being canceled or not, you have more options. Consider these scenarios.

A portfolio manager realizes after two iterations that Project A will not return the promised marketing forecasts. The project’s priority drops and its resources are freed for other more lucrative projects. The project’s achievements, though, are stored; the project has simply been moved into the agile portfolio—returned to the backlog, so to speak.

The originally proposed features list for Project B is 80 percent complete. The project is far beyond delivery date and the competition has announced an impending release whose features are similar to the ones that have been completed to date. The portfolio manager decides to stop the project

Project C is a proposal that initially sounded very promising and relatively easy. After only one iteration, though, reality has proven the feasibility study wrong. Rather than waste any more time, executive management decides to cancel the project and remove it from the agile portfolio entirely.

Notice how in all of these scenarios, there was no stigma attached to modifying, delaying, or canceling a project. “No” has lost its sting. Because the investment in each project was minimal, the cost of returning it to the backlog or changing its parameters was also minimal. That’s powerful. That’s agile.

Johanna Rothman, famed Agile practitioner and author of Manage It!: Your Guide to Modern, Pragmatic Project Management, states that when organizing an Agile portfolio, she asks these 4 basic questions:

1. How strategically important is this set of work?
2. Do all these things look like they'll fit into one iteration?
3. How does this iteration fit into all the releases we'd like to do?
4. Is there anything preventing us from completing a particular iteration? (Or is there a reason to order features in a particular order?)

When viewed from the lens of a traditional PPM point of view, question 1) asks you to prioritize the projects based on a company's strategic initiative, 2) is really asking whether you have the resource capacity to do the work, 3) is whether it will impact scope/requirements and 4) is whether there are any roadblocks (impediments in Scrum terms) that will effect the performance (or velocity in Scrum terms) of the portfolio.

The following figure from Lee Merkhofer, a well know practitioner in the field of decision analysis techniques for prioritizing portfolios provides a flow diagram that parallels the questions just outlined:


Interestingly, there is really little divergence from the questions and procedures outlined by the Agile and Traditionalist groups, except that the latter has a bit more formalisms in their terminology and process. In my mind, both movements have always adopted the notion that you would have to loop back into your process if scope changes occurred (which they almost always do), and the difference is that the Agile group have been more explicit about it and needed to create a new vernacular to describe their process so as to differentiate themselves from the waterfall movement. PMI in their upcoming 4th edition of the PMBOK seem to be trying to bridge this gap and is a topic I wrote about before.

The diagram below shows how easy it is to reconcile the two movements:


Regardless of where one stands in relation to these two movements, the most important factor is that effective PPM management is more than just the collection of status reporting of a group of projects for a specified date, but also forecasting the delivery time, scope and cost of those projects and how that will impact the overall business initiatives of the company. Without this capability, we are not able to take true portfolio decisions – such as reallocating investment from one project to another, or canceling underperforming projects – to maximize ROI.

But once an organization has realized and achieved such a state, the organization has moved beyond traditional PPM, and is now engaged in Portfolio and Investment Optimization (PIO) and would be looking to utilize such portfolios of investments to capture new markets and/or become a disruptive force in their industries. Traditional project management is typically concerned with what is known as the "triple constraints" of time, cost and scope, but an organization involved with PIO would be elevated to a new triple constraint of priority, capacity and objectives:


The need to balance the constraints of time, quality and scope to maintain the quality of the projects and portfolios would be elevated to the balancing of priority, capacity and objectives to maintain the performance and velocity of the portfolios and investments of the organization.

By adding the descriptive, empirically based framework of Agile/Scrum to the prescriptive, process based framework of the Waterfall/PMBOK we can have the best of both worlds: e.g., time tested and proven methods of traditional project management and the unadulterated transparency that exposes to everybody whether the best decisions relative to the business objectives are being taken given current information at the moment of decision and if not to go back and fix the problem through iteration.

By integrating and utilizing these practices on a consistent basis, would an organization be truly engaged with the kind of forecasting and trend analysis at the enterprise level required of a PPM system allowing it to build an optimized portfolio of projects and investments. At this level it could develop truly meaningful, time dependent models that would allow the organization to determine demand capacity, prioritization of important project investments, and shifting requirements of its total portfolio. This is the foundation of PPM that maximizes the efficiencies to obtain ROI.

The expanding scale and scope of Agile

Here's an informative webcast on the scalability of Agile development/project methodologies:



What's most informative about this video, is the underlying acknowledgement for the need to scale Agile methods to larger, even enterprise wide organizational levels. Much of the reason for the success of methodologies such as eXtreme and Scrum was that it was employed in mostly small, co-located teams, which allows for the facilitation of self-organization and governance, as well as close interaction with stakeholders.

But many projects and IT initiatives have expanded throughout the enterprise, which have caused the need to adopt a more centralized, process driven methodology. A recently published book, titled The Enterprise and Scrum is attempting to address this issue, and has had mixed reviews on Amazon and lukewarm acceptance within the Agile community, at least as I've seen it.

Likewise, the Project Management Institute specifically via the PMBOK, has been criticized for being too centralized and process heavy, and not being "Agile" enough. While good for industries such as defence, aerospace, construction and other large infrastructure projects, it is not agile enough for software, Internet and other fast paced high tech industries.

What I think will happen, or should happen, is a merging of techniques from process heavy methodologies such as PMBOK, CMMI, etc. with Agile, into a more flexible, adaptive methodology, that can still be systematically scaled and centralized as needed.

Japanese Origins of SCRUM

I'm going to be giving a presentation tomorrow to my work colleagues on the origins, concepts and philosophy of the agile project framework called Scrum. As I am currently taking weekend classes as well as self studying for the PMP certification exam, the whole topic of project management has been on my mind quite a bit. Studying the traditional project management methodology of PMI in conjunction with research into Scrum for my presentation, has been an interesting study into the contrasting views with respect to project management from both sides.

This is not to say that either is right or wrong, or better than the other, but one is geared toward the dynamic and ever changing nature of software development [Scrum], whereas the other is a general framework for ALL kinds of project management endeavors. A blog for a book I just purchased, called "Head First PMP" acknowledges this, as they state "the PMBOK wasn’t written specifically for developers. A lot of projects that use the PMBOK processes and principles are things that you can’t do iteratively — like, say, highway construction or building a skyscraper... These are things that Agile doesn’t address because they’re just out of its scope."

The most interesting thing that though, that was revealed in my research into Scrum, was a reference to a paper by Hirotaka Takeuchi and Ikujiro Nonaka titled "The New New Product Development Game" which was referenced in the original book by Ken Schwaber titled quite appropriately "Agile Software Development with SCRUM". Published in the Harvard Business Review in 1986 it was a landmark paper and had many ideas in it that are now quite fashionable both in Agile project management and the general business landscape as well.

On the very first page is where the Scrum metaphor is defined as "a holistic or 'rugby' approach — where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements." But to simple assign this paper as the backdrop for how Scrum got it's metaphorical name, is to do a disservice to a short paper with some very profound ideas on management.

They highlight 6 main aspects to their management framework, which include the following:

1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

Any one of these topics could be a whole research thesis on their own, but they are at pains to emphasize that all these ideas must be taken as a whole and have full involvement from both the implementors and management at all levels. This is in agreement with the Agile community, especially with its emphasis on customer involvement since without their deep involvement and commitment, the whole notion of phased deliverables would not be possible.

I like Takeuchi and Nonaka's very modern ideas of employee autonomy and self transcendence that is achieved with self organizing teams. As they state "the project teams appear to be absorbed in a never-ending quest for 'the limit.' Starting with the guidelines set forth by top management, they begin to establish their own goals and keep on elevating them throughout the development process. By pursuing what appear at first to be contradictory goals, they devise ways to override the status quo and make the big discovery."

There are many other modern ideas such as giving employees an allocated time away from work to pursue independent research much like Google does today. The site 3M at the time who "encourages engineers to devote 15% of their company time to pursuing their 'dream.'" I would definitely appreciate my company encouraging such a thing!

I especially think their ideas of "multileaning" or what we would now call "cross functional" teams is a pretty important idea. There's a problem especially in the technical fields such as software development, where developers can get compartmentalized into a specific role and tagged as being the "Java guy/gal" or "DB guy/gal" and pretty much do nothing but that. This not only leads to burn out, but also keeps them aloof and completely ignorant of what other team members are doing. This is not to say that Designers should start coding C# or Business Analyst to build web pages, but using something like pair-programming with pairs from different departments would allow teams to better understand and appreciate what the other members do as well as picking up and possibly taking on a new skill set they might otherwise have not know they had an interest in.

In the final paragraph, they conclude "multinationals must achieve speed and flexibility in developing products; to do so requires the use of a dynamic process involving much reliance on trial and error and learning by doing. What we need today is constant innovation in a world of constant change." This was stated more than 20 years ago, but is more relevant today and will be so for the foreseeable future. It's has been both enlightening as well as a little sad that many companies then and today have yet to come to grips with this.

I highly recommend getting a copy of this paper and referring to it periodically if you are in involved in project management or any kind of business for that matter.