March - 3rd Agile Principle
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
You might wonder how the third agile principle differs from the first. The first principle talks about “early and continuous delivery” of software. This sounds a bit similar to “delivering software frequently”. However, there is a significant difference. The first principle is all about customer satisfaction. It is realised by continuously delivering value to customers. The third principle is all about method. The principal method used to achieve the goals of the first principle is development in iterations. An iteration is a defined time span during which the entire software development life cycle (SDLC) is traversed. An iteration starts with requirements analysis and ends with software delivery. It can be modelled as a closed and repeating cycle.
If we recall the waterfall model, there are some major differences. Most importantly, the waterfall model traverses the software development cycle only once. This usually takes a much longer time. It is common that the duration of this long-term traversal cannot be predicted exactly. For that reason, deadlines are often postponed. Another major difference is that rollout and maintenance phases are periods at the end of the waterfall SDLC, whereas agile methods do not stipulate predetermined phases for these activities at all. Agile teams carry out maintenance “on the go”; it is part of the normal development work.
The time frame of an agile iteration is more rigid, by contrast. It is commonly fixed and takes anywhere between a few weeks and a few months. For example, teams that use Scrum often work in cycles of 2-4 weeks. There is no delay or postponement. Instead, if a feature is not ready, it is moved to the next iteration. The quantity of work completed within this relatively short amount of time is of course much smaller. So, at the beginning of each cycle, the team continues to build upon the foundation laid in the previous cycles. The process is therefore also incremental. This has certain advantages for both developers and clients.
Let’s state again that the agile process is both iterative and incremental. This is important. At the end of each iteration, new features and fixes are demonstrated to the stakeholders. In many cases, the iteration also results in a release, which means that software is deployed to production at the end of a single iteration. However, this is not written in stone. For example, a team may decide to work in 2 weeks iterations while adopting a release cycle of 4 weeks to match maintenance windows. Another team may prefer a continuous delivery model where features are released to production as soon as they become available.
It does not matter, as the iteration is not strictly coupled to the release plan. What matters is that software is delivered frequently and that the time span of an iteration is kept as short as practicably possible. This makes for a short feedback loop which allows stakeholders to intervene quickly. It increases the control of business stakeholders and allows for an amount of flexibility that is impossible to attain with the traditional waterfall process. For example, change requests and bug fixes can often be implemented and released within a single iteration making for a time to market that can simply not be achieved with any other method.
From what has been said, it follows that the agile process is also evolutionary and adaptive. Because large scale features are built incrementally over the span of multiple iterations, developers build on the foundation of existing architecture and functions. New blocks of software are added to existing blocks. Existing blocks are sometimes refactored or changed. It is therefore possible to test concepts in practice before a feature is completed. It is also possible to improve concepts and functions over the span of multiple iterations. The end result is always working software.
This means that software features, especially large scale features (called “epic” in Scrum methodology), are not typically conceived at the drawing board. Instead, prototypes and proof-of-concepts make their way into working software long before the planning and implementation of a large scale feature is completed. This is another major difference to the waterfall model. The key advantage provided by a short feedback loop is that bugs, logical errors and flawed concepts can be spotted and corrected early. This keeps the cost of such improvements to a minimum.
Because the evolutionary and adaptive nature of the agile software development process, planning and design is often restricted to a relatively small time frame and is open to change. For example, the requirements for implementing an epic could change midway during one of the many iterations it takes to complete the epic. In some cases, these requirement changes necessitate rethinking and altering existing features or even rethinking architecture. Code refactoring, the restructuring and improvement of existing code without changing its functionality, is therefore very important in agile development. Without continuous refactoring, agile projects are in danger of accumulating technical debt.
Continuous refactoring is perhaps the price that has to be paid for the extreme flexibility and quick time to market that agile development affords. A team that follows an adaptive approach must guard against code smells and software entropy. Only with sustained attention to these problems, software will stay maintainable and extensible in the long run.