Value streams in DevOps

How should you start with DevOps?

Good question, but as an IT application developer one already knows a solution: the introduction of Continuous Integration and Continuous Delivery (CI/CD). Maybe one uses new tools like Bamboo or tools from cloud providers like Azure DevOps. And of course, everything with microservices in Kubertnetes containers. And that’s it.

Sounds simple, doesn’t it? And the great thing is: it increases the feeling of happiness! Yes, really! Statements like “We’re doing DevOps” are always accompanied by a portion of happiness or pride. And partly rightly so, because those involved have simplified their work processes by introducing CI/CD. Consequently, they can now develop faster and deploy faster. Everything runs like clockwork.

If you have any doubts now: that’s good. Practice in many companies shows: of course it is not that simple. Who doesn’t know the situation when a new version is finished, the mail is sent to the test team and … nothing happens. Waiting is the motto. Maybe a day, maybe a week. And then the feedback comes and, not surprisingly, something has to be changed again. Well, simply saying “We’re doing DevOps!” is not really enough.

What is DevOps anyway?

DevOps describes an approach to improving cooperation between software development and IT operations. The term itself is a portmanteau of the terms development and IT operations. Shortened, DevOps is based on three building blocks:

• Understand and increase flow.
• Shorten feedback times and react to them faster.
• Learn continuously and experiment.

Let’s take a look at the 1st point: What flow are we talking about here?

Question: For whom do you produce software? Answer: For your users. So if you want to increase the flow, it is about creating “value” for and with your users. And not just the production (hm, that would be typical of Scrum), but the permanent, continuous increase of customer value (maybe think of Tesla for a moment).

Perhaps flow is not the right term. After all, we want to achieve more. So let’s just talk about stream. Of value stream.

Adding value is…

In classical Lean, the guiding principle is “value is what the customer is willing to pay”. The customer expresses her benefit in her willingness to pay.

That sounds very academic now, doesn’t it? Simply put, it is about continuously increasing the benefit stream while increasing the customer’s willingness to pay or at least keeping it the same over time. (Perhaps we should think of Apple here for a moment).

In value stream mapping, it is important to first understand the product’s creation stream in detail. What happens in the many intermediate steps? Why does it take 10 days to correct an error reported by a customer in the app? Why does it take 30 days to publish a financial report? This SEE and UNDERSTAND is the central point of value stream mapping.

And it is the same with DevOps. SEEING is done by OBSERVING the actual processes. In the past, this was done by going into production halls, today it works by observing teams or conducting structured interviews. However, it is not about finding solutions, it is about supporting teams in their reflection. The goal is for the teams themselves to recognise improvements in cooperation and to put them into practice.

What do value stream mapping look like?

Let’s take a look at a value stream mapping. Basically, it is about identifying process steps on the way to the final product. It is about the duration of these process steps (also called Process Time (PT)) and the waiting time between the process steps (the so-called Lead Time (LT)).

Here in the example, it takes 15 days until the product is created, whereby 8 days are working time and 7 days are waiting time.

After a whole generation of business economists struggled with the idea of optimising individual process steps (buzzword: operations research), value stream mapping and ideally also DevOps take a different approach: different teams that are responsible for individual process steps get together to jointly optimise the entire value stream across all process steps. In corporate reality, it is no longer enough to optimise the step from code check-in to activation of the build process if the subsequent lead time is ignored. The holistic view of the value stream comes into focus; not the optimisation of process step 1 from 5 to 3 days, but the reduction of 15 days for the creation of the final product.

In summary: Value stream mapping is about understanding processes with their process steps and waiting times as a whole. And practice shows that it is much more efficient – based on a common understanding of those involved – to optimise the value stream and not individual elements separately.

Improving value streams at Swiss Re

At my employer Swiss Re, we are also dealing with value streams in DevOps. Below I describe a small excerpt of our approach:

• Conducting structured interviews.
• Processing of the findings and description of the current state.
• Conducting workshops to identify and prioritise improvements.
• If necessary, situational support for individual teams.

I would like to say at the outset that a certain level of commitment and interest on the part of the teams is important. It does not help much to take a top-down approach, because optimisation of value streams cannot succeed without the support and participation of teams. In fact, we even had a case where a team was so doubtful about the approach that we preferred to cancel a workshop at short notice. Value stream mapping and DevOps are about supporting teams, not dogmatically lecturing or proselytising. Unfortunately, in my view, this happens very often with Scrum and agile transformations.

We started by conducting structured interviews. It was important to create a space of trust. We didn’t want to evaluate, we wanted to understand. The people involved came from different areas:

• Core product team (developers, scrum master, business analyst, etc.)
• Change management process owners
• General IT specialists (e.g. for the build tools, or database specialists – depending on the area)
• Representatives from other teams with close interfaces
• Users of the product, colloquially referred to as “business”

Standardised questions were defined for each topic area, which were “worked through” in the interviews. It was striking to experience different types of employees (see recommended reading). For example, the following questions were asked in the area of “requirements definition”:

• Who formulates requirements?
• How are requirements collected and documented?
• How are requirements prioritised?
• Which resources are involved?
• What are typical lead times?
• …

From these interviews, we visualised the current state in preparation for the workshop:

In the workshop itself, the visualisation was addressed and changed through the feedback of the participants. What sounds simple at first glance has a big impact at second glance: optimisation is about the teams and their view of possible improvements. It is about reflecting on cooperation and not about hidden top-down management.

After we were able to establish agreement on the current state, the focus was on improving the entire value stream. Each participant could bring in and present improvements. Corporate hierarchies did not play a role and were faded out in the workshop. Energy was quickly released. And when teams inspire each other – wonderful!

In the end, the improvements had to be prioritised and incorporated into the backlog. We accompanied some teams after the workshop and supported them in implementing improvements.

Conclusion

In my view, value streams and DevOps are good acquaintances. Value stream mapping is an excellent tool for DevOps transformation. They should be used regularly – for example, as in our approach – to keep a continuous improvement process alive. The important thing here is that recognising and improving should not be done in an ivory tower, but is a joint task of the teams involved.

References (in German):

Tom DeMarco, Peter Hruschka, Timothy Lister: Adrenalin Junkies & Formular Zombies – Typisches Verhalten in Projekten

Mike Rother, John Shook: Sehen Lernen – Mit Wertstromdesign die Wertschöpfung erhöhen und Verschwendung beseitigen

Klaus Leopold, Siegfried Kaltenecker: Kanban in der IT

Justus Graumann has published another article in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.