When working in a traditional project management setting we often need agile pendentives that let us fit agile practices onto a traditional base. Here are some examples:
Traditional to Agile
1. WBS –> Prioritized Backlog. When asked to show the Work Breakdown Structure (WBS) sponsors and PMO are likely looking for a breakdown of the project deliverables. Traditional project management approaches recommend creating a WBS early in a project lifecycle after gathering requirements and defining scope.
Agile projects acknowledge this upfront design is likely to change and so deliberately go a little lighter on these definition activities, preferring to invest the time in building portions of application and arriving at agreement of functionality through feedback.
2. Detailed Gantt Chart –> Release Plan. Detailed Gantt charts are another example of a detailed upfront design deliverable that is likely to be brittle and changing too frequently to warrant the update effort in project environments that have high levels of requirements uncertainty or technology uncertainty. It is not that we cannot create Gantt charts for agile projects – I do for some stakeholders. Rather that the time and effort required to update them is probably best used elsewhere in gaining agreement of the true business requirements.
So, instead of producing detailed Gantt charts that list tasks and do not survive contact with the reality of software projects, release plans that layout iterations and release timeframes are a more robust planning tool.
3. Earned Value Reporting –> Velocity and Feature Based Reporting. Traditional earned value reporting shows progress against a plan at a given moment in time. It can show how far ahead or behind we are in terms of progress and spend. It can also used to estimate completion timeframes and final costs. However it is tied to the accuracy and quality of the plan we are tracking against. The phrase “The Map is Not the Territory” speaks to the issue that if reality diverges from our map or plan then we have to accept reality and draw a new map. Unfortunately the uncertainties of software projects often show us that our initial “map” was flawed. “Plan the work and work the plan” is a fine approach when your plan is solid, but a recipe for failure when change rates are high.
All the same estimate to complete, cost and schedule performance indices can be calculated by tracking Velocity (number of features/points completed per iteration) and checking these delivery rates against the total number of features. See this previous article for more details.
Summary
These are just a few traditional to agile pendentives, they let us apply agile “round” solutions to traditional “square” circumstances. The key to finding them is to look for the meaning behind the traditional request and then explain why the agile alternative is in a different format.
Often it is to address the uncertainty of original plans. Plans created when we know least about the endeavour (at the beginning of the project) are likely to be poor on software projects. This is because most software solutions are unique, intangible and hard to describe without reference to an evolving system. Agile methods make use of the learning’s gained through progressive elaboration to refine planning artifacts.
Other agile pendentives can be found in how we make decisions and approach estimating. The unique characteristics of software projects does not mean we cannot create project management deliverables, it just means they may be in a different format to better reflect their environment.
