DevOps And Agile: Fail Early, Fail Fast

The agile development method of software development has been around since 2001, and was, in many ways, a predecessor for the DevOps approach. As we have discussed in detail previously, agile methodologies were quickly adopted by software developers because it was considered a big improvement on the waterfall method, which was characterised by identifying the user need and creating a product that was finished keeping in mind only that need. While the waterfall method helped developers stay focussed and design, develop and test a product in the shortest time possible, a major shortcoming of the method was that by the time the software was released, it was already a bit outdated because new customer needs and functionalities had been identified in the interim.

The agile method was widely used between 2001 and 2008 because it allowed developers to break down the development process into smaller parts called ‘user stories’, which could be developed and tested in chunks. This was helpful because bugs could be identified and fixed within these parts without derailing the development of the entire software. Additionally, it was much more cost and time-effective in case new functionality had to be added into the software. However, the file method too created a new set of problems, namely frequently missed delivery deadlines and independently functioning but collectively incompatible parts of the same software which was caused because they were developed in separate, uncoordinated scrums.

And this is where DevOps came into play. The DevOps approach solved the biggest problem within the agile methodology — communication and coordination between all the stakeholders involved in the design, development, testing, and deployment of the software. In the DevOps method, developers, operation engineers and testers had to communicate constantly, and every member of the team was responsible for all functions.

In many ways, DevOps can be seen as an extension of the agile methodology. By adopting both, businesses can add immense value to their software or applications, which in turn improves their brand’s value in the eyes of the customer. While the agile approach helps organisations pay heed to customer’s changing needs and expectations from a product throughout the software development lifecycle (SDLC), DevOps lends itself to speed and improved quality due to automation of processes, aided by continuous collaboration between teams.

When companies use DevOps practises in an agile framework, it can help them increase operational efficiency, reduce the time required to go to market, as well adapt to changes faster. Using DevOps and agile together helps companies to fail early and fail fast, in an unfortunate situation where failure is inevitable. Another big advantage is that demos can be held continuously, and validation from stakeholders for smaller components within the software can be sought on an ongoing basis, along with demos. This, by itself reduces the chances of a big, unforeseen failure that can lead to major loss of time and money. Since combining agile and Devops leads to cross-functional teams where everyone is involved in the development and testing, the entire exercise is less risky and changes are incorporated on the go. It is evident, therefore, that using agile and DevOps practices together are in any organisation’s best interests.

Some of the salient features of a combined DevOps and agile process are:

1. Each release can be anywhere between one to three months

2. Develop smaller units of one to two weeks within each sprint for release

3. Each of these smaller units is considered complete in its own right

4. Within such a system, it is imperative that all developers, QA testers, and project managers work in parallel and in collaboration with each other.

5. The entry and exit criteria for a particular sprint are defined and validated at the start of the sprint itself.

6. Consistent and sometimes automated quality tests and checks are used to assess every small unit of work as well. Testing is not left until the last stage, when all the components of the software have already been developed.

7. Daily scrum meetings help the team identify current and future challenges and deal with them in a time and cost-efficient manner.

8. The developers, QA testers and project managers have to take all stakeholders through a demo of the unit of work at the end of every sprint.

9. The exit criteria at the end of the sprint are signed off only after the demo is considered satisfactory by all stakeholders, and the sprint is declared complete.

10. Any additional requirements or feedback is incorporated into the next sprint, where the same process is once again repeated.