Agile software development requires 3 foundational sets of practices to be in place. Doing iterations alone does make you agile unless the output of your iterations is production-ready code. But how do you get production-ready code for a large complex software product out of a 2-week iteration?
We will spend a lot of time discussing Scrum in this book. Scrum has become the de-facto best framework for doing iterations. But scrum by itself does not produce deployable code as its output, unless backed up by 2 prerequisite sets of practices, namely Continuous Integration and Test Automation.
Take for example a communications product that resides at the core of a high-speed network. This product not only executes multiple stacks of routing protocols, and needs to be highly configurable and manageable, but also interacts with multiple external devices and products, against all of which it must be tested with to ensure interoperability and tolerance to many types of adverse events in the network. In order to do this, thousands of test cases must be executed, including performance and stress test cases, which traditionally may have taken months to complete. A very high degree of automation is required to get this done on virtually every change that is submitted.
But there is another prerequisite. Traditional construction has involved multiple developers working on private code branches. Changes from each developer are coded/unit tested on their own private branch and then checked into a trunk line from where the next build is produced. New builds must be ‘sanity tested’ for integrity, and then made available to the development team for verification of their changes before the system test team takes over. The process of getting a new build to system test may take several days, and many organizations working in this mode may typically make one new build per week. This is the ‘big batch’ approach to software construction which simply is not consistent with delivering production code in 2-week iterations. Changes from developers must be submitted continuously, and these changes must be of very high quality to ensure minimal re-work, and minimal accumulation of an open bug backlog. We will elaborate on the subject of Continuous Integration in a subsequent chapter.
Whereas scrum and be taught and implemented in a fairly short time frame, building an effective CI system, and automating large legacy test suites may require significant financial investment and time to get into place.
In summary, agile software development must comprise elements of:
- Iterative development e.g. Scrum
- Continuous Integration
- Test Automation
We will be elaborating on each of these topics in subsequent chapters.