Robin Yeman

All right, it's awesome to be here, especially right after lunch on the second day after a really cool party. It's going to be great. What could go wrong?

Thanks for coming. I am here to talk to you today about why your digital transformation may not achieve the results you think it's going to. I am going to be practicing with something called Mentimeter, so you guys will have some work to do in here if I do it correctly, and we'll see how that goes.

I was supposed to present with Suzette Johnson. She's a fellow from Northrop Grumman. We had been working together actually for probably 10 or 12 years. I spent 26 years at Lockheed Martin doing all kinds of systems. Then I've spent a couple years playing around at startups, which, believe it or not, is drastically different than Lockheed Martin. Go figure.

You can take your phone out and take a picture of this. This is menti.com, which means that you guys can access this. Let me see if you can get to it. I'm going to go to the next one. Cool, I'm getting responses. You guys know this better than I do.

What's one word to describe your conference experience? This is just going to let me know how we're doing and also if this works. Free drinks are a killer, aren't they? Nice. It looks like enlightening and inspiring are definitely winning here. Awesome. Thanks for that.

Digital transformation: I've actually worked a number of these. I started working at Lockheed Martin a long time ago, and I actually started working agile programs in 2002. You may not know this, but the intelligence community started requiring it in RFPs pretty early, and there wasn't a lot of documentation on it at the time. I have been practicing, and the reason I say practicing is I don't think I have found a foolproof solution yet on transforming organizations in order to optimize those business outcomes.

Why do we want to do this? McKinsey said that digital leaders move four times faster than their peers with twice the power. That's a pretty good reason. But what I usually run into is people tell me, 'We want to do digital transformation,' and it really comes down to that they don't quite know what they're asking. I feel like they're asking for two scoops of a digital transformation in a DevSecOps cone. 'How do we buy one of those?' That's been my experience. What does this power mean? I'll answer that question a little later.

Let's just say we want to do a digital transformation. The books are all there. I got all the tools. I've read all the books. I've got all the tools. Ready, set, go. Is that how it works, you guys think? I wish.

Ready, set, go happens pretty frequently. I very much resonated with the butterfly song the gentleman played last night, because we're always so excited and we're going to change the world, we're going to make everything happen, and then we get through that disillusionment. We're a little unhappy. The big things I see are really not aligning to a common strategy. We don't restructure. We're just going to change because everybody's smart enough anyway. We haven't changed our processes, or if we do, we keep both. We haven't actually changed how we're engaging with people. In some cases, we're not investing in our technology.

I had the opportunity to go to an Agile for Hardware class with Joe Justice. He said, which surprised me, that Tesla spends 50% of their money on test. I haven't worked at a company like that. I think it's brilliant, but usually people are pushing back on that.

Also, the flow of value really impacts your results. I have worked lots of large programs, and there are multiple problems here. We all agree that there are silos, but there's another thing: silos, and we use a different language. We don't even talk the same language. Program management is talking about lean, and maybe lean startup if they're really fancy. Systems engineering says, 'We're going to do systems thinking.' Designers are going to do design thinking. Hardware folks are on to rapid prototyping. Software is talking about agile. Test is talking about shift left. Operations is all about ITIL, or IT Infrastructure Library. They're all trying to do the same thing. They're all trying to optimize the system for change. Unfortunately, we're not all talking and we're not aligned.

I see this pretty frequently. The last program I had the opportunity to work on was a large missile program. It was pretty interesting because we had to go fast, and the full defense agency had asked for a completely agile program: agile for software, hardware, firmware, across the board. So what did we do? The systems engineers still got CDRLs in the government. Those are contract deliverable documents. They've got CDRLs, and they've got to get ready for phase-gate reviews: PDR and CDR, preliminary design review and critical design review. They get going and start reusing some artifacts because they don't have much time.

Then our modeling team starts getting reusable models, because we need a full model-based systems engineering approach. Then our digital twin team, which is different than our systems team and different than our modeling team, goes to get a digital twin and starts building out what we would call a digital shadow, which is pretty much an empty twin that we're going to use to model the next one after. Then the software team downloaded a set of reusable missile code. This sounds like a great idea. They all picked a different missile. Now, they're super smart engineers, and eventually it will come together and there will be integration. But can you imagine if they actually talked to each other and picked the same missile to model after? That would be cool.

The first thing I want to talk to you about is having an aligned strategy. Digital transformation means different things to every single group. They've all got their different buzzwords, but they don't mean the same thing to everybody, and not everybody is using the same language. Does your company have a single aligned strategy across the business value stream? No? You can answer the question and you don't have to say it was you. Leadership says we have that; I had to have that because my leaders were always telling me we had one, and I was like, 'Really? That's awesome.' I'm not alone. You guys have seen this and you're experiencing the same thing. This is a really big problem.

Restructuring the system: when I say system, I mean people, process, and tools. I mean everything. The first thing we need to do if we want to do something different is restructure our organization, restructure our processes, potentially use some new tools, and potentially connect those tools. If you want to make a change, it's my belief that you need to restructure your organization. Which areas did your business intentionally restructure: tools, process, organization, nothing, everything?

It looks like a lot of people restructure the organization. I guess that comes back to the reorg rag from last night. The interesting thing I find is that even though maybe they are restructuring, typically what I've seen is we try to keep our same stuff and add to it. I've had many teams say agile is more expensive. When you dig into that, what you find is we have a full waterfall process, we're doing all of those things, and agile. I don't care how lean you are. I don't care how lean your DevOps approach is. If you're trying to do both waterfall and agile and DevOps, it'll always be more expensive. That's just a given: two different processes are more expensive than one.

Predictive versus empirical process is one I'm very passionate about. After working so many years with the government, we typically have a lot of phase gates, and phase gates are to make sure you're ready to go into the next phase. Unfortunately, every project I've ever worked has looked amazing until I get to integration. We are on schedule, we are on cost, we're totally rocking this, until we try to actually integrate and run it. I would argue that's the problem with the phase gates.

What is empirical planning? One of the ways I have set up most of my large-scale programs is multiple horizons of planning. It looks like a recursive structure. Fleet ballistic missile is a huge program. It's 50 years long, and they transitioned to agile. That program has a 50-year plan. They have to. But then we decomposed it into a 10-year plan, or a set of 10-year plans, and then five-year plans. Then annual plans, quarterly plans, and then sprints: two-week or one-week iterations.

What do you get from that? You get to revisit your plan. Having a high-level plan that comes all the way down to a near-term plan, and then using your empirical data to adjust and adapt your plan, is actually pretty good and it doesn't take that much longer. In the past, I had an integrated master schedule that would tell me what I was doing on Thursday in 2028 at the end of October, because somehow we knew.

I'm a big fan of multiple horizons of planning and using that planning to update my forecast. If I planned to complete 10 things and completed six, and if I do that again tomorrow, I can tell you with very good certainty that it's likely I'm going to complete 60% of the work at the end of the sprint. If I do that a little more and look at those sprints, and I'm 60 or 70% complete at the quarter, I only have to go through one quarter, maybe a quarter and a half, and it's pretty good that that's what the end of the year is going to look like. There is never a magic catch-up, unless we re-baseline, which we do sometimes, but other than that, I've never seen a magic catch-up.

Does your business follow a predictive process such as waterfall, an empirical process such as agile and DevOps, or both? I see a lot of both, a lot of hybrid. The big problem here is that two processes over one are always going to be more expensive. The other problem is that typically agile and DevOps are within the software community, which means requirements are still done the same way, systems engineering is still done the same way, test is still done the same way. So yay, we're agile. But if I really look to optimize delivery of the entire value stream, I have to optimize and use the same approach across all pieces: hardware, software, and firmware.

Reorganize and reframe people. This comes back to Jonathan Smart's presentation today. We're coming back to tribes. We need those cross-functional teams, and we need to have T-shaped people who can be successful, have depth in one or more areas, and breadth in others. It's a tough ask, but I'm not saying be an expert in everything. The first time I read Team Topologies, I was a little offended, because I'd been working for 20 years to get everybody to move to cross-functional, value-stream-oriented teams, and now they said, 'What about this?' That makes sense, and I can definitely see the value.

I'm currently getting my PhD. I've completed all the classes and am writing a dissertation on how to build complex safety-critical systems using agile and DevOps. One of the things I've noticed, even in the university, is they're completely separated. When I talk to my systems engineering professor, he asks, 'Why do you need to do this? Can't you just requirements better?' No. That never worked in real life. Super nice, but he's been a teacher his entire life.

How are you guys organized? Lots of hybrid. I'm glad we're seeing more cross-functional and functional. I see the hybrid too. In this case, I don't think the hybrid is as bad as the other. But I will tell you that cross-functional teams do deliver faster. If you take a look at the research, they will tell you that cross-functional teams are faster, have higher quality, and better capabilities. They have one problem, according to the research and Google: friction. People don't necessarily like to work with people who are different than them. One of the problems with cross-functional teams is a little more friction, even though everything else is exponentially better.

Integrated technology is the other problem I see all the time. Everybody has their own set of tools. Systems engineers doing requirements are using DOORS, or maybe Jira or some other mechanism. Modelers are using Cameo, Simulink, MATLAB. Testers are using Test Architect, or maybe they do some behavior-driven development and are using Cucumber. The bottom line is they typically are all in their own environment and none of them talk to each other.

This also is a problem. I had this dream that I would really like to build a lab where we could update something like a CubeSat. On day one, we would help people update requirements. On day two, we would do some models. It would need to be heavily scripted. On day three, we would take those models and use them to inform our digital twin. On day four, we would build multiple tiers of tests: unit, integration, regression, security, and performance. You get the thing all the way through the value stream to actually getting something operational, where I updated maybe a CubeSat sitting on the table. I think something like that is small enough where people could wrap their brain around it and see the changes. The really large programs I tend to work, like ABMS, GBSD, or F-35, are just too big to actually see the handoffs and the problems. I think in the small you'd see it through the integrated tools.

Do you have integrated tools? I'm impressed, because at least within the government, this is one of those big problems I run into all the time. We are all in different tools and different environments. You see things where people do them twice, and you see things where there's a gap and they miss the handoff. Not for everything. Thank you for that.

In my world, in my daydream, I really consider this the digital engineering value stream. A lot of people would only consider, let's say, your modeling tools, maybe your digital twin, augmented reality. But in order to get from a need all the way out to value to my customer, I think I have to hit most, if not all, of these hexagons every single time. Having a digital value stream that would allow me to deliver capabilities across this, I think, is the answer. That's a hypothesis, because remember I can't predict the future, but that's my belief.

I haven't talked to you guys about this too much, but it really is about the research for this. I'm working with Suzette on a book called Industrial DevOps, and it's really how to do DevOps for cyber-physical systems. I'm particularly interested in safety-critical cyber-physical systems. We've come up with, and keep playing with, a set of principles on what we think would be the best. Now that we've got nine, I kind of feel like I need 10. Maybe it's just a thing. We are working on that, and I would love for you guys to reach out and help us with that. We're at the place where we're delivering our first rough draft.

That leads to what I'm looking for. I would love to have any results or examples from your environments, any stories, lessons learned, and I'd love to collaborate. I really do believe we could deliver systems business outcomes better. I know that we could, and it feels like we're just this close. I know this is more of a commercial conference, but one of the things I really push on, at least in my world, is this is the first time in decades where we have friction on two fronts. We actually just don't have time not to deliver systems faster. Otherwise, the world could look very different in just a couple of years.

Two years ago, the Under Secretary of Defense was talking about near-peer adversaries. They refer to them as peer adversaries now. It's only been two years. I don't know what the next two years will bring for us. With that, thank you.