Agile Software development and IT operations unite How DevOps has changed Agile Processes
Modern, agile software development and DevOps are crucial tools in times of increasing digitalization. Both enable the company to respond quickly and flexibly to new requirements.
Companies on the topic
DevOps benefits when employees from IT operations and software development form cross-functional teams.
In a classic division of tasks between development and operation, the developers focus on the software. The goals of the developers include innovations, new features, high agility and a short time-to-market. The focus of operations, however, is on infrastructure. Its goals are high stability, availability and performance as well as maximum standardization.
The intention of DevOps is to resolve this traditional conflict of objectives between development and operation, that is, to overcome the “wall of confusion”. It arises during the functional separation during the transfer of responsibility between the two business units, i.e. at the point at which the responsibility for a software is transferred from development to operation. This separation can be reversed by the formation of joint, cross-functional teams.
Agile software development thrives on small, manageable changes that lead to a big change over time. In an agile approach, change is the norm. The agile team regularly reviews its practices and adapts them to become more effective, according to the “Inspect and Adapt”principle. Experiments are an important agile instrument.
In agile software development and DevOps have evolved over time in the areas of
some best practices crystallized. We will take a closer look at these in the following.
The role of the product owner
The product Owner must prioritize the tasks in the Product backlog. In the form of tasks and user stories, the product backlog usually describes not only the technical and functional requirements, but also the non-functional requirements, such as the quality requirements.
A consistent use of DevOps, the operational requirements of the quality requirements, or operational requirements in the Form of mostly technical tasks to improve the maintainability and operability of the Software. With DevOps, the product backlog thus contains a greater proportion of technical tasks.
Product Owner, however, have a natural Bias to new Features, that is, to the functional requirements. As a result, there is a risk that the qualitative and operational requirements will not receive sufficient attention. In addition, product owners often find it difficult to weigh the costs and benefits of technical topics such as availability, performance or safety-especially if they are less technically experienced themselves. Therefore, the support and advice of the product owner on these topics is essential for successful DevOps.
Experience shows that it makes sense to reserve a small share of the budget – about 15 percent – for small technical improvements. For these” quick wins”, no consultation with the product owner is necessary if their implementation takes less than three working days. This procedure relieves the product owner. In addition, this enables the team to continuously work on improving the quality, operability and maintainability of the software.
“Story Parents” describes the idea of giving each user story a “parent”. This Story Parent takes responsibility for the content of the user story – from the birth of the user story in the Product Backlog Refinement to the age of majority of the user story with the installation of the feature in production.
The Story Parent has the task to become an expert for the topic of his user story. However, this does not mean that the Story Parent has to take over the actual implementation of the individual development tasks of the user story. But the Story Parent is available to his colleagues in the development team as a contact for the user story. This also relieves the product owner.
In addition, the Story Parent ensures that the user story is meaningfully tested in the context of hedging on the end-to-end environment. And he checks that the feature works correctly in production. The concept of Story Parents thus supports thinking in verticals. Last but not least, it reinforces the DevOps idea by taking responsibility for the story Parent until the feature is successfully in production.
Especially for large scrum teams-about seven people or more – and large, complex system landscapes, which are managed by a scrum team, the concept of Story Parents has proven to be a real success model. It allows a good trade-off between the avoidance of islands of knowledge and team effectiveness.
For successful DevOps, the feedback loop from the productive operation of the software is of central importance. On the one hand, the developer of the user story has to learn what consequences the decisions he makes in the context of development have. In addition, he must know which challenges occur in the company and how they are solved. On the other hand, he should contribute his understanding of the inner workings of the system to troubleshooting and troubleshooting.
In the end result, the developer gains a better understanding of operable and maintainable software. The results include more targeted logging with more informative log messages, better monitoring, more meaningful health checks and meaningful smoke tests. With successful DevOps, the maintainability and operability of a feature is already taken into account during the development of the user story.
Kanban for Operations
The field of operations, i.e. IT operations, includes work that can be planned. Examples include an upcoming major release, planned adjustments to the IT infrastructure, or system updates. However, there are also many operations that are inherently unplanned. This includes a sudden increase in load, a system failure or a detected vulnerability that requires immediate action. There is no time to prioritize these tasks in a product backlog or to schedule them in the next Sprint planning.
For this reason, it is often not scrum but kanban that is used for planning such tasks. At Kanban, the focus is on the lead time of tasks and team productivity. Kanban makes bottlenecks visible. Such a bottleneck exists, for example, if there are currently not enough resources available for a certain process section or if the available resources are working on too many things at the same time, i.e. if the work-in-progress limit (WIP limit) is exceeded.
Kanban provides a high level of transparency about the status of the project. In addition, Kanban enables very efficient team collaboration, especially in cases where team members work together from different locations. Often Kanban is supplemented by a backlog with the plannable tasks; this ” Kanban with backlog “is also called” Scrumban”.
Overall, DevOps has fundamentally and permanently changed agile software development. And the triumph of DevOps has consequences: the product owner must now also deal more with operational requirements. For this he needs support and advice. Concepts such as Story Parents can relieve the product owner and strengthen the DevOps idea.
The Feedback loop from the productive operation and taking into account lessons learned in the implementation of the User Stories lead to Software that is more maintainable, operable, and, ultimately, better. With the help of Kanban, even classic operational tasks can be organized in an agile manner.
It should be clear that agility and DevOps are not enemies, but friends. Both have the goal of creating added value for the business by improving communication and fast feedback cycles.
* Dr. Christoph Ehlers is Principal Software Engineer at Consol.