In this episode, Clarissa & Bill promise to open up new avenues of thought! Agile, Lean, and DevOps – you've probably heard these terms thrown around in software development circles. But what if we told you these methodologies are not confined to the digital realm? Join us as we shatter this age-old myth with our guests, Robin Yeman and Suzette Johnson.

Our daring duo takes us on a rollercoaster ride of their experiences, applying Agile, Lean, and DevOps in areas you'd least expect. They're not just sharing theories; they're bringing you real-life stories of implementing these dynamic practices in places ranging from auditing to operations. This episode is a treasure trove of tales and tips, perfect for anyone skeptical about mentioning 'Agile' outside the IT department.

In this insightful conversation, Robin and Suzette delve into the application of engineering principles to cyber-physical systems and stress the importance of considering constraints in the design process. They talk about the need for multiple planning horizons – a strategy that ensures predictable delivery while allowing the flexibility to adjust scope and resources based on empirical data.

Our guests share their journey in overcoming challenges and achieving success with new working methods. They highlight the importance of aligning on a common language and building internal support, which is essential to any transformation. Plus, they explore the concept of 'crossing the chasm', underscoring the necessity for continuous improvement in an ever-evolving digital landscape.

This episode is not just about changing how you work; it's about a paradigm shift in approaching technology governance and innovation. Let's dive in!

• Read the book "Industrial DevOps" - https://itrevolution.com/product/industrial-devops-book/ 
• Follow Robin Yeman on Linkedin - https://www.linkedin.com/in/robinyeman/ 
• Follow Dr. Suzette Johnson on LinkedIn - https://www.linkedin.com/in/dr-suzette-johnson-984bb14/

Takeaways

• Applying engineering principles to cyber-physical systems involves considering constraints and designing with the end in mind.
• Multiple horizons of planning are essential for predictable delivery and the ability to adjust scope and resources based on empirical data.
• Agile, lean, and DevOps principles can be effectively applied beyond software development, including in areas like hardware and manufacturing.
• Security and auditing need to be integrated early in the agile development process.
• Overcoming challenges and finding success with new ways of working requires aligning on a common language and building internal support.
• Crossing the chasm involves building a full product offering and providing evidence of success to gain wider adoption.
• Continuous improvement and a growth mindset are crucial in an ever-evolving digital landscape.
• Understanding and integrating constraints from the beginning is crucial for successful system development.
• Bridging the gap between software and hardware is essential in cyber-physical systems.
• Continuous improvement and innovation are necessary to keep pace with evolving industry trends.

Chapters

• 00:01:06 - Episode Introduction
• 00:02:44 - Robin & Suzette Introductions
• 00:04:38 - Discussion on Systems Engineering and Agile Approaches
• 00:07:19 - Industrial DevOps and Cyber-Physical Systems
• 00:11:49 - The Role of Constraints in System Development
• 00:16:38 - Bridging Software and Hardware in Cyber-Physical Systems
• 00:20:43 - Security and Auditing in Agile Frameworks
• 00:23:03 - Multiple Horizons of Planning
• 00:28:01 - Adopting New Ways of Working in Traditional Projects
• 00:32:19 - Advice on Implementing Agile and DevOps Principles
• 00:35:30 - Crossing the Chasm in Innovation
• 00:38:18 - Final Thoughts and Conclusion

That was kind of this moment of epiphany for me because at the time I was working on this, my radar program and had an amazing software team where they had really turned around their software to deliver capability. But yet we weren't really, if you looked at the whole schedule, we really weren't any further ahead in delivering product.

And it just happened that at the same time, I was reading the goal. And that's when I realized, and it's actually the very opening story that I write in my intro.

It was that moment that I realized what we did. We had built all our efficiencies before the bottleneck. So all we had done was move the bottleneck. And because we hadn't focused on that shift, we still weren't able to deliver the whole thing any faster, even though software was speeding up.

Hey everybody, welcome back to the podcast. I'm Bill. And we're the, exactly, what was that? See, we're not gonna cut that. That's gonna be our intro, we love it.

And I'm Clarissa and this is Control Freaks. Dang it.

One day we'll get it right, but today's not that day.

I'm sorry.

He's a villainite.

So, go ahead, Clarissa

we might get out. Bill and I are so excited to have Suzette Johnson and Robin Yeoman here with us today. We'll get them to introduce themselves, but I want to start with the objective and what we want all of you to walk away with today. We want you to learn some ideas and approaches that and learn from Robin and Suzette on the trials and tribulations that they've encountered when they in successes when they have tried to apply.

agile, lean and DevOps to areas other than software development. So for those of anyone who's tried to have a conversation with someone outside of software development and talking agile, lean DevOps, sometimes you get the response and I know I've experienced this too of, Oh, that only works in software development or from the audit perspective, Oh, that only works in IT audits. Um, so we want to dispel some of those myths and that's what we want to walk, want all of you to walk away with is.

a different understanding and more open mindset as to where we might be able to apply these different ways of workings. And then what might set you up for success if you're driving some of those transformations as well. So Robin, Suzette, do you both want to take a couple minutes and introduce yourselves to the listeners?

Sure. My name is Robin Newman, and really excited to be here. I have had the opportunity to have a pretty diverse career. I spent most of my time working at Lockheed Martin, which is a large defense contractor, about 28 years, building everything from submarines to satellites, so a whole range of capabilities. And I currently am working at

Carnegie Mellon, the Software Engineering Institute. We're an FFRDC and our goal is to help the government build capabilities, deliver capabilities at the speed of relevance.

Welcome.

Thanks.

Yeah, so I am Suzette Johnson. I started my career in the commercial space, actually, for a tech startup in the late 1990s, which was a pretty amazing opportunity. And with the surge of the whole internet boom at that time and e-commerce, it was a great place to be. Shortly thereafter, I came to work at Northrop Grumman, and I've been there ever since.

by trade, my background is systems engineering, and very similar background as Robin, which is how we ended up getting connected. And my primary focus as an NG fellow here at Northrop is really continuing to drive lean and agile and DevOps practices across our company and specifically in our space systems where we have the most significant cyber physical systems. It's a real exciting place to be right now with the.

emerging capabilities and growth in the space domain. So I thank you for this opportunity.

We're both excited to have both of you incredible backgrounds and really excited to dig in.

Quick question, would it be fair? Is this fair? So correct me if I'm wrong. Are you recovering systems engineers and agile holics, or is it the other way around? How's this playing out?

I think I started as a developer, right? I'm a software engineer by trade. And for the longest time, and I told Suzette this, for the longest time people kept saying, yes, but you don't understand systems. I was like, that's it. So I decided to go get my PhD in systems engineering. I was like, I can't keep hearing this argument. So it's probably the other way around.

Nobody can tell you don't understand anymore.

I like that. You don't... That's like the ultimate mic drop. You don't understand anything. Hold my beer. Let me get my PhD.

Yeah.

I know right?

And it's interesting because it was a different experience for me. So my background, as I was saying, I started in systems engineering and then we wanted to, back in 2005, deliver capabilities faster. So as the systems engineering management lead for this effort,

It was my responsibility to figure out like what should we do? Like what are the practices that will help us deliver capability faster? And I had a coworker that I just happened to meet and we talked about this agile thing. And I'm like, I think this is it. This is how we need to be building our system. And we just moved forward with it. And it was really from that systems engineering focus that we got started.

Software kind of knew how to do it already, but how do we broaden it across our system?

love this. This is what you just went through. This was a beautiful message right there. And this is like why Clarissa and I are banding together. Cause I think a lot of people understand to do this, you have to understand the other side of the house. Robin, you went from software engineer to systems engineering, Suzette systems engineering to the software side, the agile side. So at the end of the day, and like, I remember talking to a couple of people that are starting their own transformations and they get to that point where I have to understand the other side.

Mm-hmm.

And they absolutely hate it. But I just like, before we get going, I just want to pull this out to the listeners. Like this right here, you want to understand why your stuff fails? Well, this is the first reason, this is the first way not to make it fail. Be able to legitimately put yourself in the other shoes. And I want to go somewhere with that. So your book, you recently just published a book, industrial DevOps here in October, which I've read through it. It is freaking phenomenal by the way. Um, lots of stuff. We'll cover it today, but industrial DevOps. What?

Mm-hmm.

Thank you.

is industrial DevOps. Like what's this term mean?

So, industrial DevOps, and I'll start and then Robin, feel free to add to that. But what we were looking at is how do we take all the goodness that we were seeing from the software community and apply it across the value stream to include not just software, but hardware and manufacturing and supply chain and all the different areas that it takes to actually deliver a capability. But again, I want to highlight most significantly, it was really looking at the...

and embracing the hardware community because we were delivering software, but we found in the type of systems that we worked, you could deliver great software, but if the rest of the value stream wasn't with you, you still couldn't deliver. So we wanted to, again, take those practices from Lean and from Agile and DevOps and systems thinking and apply it in that cyber-physical space.

So quick question. So I don't have a tech background. I have an audit background. So I'm always asking kind of, I call them the foundational or elementary questions. Can you help someone who doesn't have a tech background understand what you mean by cyber physical? That's a new term for me.

So typically, cyber-physical means a vehicle, right? A car is cyber-physical. It has software, it has hardware, it's electronic. So it's got multiple different aspects to create a system.

Okay. So the emergence of, I mean, at the end of the day, if I say a different way, it's just the emergence of software and hardware. I mean, a lot of people, it's, people don't think about them. Like when you look at a car, like you said, Robin, you look at it as like one thing, but when you really think about it, it is two separate things. There's hardware and there's software. And it almost sounds like Suzanne, as you're talking about what industrial DevOps is, is you can build the software as fast as you want, but you can't build the car any quicker until you start integrating these two. You got to make that whole system. And I think in your book, you, uh, I love it because you talk about, uh, gold rats, uh,

Awesome.

uh, go rats, the goal in there and, and some of the very introduction stuff, which I think is interesting. So let me ask this as you guys were talking about, did, did the fact that you read the goal and knew about the goal and the theory of constraints in industrial DevOps and your projects, did that help at all with any other non-software people like manufacturing engineers or anybody else like that, or are they still like, Nope, sorry, the stuff's not for us.

I think that it depends, right? So for some people, absolutely. They got it right away. For others, I think even now, we still meet with folks and they're like, and this software development thing. So I think that the goal and the way they put, the way Goldrad put it, which it was basically the analogy while he was having the...

Boy Scouts walk and how that constraint just caused the problem for everybody. It clicks. Everybody gets that. And it's the same thing in system development. How about you, Suzette?

Yeah, so I'm so glad you asked this question because that was kind of this moment of epiphany for me because at the time I was working on this, my radar program and had an amazing software team where they had really turned around their software to deliver capability. But yet we weren't really, if you looked at the whole schedule, we really weren't any further ahead in delivering product.

And it just happened that at the same time, I was reading the goal. And that's when I realized, and it's actually the very opening story that I write in my intro.

It was that moment that I realized what we did. We had built all our efficiencies before the bottleneck. So all we had done was move the bottleneck. And because we hadn't focused on that shift, we still weren't able to deliver the whole thing any faster, even though software was speeding up. And in some cases, I've seen where, when that happens, when software is moving so fast, but the rest of your value stream isn't.

then software just starts to sit kind of on the shelf. And when it's not used, and then defects are found so much later, and then the cost of fixing those defects kind of continues to rise.

whip process. I have to be careful sometimes when I say this. I find a goal every time I went in to go find a bottleneck and call it the herby hunt. So you have to be very careful when you say that. And if nobody's read the goal, they don't know what you're talking about. And you just like this head, yeah, like we're doing what? Like, let me explain. And for folks that read it, side note, you should read the goal listeners if you have not yet. But as Robin was talking about, as Susette was talking about in the goal.

Yes! They're like, what?

the little boy scout, his name was Herbie, and it was basically how to pace the line. And Herbie was the slow boy scout, and he was at the very end, and the other boy scouts kept getting further and further ahead of him. So to keep everybody together, they put Herbie at the front. So Herbie paced it. And as Suzette was talking about with bottlenecks, Herbie was the bottleneck. So if you wanna make the boy scouts go quicker, you focus on him. And the beautiful thing about this, what I love, is there can only ever be one bottleneck in your system at a time.

regardless of how many things you think are slow, you could only have one bottleneck, one thing that's pacing your system. So I'm gonna stop geeking out on that one because I think everybody should love it. Anyways, so cyber physical. This is interesting because cyber physical is the emergent of software and hardware together. As you're talking about this, software is going quick, it was piling up or not getting a return on investment. This almost sounds like some stuff that's happening in the auditing world when Clarissa and I talk about it. Can you...

Mm-hmm.

Dig in more on how you guys are solving this cyber-physical problem.

So I think you're exactly right. It is just like what Clarissa is dealing with. Because one of the biggest things, at least in Suzette and my domain, is being able to get authority to operate, right? ATO. And actually within large government systems, ATO, authority to operate, is more expensive and takes longer than building the entire system itself. Right?

people don't actually realize the extreme expense. And it's because we don't begin with the ended mind. So I'm gonna build a system for Clarissa and I'm all done and then she's gonna go, but this, and this, this will never go, which creates this huge rework cycle. So we do it a little again. Beginning with the answer to the test question.

So tagging up with Clarissa on the front end makes it so that I'm beginning with the things that I have to have done before it can be deployed. Otherwise, I can go as fast as I want. It still isn't making any difference to the user.

And that, so if I'm missing the part of the point here, point me in the right direction, but when you begin with the end in mind and you're figuring out kind of where do you want to go, a lot of that seems to be focused on the value. So you could do all these other things, but they're not valuable. You could be focusing on creating things, but if that's not focused on what's valuable to the end user or the end customer, then it's kind of a little pointless.

Mm-hmm.

It's very close, but the difference is, I could build something very valuable, but it may not be able to be certified and put into the customer space. So for example, if I update flight software, but I haven't begun with what it's gonna take to certify that flight software, I still can't give it to you. It's not that it's not.

valuable, it's that I didn't begin with the constraints. A little bit like cyber security. I could build systems that are completely open to hackers. It may be valuable for about five minutes before they take it down. So I have to begin with, how do I make sure I don't have SQL injection? What are those controls?

And when I think about value, I think of it maybe a little bit differently too, is a system that is open to cyber attacks is not going to be valuable to me as an end user because it's only going to work for a minute before all my data is stolen and everything is locked and I'm no longer able to use it. So that's, and it's interesting because we probably all define value differently. It's one of those, we all know what the word means, but like how we define it and what we see as value are challenging, which creates.

whole lot of challenges there. But so when we think about value that way of not just meeting one need, but meeting the continued needs, keeping an eye on what are all the value propositions and what are all the aspects of value that are important and starting with that in mind before you just start rolling with things.

Yes, you are exactly right. Yes.

Awesome.

I would dig into this a little bit. So systems engineering. I mean, this is a, this is also, I mean, based in physics, this is a really basic, a physicist will probably this way starting, we start in the end of mine. If I were to say you're actually starting with the constraints. So what's the end, but what are the constraints that we have to build to? And what's interesting, I heard you say, Robin is like Clarissa, you think about control activities and controls. And I see this in software and hardware. Nobody really blueprints software.

But people blueprint hardware. How many times can I go and find a spec on a hardware diagram about tolerances and basically my constraints? And I feel as we're getting to something here, what's interesting in this, what you started as you guys were solving things in the cyber physical world was you were starting to think about applying, I mean, those same engineering principles, but what are those constraints and Robin, you said C A T O. So what are those constraints that I need the authority to operate to start with? And if we start there, or if I don't start there, no matter what I build,

is going to be, and people don't like the word constraints. They don't like to be constrained, but the reality is you have to build the constraints and cause somebody like with the course on the auditing side, like they correct me if I'm wrong, Clarissa, but with controls and control activities, this is the strength of a good internal auditing team is to help understand what the risks are and help communicate and help build those set of constraints such that value can be delivered, not just to it, but can be delivered in a sort of an expeditious and a predictable way.

Absolutely. Good example. Working within secure environments can be somewhat unique. I had a system where we were building a multimodal biometric system and I had experts in biometrics, so out in Utah, but they hadn't ever delivered into a closed system.

We would call it a stigged system in the government. And they kept delivering software, but my teams in Washington had to tear it all down and rebuild it because it would not work in a closed environment. And it's just because they didn't understand the constraint. They were building it the way they always could. And I know that comes up all the time, being able to understand

what domain, the context that your work is going to be in. Otherwise, you can't actually deliver it.

I want to go ahead Robin, or Suzette, sorry. What did you about to say?

Yeah, I was just going to say, yeah, this kind of, this ties into a couple principles that we talk about with the multiple horizons of planning and the engagement of having everyone you need as part of that planning so that you can continuously build in those constraints, you know, work towards building against those constraints and building in the requirements that you need for security and auditing.

and making sure that people that understand what those requirements are, are part of that team. Because I remember years ago building a system and then one day security comes to my area and they give me this stack of security requirements and things that we have to make sure we're building into the system. But I was very fortunate that this person, because I was like, I don't know what to do with all of this.

But that security person ironically had an agile background. This was over 15 years ago. So I just asked if he could just join my team for a few months to help us figure out how do we start building this in and actually build it in iteratively so that when it's time to release, we have built the requirements in. And oh, by the way, are there some of these requirements where we can actually automate or run scripts so that we don't have to keep manually testing against it?

So that was a great experience and like I said it was just fortunate for me that security person actually had the understanding of what we were trying to do. It was an amazing opportunity.

I was like shifting audit and security left before it was cool to do that.

What?

Mm-hmm.

Yeah.

What let's dig down the hole. I want to, I want to dig down the hole of multiple horizons planning. Um, before I go there though, Robin, you said you use an acronym called STIG, uh, security technology implementation guide. If I recall correctly is the acronym. Clarissa. Have you heard of STIGs before?

Yes.

did, I have. So when we audited a certain type of technology, they leveraged the STIGs for configurations to make sure that they were secure configurations. So yes, I do know that term.

You have?

Nice.

Mm-hmm. Yep.

You're always ahead of the game. Yeah. You're already. What would I, what I love about that? They're like the stick because a lot of people that aren't in the DOD space have never heard of stick. Um, and so when you think about it, and I tell you, I'll use the, the word control and control activities from the audit realm, all the stick is a list of control and control activities for a specific piece of software, like a operating system, like Linux or something like that.

Mm-hmm.

which it gets back to the automated governance aspect. And Suzette, as you're talking about some of these, Julie said, like, STIGs are a great way to automate this or the concepts there. So I wanted to highlight that one because as we go to multiple horizons of planning, like the ability, like I look at it from the governance engineering side, the ability to codify this back into something that's automatable is key. And I think STIGs are a very key example of how you can automate it, but let's.

Let's take it to multiple planning horizons. And so I feel like Clarissa, as we talk about bringing our sides of the house together and Suzette with the story you just told about some security, this is like the first probably what I mean, all these nine principles are key, but I feel like this is the first one to have to get over, cause if you don't do this, you can't organize for flow. You can't do data decision just like the other ones. I'd largely argue they don't systematically matter. Um, but like, how did you all like.

Can you give us like some stories, some horror stories, success stories? Like how did you go through? And for the listeners here, they're gonna ask it cause they're gonna go to their auditor. They're gonna try to do what you did in their context. So how could you help them with your experience? Outside of course, read the book. Do you got any quick stories, anything you can tell about the planning horizons and how to do it better? Or how to do it?

So I'll start and then I'll pass it over to Suzette. But one of the things that I see pretty regularly, and it's not unique, but we have an aspiration to deliver a product. And we have a time. And basically, we have one single fixed time. Well, we can't actually validate it. Now, many people in the Agile community will beat us up. And they'll say, well, we only need to plan for two weeks.

Well, that can be really difficult if you want to build a submarine or a radar. Like, those are very big, long systems. Planning two weeks at a time means that we could probably lose the forest between the trees, right? So what we're saying is, yes, I need these short planning horizons. I also need to have the long one. So if I'm going to build a satellite, maybe I need a three-year plan.

What's the end? But I also need to further inform that plan. So typically in the waterfall space, I have a plan, I decided it when I knew the least amount of information and now I'm gonna beat everybody into submission or something like that. What we're saying is actually even in these, let's say one week, two week sprints, I'm getting empirical data, right? So we're moving to an empirical planning approach.

If I plan in that one or two weeks to, let's say, easy widgets, complete 10 widgets, but I complete seven and I do it another sprint, it's likely, because a typical quarter, which is where the government does a lot of rolling wave quarterly planning, has about six sprints in it. If I go two of those sprints and I'm seven out of 10, it's likely that at the close of the quarter, I'm gonna be 70% complete.

Now, I can keep going, but there's this reality that things don't magically fix themselves, right? It doesn't just magically happen. So if I see it after just a couple of sprints, I have the opportunity to adjust, meaning I can adjust my scope. I could potentially adjust my resources. I could adjust my automation strategy.

There's lots of levers that I can pull, and that will allow me to get to that predictable delivery, or maybe I'm just way off plan, and I will adjust the plan. Now the customer may not be happy about it. They might not be at all happy about it, but they are much happier to learn a couple weeks or a couple months in that they're gonna have to slip than they are when we get right up close and go, you know what?

Thought we were gonna be done, but we need another 10 months. Like that goes so much poorer.

Surprise.

Yeah, and to build off of all of that, what I was thinking, Robin was talking, is some of this, the multiple horizons of planning, what it's addressing are two things. One is the scaling that we're dealing with, especially in cyber-physical systems. And then the other is the experimentation and the feedback loops that we need for complex systems. Right? So because we're scaling, we do have...

to think, you know, I mean, you do have a time, like, when you want to launch that system, like, for real. And then that launch date, you pretty much want to hit that target because there's a lot of resources that have to be scheduled when it's time to do a real launch. In addition, it's got to go well because there's safety and critical needs. And we want it to be successful.

But that could mean some distance out. So what the multiple horizons of planning will do is as Rybin was describing, we'll be able to iterate along the way. But let's just say that launches 18 months out of making something up. Well, along that 18 months, where will you have an MVP or something that you can actually test where you can show some level of integrated capability? And we want to, then we can iterate towards that

then have that integrated demo, either virtual or ideally with some sort of prototype where we can actually get real feedback on are our assumptions about the system accurate? And how are we learning because we might make some adjustments then that we hadn't thought about if we didn't have that experiment to learn from. And then it goes into the next cycle and we can continuously improve it so that we're that much better off when it's time to launch and we have full confidence when that data arrives.

And so this is a different way of thinking and a different way of working than how these types of projects have historically been done. Is that a fair assumption? So.

Yeah.

But they typically, like for example, my first project at Lockheed Martin was building the Sea Wolf Sub. I spent three years just defining requirements. It's exactly the wrong approach.

So with that.

So when you started to apply these different ways of working and these different approaches, I'm going to guess there was a little bit of apprehension or a little bit of pushback, and it wasn't just everybody like, okay, yeah, let's just change what we've been doing forever and try this new thing. So how did you overcome those challenges and find success with experimenting with these different ways of working?

Well, we keep running into a new challenge, right? So I typically try to map it back to some of the practices that people have done before. So we like to think that everything's new, but actually, right, the theory of constraints has been around for a while, Little's Law has been here for a while. There's a lot of actual information.

And no matter what we call it, it's been here. So if I'm talking to a program manager and I bring up things like story point estimating and they're like, oh my God, this fluffy thing that you're doing, all I need to do is map it back to Delphi planning. Delphi planning has been around since the 40s and it's been successful since the 40s. So applying a language that people are used to and mapping it to something that's

in their context that's known starts to make it seem a little less risky. That way the pieces that are novel you can still push forward with, but they've got some comfort. This isn't brand new. She's just making this up on the fly.

Yeah, and there's also looking at your sort of early innovators, those people that are kind of eager to try new things and starting there. And then we can build off of those successes and have some evidence of, you know, this is how they're doing it. This is these are the results we're seeing. And but it's always interesting because I came out of an environment where I had an amazing government customer that I worked for.

But he and he always thought was if we don't continue the risk of not Continuously improving and doing things better was the greater risk not the risk of not changing Because you know he understood like things are always evolving around us and we have to continue to evolve with it But it's so we were a little bit more of the innovators where we were willing to take those risks because we understood

how that was important in terms of continuously growing and building new capabilities. In some areas, it's continuously looking at their successes or whatever successes they've had, or kind of to Robin's point, some of that same language, where are they comfortable and then building off of that, in some cases, a little slower than we might want, but to continuously evolve and a continuous improvement mindset.

That is fantastic and I want our listeners to, you know, rewind that and listen to that again. And here's why, because this is, for anyone who's been in software development, I know I've been to a lot of the DevOps enterprise summits and I've heard these stories primarily in the software, technology development, use cases. Everything that you said there is exactly what they would say as far as how to create that success.

in my own experiences with applying agility and DevOps and lean principles to auditing, that's the same advice that I give to organizations as well. Align on a similar language, align on what's not changing or what's not brand new and show here's where these things have been successful even if it's not in this particular instance. Starting with those.

Mm-hmm.

people who are very excited. I love how you said the early innovators, build momentum with them, share that, and it's contagious. And I love how you also said understanding the risk of not innovating. There was a, somebody gave a talk at a conference I was at earlier this year, and the title of it, really catchy title, innovate or die. It seemed like a little harsh, but it drew me there, and I feel long-term, that might not be terrible advice.

Question, Suzette, have you read the tipping point by Malcolm Gladwell by chance?

Yes, it's been a long time, but yes I have read that, yeah for sure.

As you're talking through that, that's what reminded me. I think it was Malcolm Gladwell, I could be misquoting. It only takes 7% of the population to create a tipping point. Clarissa, are you going in? There's probably more than 7% people of some organizations that are really interested in doing better and different things. I loved how you just organized it. Just be a bottoms up leader, organize them and go to town.

Yeah, and if I can go off of that, I guess, right, it's the whole crossing the chasm, right? And you have your innovators, your early adopters, and then you have this chasm into the early majority. And, you know, just an interesting story because I started my career, right? I remember I said I started even with tech startups and when I came into, you know, where I am now, I started more with a very innovative group of people. So I was...

Mm-hmm.

That's just what I was surrounded with. So we embraced innovation and change. But once upon a time, as things are starting to grow, starting to scale, you're reaching a much wider audience, there are people that start wanting that evidence. And I joke with people, I'll never forget the day, I actually remember where I was, when someone came up and said, can you show me the case studies where this works?

And I always tell people like, I was just stunned for a moment because I thought, it's a fair question. There's nothing wrong with the question at all. But I just paused because we never, innovators don't ask that question. You innovate. And I had never asked the question, show me where it's been successful before. Cause I always worked with a group that, well, we're going to do what we need to do and we're going to be successful at it, regardless of anybody else's success. Yes, absolutely.

We're gonna be the case study.

But so I had to think for, I mean, I have reflected on that conversation a lot because first like why was I surprised by the question? So that was what caused me to do the research. And then understanding, you know, what is it that I'm actually hearing? And that's when I realized we were actually starting to scale and we were actually getting into that early majority. We were starting to cross the chasm because as you grow in an organization.

That is a very fair question to ask because now you're going to start changing some of your policies and practices internally at scale and you want to know kind of what is that track record and what is the ROI that we're receiving.

That's beautiful. Like we got just a couple of minutes left here. So I would have quickly like in 30 seconds, doubled down on that, like crossing the chasm. So for the listeners that don't understand the crossing chasm is, it was a book by Jeffrey Moore and it's about how high, was it a high tech products go into the market. You have these early adopters and you have innovators and it crosses a chasm and this chasm is what's referred to as the whole product offering. So Suzette, what you just talked about there and I think this is what a lot of innovators and organizations forget.

Like you have to cross a chasm as you're building a product. You're also building a full product offering, not just a piece of hardware or a software and like that right there is beautiful. That proof that's case studies, this, this explanation. We'll just call that like internal support. If you want to think about it that way, like that's what you have to build. And I would, a lot of people run into, like you can do some early wins, but it's easy to get stuff started. It's hard to keep it in the air and flying over time. And I love it. Just.

So I'm geeking out on this because you just hit such a key point there that a lot of people don't think about it and they don't, and like Robin, starting with the end of the mind, if we can innovate, but we're gonna have to cross this chasm. So at some point in time, we gotta start answering those questions. Holy cow, this has been phenomenal. Clarissa, do you have any last questions for both Robin and or Suzette?

Mm-hmm. Yep.

Any last advice for anyone either in cyber-physical environment or auditing or some use case that we haven't thought of yet. If you're applying Agile Lean DevOps principles to something, what would be the last piece of advice that each of you would give to our listeners?

Well, the big thing that I keep coming back to is many of these organizations have cyber initiatives. They have digital transformation initiatives. They've got model-based systems engineering initiatives. Now we've got artificial intelligence initiatives and cloud initiatives. And really one of the key things that we think is we need to come together

and use all the tools in our toolbox to be able to build these systems faster. So stop being so literal, come up just a level, and really look at the flow across all work. It doesn't matter the type. How do I optimize delivery from the time I have a need till I get it into the user's hands? And in that case, we wanna make sure that we're really looking at the system level.

as opposed to each of the individual pieces.

Sounds like a systems engineer to me.

Thank you, Robin.

Yeah, I love that. And I guess in addition to that, as we are, we're just in this amazing world right now, where all of this is coming together and the digital capabilities are just growing at such a fast rate. So kind of bringing all of these things together gives us such an amazing opportunity. But all of that also means that we need to be committed.

to that growth mindset and continuous improvement. And that what we did 30 years ago, 20 years ago, even 10 years ago, because I continuously rethink about how these things are being applied, because it will be constantly evolving, especially like Robin's talking about AI. That's going to change some of this of how we're doing things. So we need to keep an open mind and constantly think about, well, how do we embrace what we have today?

continuously improve and then, you know, embrace those new ideas tomorrow. So, it's just, we never have it all figured out.

I think that is a key takeaway, regardless of what we're talking about, we never have it all figured out. So Robin, Suzette, thank you both so much for being on the show today. We can post some links of where people can find industrial DevOps, thank you, Bill. So again, thank you both for being with us today. I'm Clarissa.

And I'm Bill, be a freak, not a foe.