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.
Agile teams use "just-in-time" estimation for iterations and focus on delivering business value incrementally. However, release and roadmap planning is used for longer-range estimates. If an executive hears that an agile team is only prepared to give estimated delivery dates for the next couple of iterations, it should raise a warning flag about the team's capability to build a credible release plan.
Developing a PPM framework with standard metrics that apply to both agile and traditional projects is important. Scheduled finish date is just one of the common metrics that enable executives to get visibility into project status, regardless of the delivery method:
• Scheduled finish date. "Planned finish date" is the estimate made at the inception of a project for the planned delivery date, whereas "scheduled finish date" is the estimate of a project finish date at any given point in time based on current data. For a traditional project, this is based on the task plan and critical path for the project. For an agile project, it is based on the release plan. Comparing scheduled finish date to planned finish date will give an indication of the team's ability to estimate delivery dates accurately.
• Percent complete. Percent complete for a traditional project is calculated by summing the hours for completed 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.
• Scope changes. Percent complete gives an indication of progress, but does not show if the scope is changing on a project. For traditional projects this is typically represented by the number of change requests. For an agile project, it is typically measured by the change in total story points over time.
• Actual cost vs. budget. Both traditional and agile projects have capital and operational expenses that are tracked. Actual cost vs. budgeted cost should be reported, regardless of the project methodology.
• Project health. Project health is a summary metric that indicates if a project is "on track," "needs attention" or is "in trouble." This metric varies by organization and is often calculated using conditional logic based on the four metrics above, as well as other data such as outstanding issues.
Myth No. 3: Agile and traditional practices aren't compatible
Even for project managers willing to adopt agile, integrating agile projects into a PPM framework has proved challenging for many organizations. Project managers are being faced with different, often conflicting methodologies, metrics and controls. Further, some teams are adopting hybrid processes that include elements of waterfall and agile methodologies and are confused about how to rationalize seemingly incompatible methods.
Integrating an agile project methodology into a PPM framework is no different than integrating a more traditional project methodology, with four exceptions:
(1) Imposing unnecessary stakeholder reviews, checkpoints and data capture requirements on an agile project will reduce the effectiveness of the team. Of course, if major decisions need to be made with executive input or the agile project has dependencies on other projects, stakeholder meetings will be necessary, but these should be the exception, not the rule.
(2) Agile projects measure progress "story points" complete or business value delivered. This is a fundamentally different way of tracking progress than using a task plan and measuring task hour completion. In addition, a project manager assigns tasks to owners in a traditional project, whereas agile teams are often self-organizing, so tasks may be reassigned at any time by the team to ensure project delivery is on track. This difference requires that metrics for "project health" and "percent complete" are tracked differently from projects based on task hours.
(3) Given the task assignments within an agile team are dynamic, it's unwise to assign a resource part time to an agile team as this breaks the self-organizing model. Instead it's better to treat agile teams as a unit and assign resources to them full time.
(4) Finally, regular reviews of agile projects are more focused on "working software" than reaching predetermined milestones or delivering project documentation. Reviews should be tailored to the type of project to ensure they are valuable to the team.
The rise of agile development practices is driving many benefits by creating a culture of continuous feedback and a focus on delivering quality software that meets customer needs. Although some fallacies around agile development exist, it should not deter PMOs and executives from encouraging agile adoption.
Project managers and PMOs should carefully consider which projects are suitable for agile methodologies. They should also develop a PPM framework that applies to both agile and traditional projects to enable executives to get visibility into project status, regardless of the delivery method.
Daptiv is the on-demand leader in project portfolio management software.
Read more about infrastructure management in Network World's Infrastructure Management section.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.