Agile Decompiled : Incremental And Iterative Releases
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
One of the hallmarks of an agile process is the use of iterative and incremental releases. Proponents of the Waterfall Model suggest that by doing all the design up front and making sure that each part of the process is correct before moving onto the next part, means that bugs are found sooner and therefore costs are reduced.
However to do this requires meticulous checking and the process is still carried out by human beings who are prone to error. This type of situation is described in the book The Design of Design: Essays from a Computer Scientist by Frederick P. Brooks Jr. It can be done but mistakes can and are still made. So what is the answer?
Well let us take a step back a look at how we write a piece of code to begin with. In my experience most developers write a software method or two, maybe a few more, and then run the code the see if it works. If it does then we know we have written that part correctly (at least partially) and then we add a bit more on and repeat. The shorter the feedback loop between writing and seeing if the code runs, the quicker we can see where there may be issues.
Now what if we could do this with the customer? If we could make the time between delivering product to the customer and getting their feedback small then we would be more likely to discover any bugs, and any incorrect assumptions made about how the system should run.
Enter incremental and iterative releases. By using this approach we can quickly make changes to the software product we are working on and get those fixes or enhancements out to the customers quickly. By making small incremental changes it also means we have less emotional attachment to the code than we would have had with long release cycles. This allows us as developers to have more objectivity about the code if others suggest a better approach if necessary, and to improve our knowledge of the code base at the same time.
By building incrementally in short bursts we reduce the risk of delivering software which does not meet the specification, simply because if the product is incorrect it will only be a short time before the item is looked at as part of the next release cycle, where it may be implemented.
James Shore and Shane Warden cover many aspects of the ways in which incremental practices can be put into use for both requirements elicitation and architecture design in their book The Art of Agile Development for example.
So do you build in an iterative and incremental way? I would love to know so feel free to leave a comment.