Irene de Kok

So welcome everybody at the war story, "How We Got Out of the Trenches."

Thank you all for coming. We are going to present to you in this presentation two topics. The first one is how I found my DevOps team in a stalling DevOps transition. After eight months, they were working out of the trenches and trying to get everything done in time, with quality, without working overtime. And of course they couldn't. The second thing is that we are going to explain four approaches that we took to get them out of the trenches. We will come to that in this presentation, so hang on with us.

We are curious which symptoms you recognize. The first one is a symptom that you work overtime. Put your hands up if you acknowledge that one.

So half, almost. In the meantime, it can be that actually the amount of work, your queue, your backlog, is actually rising while you're working so hard. A little bit less, but also almost half.

And then it's of course tough to work on improvement, so it feels too busy to work on improvements. Hands can come, but I think 60%, and the man next to me raises his hand.

Bernie van Welt

So you will ask yourself, why am I raising my hand here? I run a DevOps sub-department, and we have all the symptoms that you saw up till now, and we have a couple more for you. So please pay attention to the troubles that we found.

Irene de Kok

Applying DevOps by the book doesn't feel effective. A few hands are rising.

Losing great employees in the meantime, in this tough labor market, of course. Finding the proper new ones is tough; better, easy to keep them.

Multiple DevOps teams living on their islands, like it feels. They are in separate contexts. A few hands go up. Thank you for sharing.

I hope there is something in our story. At least these were the trenches which we found out in the beginning of our journey.

Bernie van Welt

So let me quickly introduce myself and the reason why I am here, and also the reason why Irene is here.

I am VP DevOps for Keylane. Keylane is a company that provides SaaS services for insurance companies in the Benelux, the Nordics, and in Germany. As I already said, I found my team stalling after eight months of doing DevOps.

Of course, we gave them all the proper training. Of course, we gave them The Phoenix Project handbook. Of course, we gave them The DevOps Handbook. We did a re-teaming and everything according to the book. But apparently that still meant that my team came to a stall. They weren't improving anymore. They were working overtime. They didn't have any time to think, to improve, or to innovate at all.

I also came to the conclusion that I was not able to do the solutioning of this problem by myself. So I reached out to Xebia and to Irene to help me, because Irene could nicely work with the teams inside-out and on the ground level. By having Irene, I could focus a little bit more on the managerial level, work with my team on the leadership traits and everything. So, Irene.

Irene de Kok

I am Irene de Kok. I am a consultant at Xebia, and I love to create healthy work environments where we work on what we believe in and what works in practice.

Learning is something you should facilitate. But if you are very busy, that is very tough. I love the people working at Keylane. They are very modest, very smart. But their primary tactic was to work harder, or think, "I am maybe the only one who thinks there is a problem." And there were not that many occasions to fix debt, so then it doesn't improve.

Bernie van Welt

So what happened? My team was in the doom loop, and everybody knows the doom loop from Jim Collins's book. They were working harder and harder and harder, but not smarter, because they didn't find the time. Customers were calling. We had too many tickets open. Everything that you can imagine kept them from, "Friday afternoon is where we do improvements." But Friday afternoon never happens, right? Everybody knows that.

So we had to find a way to get them into the improvement flywheel. We were searching for the flywheel effect, and our approach was to start doing proper retrospectives, proper improvement sessions, but also find time to innovate.

Irene de Kok

And it is very tough, of course, when SLAs are tough to maintain and you are so busy. You should really use your time effectively when you invest in improvements, because you do not want to say, "Oh, it is lost time." So it should be very good.

But we managed to get out of the trenches. These are actually, after a year, accomplishments or the impacts we could see.

Bernie van Welt

Don't think that this is the end of the presentation, because this is the middle. We like to do a sort of mix-up of start and end, and we have a nice takeaway at the end. So we wanted to explain to you the observable metrics and results.

After Irene and I worked together with my teams, I have four DevOps teams that serve 20 customers. We found out ways not only to work on the improvements, but also to measure how we could improve.

The first one is that we saw after a year that we were able to do all our work in normal hours instead of working overtime and hard time, evenings, and weekends. The good thing is that when you are able to do that, you automatically create time to start thinking, to start improving, and start innovating.

The second thing that we saw, and what we also could measure, is that we were able to bring down the open ticket count that we saw at any minute in the day. It was lowered from 1,600 tickets to 1,000. So we almost came close to halving it down.

We also saw, and you saw one of the things that we were struggling with was attrition, we were able to foster an environment that was not about working overtime and only working hard and making sure that you have everything right. So we were able to lower attrition to normal standards in our industry, but also in other departments of my company.

We could also measure employee happiness. Twice a year we do an employee survey that we measure, and we were able to get the employee happiness score, if you would want to call it like that, from a seven on a ten-point scale to eight. So that was really a huge improvement. I managed to get the highest score in the company for my department.

Irene de Kok

Especially if you look to the ranking from the bottom to the top, actually.

Bernie van Welt

At the end, and the most important one, customers were able to feel that we were improving. We had fewer incidents, we were solving incidents faster, and we had time to think with them instead of just working on incidents. So we were able to work together with them on improvements.

Irene de Kok

But we would really like that you are maybe more capable to fix this. So if you have clarifying questions, you are welcome. If you would like to discuss with us, come after the talk. Before we go to our war story, I would like to make that invite.

Now we will explain which four major steps we made to climb out of these trenches, to break out of them, and get to a more healthy environment where you have overview.

Bernie van Welt

Let's start with the beginning of our journey. Irene and I sat together and we were thinking, okay, what can be the first step? How can we get these people out of the trenches?

We came to the idea, perhaps a little bit inspired by The Phoenix Project, that we needed to find where the true bottlenecks are. Because when I talked to the people in DevOps, they were saying, "Yeah, we do improvements." But it was individual improvements, when they had a little bit of time left, and it was all suboptimal. There was not a list of improvements. There was not a list of bottlenecks. There was no prioritization.

So what we did, we invited a good sample of the DevOps teams, took the Xebia office for a day. We took them out of the normal working environment, put them at the Xebia office, and we did a business process mapping exercise with them to find the bottlenecks and find which ones are the most important, but also the most effective and efficient to start working on.

Irene de Kok

That is inspired by Eliyahu Goldratt's The Goal. To facilitate flow, it is very important to focus your efforts on the thing which creates a growing queue, which is the smallest part in your process, where you lack capacity. You need to know that, and therefore you also need to have overview to distinguish where it is.

So it crosses organizational boundaries. Therefore, we invited a sample overtaking multiple organizational boundaries. All teams of your department were present. From the other adjacent departments, there were people present. So we had all perspectives to get a representative view, to be able to prioritize which bottleneck gets the most attention.

We were wondering, who does that kind of prioritization? Where is the bottleneck, and what should be first in your organization? Maybe some people may shout out which position, or who does that at your organization? Whoever did a proper business process mapping to find the true bottleneck? I don't see hands. Nobody.

Perhaps that is also a good answer, because it should not be nobody, but it should be everybody, because you need many perspectives to distinguish which bottleneck makes sense the most.

So we first start to map the current reality. How does this process look? It was the monthly deployment, which was actually taking longer than a month. So it is overlapping, and then becomes really busy, so it should fit into a month. With all the people present, it was like 15 or 16 people, something like that, and we managed to get a representative overview within two or three hours.

The next step, we asked them, where do you think is the bottleneck? Which is taking too long? What is tough? What is too laborious? Also boring, because we want to tackle that attrition as well, so it should be interesting work. Where is the bottleneck which lowers our total capacity?

Also a very important thing when you know where the bottleneck is: how do you start tackling that? Especially with these modest people, they think another person may make the first step. But we started to at least sketch where the first step is, what is the solution direction, so you can start on the journey.

I was really strict on that. The first steps may be quite actionable. It is mitigating, so you don't really resolve the full bottleneck, but at least you start getting a view on what you could do, how big the problem is, or when the problem happens, or who to talk to. I don't know, whatever. But it should be somehow actionable.

This is a view on how the process looked like. I think almost a hundred steps and all kinds of agenda, how it works. Also, an important thing I would like to mention is that there was a representative set over there, but we made a video, which was a recorded presentation, which was shared with everybody. So everybody who was not there could also at least see your insights.

Bernie van Welt

What we did in the morning, we were able to map this out. In the afternoon, we focused on the blue sticky notes that you see here. How can we solve them? How can we remove manual work? How can we automate things better or faster?

What we found out, and Irene already mentioned that a few times, is that typical engineers are a little bit inside their head. They are not outspoken. We came to the conclusion that we also had to bring a little bit more safety into the meeting. That brings us to the next slide.

Step two in our war plan. I know that we see this in a couple of presentations yesterday and today, how important it is to create a psychologically safe environment. Because when the engineers do not feel free to speak up, to tell really where they think the problem is, or that they can safely come up with a stupid idea or a bright idea without the chance that somebody says it is a stupid idea and let's move on, let's start working, we are talking too long.

What we did is, together with Irene, we figured out how we can bring this psychological safety into the daily meetings, the weekly meetings, the monthly meetings. That is also very important why Irene, as an outsider, could work together with the team in a safe way. Because you can imagine that I, as VP, cannot start attending retrospectives and telling them how to work, or that it is not okay what they are doing, or that they should be more creative, et cetera.

For me it was very important to have somebody like Irene, who worked for me over a year. In the beginning once every week; after that, we did it every other week for a day, to work on psychological safety and also work inside-out with the teams. You worked with the teams while I was working perhaps with the same ideas and the same method, but then more top-down with my managers and working with them on that side.

I think one of the takeaways is that you really, really, really have to nurture this safety throughout the organization. The safety should come from the top down. I need to be safe as a VP that my CEO agrees with this. But also my managers should feel safe to do all these kinds of things with their teams without me being present. And Irene and the teams should feel safe to do whatever they think is needed to do these improvements.

Irene de Kok

I saw really at Keylane that people are really strict and modest, and they really complied to anything. But if you see it doesn't work, you should vary your approach within an acceptable risk, and you may not know the solution up front.

That kind of safety we really needed to nurture. Not only the expert knows the solution; maybe more people than only the expert.

We had various ways where we nurtured and fostered this kind of safety. A few were from you.

Bernie van Welt

What we did, we decided together, because we could not always work together, but Irene was working in the trenches and I was hovering a bit above the trenches, perhaps. We decided to share some mantras that we would use in our verbal communication, in written communication, et cetera, so that we would speak the same language when Irene was working with the teams and I was working with the managers.

One of the things that we thought was very important was, for instance, trust over control. So trust the teams instead of trying to control them. Errors are okay, but don't make them twice. Dare to give, and dare to ask when you have problems. Dare to ask other people for help. It is not stupid to ask for help, but also dare to give even when you are busy: help your colleagues, et cetera. So we decided to have some mantras that we could work with.

Irene de Kok

One of the things which really helped to nurture this safety is, if people intended to do something, I often asked them, "What did you do with it?" But really, they were open that they could also acknowledge, "I did not do anything with it." Then I asked, okay, is it not applicable anymore? Or, oh yeah, no, actually I should do something. Okay, so think when. What will you do upcoming next week?

I was kind of strict with that, but I fostered them to take some actions.

I am wondering what kind of mantras you do have to nurture that safety or foster that continuous improvement culture. We would like to give you a minute to share with your neighbor what kind of things you say to foster that environment. Afterwards, we stick ours on the wall, and we would like to invite you to add yours at the exit when you leave the room. So please take a minute with your neighbor to share your thoughts on this.

Audience Exercise

Slide. Border slide. I don't... oh yeah, there is the timer.

Bernie van Welt

I think it is also very important for you all to think about these kinds of mantras that you can use within the team and within your management, et cetera, to work and use these mantras in your daily communication. At the end of this presentation, if you want to put a sticky note up, if you have anything to add for us that we can take home.

So we are going to the next slide, and we are going to step three.

Irene de Kok

No, no, no. Just ten seconds.

Okay, the minute is over.

Bernie van Welt

Yeah, you saw the minute is over now. I saw the time.

Irene de Kok

Five, four, three, two, one.

Ladies and gentlemen, we would like to finish our story in time. We would like to go to step three in our war plan: create breeding places for improvement.

With the business mapping, we took a focused effort, but it should be natural that great things have a chance to grow. We set up or nurtured multiple places where they would be.

The first one is the retrospectives. As an agile coach, I have seen and hosted a lot. When I was at Keylane, I heard they were boring, and they often skipped them. I thought, that is not good. What do they do? They did it by the book. They did the exact format they learned in the training each time and again. So they asked the same question to the same people about the same timeframe. Of course then it is fading out the interesting discussions.

So I encouraged them to see it differently. It is time with your team to find improvements. You should look every retrospective for a certain focus, on a certain theme or subject or aspect or whatever. You box a little bit of content, and you find a format which facilitates the proper discussions. Maybe sometimes it has some preparations, and also it should be fun.

That really changed, and actually now they don't find them boring anymore.

The next thing: we have these focused bottleneck mitigation workshops, like the business process mapping, for also a few other occasions within the complex processes to overcome the organizational boundaries.

The last: we also had guilds. Because of cross-functional teams, certain disciplines are spread over teams, and they lost connection, living on their islands. They should reconnect and learn from each other and think, "Oh, I see this problem. Do you see that also?" One of the main guilds we started with was with the Flow Masters. They work with Kanban or another Scrum Master, but the Flow Master fosters good cooperation within the teams.

Bernie van Welt

They said, well, these breeding places we actually do miss in our company. What can we do?

Irene de Kok

Exactly.

Bernie van Welt

So these are all kinds of improvements that we could do within my DevOps department, but we also came to the conclusion this is about improvements. We also want to go on to step four, and step four is creating room for innovation. Not just improving the bottlenecks, but how can we invent something new, or new tools, or new ways of working, new technology?

We wanted to do that not only within DevOps, but cross-functional, cross-team, and cross-departments, and we call that an open space. Irene can explain what an open space is.

Irene de Kok

It was actually very innovative at Keylane, because it was really time we give to the people to exchange ideas without a strict content policy up front. It was actually very open. Everyone who had an idea, or something they wanted to explore, a problem or a solution or technology, is welcome to come. If you don't want to, please stay at your desk, no problem.

We also invited adjacent departments. Actually we had a big space, the ground floor of the Keylane office, and we said, we have that corner, we have that corner, and this middle big table. Everyone could put their subject on the schema. It was like session one starts at three o'clock, and choose which of the six parallel sessions you could have.

What I really like is the law of two feet. It was really giving the trust to the people to use their time wisely. One of the rules was, if you don't contribute or learn at the moment, please move to another session.

Bernie van Welt

Or go back to work.

Irene de Kok

Go back to work. Also allowed. But you are responsible for your own effectiveness during the open space.

Bernie van Welt

What happened at Keylane was funny, because we have a very open space, which is also a little bit where the name comes from. It is our cafeteria area that we also use for big presentations. There were all these people running around with sticky notes and visible different groups at different spaces in the open space.

One of my C-level directors came to me and said, "What are these people all doing? Shouldn't they work instead of running around here and doing all kinds of sticky-note sessions for three hours in a row?"

I told him, well, this is exactly what I want them to do. They are finding bottlenecks. They can do that in a psychologically safe environment. They are working on improvement, but they are also working on innovation. So this is exactly what needs to be done here.

So the guy nodded and slowly went away, like, okay, I shouldn't interfere. That was a good thing to have.

Irene de Kok

We have to watch the time; people are telling us.

We learned a lot, but we still have some open challenges. You can read them here. Please talk to us later. And of course, this is not rocket science, is it?

Bernie van Welt

That is almost with all presentations that you already see. Everybody reads the books. Everybody has been to different conferences to hear about the stories. Is it rocket science, what we told you today? No.

But most people know it, or try it, but they forget to do it in their day-to-day work. That is how we want to end this story. You saw the problems, you saw the solutions that worked for me or for my company.

Our advice is just do it. Just try it, and do it in a psychologically safe environment. That will bring the results. Thank you very much.