Jordan Stoner

All right, well, welcome. My name is Jordan Stoner. I'm an Agile coach at Lockheed Martin Space. I've worked prior to that at Boeing and at Morningstar Financial.

Anthony Earl

My name's Anthony. I'm also an Agile coach at Lockheed Martin. I have a long career in various major corporations doing research and architecture and some smaller startups. And I'm currently working at Lockheed.

And I do want to thank you all for coming straight after lunch on the third day. That shows some interest, and thanks for doing that.

Jordan Stoner

Absolutely. So Anthony and I both speak English. So I'm from the United States.

Anthony Earl

And I am from the United Kingdom, which is four countries. And I've spent time in New Zealand, where people all speak English.

Jordan Stoner

But then, for instance, Anthony and I might have, you know, I have a shopping cart.

Anthony Earl

No, that's a shopping trolley.

Jordan Stoner

Oh, okay. Or like I had some crisps.

Anthony Earl

Chips.

Jordan Stoner

Chips.

Anthony Earl

Crisps or chips?

Jordan Stoner

Chips or chips. And then I have crisps.

And then, so for instance, the title character of the show, Ted Lasso.

Anthony Earl

Is that Lasso?

Jordan Stoner

That's how you're pronouncing? Yeah, absolutely.

So obviously language can be a challenge. As we're talking about the ideas, we have problems at Lockheed that we're trying to figure out when we're implementing new systems. We're trying to create an environment conducive to learning. We're teaching, but we're also learning as well.

We are learning the terminology of space. We're learning what it means for our teams to do things. They're learning Agile. They're learning DevOps, trying to understand what we're trying to teach.

So we need cost-effective solutions. We need high quality. Obviously we need delivery at the speed of relevance, practical support in unusual environments. We're in space. We're not a mobile app. I mean, there's an aspect of that that is very different than most of your normal mobile apps are having to be done.

So just a quick shout-out, and Harry is here from Scaled Agile. We, Risa, who helped us get these graphics that Harry helped us with, who's sitting a couple rows back, got to give him a shout-out.

So just a little bit about the characters, for those of you who are unfamiliar with the show. Ted is obviously the main character, kind of a folksy Midwestern, not unlike myself, kind of a little smarter than he lets on. We will talk about his leadership style in a second.

Coach Beard is more of his tactical genius: X's and O's, making the plays, running the practices. He's kind of the strong silent type.

Rebecca is the owner. She gets the soccer club in a divorce from her husband, and so she kind of wants the team to fail. I'm not giving anything away: hiring Ted, because Ted had coached football, sorry, not soccer, but football. Football. And so she kind of thinks that maybe the team will fail and do bad.

And then Keeley is one of the girlfriends of one of the players in the show. They all have their different arcs.

As the show goes on, I will say I had a discussion the other day when I was coaching a team, and we got talking about Ted Lasso. I said, "Oh, which character do you relate with?" This was a senior manager, and she said, "Oh, I'm totally Ted Lasso."

And I think all leaders think they're Ted Lasso, and that's great. But then I'm like, "Well, why would you think that?" And she said, "Well, this and that." And then I'm like, "The more I talk about it, the more I may be more like Rebecca," or whatever.

But I think as you have that discussion, that's a great discussion point. Because every member of this show, or at least these, all have different leadership qualities. And as you're watching, as you're understanding the flow of the show, how is that playing into the show? Obviously there's different things about the show that are funny and that sort of thing, but that's kind of an important take that I took out of it.

Anthony Earl

And if you haven't seen the show, there will be no spoilers.

Jordan Stoner

We'll keep it spoiler-free.

So what does Ted Lasso have to do with this? Throw it out: what's the show about? Anyone who's seen it?

Leadership. Thank you very much. What else we got? Empathy. I love that. What else? Any other thoughts of the show?

Success. Success, failure, and success. Absolutely. Any other ones? Do I get optimism? Thank you very much. I love the dogged optimism.

So to us, the show is about we're implementing a new system. Does that sound like DevOps? Does that sound like Agile? And then, so we're staying positive. I heard the optimism there. Ted's always in a great mood, trying his best.

We are learning new terminology and overcoming a language barrier. A lot of the jokes in the show come from Ted learning soccer terms, football terminology, and British English. And he's stumbling over a lot of these things, but that's kind of what makes him more endearing.

And as leadership goes, we're building relationships and encouraging teams to do so as well. Obviously all of our engagements are about relationships. We're learning this from the show, but we're also understanding that that's a core value of the show, and how all the characters you saw earlier, and then even Roy Kent and everyone, all the interrelationships are all intertwined. And you're trying to understand that as the process goes on.

So Ted says, "I think one of the neatest things about being a coach is a connection that you get with your players. That's a loss that stays with me, and it hits me a lot longer than anything that happens on a patch of grass."

We're not the first ones to notice this. There's a lot of articles about Ted Lasso, and I had a nice chat this morning with, I think she's sitting in the back, the IBM fellow, about servant leadership.

When I teach classes about Agile and when I talk to teams, she had a great thing about it this morning. Servant leadership is very under... and all of us are leadership in some sense, but really this show kind of digs into how he's not their boss. He's the coach, and he has a lot of sway, but he can't fire them and he doesn't affect what they make, but he really gets them to perform.

And I think we're trying all to do that. When you talk a lot about servant leadership, that's one of the ideas we want to drive home. So these articles, you'll get the deck. There's plenty of them on Ted Lasso leadership, but I'd highly recommend looking them up. And, yeah, "Why Real Leaders, Real Coaches Want to Be Like Ted Lasso."

Anthony Earl

So language problems are not a joke. So Ted says that his job, if I were to get fired from the job of putting cleats in the trunk of my car...

Jordan Stoner

"You got fired for putting boots in the boot?"

Anthony Earl

And Ted says, "I love that."

So, yeah, Jordan, you've done Scrum, right?

Jordan Stoner

Yes, of course.

Anthony Earl

So you know about all the Agile terms. You know every one of them.

Jordan Stoner

Every, like sprint?

Anthony Earl

No, no, it's iteration.

Jordan Stoner

Oh, so look in the Agile Alliance glossary. Yeah. How about Scrum?

Anthony Earl

I've played rugby. Yeah, I'm Scrum there.

Jordan Stoner

There you go. So how about a...

Anthony Earl

No, no, no, it's a daily standup.

Jordan Stoner

Daily standup. Is that like the team sync in SAFe?

Anthony Earl

This terminology. How many terms are there in all these glossaries?

Jordan Stoner

So there are 75 terms in the Agile Alliance glossary.

Anthony Earl

And there's over a hundred terms, that may be growing as we speak, in the SAFe glossary. And there's 30 more in the Scrum.org glossary.

Jordan Stoner

So if you're new to Agile, and we haven't even gotten into DevOps, you're speaking a new language. It's like Anthony and I are speaking the same language, but not really. You'll have a lot of that as you're implementing and making your changes.

Anthony Earl

That's right. We have this clicker to go smoothly.

First of all, recognize our language barriers. I've heard the term cognitive load a lot this week, and bringing a whole new set of concepts to people as you're making an Agile transformation is something you have to remember is going on.

We speak about this just about every day, so we're very used to the terminology, and it's easy to forget that not everybody is. We obviously do training. Training in some formal circumstances. We use the SAFe license material, or we use some of the Agile material we've developed ourselves.

But every interaction we have with the teams is an opportunity, not so much to force them into a new terminology, but to try and give them examples of where they're using some new concept from Agile. They're using it well, or maybe they're hitting an anti-pattern. And we really want to point out these are the consequences that you could have if you take a different route with that.

But it's not a one-way street, because Jordan and I don't have a background in space. We do kind of now, after two or three years, though. But a lot of the terminology, when you go to a new program, is very unfamiliar.

I realized that the space geeks have had about the same amount of decades to create their own terminology as the computer science geeks. Around the same time. So that was just an observation I made, I think yesterday.

And one thing that happens during the show is Rebecca's there, and Ted arrives, and she asks, "How was your first day?" And so Ted says, "I'm not exactly sure what y'all's smallest unit of measurement here is, but that's about how much headway I made."

So we recommend taking small steps. But you have to recommend a first step. In many cases, introducing some form of Agile tool, whether that's Jira, VersionOne, whatever you like to use, just getting something like that in place has several benefits.

It's going to offer you some early predictors quite cheaply, because you're starting to track real progress. A story's done. A feature's actually done. And having that initial set of data, and being able to start to extrapolate from that, will give not just the teams but the leaders some immediate value to seeing how things really are at the moment.

It also gives us, as coaches, some ideas of whether the rules are really being followed. Have teams really planned to capacity? This is a rule. I can't understand why teams will say, "You want us to calculate our capacity and then make a plan that's within that? Okay." And they come back, and inevitably, they don't know the rules.

So, not knowing the rules. Ted says, "How's that offside? No, I really want to know," because he doesn't actually know.

And this is where I have to stop. I have to say, if any of you are Liverpool fans and you know what happened during the Tottenham game, then now I have to believe that even the referees in England do not understand the offside rule. I know that's an aside, but you know.

Jordan Stoner

We got a long discussion in me, Coach Earl.

Anthony Earl

I actually met another Liverpool fan just before I talked. So there you go.

Jordan Stoner

So Ted's always getting feedback. "I want you to know that I value each one of your opinions, even when you're wrong."

So Ted's getting feedback instantaneously at the stadium. Obviously the fans are quick to register their displeasure or their pleasure based on how things are going. The blokes at the pub are telling him how to do and not do things. The team is giving him feedback. They're understanding what kinds of things are going.

One of the parts in the beginning I like is when he puts in the comment box, and no one really takes it seriously. But then one of the teammates says, "Oh, the shower pressure's bad." And Ted's like, "That's something we can work on, and that's something we can fix." You're getting roadblocks out of the way. It's something simple and easy.

But then at Lockheed, we have feedback too. We have our customers. We have our stakeholders, who are the U.S. government or other governments, for that matter. And then we have our teams internally in the organization. There's lots of feedback loops going on in there.

We have to think about our customer. Our customer is not the user. The government's buying the fighter jet or the satellite or whatever, and the pilot is not buying it. So we have to understand that feedback loop. How is this being used? What are we doing with it?

We do earned value. We want to bring our customers along with us, bring them to PI planning, involve them with the processes, and make sure they understand that they're part of this too. We have to break those silos down as best as we can.

"Back where I'm from, if you try to end a game in a tie, well, that might as well be the first sign of the apocalypse," Ted says.

So when we talk more about feedback, football teams report their progress once a week: wins, losses, tackles, goals for. Again and again, the unofficial stuff: pass completions, tackles, et cetera.

So like I said before, we use earned value. For those of you who have heard of it, we're tracking that. Plus we're using the regular Agile metrics, velocity, that sort of thing, going against all of that combined together to show how we're making our progress.

Obviously regular reporting has benefits. Leadership is able to have the data in front of them to make the decisions at the right time. All projects get behind. All projects have problems. It's kind of when are you seeing that that is the most important part of it.

And celebrations are important. "If you've got a... if you care about someone and you got a little love in your heart, there ain't nothing you can't get through together," Ted says.

So we celebrate as much as we can. Any sort of win. When you have a good iteration achievement, a demo goes well, let's celebrate. The customer likes it, celebrate. If I got a roadblock out of the way, let's make the best of it.

The show is a lot about celebration. Sam's birthday, they have a party even though they lose. And that's early, so that's not a spoiler. The other thing: they break a tie streak and they celebrate. The Christmas episode is one of my favorites, because they're all getting together to bond and celebrate together.

Birthday, special occasions. If we have new team members, you want to bring them into the fold. We do fortnightly classes on the tool, on Agile, on what DevOps is, just to make sure people who are coming in are welcome and feel like they're part of the team. We're engaging them together and helping everyone feel part of the team.

Anthony Earl

And part of team building and mentorship, Keeley is mentored by Rebecca, and she says, "A good mentor hopes you will move on. A great mentor knows you will move on."

What I want to convey here is that you often see mappings between the existing organization: this is where everyone's going to go in an Agile or scaled Agile organization. You could have those mappings. You could try those mappings. But don't expect them to work for everyone in your organization.

People have their own background, their own experiences, their career goals. They may or may not be successful in the traditionally mapped role. So give them an opportunity to learn what that role is. Let them take training for maybe two or three different roles. See how they fit. Give them an opportunity to try that out.

Maybe you can even try that out as you're doing your Agile transformation. Take some Agile approaches to that and see if that helps people understand what their new role really is.

And also remember that they may have to carry on with some of their existing corporate roles, and make sure they understand which ones they're keeping, which ones they're handing off, which ones they're gaining in the new system.

And just Nate and Roy Kent also move on in the show. But a story about the actor who plays Roy Kent: he's a writer for the show. He's a stand-up comedian, and he didn't realize that he would be the best actor for the show, but he turned out. He did apply for that. He got the part, and I think he won an Emmy.

Jordan Stoner

He won an Emmy.

Anthony Earl

Just from being a writer to moving on.

Jordan Stoner

So yeah, talk about roles and transitions.

Anthony Earl

And then small teams, another one of those roles that we can recommend forever. And people will take an existing large team and they'll call them a new Agile team. And again, it's not going to work.

A lot of the mechanics or the physics of Agile work with smooth flow and effective, efficient meetings and so on because the teams are small. If you leave big teams in an Agile system, you're probably going to hit some problems.

You're also going to face, especially in an organization like Lockheed, and I'm sure it's true in many, many areas, you have some people who have very specialist skills. There are only one or two of them maybe in the whole company. You will have to share them.

But don't make that an excuse to make it a common practice to have people having to go to two or three daily standups, or to not be there at planning because they're with another team at planning. So make sure you avoid that as much as you can, and give people time.

I think I've already covered most of these points. But as they're trying a new role or just practicing a role they want, they need some opportunities to see what success is like, but also some kind of failure.

Obviously as coaches, we're not going to let them fall off a cliff, but we are going to say, "Well, explore that avenue for a while and see how it goes." And if it's not going the way they hoped, we talk to them and say, "This is what you can learn from that experience."

But you can use that as an exemplar for the team to see how somebody's treated. If they do make a mistake, the team should be supportive. You really want them to have the help that they can get and the support and trust from their team.

And as coaches, we're having fun. We're passing on this knowledge that we've gained over the years, and that is also something we can celebrate. But as we're being happy about this, we also have to admit that we are going to see some resistance to change.

People just don't like change. Many people don't like change. No matter what their mindset is or how they present themselves, there may be some deep down discomfort with the type of change they're going through.

We see this a lot with managers who want to keep their regular staff meeting going for an hour, even though they've had all the updates, the opportunities to sit in on daily standups and get all the updates they might need for all of the team members. They still want to gather people together and go through the same old routine.

We see that in the show that Jamie's one of the strikers. He likes to take a shot whenever he can. He doesn't want to make that extra pass to guarantee the goal is scored. That's an old habit he has. Whether he changes that or not, you'll have to watch the show.

People, when they're first introduced to stories describing the work that's needed to be done, they often will write down, "How are we going to do this?" They'll write down in great detail, how are we going to do this? We don't need to know that.

We want to give the team the freedom to find a way that works for them as to how they're going to solve the problems. What we want is what are they, what's the story going to achieve? It saves a lot of time writing stories as well. There's a lot less you have to put in there.

There's a habit people have of wanting work assigned to them, and some people like to assign work. That's not an efficient pull system. And that's, again, a habit we like to see broken as quickly as we can.

And Ted was not uncomfortable to delegate training practices to Coach Beard, and then eventually to Nate.

Jordan Stoner

And play calling.

Anthony Earl

And play calling. Yeah, he delegated that.

This is an approach we like to take. Ted, in terms of resistance, nudged that ship in the right direction. We do like people to learn on the job. We like to nudge them in that right direction rather than tell them how to do that.

There is an episode where you're introduced to Led Tasso. That is not a typo. Led Tasso is an alter ego coach who tells players how to do things. Don't be like Led Tasso.

And I've mentioned before, teams need that safe space. They need the trust of their team that they're doing the right thing by exploring. Sometimes it will work, sometimes it won't. But if they can learn something from those explorations that didn't work out, then that's just as valuable, or can even be more valuable.

We've seen people, and I mean literally, save millions of dollars for Lockheed on a program by exploring an alternative to what was originally planned. And that's something that you're only going to see if people feel like they're in that kind of safe environment.

We want to give them tough feedback at times, but we want them to learn how to do effective retrospectives and trust that they will be confident with that.

And in terms of teaching people how to do things, like "teach a man to fish" kind of idea, there is a quote from the show: "Well, you know the saying, you buy a man a table, he eats once, but you teach a man how to get a table, and he eats at that restaurant until it becomes a Starbucks."

So planning and plans need feedback too. Ted says, "I'm not planning for that. No, my plan is for my plan to work. But you know what they say about best-laid plans, right?"

Teams strongly resist planning to capacity. I've said this once before, but they really do. They really want to be irrationally exuberant. We've got to make sure people learn how to give and take feedback. And one way we have to do that is to give the team strong feedback that you are not going to plan beyond capacity.

We might let them do it once or twice to see what happens, which is generally not good. And then the change, when they do, tends to be a change in a very positive direction. They produce a lot more.

And then we want to emphasize who there are specific roles given in Agile where those roles should be the ones who know this and practice this, show the teams how that works, and pass those skills on to everybody else.

But most of all, just like professional athletes, our teams want to win. They want to win. So sometimes just gentle peer pressure will help your team along.

In our environment, we're widely distributed, mainly across the U.S., but some international areas. We've got to enable the introduction of tool support and create a digital environment.

We're not different from almost all of the speakers who've spoken this week, that there's digital transformations going on across Lockheed in some specific areas, and then more broadly across the company. We're in the software factory.

As well as Jordan and I being Agile coaches, there is kind of a sibling team who specialize in specific tools and bringing in secure, free open source software, making that available to the team so they can have a turnkey solution and be able to save an enormous amount of time in having to create an environment.

So that when they get the go-ahead, they can have the environments they need to start being productive in hours, maybe days. That's some really important things that are happening at the moment that are not directly from us being Agile coaches, but we want people to have the right tooling that goes along with that.

That does provide a lot of savings. The tooling is probably the most obvious way we save many dollars. I can't give you any numbers, but we save a lot of dollars.

For each of the coaches who participate in training throughout the year, we've calculated we train about 300 students each. And in our organization, that spreads quite widely. And remember, we're only Space Software, sorry, the Space Software Factory. So there are about four other parts of Lockheed where similar efforts are going on.

And then that significant savings in times to build the environment is a big time saver. The software factory is an idea that is documented by the government. It utilizes people and processes and tools. But we'd like to emphasize today the people really are the most valuable resource that we have.

So we treat them with respect, offer them a purposeful job, create that supportive environment, and understand that change is difficult. We're going to see language barriers. We advise you take small steps, listen to feedback, have consistent reporting. Celebrate.

Jordan Stoner

Is anyone's birthday today?

Anthony Earl

We're not going to embarrass you.

Jordan Stoner

We're not? Yes.

Anthony Earl

Or this week, or during the conference, or anything.

Jordan Stoner

This year. This year. There we go. So anyone this week? This week?

Anthony Earl

This week.

Jordan Stoner

We have some pops for birthday people. So I have three of them up here. Someone after the show would like to come get a pop for your birthday, because we celebrate, because that's important.

So, because... thank you. And one...

Wait, wait, wait. We believe in DevOps, and thank you for coming to our TED Talk. Thank you very much. Appreciate it.