Robin Yeman

All right. So welcome. Thank you for the opportunity to be here and for joining us in this session as we share with you Industrial DevOps, From Value Streams to Agile Teams. In this presentation, we're going to revisit the principles of Industrial DevOps, and then describe the importance of systems thinking and value stream structures as an organization works to deliver value to its customers. Okay. Maybe. Okay. So my name's Robin Yeman, and I work for Lockheed Martin, and had the opportunity to deal with a number of safety-critical systems that really brought me and Suzette together, because similar in nature, we're having to build not just agile and DevOps for small team of teams, seven plus or minus two. Most of our work has very large teams and complex system of systems.

Suzette Johnson

That's right. And I'm Suzette Johnson. I work for Northrop Grumman as a technical fellow. And we've been on our lean agile journey for several years now, and as Robin was indicating, we've happened to notice there are a lot of similarities in the systems that we build and with the challenges that we're facing as an organization. So we want to continue to share these experiences with you in hopes that you can learn from our experiences as you go through your DevOps journey.

Robin Yeman

All right. So you take a look at these two systems. We've got the F-35 and the B-2 bomber. Both of these are large safety-critical systems with many team of teams on them, and we run into all the complexities that you would run into on a car. So our approach is going to be to describe a lot of the things that we see in day-to-day life, but in the context of Alset, an electronic vehicle. Yep. And as we go through this journey with Alset, again, we're sharing our common experiences and how we put these into practice, and then using them in the scenario that I think people will be able to relate to. And as we talk about a couple different contexts, not just the system context, but also the organizational context as we expand our thinking and our experiences with implementation at scale. Okay. All right. So first, we're going to start with the system context, and we know this in itself is complex. We have large system of systems, and they've each got unique behaviors that we're bringing together. So as we look at it, we find that there's multiple ways of looking at quantitative information flows. The system has multiple ways that it's moving through. There's heterogeneous elements, so we're really talking about a varied set. I've got firmware, I have hardware, I have software. I've got a variety of things that are talking to each other, that are actually different in how they exist. So it's an entirely new world to work across these areas. Once I put these systems together, you notice that there's emergent behavior. And we have to look at all areas of the system when we're trying to find where these emergent behaviors could happen. Or, for example, I could experience one behavior in a certain scenario and context, and then move that capability out into the field and experience one that I hadn't before. We have to look at interfaces. In the software world, we're looking at APIs and how they talk to each other, and we've got software to firmware interfaces and firmware to hardware. Now, once I start looking at that, you'll notice that there's a different language. We're going to talk about hardware engineers building things like breadboards. That's a whole lot different than, let's say, a software engineer building out "Hello, World." So we have to learn how these different elements communicate to each other.

Suzette Johnson

Yep. So you can see there are some similarities between the systems context on the left and the cultural context on the right, and this is largely because the solutions we build and the organization of the people, in fact, they're both systems. So in the cultural context, we've also identified six related or similar areas as we've identified on the systems context. We talk about the organizational structure, and the organizational structure is how the organization is aligning its people and its teams to provide value. The structure's important to ensure that we're organizing around the delivery pipeline and to ensure decision-making is at the right levels, along with improving the flow of communication and collaboration between the teams. So, for example, are teams aligned around features? Are they aligned around components? As they build the system, how often do their changes have a rippling effect across other teams? And this rippling effect, or this rippling impact, is sometimes caused by the system structure or architecture, but it also could be how the organization has defined their team structure. So this is an important element that requires attention to ensure the teams are able to build new capabilities, and new functionality with minimal impact across the other teams. And then we have qualitative information flows within this organizational system. So, we understand that communications may in fact look different than the org structure and the way in which the teams are organized, and how they need to enable value creation with fast feedback between the teams. There's also the correlation between the organizational structure and the qualitative information flows. Then there is something we're calling heterogeneous subculture. That is, the impact of the different cultures of the teams, not only in their organizations, but maybe with the suppliers who we're working with, who also are interfacing with us, and they're part of our value stream. So we bring these different groups together to build solutions, and we need to acknowledge that they likely have different ways of working. So, for example, a hardware team from a given supplier likely has a very different culture than another supplier or another part of the organization, yet we're expecting this collaboration and alignment towards common goals to magically happen. So that's an area that we want to make sure we're addressing because of its impact, and how we are able to deliver value. There's shared mental models in how we think about the world in which we work and how we have shared values and beliefs. And then importantly are the relationships and the language between the teams. That is, having a common understanding for the work that we do, the levels of autonomy, who's making decisions. Are we able to have some level of decentralized decision-making? Is it getting at the right level? What are our defined rules of engagement? And all of these things are an important element of the cultural context and how teams are expected to collaborate and deliver value. I especially like how Ruth Malan, she's an expert in industry for her work on software architecture, and the way that she worded it. "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins." So that's why we're looking at both the systems context and the cultural context.

Robin Yeman

All right. So here we talk about the industrial DevOps principles, and we really only have time to talk about the first one. So we're really going to focus on visualizing and organizing around the value stream. However, if you look across this slide, each one of these principles that we came up for industrial DevOps would be impacted both by the system and by the culture. But as I said, we are trying to get a lot of information in a short period of time, so we're going to talk mostly about the visualize and organize around the value stream. All right. So first we begin with the system context, and we're talking about a fictional company, Alset, who builds electronic cars, and they are actually building safety-critical systems, much like the products that we would build at Lockheed Martin and Northrop Grumman. And as I look at the system context, there's a lot going on here. Each one of these could be considered a system of systems. So I've got sensors and I have communications. I've got a variety of different products on here. I've got things like infotainment, and then I've got active safety. So a variety of different elements within this system are impacting the work that we need to do. Now, for our scenario, when we talk about it further, we're going to notice that we're referring to reducing the collision avoidance system. And so by looking at that, we're going to be impacting both hardware and software. But before we get into that, I'm going to let Suzette tell you a little bit about how complex this gets with the culture.

Suzette Johnson

That's right. Thank you. So the people that Robin's talking about, the people that do the work as part of these different systems that are building this autonomous vehicle, they are responding to their organizational context. So we've learned from experience, and from our research, such as Edgar Schein's theory of organizational culture, is that culture consists of both behaviors and processes, as well as the tacit values and assumptions or the belief systems of the people and how they work together. The culture will protect the organization's norms against variations or deviations, so that makes change and new ideas difficult. And they may even be rejected as a result of the organization's belief system or their structure to incentivize the behaviors and performance of the people. So from a cultural context, we start to recognize that there are multiple aspects coming into play along with the technical considerations of industrial DevOps transformation. So as the organization starts to embrace a new way of working, they begin to experience this shift in culture, a shift in mindset, which needs to be part of their transformation plan as well. So the activities to support the culture change are planned just like we plan the system capabilities, and we create roadmaps for that change that we'll talk about a little bit later.

Robin Yeman

So here we're taking a look at the past papers. We began with industrial DevOps in 2018 and came up with principles, and then we had additional folks that were added to our team, and we went through and we created a fictional company, Alset, and we applied those principles on a real-life system. Now, the interesting thing that we've run into in 2020 is that story has taken a turn. As we looked at it, we're like, "Hey, we did this great thing technically. Why did we have a problem? Oh, we forgot to bring culture into play." So the key that you're going to get from the 2020 paper is the discussion about how culture impacted this journey. We had focused heavily on the system itself, but not necessarily looking at the system of systems, which included all of the people. I'm going to begin with the business goal, to improve collision avoidance. It's a great concept. And so we want to decrease the closing distance by 50%. Quite a goal. And in order to do this, we created two epics. The first one really was to enhance obstacle detection, and it's for the cars that are currently in the fleet. We're making the assumption that we have a set of cars in the fleet and that we have another set of cars that are waiting to be built. And so that set of cars in the fleet, we're primarily just updating software. Right? So not as big of a change as the second one is, which is where we're going to update the camera. Now the camera takes into account the firmware and the hardware and the software. And you're going to see that while this looked pretty doable from a system perspective, we ran into some issues. So I'm going to let Suzette tell you about the cultural impact.

Suzette Johnson

Yes. So in our scenario, also, they were actually able to finish the development of the epics. But yet, due to some of the cultural impacts, we weren't actually allowed to ship. And that's because due to these pressure and due to the constraints and the need to deliver quickly and the pressures that were put on them, they found that there were actually shortcuts taken in terms of quality, and this was identified during their demonstrations. So while the functionality was created, they couldn't deliver, and the root cause or the underlying challenge in our scenario was that it wasn't the technical competency at all, but it was rather the culture, specifically the organization's management culture. And that was that due to pressures to deliver, they deviated from their sort of core lean values of building quality in, and they started taking these shortcuts. Management's pressure, along with how people were incentivized to meet scheduled demands at all cost. The team members started also feeling like they couldn't speak up, that they weren't empowered, that they were feeling like they were in an environment that was not psychologically safe. So that resulted in the teams not speaking up as they were recognizing that they were having these concerns because they were concerned about the negative impact, either on their performance reviews or how they might be viewed within the organization. So while they had the technical competencies, the organizational and cultural impacts were actually keeping them from delivering their high-quality products that they've done in the past. Thank goodness that this is only fictional and couldn't-... really happen.

Robin Yeman

Never. All right. So I'm going to look at the Alset value stream identification. As we discussed, we're going to take into account that first piece, which is organizing around the value stream. And as you look at it, you can see that this actually decomposes into multiple value streamlets. It starts getting even more complex. Right? So I've got collision avoidance, obstacle detection, and traffic indicators with a variety of product lines. Some of these product lines are actually being delivered by suppliers. So there's definitely going to be variances in the products. And then they can all be deployed to a variety of vehicles. So trucks, performance vehicles, or hybrids. So coming back to those original items that we talked about for the system, I've got that complex system of systems where all of these different elements are talking to each other. The information flow from obstacle detection to active safety could have an issue depending on which context the actual vehicle's in. These heterogeneous elements, so when we say heterogeneous, the different hardware, firmware, software elements, the electronics. Right? I'm not doing it justice because there's so many sub-pieces when we start to break this apart. Emergent behavior is always an issue, and the reason is you don't know what you don't know, and this happens all the time. Really looking at those interfaces, and one of the keys we've found is to make sure that we're building around stable interfaces, is impacting these value streamlets. And again, coming down to the different language, the different nomenclature. If I've got a supplier and I have a prime, or I've got multiple suppliers, it's likely that they have products that are the same but actually named something different, or they have a slightly different term in their database, and I've got to connect these items together. So there's a lot of complexity going on just with the system. So what happens when I add people?

Suzette Johnson

As people do all the work. So the complexity of the system's context is actually amplified in the cultural context. All those value streamlets are comprised of people, and the teams working for Alset, and they started facing several challenges. And these are similar challenges that we've actually seen through our experiences in other domains, where the world of the software development teams, in some cases, has been very separate or very isolated from the hardware teams. And now we're asking these different cultures, these different environments, to come together on a regular cadence, to organize their work together, to plan together, to do demonstrations together, with having to adopt new tools and new processes. And this is creating a great deal of strain on the organizational system. So some challenges that might be experienced include things like different parts of the organization, saying hardware versus software, have their own subcultures, not aligned with a DevOps mindset. So this means teams may have completely different ways of working, making alignment of the integration difficult, making reporting nearly impossible. This means teams may not be able to look across their value stream and collect any lead and cycle time metrics. They're not able to visualize the flow across the system. It becomes very disjointed. So for the teams in which more frequent collaboration is required, this becomes a growing and exponential problem as you scale. Also, agile hardware, firmware, and software engineers, they do not have the same mental model, maybe around collaboration and how they do work. So for example, hardware teams within our scenario of Alset or maybe a different domain space, they have a different way of working. They might be struggling from a hardware perspective in this kind of environment where frequent feedback is desired. So that means they have different way of working. They have different technologies they're dealing with. They might be making use of new tools, digital twins, increased modeling, and this is all impacting their day-to-day work experience. So again, a lot of pressure and a lot of change in their experiences and how they do work. So how do we address some of these challenges? Well, one way is we create and always focus on the small, cross-functional, persistent teams that share a common set of practices. We continue to support self-managing teams, explicitly agree on the interaction modes and how they want to collaborate, and setting expectations to help shape their set of behaviors or that mental model of how we expect to collaborate to build a solution. We create not only a system architecture, but an organizational architecture that's designed to reduce some of the handoffs while improving the interfaces, and that is not just the system interfaces, but the interfaces of the teams, the collaboration points between the multiple development teams using clear, defined set of practices. People must also see their leadership modeling these behaviors and actively engaged in the process because leaders model the way. And another area to address is technical competencies, because we have this new way of working. We have all these new technologies, all these new automation tools. So it's up to the leadership team to ensure that the people have the skills that they need, and the environments and the tools and the resources and the opportunities to gain these new skills, and making sure that's happening for them. So there are some definite challenges that come into play through the organizational context and the culture change, and we continue to look for ways to address and alleviate some of the strain as we define a new way of working together.

Robin Yeman

All right. So one of the things that we came across, that we looked at, was actually, hey, the system roadmap. We've had this all along. We think this is a great thing. And it allows us to look at the system and be able to make incremental changes on a regular cadence. So we're coming back to another one of those principles. And the four key areas that we looked at were the system, prototyping, refactoring, and innovation. So from our perspective, we said, "Hey, if we did quarterly review of our plan, and then regularly updated that, and then actually brought it together with both sides of the coin, the system and the culture, that we could incrementally move the system and the culture to where we want to be." So here, what we're looking at in quarter one for Alset is to validate what's the as-is state, and what are my business objectives? And you heard earlier, we want to decrease that closing speed. Prototyping and really looking at the system telemetry. Perhaps, Alset is starting to see things like slow development speeds or hardware is taking a little bit longer than expected. And a lot of times, in both sides of those, we're looking at a technical debt problem. Areas of the system where we've made changes, but maybe we haven't cleaned up everything. So each one of these different areas, we can actually intentionally try to move the system and make it better and better each time. And we can actually add that together with what Suzette's going to explain.

Suzette Johnson

Okay. So as part of the industrial DevOps journey, we've come to understand the importance of organizational culture, obviously. So in our scenario, we demonstrate through Alset the importance of setting up a guiding coalition, or a leadership team that addresses and starts thinking about the needed success patterns, principles, and mindset for this new way of working, and what does that mean, and how do they want to make this change at scale in order to achieve their desired and hopeful results. So just like they did on the technical side, they also create a roadmap for change. In our example, Alset's guiding coalition created four areas of focus: mindset validation, support structure of the organization, technical competency, and role-modeling behaviors, starting with leadership. So they started laying out their roadmap for change. This roadmap will evolve over time, just like a technical roadmap would evolve over time. They focus on building awareness, sharing case studies that demonstrate and help visualize what successful change looks like. And as they begin to see positive results within their organization, they also capture these successes and share them across the organization, because we know success will build on more success. They ensured alignment with their promotion system to include team-based awards and incentives. The importance of building a learning culture with regular opportunities to grow was recognized as a key component to their successful adoption of industrial DevOps. They recognize it requires new skills and competencies, and most importantly, they learned the importance for leadership to lead and model the desired behaviors. Their leadership made commitments to understand and model the principles to build environments of psychological safety and decentralized decision-making.

Robin Yeman

Okay. So what are we looking for? What's our next steps? Well, we'd really like to have other examples of value streams for large cyber-physical solutions. So we have a bunch in Northrop, a bunch in Lockheed, but if you have others, we would like to continue to research this and get better. We would love to hear how your organization addressed leadership and any kind of cultural challenges you've had for large transformations. So as Peter Drucker said, "Culture eats strategy for breakfast." We know that, so we want to hear your stories. Any information bridging the gap between manufacturing and development, across different phases of the life cycle for our products, because I think this is really going to take us to the next step, potentially next year's paper, or even more.

Suzette Johnson

And finally, we would want to make sure we are recognizing our other contributors and co-authors. While Robin and I often present together on our papers and what we've co-authored, we definitely want to make sure we give recognition to these other individuals who have put in a lot of time, a lot of effort to help us author these papers, and to review and provide feedback. This is definitely a learning experience and contributions from quite a few people, and we just appreciate their time and energy in making this happen. So thank you.

Robin Yeman

So in summary, leveraging the power of industrial DevOps for large complex systems is an industry step change. It's going to make a difference, and the companies that solution a problem first are going to experience things like transparency, reduced cycle time. We're going to be able to get capabilities out the door, increase that value for money, and innovate faster. And just a quick side note. Suzette and I both talked about the system and the culture, and there's kind of an interesting story behind that. So currently, I'm working on my PhD, and I'm getting my systems engineering degree, and I'm focused on the system aspect of Agile and DevOps. But interestingly enough--Suzette, you want to tell them about yours?

Suzette Johnson

Yeah. So I graduated about 10 years ago now with my doctorate, and my dissertation actually focused more on the leadership and the organizational aspects, and looking at the behaviors and practices within the organization, and the impact on outcomes in both Agile and Waterfall environments. So it's kind of interesting the turn that our papers have taken over the years, and just kind of aligning with our interest at our dissertation studies as well. So it's a really neat opportunity to be able to leverage that research and the effort put into that.

Robin Yeman

All right. Well, thank you very much.