Check a few things before joining the Agile bandwagon

Agile Application Development methodologies have been around since the early 90s with different detailed methodologies coming in and out of vogue. Whatever Agile methodology is adopted, the proposed benefits are attractive - faster and cheaper delivery, higher probability of users getting what they want etc. Before jumping on the bandwagon and abandoning waterfall, I recommend working through a viability check-list to ensure you have the right conditions to be successful (note - only joking about muddy scrums!).

First some history

The waterfall model of system development has been around since the mid 70s. This approach adopts various phases (e.g. Analysis, Design, Construction, Testing, Implementation, Maintenance) which are deemed complete based on quality assured documents which allows entry into the next phase in the style of a water flowing over a waterfall! This basic approach was formalised even further in methodologies such as SSADM in the 80s. Waterfall has plenty of rigour but has some disadvantages

• the cost of document production / validation  
• users need to agree requirements and functional design quite early based around discussions and see a working system quite late on in the life-cycle. The risk is that they didn't get it quite right when they agreed these early documents.
• the cost of change later on the lifecycle is high (pushing water back up the waterfall is never going to be easy!).

Alternative approaches started to be proposed, the first I am aware of was the Spiral model in the 80s. The "alternative movement" gathered more pace when James Martin introducing his book on the Rapid Application Development (RAD) methodology in 1991. When I really looking into these approaches the methodology in vogue was the Dynamic Systems Development Method (DSDM) which I first successfully utilised in projects during the late 1990s. Other Agile methodologies such as XP have sprung up and as I write this in 2015, the current UK Agile vogue is SCRUM

Agile methodology in generic terms

Agile utilises time boxed iterations rather than phases used in waterfall. Small teams work together (including representatives of business stakeholders) to develop the requirements of the iteration, develop the code and test the results with user involvement. The resulting working application (for requirements developed in the iteration) can be shown to stakeholders allowing fine-tuning of requirements while they are reasonable cheap to change. A number of iterations may occur before a system is ready to release into production usage.

Is my Organisation / Project suitable for Agile?

In producing this check-list I admit to being heavily influenced by DSDM but I believe they apply to Agile as a concept.

1. Will the application under development have significant user interface requirements e.g. screens and reports? If true, this is point in favour of Agile. Conversely if the application doesn't have a significant user interface and is just a complex computation, a written specification will likely be better to develop and test against.
2. Are the requirements unclear or likely to be subject to change during the life-cycle? (e.g. external influences such as government legislation being developed or simply the business users have difficulty articulating their requirements). If true, this is a big point in favour of Agile. 
3. Can the application be sensibly delivered in increments? This is a core principle of Agile methodologies.
4. Is there a clearly defined user community and can a representative of this group be actively involved in the team? If either of these questions is NO then there are dangers that incomplete requirements or wrong requirements may be captured in the Agile iterations
5. Is the core team small enough? A team size of around 7 is often considered the maximum for Agile.
6. Is the core team empowered to make decisions within each iteration? If the authority hasn't been delegated to the team driving the iteration, momentum will be lost and in a time-boxed iteration, little will be achieved.
7. Is the core development team stable and dedicated appropriately during each time-boxed iteration? Saying that Fred is dedicated for 4 days and then he will be replaced with Harry for the rest of a 2 week time-box isn't going to be effective.
8. Is the core development team co-located (ideally) and if not, are suitable tools available to aid collaboration (e.g. Trello rather than a white board). Agile uses less documentation and relies on excellent communication between team members so look for barriers. This includes the inter-personal skills of team members. In my experience look at the developers in particular, some really don't like to communicate and are more suited to working from a document!
9. Skill and knowledge level of the core development team. Having a developer new to the technology who has just come off a training course or a user who has no domain knowledge of the business area affected isn't going to make the process work effectively.
10. If external resources are involved, are the commercial arrangements suitably framed? The contracts must recognise that the system requirements may evolve with some backward movements to achieve the ultimate goals.

Conclusion

So go evaluate the check-list and if the responses are favourable, Agile can be a really effective development methodology to use with big benefits in terms of timescales and most importantly delivering something which really meets business needs. If not, I suggest that you stick with Waterfall. Although it seems plodding by comparison, the checks and balances of document quality processes and phase gates create the rigour for successful delivery even if there is the risk of costly change requests late in the life-cycle.