The Agile style of development is considered best for many organizations and projects. There is a lot of criticism too, but overall it gained significant mind share and developers use it all over. The big question is, “What is Agile development?” You could look at the Agile Manifesto. This is a great collection of values and principles. However, the Agile manifesto is not a recipe. If you want to create an Agile process out of it, you have a lot to figure out. Let’s take a look at some of the common, or at least well known, Agile processes out there: Extreme Programming, Scrum, Kanban, Lean Software Development and Crystal Clear. They are all quite similar, actually, with different emphasis here and there, but overall there is a sense of a common core.
The other important thing about Agile development in general is that it prefers lightweight methods over precisely prescribed processes (one of the core values). As such, Agile methods are in a difficult place, because they can either stay on the fuzzy/fluffy edge of the spectrum or succumb to the grind and actually recommend specific practices and processes.
I’ve been practicing Agile development for more than 15 years in the trenches and it’s never done by the book. In the field, Agile is often some adaptation of Agile methods, with or without the actual terminology.
Some concepts and practices made it to the mainstream big time, including automated testing, continuous integration, short iterations, refactoring — others, not so much, or not uniformly.
The most important practice, in my opinion, is short iterations. Why is that? I discovered that if you practice short iterations almost everything else falls into place: You deliver frequently, which means you need to focus on what’s most important, which means you need to define done criteria, which means you need automated builds and testing and continuous integration, which means you can refactor with confidence, etc., etc.
A short iteration is unambiguous. If you commit that you will deliver something every two weeks, you’re golden. It’s easy to keep track of what’s going on (only a two week horizon to look at) and it is easy to measure progress and team velocity (you have milestones every two weeks). Of course it’s easy to respond to change, because every two weeks you start from scratch. By definition, you can’t be more than two weeks into anything.
