The agile movement has had a significant influence on best practices for project management.
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. Over the next three posts I’ll 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.
Let’s look at the first myth: 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.
One caveat is that reporting on ‘percent complete’ on a program when the underlying projects are using different units, such as task hours and story points, can lead to inconsistent results. In this case, finding a common metric across projects is advisable, such as ‘function points’ or ‘business value points’. This requires an organization with a high degree of PPM maturity, a well-defined methodology and strong training programs to educate program and project managers.
The rise of agile development practices is driving many benefits to organizations by creating a culture of continuous feedback and a focus on delivering high quality software that meets customer needs. Although some fallacies around agile development exist, it should not deter PMOs and executives from encouraging agile adoption in their organizations where appropriate. 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.
What are your thoughts? Have you had experience educating executives on the differences between agile and traditional projects? Let me know.