Agile
Table of Contents
Introduction
Agile is not a specific methodolgy. Unlike Waterfall, it does not prescribe a set way of working through the phases of SDLC.
It offers a set of principles that software developers can use to find solutions to their problems. It emphasises flexibilty and collaboration. It was developed in 2001 when a group of software engineers met to discuss their craft.
At the heart of Agile is a 4 point manifesto and 12 guiding principles.
Agile manifesto
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile principles
http://agilemanifesto.org/principles.html
- Highest priority: satisfy customer through early and continuous development of valuable software
- Welcome changes to requirements (even late on).
- Delivers working software frequently - e.g. fortnightly or monthly
- Business people and developers must work together daily
- Build projects around motivated individuals. Trust.
- Best way to convey information is face-to-face
- Working software is the measure of progress
- Sustainable development (i.e. consistent pace - avoid burnout)
- Emphasis on technical excellence and good design
- Simplicity: maximising the amount of work not done
- Self organising teams.
- At regular intervals teams reflects.
Agile strengths
- Agile is adaptive not predictive. It is flexible.
- It fosters a transparent relationship with the client (e.g. regular meetings and early prototypes)
- Regular iteration allows lessons to be learnt
- Rapid move toward minimum viable product (MVP) means benefits realised early on
- Testing throughout improves quality
- Small incremental change reduces risk and allows errors to be spotted early
- More enjoyable (people over process, collaborative, active, etc...)
Agile weaknesses
- Can be inefficient in large organisations - lots of decentralised decision making means economies of scale are lost.
- Projects can go off track if the customer is not clear on desired final outcome
- An excuse not to write documentation
- Often requires large changes to working practices, so can be difficult to implement
- Is demanding of the client’s time
- Makes it difficult to estimate budget