Jordan Stoner

Welcome, everybody. Those of you who don't know me, I'm Jordan Stoner. I'm an Agile coach at Lockheed Martin. I work in the space division. Prior to that, I worked at Boeing in a commercial manufacturing software program. And then, if you've heard of Morningstar, the star rating company, I worked there before on some smaller-scale projects, DevOps and Agile.

I spoke last year at the 2023 DevOps Enterprise Summit with someone who's sitting down in the front here. We talked about Ted Lasso. In case you heard it, I'd recommend watching it if you haven't. And you might have seen me on Slack. Someone asked me last night at the book signing if I was very active on Slack, so keep an eye out for that.

So welcome. A little bit about Lockheed. Founded in 1926, so we're about 100 years old. I was kind of heartened yesterday. We had a lot of older companies. John Deere is even older than Lockheed, and kind of the digital journeys that we're all taking. We've been around for a long time. Our digital transformation is different. There are a lot of Agile-native space companies, or there are some now, if you've heard of SpaceX, if you've heard of Blue Origin. So our transformation is a little different.

We have many years of success with Waterfall. Our leadership is very comfortable with Waterfall because we have been successful for many, many years. So how we think about that kind of plays into how we do our DevOps implementations and what types of things we're doing with Agile, and so on and so forth.

So the question I ask to all of you is: are DevOps implementations one size fits all? Are we going in with the same kind of ideas with every group? Are we doing the same things each time? Do I take the same approach as I go to different teams? When I go into an engagement, there's nuance. I need to understand. I did a thing on Slack today about empathy. You really need to understand where teams are.

So with that, and I want to thank, I think it was, who spoke from GitHub yesterday? GitLab. He mentioned my Overton windows. I'm very happy. That gave me some free press.

But what is the Overton window? It's a political concept, how to identify successful political policy on a sliding scale. If you think about any political issue, there are laws on either end. Either it's completely illegal or it's completely legal. I put the Wikipedia link in here just for people if they want to look it up later.

It was coined by Joseph Overton in the early nineties. He worked at a think tank in Michigan, and he came up with this idea.

If we think about, for instance, if I ask you down in front, where are you from, sir?

From where? Tokyo, Japan. Tokyo, Japan. Wow. Welcome. And then how about you over here? Northern California. Northern California, okay. And I'm from South Carolina.

In the United States, if we think about, we're all in democracies. There are different laws where we live. There are things that are illegal in Japan or in Northern California or illegal in South Carolina. There are different Overton windows. Our politicians have come to different conclusions as to what the laws should be.

And the difference is, when you think of a DevOps implementation, you want to kind of take the same idea. Where are we coming from? Where are the teams at? Where are we meeting them, and how are we kind of moving forward?

A politician doesn't move this window. A politician identifies this window. Where are my constituents? What do they feel? What are their opinions? And I craft policy accordingly.

If you think about things, just some examples. Prohibition went through kind of a crazy phase. It was completely illegal for a while, and now there's age restrictions on 21 and over to drink in the United States, for example.

Women's suffrage, only 100 years old. But back in the day, it was a radical idea. And so the window will shift over time. If you've ever seen a politician who has had an opinion on something at one point in time and has a different opinion in the future, the window has shifted. They have sensed a different kind of, "Oh, well, maybe my constituents feel a different way now." And so that idea of the window, you'll find that over time, and as things have changed over the years, that's what the idea is.

So we need a sliding scale. These are kind of just some examples, but if you think about the idea of DevOps and kind of the technical aspect, we have our manual deployment, manual testing, and then at the other end of the spectrum, you'd have your full CI/CD pipeline with a team.

And then if we think about kind of the theory aspect, you have your siloed teams. You've never done value stream mapping. And then at the complete other end of the spectrum, you have your fully scaled cross-functional teams. These axes, you need to kind of ground yourself, and there can be other axes and ideas, but just think of your teams. There's lots of places they could be on a spectrum. So if you want to think about it as the Gene Kim axis or the DevOps axis, just kind of for the idea of what it's going to be.

So what does this all have to do with DevOps? Different teams are in different spots. As we're learning, we've met all these people this week. They're all coming with different perspectives, different ideas. And so understanding that is very important to what we do together as a group with the organization.

Certain processes and our current processes seem mainstream. This mainstream idea of language and visibility are very important to mainstreaming an idea. How we talk about DevOps. What phrases are we using? What terms?

Anthony and I did last year, we did Ted Lasso, so we talked a lot about language. And it's very important when you're using language with your leadership, you're not saying things that they might not understand. What are these DevOps ideas, and why? What are this?

We have especially challenging in Lockheed because we're not just doing software. We're making physical products. And so that plays. The DevOps ideas aren't always, in a software sense, it seems a little more, people are more comfortable with that. But these are the kind of things we're dealing with as we're moving into things. And yeah, DevOps can seem kind of scary to people. We've been around for 100 years. We've done very successful things with Waterfall. Thus, the challenge remains.

As politicians are sensing these windows, we come into these engagements and we're sensing where the teams are. You really have to think like a politician. What do my constituents want? Obviously, politicians also think they know what's best for us sometimes, and there's a challenge there. And those who often do that to a large extent will find themselves voted out of office.

So in the idea of the window, we want to find it first. You have your spectrum. Where is my team on the window? When I come in, if I think of like, I have the software laptop and then the cyber-physical rocket, just for an example of the types of teams I deal with. Is this a software team? Am I working on a small-scale software program? Is this a 500-person cyber-physical? Am I making a rocket? Am I making a satellite? Whatever. That plays into where I might find their window.

And then we have earned value requirements. The U.S. government has specific ways they want us to do things, how we report. I don't want to think that DevOps or Agile or anything is not compatible with what we're trying to do, but that plays into my approach. What am I doing? I have these requirements. How the money's being spent, how I need to understand how my teams are getting paid for. That will lead into where the window is.

Has a team ever heard of these things before? Sometimes they haven't. Sometimes they have. It just kind of depends on, have they read The Phoenix Project? Well, let's start with that. What kind of things can I do to help them understand where they are and where I can help them?

Have we had a bad experience in the past? I find that a lot of times people will come in and explain the theory and then say, "Here you go, do this theory. This is how it's supposed to work. Go do it." And so that can really rub people the wrong way. Like I talked before about empathy, that really plays into how successful you can be, understanding, "Oh, we had a consultant last year," or we had whatever, and they weren't able to rate what we're doing. They weren't able to understand where we're going.

Do you understand, and do people understand, the interpretation of the expectations of what's happening within the DevOps space? That's something that you always want to keep in mind.

And then there's no training. I often run into Scrum masters that have never taken any sort of Agile class, or an RTE that doesn't know what SAFe is, or they may be doing DevOps things but haven't ever kind of read any of the theory. How do we help with that? The answers of these questions play into your approach as you're moving forward.

So if I think kind of graphically to depict where my window might be, if the software team is the laptop and the cyber-physical is maybe a rocket or whatever team we're building, I would most likely put them in different places. I want to make sure that the cyber-physical people have not heard of these things. They have a small amount of software. Not that we shouldn't try to teach them the concepts, but we really want them, don't bowl them over with telemetry and automated testing if it's not where they are. That can really turn people off when you're going 100 miles an hour and we're still kind of back in the... We want to help them understand the concepts, the why we're building these things. What are you doing? Let's take these theories, apply them to that. Don't try to move too fast. Make sure everyone understands.

And I think, for all the theory and all the people we saw today, there's obviously moving fast in the sense of getting stuff done, but being cognizant of that.

So then how do I use the window? Once the window has been identified, we can craft our approach accordingly. Always back to the fundamentals. Do they understand Scrum? Do we need to read some of the books? Do we need to lay the foundation?

Like I said, I run into a lot of people that learn on the fly, and then we wonder why they don't like these processes. Let's go back. Okay, I'm a coach. You've never taken Scrum? Great. Let's understand the principles of that, move forward from there.

How well do I know the materials? I need to understand these. Have I read enough books? Have I taken, like I'm teaching scaled Agile, I'm teaching DevOps, how well have I been versed in the materials? If I'm not terribly well versed, maybe I need to take some time too and understand that as well.

Like I said, we have a wide variety of teams doing a wide variety of projects. And so we have a unique perspective internally of what teams are doing what, and moving the DevOps into a cyber-physical context, and what sorts of different tools are more successful with different teams. A lot of software and companies here that make non-software products. But we have such a wide variety of things that it really kind of lends itself to having different ideas.

So how do I use the window? Again, if I have a manufacturing team, for example, let's break it down. Let's just have, here's a wall and here's stickies, and let's do a Kanban board. Stay out of Jira. Don't try that for now. But let's teach them the theory. Just walk by this board, move your stickies when you want, and then let's start. Don't force them into Jira. Make sure that they're understanding, this is how we want to do things.

A maintenance software program at Boeing: I worked on a 20-year-old software program that we really didn't have the opportunity to do Lean UX. But if I'm on a new startup program, maybe those are ideas I can think about. Their windows are different. It's not that I can't teach the theory to the old maintenance program, but I should cut my losses maybe and start at a different part.

Like I said, I always teach the fundamentals and understand why. I have children. I've played the game of telephone with them. They've had some fun, exciting things I've tried with that, learning the game of telephone. But that's the same thing. They're getting someone else's interpretation of the materials.

And as you come in, you also want to unpack that too. What did they teach you? What are you trying to learn? And then, okay, well, this is what the fundamentals say. The light bulbs start going off.

Has anyone ever gone to the gym and had a physical trainer, worked with a personal trainer? When you go to a trainer and you're trying to lose 20 pounds and you're trying to gain 20 pounds of muscle, you get different workouts. The same concept here. We don't want to blanketly apply things. We really want to take nuance and understand where we're going.

I also think that there's a lot of selective outrage that I run into. "Well, we're not doing DevOps because we're missing out on one part of it," or, "We're really not this." And there's really a binary kind of, you're doing it or you're not. And I think helping getting past that and understanding, if I'm not doing it, then what sorts of things can I help you with? Who's taught you things? What have you learned? And how can I help you? And take those as opportunities to kind of help with the window.

So then once you have the window, like I said, you want to identify it. The window will move, but you have to make the right decisions when you're taking the adoption into consideration. So if we pick the right concepts, if we start with the right items, if we're going back to the theory, the window will start to expand. They'll start to kind of, "Okay, this could kind of work. Where can I go from here?"

We have a lot of internal examples at Lockheed where we've tried DevOps. We have case studies. We have teams that are currently doing this. And so as we're working with our other teams, as I'm going into new teams, let's bring in some examples. Here's what we've seen. Here's Joe Schmo who did this DevOps thing, and here's what we can talk about. That helps me a lot with the window.

I also would say that I worked on a competitive downselect, and there was a lot more interest in adopting these because we wanted to look better than our competitors. And not look, but part of the bid was that we would do this. And so the window was wider than I would have normally expected it based on the things that I would usually see coming into such a process.

So I go to the team with the Post-it notes, and they finally see, "Gosh, our WIP is high," or, "QA is blocking something," or, "We don't have enough documentation," or whatever. Great, I'm showing you the theory. And then the window starts moving. I say, I have a whole book of the DevOps ideas. I have these great things. That kind of opens you up to say the teams are getting more excited about it. They're ready to kind of think about it and move forward with that.

I really harp on empathy. What are we building? The more you can empathize with what they're building. When I go to a team, the first thing I want to know is, forget all the theory and everything, talk me through what you do. What is your process now? If you're in Jira, what does "to do" mean? What does "in process," "in review" mean? And then talk through that. And then all of a sudden the discussions start kind of snowballing from there. "Well, I thought it meant this," or, "I thought it meant that." The window will start to expand because we're having those discussions as a group.

These are the things that we always kind of understand. We make assumptions of where we might be, but we're really opening that idea up. Let's talk about that.

We want to mainstream these ideas. We want our leadership to be comfortable with them. We want the language of what we're speaking to not be foreign. The language of Waterfall is not, so it feels very comfortable to people. Like I said, as these processes and tools get more comfortable, the window will continue to expand. And the more leadership can do that, the more we can do DevOps.

I'm sponsored by the software factory at Lockheed Martin. In the space division, it's an internal consulting firm able to do DevOps, DevSecOps, Agile coaching, what have you. We'll go team to team, find things in the company. Here's what we're seeing, here's what we're doing, and also able to build pipelines and stuff, and then tell teams about the best ways, best practices and such.

And we also kind of identify things that we see in the company. Team X is doing this, and connect people with that. But people, processes, and tools. We really want to keep the organization understanding, here's what we're doing, and keep an umbrella over the org, and go in and move when we need to.

So to kind of just wrap it up, you want to find where your window is. The location of it is very important as you move into your implementation. The window will help you find the right tools as you move through the process. And so let it give you that feedback loop. Listen to your teams. I always harp on empathy, but as the window is finding your tools, the window will shift over time as you continue to move forward.

I will say I am excited to discuss Overton windows with anyone, but also the community together. I would take the time at lunch today to talk to someone you've never talked to. Ask them what they see. And I think the perspective we gain as the organization, and the time that we spend, is really the value here.

I've learned so much. I was here last year and then being this year, from just the conversations in the hall, the ideas, what have you. But the perspective we gain as an organization, as the entirety of IT Revolution, the attendees of the conference, we can really find and help each other move together.

So, that's all I have.