CIOs and IT PMO Directors are increasingly asking the question, “How might I manage a hybrid portfolio of both Agile and traditional projects—and can I do so in a way that might actually improve portfolio performance?”
There is usually no small amount of pain and suffering fueling this question. Often this pain results from well-intended attempts to impose Agile adoption on all projects, only to find that project-level successes with Agile rarely seem to translate into portfolio-level improvements. Other times, the suffering arises from the “culture clash” between Agile zealots who view their more tradition-bound colleagues as dinosaurs that refuse to evolve, and disciplined traditionalists who view their Agile peers as petulant children that refuse to plan or document their projects. CIOs and IT PMO Directors are now seeing this “religious war” spread rampant disunity among their teams, degrading the performance of their project portfolios; some have even felt pressured to align with one side or the other, leading to Soviet-style purges of members of the opposing side in a few extreme cases.
When cooler heads prevail, however, IT executives have begun to ponder the notion of a “best of both worlds” scenario. What might such a hybrid portfolio look like? When should we use Agile, and when might other approaches make more sense? How might we have traditional project team members and scrum team members help each other’s teams when beneficial to the portfolio at large? How can I realize speed and reliability improvements on both Agile and traditional projects? Are there beneficial techniques that can be commonly applied to both? The remainder of this article attempts to address each of these questions in turn.
1) What might a hybrid Agile/traditional project portfolio look like?
Regardless of project-level methodology, IT executives need all projects in the portfolio to have a defined scope, schedule, and budget, with assigned resources and appropriate levels of buffer to protect each project from risk. This doesn’t necessarily mean that I must have a super-detailed, fully refined scope and resource-loaded Gantt chart at project kickoff, but it does mean that all projects must be planned, and that all plans must drive project execution through to completion. (At this point, many traditionalists among you are saying, “Well, duh!” while some of you Agile die-hards are thinking you might prefer a root canal.)
In the case of Agile projects, the buffers will nearly always be scope buffers (aka “desirement sprints”), while traditional projects tend to use a mix of schedule, scope, and budget buffers. As long as all project buffers are visible and presented consistently, the portfolio manager will be able to balance them across projects to maximize portfolio reliability.
Ideally, this portfolio will have staggered projects that avoid assigning any team member more than one task at a time, and which identify the team members and resource types that drive the throughput of project completions across the portfolio—in other words, the resource-loaded critical path, or “critical chain.” This may sound like PM “geek-speak,” but it’s actually a high-powered way to identify portfolio-level resource bottlenecks, and jack up the throughput of project completions within existing resource constraints…pretty important stuff, right?
2) When should I use Agile, and when might other approaches make more sense?
Agile is appropriate when most assigned scrum team members are properly trained—and ideally, experienced—in using Agile/Scrum techniques. But that’s only the beginning. The project sponsor (or “product owner”) must be willing to devote the additional time necessary to participate in sprint reviews, sprint retrospectives, and perhaps even daily scrum meetings. Further, a scope buffer must be appropriate as the primary project buffer—of course, this is not always the case, and can be a major cause of friction between scrum teams and product owners. Last, the scrum team members must understand that, while self-management and the integrity of the team is encouraged at the project level, they are first-and-foremost portfolio resources that can and should be redeployed on other projects if and when the portfolio may require.
In all other scenarios, more traditional project methodologies will likely make more sense. This doesn’t mean we give up hope for speed and reliability benefits, however—see #4 below for a discussion on that.
3) How might we have traditional project team members and scrum team members help each other’s teams when beneficial to the portfolio at large?
First, we must make sure we’ve resource-loaded Agile projects with individual scrum-team members, as opposed to just lumping all members into a single “Scrum Team A” type of group resource definition. While this may sound like heresy to many Agile practitioners, the practical reality is that there will be many times when members of a given scrum team are truly underutilized or even idle, and can better support the needs of the portfolio by taking a task (or sprint) on another project. As long as task/sprint-level focus is maintained for that individual for the entire task/sprint duration, helping out other projects once in a while should be accepted as normal and desirable.
What about the other way around, when a member of a traditional project team with no Agile/Scrum experience or training might be called upon to take a task on an Agile project? This is not as big a problem as some have made it seem; while some Agile training and familiarity is certainly preferable, the more experienced scrum-team members can usually provide enough context and guidance to the uninitiated to get them productive with minimal ramp-up time. A wonderful side benefit of this is that it usually helps cross-pollinate project teams with knowledge and experience that is beneficial to the portfolio as a whole, while discouraging zealotry and the disunity that it engenders.
4) How can I realize speed and reliability improvements on both Agile and traditional projects? Are there beneficial techniques that can be applied on both?
First, IT executives must understand what drives speed and reliability improvements. As discussed in more detail in a previous post, the answer is focused execution and aggregated risk. While Agile can be a good way to achieve both at the project level, it’s certainly not the only way—and in fact, an increasing number of Agile practitioners are discovering better ways to focus execution and aggregate risk on Agile projects by borrowing techniques from other approaches (see previous articles here and here for two such techniques).
Now that we’ve identified focused execution and aggregated risk as two of the most important “common denominators” that must be adopted on all projects, the common ground shared between Agile and traditional projects expands, and the differences that remain begin to seem less critical. Similarly, Agile techniques that drive customer transparency and frequent iterations can often be adopted by traditional projects to some degree, further lessening the differences between the approaches.
Hopefully you now have a greater sense of how a hybrid portfolio is not only possible, but can actually drive dramatic improvements in the throughput and reliability of the portfolio’s project completions. I welcome additional insights and experiences from any of you who have succeeded in getting the best of both worlds!
You must log in to post a comment. Log in now.