Laura Schneider

Hello. Great to see everyone in already. Still have a few people trickling in, but we'll get started.

I know we just came from lunch, so we're going to keep it a little bit active first, but I promise it won't be the entire time, so you won't hate me. If we can get everyone to stand up first, help with the digestion a little bit, bear with so much motivation. I've heard a few grunts in the crowd. Great.

Now I want you to stay standing if you have previous experience or current experience in working in a regulated industry, just to get a feel for the room. Okay, quite a few.

Now I want you to stay standing if you have never come across a problem with internal audit. So you've always been free sailing. If you've never had a problem, stay standing. Oh wow, that's more than we thought. Everyone that's still standing, you can leave the room. This won't be relevant for you. Otherwise, have a seat.

Over the next 25 minutes or so, we'll talk a little bit more about DevOps in regulated industries and what to do when internal audit says no. For those of you that haven't heard the word no, at least you'll see a little bit of the models that we've seen on the market. Maybe they resonate with those. Tell us other things that you have seen and why you've been so successful so far.

We'll get started. This is something that we heard from a MedTech company, although this is very common also in financial services industries, specifically banking: "We're not a Spotify nor Google. We are regulated; therefore, Agile and DevOps does not work for us."

You may have heard something similar in your organizations or in other organizations. This is the myth we are trying to demystify today: just because you're in a regulated industry, or if you are an organization that is highly regulated, that does not mean that you cannot embrace Agile and DevOps. There are certain challenges why that may be the case, and we'll touch on those.

First of all, nice to meet you. My name is Laura. I'm here with my colleague Sara, and we are here from Germany. We support with Agile transformations and enterprise agility. While we're both industry agnostic, today we will be focusing on regulated industries. What we mean by that is life sciences, pharmaceuticals, financial services like banking, utilities, although that's not exclusive.

We'll jump straight into it. Why exactly do we think this is important? Because 41% have reported that there has been some benefit or a proof of concept of DevOps. There is awareness that it can help, but I don't need to tell that to you because you guys are all here. But 24% have cited that they haven't been able to adopt this or they haven't been able to implement it because of disruptions in their workflows. We want to focus on why this 24% of already the 41% interested are not able to implement those.

There we came across a few key challenges, or ones that we see pop up a little bit more often. We'll touch on those, and you'll see one highlighted in purple, and that's the one we'll dive a little bit deeper into.

First up, failure culture versus zero audit policies. When doing an internal audit, the goal, or at least the wish most of the time, is to have zero audit policies, or rather zero findings. This goes against failure culture, and it touches on the mindset of the fear of failure and where there's a need for psychological safety. For those of you who came to the talk yesterday by Sonny, he also talked a little bit about psychological safety, and I know a few other talks as well. It is the contrast between wanting to have zero findings and also wanting to fail to learn.

We also see at the bottom the increasing effort for GRC and security. This is because of the importance and the regulations that have come in in this space, and the effort and the capacity that is then taken for this naturally means there is less capacity available for introducing or implementing DevOps ways of working.

Going hand in hand, we see the effort for ensuring traceability. You need to track requirements going into the backlog, going into changes, going into devs, going into ops. In highly regulated industries, we see the need to track all of this, to document all of this. With the effort and the capacity, again, there is a lack of effort then left for the implementation of new ways of working.

Of course, we have the idea of tooling and automation, which we've also heard a lot about during the conferences and the talks here. But when there isn't already a way of working and a mindset in place, there isn't the opportunity to look into what types of tools can help automate or even how it can be better.

Then we go into lacking knowledge about Agile and DevOps from auditors. I don't know about you, but when I'm asked, "Hey, can you do something?" and I have no idea what it's about, then the automatic answer is no. If you don't know what it's about, then you probably won't want to do it; otherwise, you don't know what's coming for you. Oftentimes you'll hear from internal auditors, "No," because they simply don't know, and there's a lack of awareness at least of what the use cases or the benefits can be.

Then we have outdated ways of working. In highly regulated industries, maybe taking an example of financial services and banking in specific, we have in the European markets maybe BaFin or MaRisk, which are a little bit older and have been in place for a little bit longer. This means that it takes a little bit more time for organizations in this industry to then come up with new ways of working or when they want to implement these.

Finally, what we want to touch on today, and where we'll dive in a little bit deeper, is segregation of duty. For those of you who don't know what that means, that is so that no single individual will have the responsibility or the sole responsibility and control over a critical process, whether that's decision making or the actual tasks in itself. That's to make sure that it's segregated so that it minimizes risk, error, fraud, and ultimately reputational damage and financial damage. We'll talk a little bit more about this and how this can look in different forms.

Why exactly should regulated industries even embrace it? We conducted a study looking at over a hundred different cases and organizations, and we found companies that adopt full BizDevOps operating models experience a boost in financial performance with a year-on-year revenue increase of 20 to 25%. That is a significant increase. We actually have one of the co-authors sitting in the crowd, Daniel Beja. If you are interested to hear more about that, then definitely talk to him. That is the value from agility point of view.

This shows that we can create more efficiency, you can accelerate software delivery, and optimize stability. There is a need for it, there is a benefit for it.

How exactly can we do that? Looking at the cycle, there are a lot of areas that we could touch on, but due to the time that we have, we'll only focus on one that might be the most interesting for today. If you are interested in any of these, then feel free to talk to us.

Starting with enterprise DevOps in a regulated industry starts with strategy. You see that on the top left. Where you see the differences on different industries and the intricacies, that's where we get to organization. Within regulated industries specifically, you will see different models of how this can be adopted based on how regulated they are, what their maturity of DevOps is, or their understanding and Agile ways of working. We'll look at three particular options on how to organize DevOps.

Sara Steiert

I'm going to make myself very unpopular in the audience now. Hi, I'm Tom. I'm now your internal auditor. I strive for zero audit or zero findings policy. I have varying segregation of duty opinions. I'm willing to be convinced, and with Agile and DevOps and that understanding it's the same. I'm willing to be convinced, but at the moment I'm quite conservative.

If any of you have internal auditors as well and you have a Tom, then maybe you can relate. We'll have different scenarios and different findings at least of what we've seen on a generalized market.

First off, as I mentioned, very conservative: dev and ops must be entirely separated to ensure the segregation of duty. Teams and roles must be separated. That is my point of view at the moment. How do we solve this?

If your Tom says dev and ops must be entirely separated, then this is what we are going to do. We're going to take all dev engineers and put them into a dev team, and then we'll take all ops engineers and put them into an ops team. Those teams will have separate leads.

The main purpose behind the segregation of duty, as Laura has mentioned, is about avoiding conflicts of interest. What could be a conflict of interest? For example, let us imagine I would be a team lead for two teams, and I would force my dev team to simply push features into production, ignoring all security risk and compliance stuff. And I'll force my other team, the quality assurance team, to simply look away and take those things into production. This is what we want to avoid, and this is how we avoid it by having two separate leads.

This setup comes with quite some pros and cons. Starting first, the segregation of duty is enforced on an organizational level. It follows the classic approach: we have a dev team, we have an ops team. This will make Tom very happy because it's easy to comprehend and it follows his understanding of it. But unfortunately this does not enable DevOps.

What we have seen with the organizations that we are working with is that if organizations are structured in silos, they will move within those silos. You'll need an extraordinarily high DevOps maturity and mindset to really overcome those organizational barriers between dev and ops for them to collaborate together.

This setup we typically see when clients start their DevOps journey in a regulated environment. As mentioned, it enforces the segregation of duty fully, but it will be very tough to really achieve a good DevOps maturity in this setup.

Laura Schneider

Great. We've started it off. We have a little bit of understanding now. Now myself, Tom, the internal auditor after my online webinar: dev and ops may work together as a team, yet they have to have different managers to avoid conflict of interest. I've changed my mind a little bit. Let's see how we can approach that.

Sara Steiert

That's cool, Tom, that you've changed your mind. Finally, dev and ops are allowed to work together. We'll put them also together in a team, a so-called squad, and they'll be focusing on delivering a product.

The same as in the previous option, dev and ops engineers are still separate roles and they will be allocated to chapters. If I was an ops engineer, I would be part of two teams. First I'd be part of a product team, a squad, and there I would have my functional lead, probably a product owner who's responsible for the product, delivering value and transporting the product vision to the team.

Then I'd be also part of the operations chapter, and there I would have my disciplinary lead, the chapter lead. The difference is the chapter lead would be focusing on HR topics such as career development or potentially also capacity planning for those ops engineers: how many do we have today, how many will we need tomorrow, how does my workforce need to evolve?

In this setup we have DevOps enabled via those squads, and we have the segregation of duty enforced through those chapters. But same as in the previous version, in this option we still have separate teams. Here it is really crucial to pay attention to aligning goals of those teams and those leaders very well with each other. It needs to be very well thought through how you want to reward, for example, dev teams versus ops teams, because we want them to work together and not against each other.

This option is the most common we see with our clients in the market, and it enables a higher DevOps maturity, especially compared to the previous option. Organizations that are in this state have typically already had multiple conversations with Tom for him to understand what DevOps is all about and how it can be organized.

Laura Schneider

As Sara mentioned, we see this the most common on the market, but now Tom says, okay, we want to be a little bit different. We want to be pioneers, we want to be a little bit forward thinking. I don't know how many Toms you have, but if you are, good luck and congratulations.

We have Tom now and he wants to take it one step further. We understand the way that you work. If you can prevent conflicts of interest with processes, you're free to organize as you wish. How does that look?

Sara Steiert

Finally, starting to like Tom. We'll have now all dev engineers and all ops engineers in one team. The roles will still be separated though, but we'll be having one team, one lead for the disciplinary and the functional leadership.

This organization is great because it fully enables DevOps, obviously, but we are not having the segregation of duty enforced on an organizational level. Instead, we must ensure that it is on a process level.

Just to give you an example of how this could work, you must ensure with a process and document that a developer does a change but another developer would review and approve it. Apart from that, you also need to convince Tom that you're very confident in doing so and that you will stick to this process, and potentially you may have a couple of tools that would even prohibit any other way of working.

So far we have seen this kind of setup once at our clients. The reason is because the DevOps maturity here must be quite high, specifically talking about processes and tools. As mentioned, you really have to ensure that you will be covering the segregation of duty on a process level. Additionally to that, your internal auditor, Tom, must have had already quite some experiences with it, must have understood what DevOps is, plus have the trust in your teams that you would fulfill the segregation of duty on the process level.

To sum it up, those are the three options we mainly see in the market on how to organize when it's about DevOps. As Laura had mentioned already, typically when we start an Agile or DevOps transformation with our clients, we walk through and have a look holistically at the entire operating model. Unfortunately we can't cover everything today; it's going to be also quite exhausting for all of us. So we would still like to share a couple of key learnings on all of these dimensions.

Let us start with strategy. Simply get inspired by other industries. Me personally, I've been working in a MedTech industry as well as the financial sector. Based on that experience, I've learned that regulatory requirements are quite similar in those areas. Segregation of duty is a concept in both industries. Traceability is a concept in both industries. If you are stuck, and your peers are more stuck in your industry, then maybe just have a look at the other industries.

We've been talking also a lot about organization. We won't deep dive so much into it further, but if there's one thing we'd like you to remember from today, it is to act as one team across dev, ops, and your internal audit team, including Tom.

Try to collaborate as early as possible and as often as possible. Try to challenge each other and learn from each other. Ask your internal auditor, why do these things have to be the way they are? Why do dev and ops have to be separated like that? Can you show me the paragraph, the quote where it is written that I must do things in this way? Try to find a way together.

Those regulatory requirements have often been derived during times where agility and DevOps haven't been a thing yet. The wording leaves quite some room for interpretation, and we have seen different versions of how to get along with regulatory requirements.

Do not overcomplicate and overregulate; it's already complicated enough. Try to keep things as simple as possible.

We had a client, and they had overregulated themselves so far that every tiny change, even if it would never see production, so you just create your tiny branch and you do your tiny little experiment, needed to undergo the full process for documentation in order to ensure the traceability.

What happened? The teams stopped experimenting, and they had such a high amount of technical debt because teams were scared of doing changes and they tried to keep them as minimal as possible because they didn't want to run through the entire process. Additionally, they had various product teams, and all of those product teams were solving the regulatory requirements differently. In one team, Docker was like a life risk for the patient, but in another team it didn't play a role.

If you do not overcomplicate and overregulate everything, then for what's left, try to automate as much as you can. Treat regulatory as if it was a feature. Reserve fixed capacity to fulfill those regulatory requirements, but also plan backlog items, for example, for continuously automating.

For what's left, let dev be dev. Eighty percent of a dev engineer's time they were spending on filling out Word documents and forms just for some regulatory requirements. That was their day-to-day work, and that company was really struggling with hiring and keeping IT talents. As you can imagine, as a dev engineer, it's not really attractive to be filling out all the Word documents. Try to let dev be dev as much as possible, and try to centralize all regulatory type of work and effort into centralized team, potentially with experts that are also interested in those topics and experienced in it.

This brings us to the end of our talk. We hope you enjoyed it. We hope we could inspire you. We'd be super, super keen to get into a conversation with you, to learn whether this resonates with you and your industry, and maybe you do see other solutions and options as well.

Just by the way, if you have issues with zero finding policies and issues with psychological safety and cultural topics, we've got Sonny there in the back, who has held a presentation on psychological safety yesterday. Feel free to reach out to him. As mentioned already, we also have the author of the Value from Agility POV, our Operating Model Black Belt and Enterprise Agility expert Daniel Beja, and the rest of the team is also here in France. Just feel free to reach out to us. Really looking forward to chatting it up with you later on. Thank you very much for your attention. Thanks.