This week we held the reporting workshop for sprint 15 of Software Center. The event was, with 150+ participants, the largest and most successful workshop we have had so far and it was great to have it at the fabulous HQ facilities of AB Volvo. Although we had quite a broad set of topics and community events, including product management and systems engineering, one of the topics that most companies that I work with are struggling with is continuous deployment (CD) and DevOps.
The challenge that I see several companies struggle with is that they tend to treat CD and DevOps as a goal in itself. This is entirely understandable as it is a difficult change process that requires changes to, among others, software R&D, testing, validation and certification, the interface to the customer and sometimes even the business models that the company employs.
It is important to remember, though, that DevOps is a means to an end and not a goal in and of itself. The goal is to shorten the feedback loop between R&D and deployed systems in the field. It’s not about getting the software out in the hands of customers, but about getting the relevant data back from the field.
Once you receive relevant data in sufficient amounts from the field, this data can be used for at least three purposes: R&D effectiveness, team empowerment and AI. Below each purpose is described in a bit more detail.
When we have short feedback loops between development and deployment, we can adopt a different approach to development. Rather than an elaborate requirements engineering process, we can develop hypotheses concerning what might add value to customers, build minimal viable features (MVFs), deploy each MVF and measure its impact and then decide, based on data, whether the feature should remain in the system and, if so, whether additional development should be done. The most well-known instance of this style of working is A/B experimentation where different user cohorts are exposed to different realizations of the same functionality (alternative A and alternative B) and where the relevant performance factors are measure.
As research by us and others shows that many features, perhaps more than 50%, are seldomly of even never used, it is clear that a data-driven development process, with short iterative development loops and fast feedback has the potential of significantly improving the effectiveness, defined as the amount of business value generated by a unit of R&D resources.
Second, availability of accurate and timely data allows for a significant increase in the autonomy and empowerment of teams. Rather than a manager telling the people in the team what to do, the team can receive clear, quantitative KPIs that they are expected to improve. The team is then at liberty to explore the avenues for improving the KPIs that they deem the most promising and team performance is directly correlated to the success of the team in “moving the needle”.
Finally, AI techniques such as machine learning (ML) and deep learning (DL) typically require large amounts of, preferably labeled, data for training and evaluation purposes. The fast feedback loops enabled by DevOps allow for the training and retraining of ML/DL models. In modern systems, these models are also subject to continuous deployment and consequently need to be retrained continuously, using the data coming back from the field.
Recently, I gave a talk at the DevOps Summit Amsterdam where I covered the topics outlined above more extensively. If you’re interested in watching that video, you can find it here:
Concluding, DevOps is NOT about DevOps, but rather about creating the fast feedback loops that bring data about the performance of systems in the field and the behaviour of the customers using these system. This data can then be used for improving R&D effectiveness, empowering teams and enabling AI/ML/DL model deployment. DevOps is all about the data!