The more programmer teams I meet, the stronger feeling I have that just few people have any concrete idea what these agile methodologies are. Opinions are usually divided into two groups:
- Agile development is unsystematic, unplanned, such a code & fix approach (it’s curious that this is the reason for many teams to consider themselves as agile)
- We don’t exactly what “agile” is, but it is modern so we will profess it (just another “buzzword”)
Surprisingly, a lot of people are satisfied with one of these opinions and they don’t feel the need to verify whether it corresponds with reality. (If you’re also not familiar with agile development, please spend one minute with main principles, at least).
Agile methodologies react to common problems of software projects and they try to eliminate the causes by using specific techniques and processes (like iterative development, for example). These techniques are then put to a coherent framework – a particular methodology.
I don’t want to start describing all aspects of agile development (e.g. its great emphasis on systematic and effective approach), I want to concentrate on iterations only. Nevertheless, I would like to use this concrete example to demonstrate the overall approach of agile methodologies.
Iterations
Iterative development is one of highly visible aspects of agile methodologies, however it is also included in many other methodologies. But what iterative exactly means?
The principal idea is that you get a functional program at the end of every iteration (usually few weeks long). The application could be grabbed and sent to customers (although you probably won’t do it until the program has enough features). In other words, you iteratively create a completed program, with a progressively growing feature set.
It helps to solve several common problems:
- You don’t postpone any work. At the end of an iteration, the program may be poor in functionality, but all its features are tested, documented and accepted. You don’t allow snowballing of the debt such as risks in untested code, you don’t skip the documentation due to lack of time at the end of the project and so on, and you can fully concentrate on a new functionality.
- You can change direction at any time. If you spend several months programming something what was designed another several months ago, you’re quite possibly missing customer’s priorities. Very often you also have to react to unexpected problems with the chosen technology, changes in team and everything else what usually happens in projects. If you use iterative development, you just take the changed situation into account when planning the next iteration.
By the way – the evaluation what’s doing well and what isn’t is another important (and often neglected) part of every iteration. - Even if the team is, say, hit by UARS satellite on a team building, you are still able to deliver a working product, although with limited number of features. Without iterative development, you would have just unfinished something, which couldn’t be practically used for anything.
It’s quite simple, isn’t it? You may even ask why I explain it at all. Well, let’s look at some procedures, considered as iterative development:
We have code at the and of an iteration and we’re going to test and document it later.
In other words, the functionality is not finished at all at the end of the “iteration”. We just wrote some code (we can only guess how correct and complete it is) and lots of work still need to be done. It actually solved nothing – some parts of work may be postponed indefinitely, the team have to deal with the current iteration and the backlog from the previous iteration in the same time and so on.
When the end of an iteration comes, we comment out all code impeding compilation and we continue with it in the next iteration.
That’s just even uglier variant of the previous one – “iteration” here is nothing more than some period of time. But mere assigning some dates (when code is copied somewhere) yields no agility, of course.
We divide projects to iterations, but we follow a predefined plan and we don’t allow for changes in priorities.
And isn’t that i pity? Why to develop something, what was designed long ago, instead of what customer needs? Especially ERP systems must still adapt to company needs and companies have to react to the situation on market and bring innovations… Changes are not an exception, they are inevitable.
Conclusion
Iteration from perspective of agile methodologies means simply to regularly create a finished product, with a gradually growing set of feature. It helps to cope with some problems which occur in projects again and again. But if “iterations” don’t meet the mentioned characteristic, such results cannot be expected too.
It would be possible to write a lot even about iterations only – and it already has been written. And agile methods consist of many other pieces. If you want to benefit from advantages of agile approach, you have to understand especially which problems a particular technique try to solve and how it achieves that. Without this understanding, the new processes are frequently just the old ones in a new coat (with lots of “right” words like agile, scrum, use case or stand-up meeting, for instance), but they don’t solve the old problems.