Controlling Agile Development in a Project Portfolio Framework
Project management leaders have embraced agile practices and attempted to redefine their roles to focus less on planning and controlling agile projects and more on providing an environment to allow agile projects to succeed.
Tue, December 06, 2011
Network World — This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.
Project management leaders have embraced agile practices and attempted to redefine their roles to focus less on planning and controlling agile projects and more on providing an environment to allow agile projects to succeed.
However, some agile ideas about embracing change, "just-in-time" planning, and eliminating hierarchical decision-making have led to misconceptions about the compatibility of agile projects with PPM processes. It's time to set the record straight about common project management fallacies that have led to concerns over how to monitor and control an agile project as part of a project portfolio.
IN DEPTH: When agile projects go bad
Myth No. 1: Agile projects don't provide enough executive visibility
A large part of the popularity of agile is the belief that teams should be empowered to make business decisions rather than relying on executive stakeholders for approval. Empowering a team, however, does not mean they shouldn't provide timely executive status reporting.
The struggle many agile teams face is the requirement to provide status reporting in a format that is inconsistent with agile practices. For example, a requirement that an agile team maintains a separate task plan to enable reporting on metrics such as "percent complete" can negatively impact the benefits of an agile approach. Instead, executives need to learn how to interpret project status from an agile team rather than impose reporting requirements that are not consistent with agile.
Let's take percent complete as an example, which provides an indication of project progress. Percent complete for a traditional projects is calculated by summing the actual hours for tasks and dividing by the total task hours for a project. In contrast, an agile project progress is measured by story points delivered. Percent complete is calculated by story points accepted divided by total story points for a project. Educating executives on what a story point is and how it measures progress enables agile teams to report progress in the unit that makes sense for their team.
Myth No. 2: Agile projects lack reliable schedules
It's a fact that agile methods are designed to adapt quickly to changing realities, whereas more traditional methods focus on planning the future in detail. Although agile teams shy away from providing guaranteed delivery dates (given the cone of uncertainty around a project), it's untrue that an agile project can't provide a scheduled finish date.


