Sections of this topic
Right now there is no single more popular topic in (especially in software) projects than Agile. Before I describe what it is, here are the most common misinterpretation of what it is not:
- it is not a methodology – it is a set of values and principles;
- it is not a project management ‘method’ – it is a product development method that can be combined with other practices to cover the entire scope of planning and delivering projects.
You can take an agile approach to the management of anything (as far as possible) and what that should mean is that you are following as many of the principles of Agile as possible. Does that mean that 87 storey buildings are going to be delivered and accepted in an incremental manner? I think not.
Agile addresses a number of challenges which many would argue are ignored too often by projects in the past. However, it is a mistake to say that traditional methods fail to do what Agile does, the truth more lies more in the interpretation and implementation of traditional methods by project teams in the past. For example, there is nothing in Waterfall that says you can’t plan and deliver the project in a highly collaborative way; it’s just that people chose not to.
So what does Agile try and achieve?
Agile accepts a number of things, for example:
1. Priorities change
2. People find it very hard to envisage and sometimes communicate physical requirements, especially towards the font-end of projects and even more especially all in one phase.
It tries to have a development process that recognises, accommodates, allows for these and provides a more productive environment for requirements to emerge and be confirmed before actual code is developed, on a just-in-time basis.
It also encourages very short development cycles, so that the review (by users) of product is continual throughout the development process. When it works well, this can be an excellent way of producing product and reviewing it (almost) in real-time as it is developed. It’s the very opposite of a big bang approach and should reduce the size of issues to make them far more manageable. By the time you get to the end of the final iteration, there should be no major surprises. The development should be driven by the priorities of the business and therefore functionality of greatest importance should be at the core of the deliverable.
One other aspect is also attempted and that is to delay decisions until they have to be made. This can have advantages but takes a very skilled team. All development activity carries uncertainty so if uncertainty manifests itself around late decisions this could cause real issues and delays. This principle needs to be applied with great skill and care.
Agile can enable some really good things but there are some ‘Agilists’ who spread some very dangerous messages. For example: Agile does not do deadlines; projects begin with a product backlog; there is no accountability in Agile teams; Agile does not do (need) project management (on larger projects there are usually many things outside the software development – clearly these will all need to be managed too).
Agile is fairly simple to understand in principle – much harder to do (well) in practice.
