For those project managers familiar with Gantt charts, certification, and maturity models, Agile projects may appear like disorganised chaos.
If you are unfamiliar with the Agile methodology, this is a glimpse into a world that is quite the opposite of what it seems, a world that is highly organised, with teams that have clear focus and are producing results that delight stakeholders.
The Manifesto for Agile Software Development was signed in 2001, but this had been preceded by the increasing use of various iterative and lightweight approaches to software development, such as RAD, Scrum, DSDM, and Extreme Programming.
Agile is now firmly rooted as a respectable approach to project delivery, most often contrasted with the traditional, and typically more heavyweight, Waterfall methodology.
It’s hard to dismiss something that is being widely documented as a key contributor to project success. I’m reluctant to cite too many statistics here, as project success is defined in so many ways, but the Standish Group 2011 Chaos manifesto have some figures, as does Dr Dobbs with his 2010 analysis of IT project success rates.
Is this something you can afford to ignore? If you look at the jobs currently being advertised in Australia, there are over double the number of positions on Seek calling for Agile skills than those advertising for PRINCE2. If you take professional recognition as an indication of maturity, then you’ll be interested to know that the Project Management Institute now offers an Agile Practitioner certification.
Planning an Agile project
The Agile Manifesto says to value responding to change over following a plan. Planning on Agile projects accepts that change is a normal part of a project process, and can result in the project realising greater business value.
Planning happens regularly and often, but only in detail for the immediate future, for the work that the team are about to do. Planning for the longer term is done at a more coarse-grained level. This allows us to delay committing to the detail until we have built knowledge about the product. By doing this, we can both take into account the experience we have gained, and we can cope with change more easily and with lower cost.
Planning on Agile projects is outcome based, rather than task based. This results in the measurement of project progress being based on realisation of business value rather than completion of a task on the project plan.