Suzette Johnson

Welcome. Thank you for the opportunity to be here and joining us for this session, Industrial DevOps: What are the barriers?

In this presentation, Robin and I will continue the Industrial DevOps journey. We will briefly revisit the principles of Industrial DevOps, and then discuss the barriers to an Industrial DevOps transformation, along with providing some recommendations based on research and some of our own experiences that we want to continue to validate. We believe that you likely have some of these experiences and would welcome that conversation following this presentation.

With that, I am Suzette Johnson. I'm a Northrop Grumman Fellow, currently leading our enterprise lean-agile strategy. With me today, we have Robin. Robin, would you like to do a quick intro?

Robin Yeman

Yes. So nice to be here as well. My name is Robin Yeman, and I worked at Lockheed for 26 years and recently have had the chance to transition to a not-for-profit. I am now the chief technical officer for Catalyst Campus.

Here you can see Suzette and me. This is, I want to say, three or four years ago, but Suzette and I have been working and presenting together for over eight, nine years now. We actually had the opportunity to meet at a conference and were listening to each other's presentation, and it sounded like we were both talking in stereo. We were saying the same thing, we had the same stories. After that, we decided to team up and actually tell some of those stories together.

Suzette Johnson

With that, we want to get into our conversation today about Industrial DevOps.

First, we'd like to start by giving a little bit of context of what Industrial DevOps is, in case this is a new concept for you. Industrial DevOps is designed for large cyber-physical solutions. We have identified eight principles of Industrial DevOps, and as we talk today about the barriers to Industrial DevOps transformation, we are going to stay centered on principle number one, which is to ensure that our organizations stay centered on the delivery of value. While there are many practices and tactics and behaviors that we'll discuss, we want to be sure that we stay focused on the outcomes that we're after, which is delivery of value in the shortest sustainable lead time.

Robin Yeman

We have a scenario that we are going to put in context of this Alset Transport company. They're a fictitious company who produces vehicles to support assisted and autonomous vehicles, both commercial and consumer markets. In this context, they have been implementing Industrial DevOps principles for nearly a year, and they're experiencing some challenges, including multiple competitors, rapidly changing technologies, security and compliance issues. They're also struggling with their adoption of the principles in terms of getting it to stick within their culture and really getting it to apply and be part of how they do business.

Suzette Johnson

With that, Robin, do you want to tell us where Alset is right now in their adoption?

Robin Yeman

Absolutely. Basically what we're looking at here is Alset has been awarded a federal DevOps program, Autonomous Transportation Communication System. As you can see, this is very much a place or a situation that Suzette and I would find ourselves in, both at Lockheed and Northrop Grumman, in these large cyber-physical systems that require multiple different suppliers.

In the context of Alset, what I'm going to tell you is they really still have a functional organizational structure. Not sure if you guys have ever experienced that, but we're trying to make the transformation, and they still have one. They haven't had the chance to change because they've got this great big contract, and they actually need to get started quickly. They'll get back to it later. What they're thinking about is, "Hey, maybe let's just have some IPTs, or integrated product teams, until they can reorganize."

The engineers are still allocating all of the requirements. So when we look at that, we have not had the chance to create these cross-functional teams, these teams that actually can deliver value all the way through the capabilities. They're still staffed organizationally by systems engineers, software engineers, test engineers. Maybe you've had this problem before.

The team thinks that in order to get started quickly, maybe they'll just use the sprints and the timeboxing to build their architectural artifacts. If we build those first, then maybe we can get started and actually really move into a DevOps program. But we know that this could possibly be a trap.

They have developed a detailed master schedule, and they need that schedule so that the customer can see what their milestones are and what their timelines are. But we know that they really need to use a product backlog and move from predictive planning to empirical planning.

They have to start immediately, so instead of incrementally staffing up teams, they're going to hold a hiring event and bring everybody on all at one time. We know that's also a problem.

They have detailed statements of work for all of their suppliers, so they've already taken out all of the creativity. Even though they really want to enable, they don't know how to make the change. Because they have promised a really tight schedule, they believe that starting all of the features at one time is the way to go.

The reason I bring this up is because, just like Alset, I have had this experience over and over and over again. The most well-intentioned programs want to make these changes to move to a full DevSecOps lifecycle. They want to deliver at the speed of relevance, but they're really struggling because this underlying organizational structure or architecture that they have is creating these barriers.

Suzette Johnson

Now we will take you on this journey with Alset, and we'll talk about specifically what are some of the barriers that they're experiencing as part of their transformation, and what are some of the recommendations that they are going to try and experiment with to help overcome these barriers and to form this new way of working.

We have six barriers that we are working with with Alset. The first one is going to focus on their organizational structure. Then we'll talk about the challenges around the lack of a common language, not staying focused on the value stream or really understanding what their value stream is, patterns to breaking down the system and what challenges they're struggling with there to really understand the system and how it decomposes, also valuing exclusivity over inclusivity and what is the impact of that and how do we make some changes so that we can have a more inclusive environment. Lastly, we'll talk on the lack of psychological safety.

Robin, do you want to talk to us about organizational structure?

Robin Yeman

Yes. This is near and dear to my heart. The biggest challenge, and it almost looks like everything comes back to this, is the existing organizational structure. Here, the executive is saying, "Hey, we really need specialization because of efficiency, and we need clear roles and responsibilities." This is what our executives have been taught. Because of that, they're really struggling with the recommendations that the coaches are making, which is, hey, Conway's Law, for one. You are doomed to build a system that matches your organizational architecture. We're going to create those hierarchies.

With all of these functional organizations, we have an incentives mismatch. It's highly unlikely that somebody that's spent their entire career becoming the VP of software engineering or the VP of systems engineering wants to give that up and actually look at a product delivery organization. Their incentives are completely opposite.

The handoffs are continuously causing delays, but they can't be fixed, and we cannot reduce the dependencies because of both the organizational architecture as well as the systems architecture. We've seen this over and over again.

I think the key, and I don't have the end answer, but I think the key is companies have to determine whether they want to optimize for product delivery or specialization and really focus on making those changes. They can utilize things like a dual operating system, maybe considering involving technical people in the design of their organizational team structure. But this has to be dealt with because it's causing our large legacy systems over and over again to fail in the same way.

The next barrier we've talked about is this lack of common language. The DevOps coach is really working with the executive to talk about cross-functional teams and how working together drives innovation. However, what you're experiencing is a lack of a common language, which is reducing trust.

Currently we've got program management really focused on lean, which is exceptional, but systems engineers are focused on systems thinking and design thinking. Software is really focused on agile and DevOps, where you're still seeing operations talking about ITIL, or IT Infrastructure Library. The bottom line is all of these environments want to deliver optimized systems, but they're having the Tower of Babel issue. They are not being able to communicate, which is leading them to not be able to work towards a common vision. Things like building a common language, developing a Rosetta Stone, or mapping the language together so that people have something to look at could potentially be the solution.

Suzette Johnson

Building off of that, they have another barrier that they are facing, which is they don't understand their value stream. Alset, like so many organizations, struggles with understanding the value stream, especially in these complex environments where there's software, there's hardware, there's suppliers.

Why do we care about this? We're working with Alset to help them understand that the value streams really help them understand the flow from their requirements and the customer needs to the delivery of value. By understanding our value stream, we can also measure and visualize the flow of work, the metrics, the progress. We can understand where the bottlenecks are and also how to best align our teams to deliver that value.

It takes time to really understand and capture the value stream. We are talking with them and working with them to take time to hold the training, hold the workshops, and really map out that end-to-end flow of value.

Where is the greatest opportunity for improvements? We're going to look at the whole value stream and do some assessments. Maybe we don't have to do everything all at once, but let's think about where we want to start that provides the greatest return on investment.

Some things that we are also going to do are use the metrics to measure the improvements as we make the changes, use a modeling tool to help make the value stream visible, and revisit this regularly. It's not like we do the value stream once and we're done. We'll map out the value stream, look at the opportunities for improvement for the alignment of work, where we can make improvements in the flow of delivery, and then measure that progress and continue to make improvements.

Robin Yeman

The next barrier we run into is access to patterns to design the system, especially these large complex systems. The DevOps coach is really focused on building your system around products and services. They're trying to support the executive so that they understand what Conway's Law is: any organization that designs a system will inevitably produce a design that's a copy of the org structure.

Frequently, you can hear executives say, "But if we have really good documentation, or if we have really clear roles and responsibilities." But we know that that's a trap. Recommendations to the business are going to be decomposing your system based upon products and services, not based upon input-based artifacts. Shift to product teams over project teams. Architect to reduce those handoffs. Dependencies are a killer. Create small cross-functional teams that share this common set of practices. It's very difficult, but it's going to really help Alset.

We want to make sure that people value inclusivity. But for years, valuing exclusivity made people feel special. You were in the in crowd, the in club. Here the DevOps coach is saying you really want all hands on deck. The answer to the solutions of the next generation are going to be from these diverse groups, these diverse people. Happier people build much better systems.

This is difficult for the executive because they've earned their stripes. They've earned their position. This is a really hard pill to swallow. They haven't seen it in action yet, so it's unnerving. They're actually having to take a leap of faith.

Recommendations for the business here are going to be applying a growth mindset. Think beyond what you thought was the answer. Use a model to decentralize decision-making. We really want to distribute that out. Build safe environments, not just environments for the cool kids, environments for everybody. Ask questions and practice active listening. We want to leverage tools that teams can brainstorm with easily, especially now in the terms of COVID, where we're all working separated. We really want to make sure that we're using our tools and our voices to value inclusivity.

Suzette Johnson

In order for this to work, we really need to focus on creating an environment of psychological safety. Lack of psychological safety can sometimes really prove to be a barrier to your transformation, especially with the increased transparency and visibility of progress into what is working, when things are not going well, and how do we react to that as leadership.

Psychological safety creates environments where we can really thrive and where people are willing and able to share their ideas, ask questions, and raise concerns. They recognize that when they fail, that's actually a learning opportunity, and from that learning opportunity, we can continue to innovate and improve. We fail fast, fail early, but then we learn and innovate as a result of that.

In a psychological safety environment, management recognizes that short iterations of failure, coupled with this rapid learning, actually reduces project risk and creates an overall ability to make better improved decisions because we have information at hand and readily available based on what the teams are actually demonstrating.

Our coaches recognize the need for transparency. They will coach the teams, they will coach our leadership to understand that failure can be seen in the right context as an opportunity to continue to grow and learn. That's actually applying the growth mindset that Robin was just talking to us about.

Some recommendations to our business are to ensure that we're leading by example, make sure we understand our culture and how we are reacting and responding to these small increments of failure, and actually building a generative culture. A generative culture is where we have high collaboration, high levels of trust across the organization, up and down the hierarchy, as well as horizontal across the organization. We continue to have studies from industry that show qualitative results and quantitative results about how that actually produces better results, high-performing teams.

We want to also think about making sure we are aligning our incentives and our performance reviews with the behaviors and practices that we're seeking within the organization.

In addition, we're going to take all this learning, and we're actually going to create an intentional culture. We do that by looking and building a roadmap of these behaviors and things that we want to change. We'll actually group them in four different areas. These different areas align with all the different topics that we just covered. We will look at mindset validation, the organizational structure, technical competency, active role modeling. With these different areas, we'll actually think about what improvements we want to make as an organization. We'll put it as part of our roadmap and have intentional cultural architecture as well. We'll get feedback: how we're doing, how are we progressing, so that we continuously help our organization triumph over the barriers that we're experiencing.

Help we're looking for from you is feedback. The next one is, what do you see working in your environment? I think that we have some ideas, what we've seen working in ours, but I think there's more. We would welcome any ideas or stories from you.

Robin Yeman

We're currently working on the next draft of the Industrial DevOps paper, and we would welcome feedback from that draft. Do these barriers resonate with you? Have you seen these, or are they things that we're just seeing in our environment? Please share. We're so excited to hear back from you. Thank you.