Five Myths of Agile Development: Myth #3 – Agile is Not Predictable
Yesterday’s post in this series discussed Myth #2 – Agile Teams Do Not Plan
. Now let’s continue with Myth #3 – Agile Development is Not Predictable.
As with planning, agile development methods promote a fundamentally different approach to metrics and forecasting than traditional development. The approach of traditional development is one of creating detailed, activity-based plans upon which to evaluate progress, deviation from plan, and the ability to predict precise outcomes. Unfortunately, plans created in this manner have often offered only the “perception of predictability.” After decades of experience, the results associated with this type of planning on software development projects have proven dismal at times. Just as importantly, the predictions associated with these plans rarely improve over time because there is no simple mechanism in place for evolving the plan as new information becomes available.
Agile development instead replaces detailed, speculative plans with high-level, feature-driven plans that acknowledge the inherent complexity and uncertainty of software development projects. Ongoing reconciliation of actual effort to original plans is replaced with incremental planning and re-planning at a more granular level throughout the development process. Because agile development operates in a rapid, iterative fashion, valuable historical data quickly emerges for supporting both short- and long-term planning.
Using this historical information upon which to base future planning, the quality of plans quickly begins to improve. As speculation is replaced with historical fact, teams are able to predict with much greater accuracy what they will be able to deliver over time. Agile teams replace PERT and Gantt charts with simpler concepts such as Velocity and Burndown charts.
As shown on the VersionOne Project Dashboard, a Velocity chart, typically measured in terms of story points, ideal days, or hours, displays the volume of features a team delivers each iteration. Over a short period of time, a team’s Velocity will stabilize, resulting in a very reliable planning metric for future iterations.
The Burndown Chart, shown on the same dashboard, reflects both the amount of work remaining as of each day during an iteration, as well as the overall change in scope of the work within the iterations. If the slope associated with the remaining effort, represented by the red line, is not such that the work will be complete by the end of the iteration, this is immediately apparent to everyone on the project. Not only can the team act on this now, they can use this information to calibrate the amount of work they put into their next iteration plan. Simple charts and metrics such as the Velocity and Burndown charts convey as much or more information as PERT and Gantt charts, but do so in a very visual and actionable manner.
As opposed to planning once a year and executing against that plan for the remainder of a project, agile teams are constantly planning, estimating, prioritizing, and delivering against the plan. As teams continue to plan and re-plan throughout the development process, each individual’s planning skills continue to improve. As a result, a team’s confidence in its plans increases, providing all stakeholders with a much better sense of where the project actually is and what can be accomplished. This type of accurate, black-and-white visibility into the development process also helps build trust throughout the organization.
Tomorrow, we’ll address Myth #4 – Agile Development Does Not Scale.
Read the other posts in this series:
Myth #1 – Agile is Undisciplined
Myth #2 – Agile Teams Do Not Plan
Myth #4 – Agile Does Not Scale
Myth #5 – Agile is Just Another Fad
If you’d like to download this blog series in document (PDF) format, get the Five Myths of Agile Development white paper.