Despite being around agile for a number of years, I find it surprisingly difficult to define the field in a single concise sentence.
This is because to me, agile consists of two things which are often used interchangeably in discussion:
1) A set of goals and qualities with regards to how we would like to develop software;
2) A set of techniques, working practises, and development methodologies that help us to move towards those goals.
I think it’s important to keep this distinction in mind. This is because the first category, the goals, are always relevant and almost universally desirable, but the processes that we use to get there are varied, subjective, and very much situationally dependent.
The Goals Of Agile
First, what are the things that we hope to achieve by using agile instead of a more traditional development process:
- To reduce risk;
- To plan with more reliability;
- To prioritise better;
- To deliver software in in a more iterative style;
- To improve the frequency and quality of engagement with stakeholders;
- To improve the quality of the product;
- To accept and account for change during the project;
- To work more pragmatically and reduce unnecessary work that does not add value;
- To use a ‘lightweight’ process with unnecessary ceremony.
How do we get there?
There are a number of agile software development processes, each of which implement different rules and practises that in theory help us move towards the above desirable goals.
What each of these have in common is that they attempt to:
- Change communication patterns;
- Change prioritisation and planning;
- Change implementation practises and processes;
- Change quality procedures;
- Change values and culture.
Note that I did not mention the word SCRUM, KANBAN, XP or AUP in this discussion. These can all be useful starting points and frameworks to work within, but they do not, in themselves, represent agile software development. Agile software development is much bigger area than the simple application of a process.