Host Intro (Gene Kim)

I was so delighted to meet Dean Leffingwell in 2013 at the Agile Conference, because when I saw that famous big-picture diagram, SAFe, it was a genuine revelation. Just seeing that diagram, I immediately recognized what we were missing when I was at Tripwire from 1997 to 2010. We had no mechanism to coordinate and synchronize activities across multiple teams. The only planning tool we had was the marketing teams choosing which conference to do our product launches at, and the result was so much unnecessary disorder, last-minute emergencies, and chaos.

So I imagine people have the same reaction when they first saw the periodic table. And there are certain types of people like me who love the fact that bananas in any grocery store have the UPC code 4011, and organic bananas 94011. So you do not have to eat all the fruits and vegetables, right? It is just very helpful to have these numbers if you are a retailer or in the supply chain.

So I was really honored when Dean invited me to spend three days at one of his training events, and it was so great. Anyone who does not think he can learn something from Dean, given his vast experience and the books he has written, is fooling themselves. So I asked Dean to talk about what we need most from leadership and what this community can do if it is not there. Here is Dean.

Dean Leffingwell

First of all, the last speaker: isn't that why we are all here?

I will soon wander off my slides for sure, because I was actually enamored by agile, not by Scrum or Kanban. Kanban did not exist at the time. I was enamored by extreme programming because I came from a high-assurance software background. And when I saw extreme programming, I thought, that is really cool. I sat down next to an extreme programmer and he wrote some code, and then he wrote some other code. I said, well, what is the other code? He said, that is the test code. And I said, why are you writing the test code? Do you not know that your code works? He says, I wrote it. I know it does not work.

So I am Dean Leffingwell. Gene introduced me overly graciously. How do you think he knows what year he met people? He has a special notebook that says, I met this guy this year, because I had no idea when I met Gene until he reminded me of that.

And the first question you are probably asking yourself is, why is this guy not retired? I mean, come on. A couple reasons. Number one, most of the people that have died that I know were retired. I do not want to take the chance. What the heck with that? Number two, the mission that I have been on since it seems like time immemorial is not completed.

I want to talk about that mission a little bit. I want to talk about some of the pains and gains of leading in the digital age, specifically what we as leaders can do and are not doing sometimes, and just some tips and some observations from the field. This is basically a seminar that highlights real-world stories from the field. I am going to add those as well.

But wherever I go, this little guy follows me. This is me at age nine. Well, it is not really me at age nine. It is the way I felt at age nine when I saw Sputnik go across the sky for the first time. And I decided right there at age nine, I am going to be an engineer. Because that is going to be really cool. It is the space race. It is national defense. We are going to travel in space. We are going to inhabit other planets. I used to sit in grade school and draw pictures of airplanes and jets and things I was going to ride.

But I went to school for systems engineering. I studied systems engineering, aerospace engineering, and biomedical engineering, and then I became a programmer. And I liked being a programmer, but I was frustrated by a couple things. One was the systems that we were working in were really pretty bad systems, really hard to get work done. Even then, this was microprocessor-based programming, not a heavy SDLC, but the resources you had, the structures you had, the requirements you were given: it was easier to write code that was bad and met the requirements than it was to change the requirements even then. I decided at that point I could do something better about it, and I have worked my entire career for only one thing, which is: what are the methods and practices that help people build better software systems faster, better, cheaper, with happier employees?

My first company was an R&D company, and at that company I spent 18 years building really cool things, things that had never been built before, the first microprocessor-based ventilator ever approved for home use. And it was late. And people complained about it being late, and yet it was a thing that would save lives. So I got tired of that and thought, I am going to work on this.

So all my life I have been working on it, and you are going to get the accumulated opinion of what I have resolved on my own over the last X years. It does not have to be your opinion. I do not offer it as yours. Even within my own team our opinions vary. That is the nature of a high-performing agile team. But the fact is, I have an opinion that the real root cause is the fact that we need a different way of thinking and working. What the teams do is important. What the middle management do is important. What leadership does is important. But what the leaders who lead by example do is even more important.

So I want to talk about some of these challenges and some of these pains.

Now, we have adopted in our company and in the framework, over various periods of time as it evolves, a set of very simple core values. I think simple is great. It is a pretty big framework, so having something simple is great. I propose that there are four that you could pretty much all agree on: if your enterprise works this way, your leaders work this way, and the teams work this way, you would be better off. They are alignment, transparency, respect for people, and relentless improvement. But guess what? There are pains in this regard.

Alignment is not a natural state. Alignment happens when people who do not wake up agreeing agree to agree through a process, often facilitated, and come to a conclusion that they now agree. The very next day, the entropy of the universe kicks in and we start to have different opinions about what needs to be done, because the facts have changed. So alignment is not free. When you see executives that are not aligned, it is because they have not taken the time to be aligned. We have language for this. We rarely say in our company that we do not agree. We say we are not aligned on that. And that is a big difference.

It is not a natural state. You have to fight every day to be there. You have to invest to be there. You have to be with your peers to be there. A facilitator often helps. Align on strategy, align on execution. Everything you align on is going to require some help.

Transparency is really hard. Growing up as a leader, pretty well grown up now, I grew up in a different environment: the trucking company. I drove a truck. My dad said, okay, drive this truck this far, whatever. There was no transparency in that. There was no why behind that. It is just do it. And here is the thing, to give you an idea how leaders have to evolve: he never asked me, by the way, how do you feel about that? That was not in his language.

Transparency means that you have to be transparent yourself, and you have to admit your mistakes, especially at the leadership level. You have to say, I blew that. Because if you are asking for transparency from everybody else and you do not give it, you are just the hypocrite of the day, and people totally get that. Do not underestimate the knowledge and the insights of people you work with. They get it. You can say, my backlog is transparent, but oh gosh, it turns out the lean portfolio management Kanban is locked out, I cannot get into that. Or, yeah, I blew that, but I am not person enough to stand up and say I did that.

Relentless improvement: we do not call it continuous improvement because that is just a boring word. Of course we evolve, of course we continuously improve. But if I sit down with an executive in your enterprise and ask, do you have a value around continuous improvement, they will say absolutely. And I will say, well, do you improve relentlessly? And they will say, what do you mean by that? Now I am engaged in the conversation. Illustrate to me what relentless improvement looks like in your organization. Describe to me a couple of interesting situations that you are doing right now to do relentless improvement.

Respect for people felt right in the Agile Manifesto. It is in one pillar of every house of lean that has ever been created, including the derivatives of dozens. I have never seen a house of lean that did not have respect for people. Lean started out with respect for people doing the assembly work. It started out by empowering the people on the floor to throw up a quality circle if some problem happened, or do a root cause analysis if there was an issue on the floor. So respect for people, we always say, and we always respect people, right?

Well, we do not always. When we see it, we recognize it. I left a meeting, I will not tell you which one, just the other day right in this room where the group said, and then the manager walks in and everybody is looking down. Well, that is not respect for people. That manager probably does not deserve respect, or maybe he has a team that does not understand that they need to have empathy for him as well. But it does not have to be like that, and it is not always so.

While I have basically been pushing my shoulder against leadership and managers and executives that grew up in Taylorism and various forms of management, I have worked with leaders that were command-and-control people and servant leaders of all kinds. I find those leadership styles generally independent of results, because it is the intangibles and how they lead inside that style that really works.

We do see it. We see it here. Just recently, at our summit, from Southwest Airlines: in the midst of COVID, we never had furloughs, never had layoffs, and we were not going to break that trend now. This is not an IT story. Well, it could be an IT story. In fact, that is leadership. That is executive people. They say, we do not know, our revenue went to zero, we are going to keep our people on staff until we go down for the count, and it gets a little deeper over time.

Our customer here, Porsche, the VP of Engineering, said it was bringing the people together, talking very often about why we are doing it, the why. You do not have to force them, to push them. You have to convince them about the why, why they want to do it. They realize then it is okay, it is necessary, and it is fun. I love the last quote here at Porsche: it is necessary to have fun, otherwise we will not get that kind of product. They did not give away a Porsche at the summit or anything. I was really disappointed with that. It still galls me a little bit. I cannot really get out of a Porsche anymore anyway. It is still hard.

Embracing a lean-agile mindset: what a simple concept. Again, we have simplified in our world, and in the SAFe world, the two basic paradigms, because one paradigm was not enough. I was tipped to agile when the Agile Manifesto came out in 2001. I started coaching agile teams. I was working in the venture capital world. I turned teams that were really not performing into extremely high-performing teams with agile. And by the way, some of those were the same people I had coached at Rational using the Rational Unified Process. Same people, different process, dramatically different result. So that took me to agile.

I was lucky. I actually attended Goldratt's seminar on The Goal one time. At one of my first companies, we basically purchased a small manufacturing operation and then we started to lose money hand over fist. It started to be a real worry. So at that point it is like, I have got to learn how to manufacture. So I went to the school of lean and learned lean, learned the Toyota Production System, and implemented that.

Lean scales. Value streams come from lean; we are not making this up. You can see that here, well, you could if I actually pushed the button. Basically, simple words: we are here now, like precisely specify value by product, project to product. This is not new. This is 1986 lean thinking: specify value by product. Identify the value stream for the product.

I never thought I would get tired of hearing the word value stream, but this week I almost did. Because it is the container and the mental model for organization in a way that, whether it is matrix or line-based management, it collects the people together to do the job that needs to be done, to work together to produce an outstanding outcome. There is value delivered by its definition. If you cannot tell what products or services you sell or who your customers are, you cannot achieve that.

Both schools of knowledge are extremely deep and extremely rich. There are as many books in our libraries on lean as there are on agile, and they are both incredible: the power of TDD and XP and agile development and Scrum and the role of product owner, and lean thinking across the enterprise. In my mind, growing up 10 or 15 years ago, these all came together and said, this is great. These are not countervailing trends. We can be lean and we can be agile at the same time.

The trick is, a lot of us assume agile. And now that our company has grown, I can tell you: beware. Agile is fundamentally and monumentally hard to do, and if you turn your back on helping people be agile, they will not be. They will revert to their specialty skills, their individual silos. You will work with the designer that says, well, I work in EPS. Well, I just need a sketch in PowerPoint. No, I do EPS. Well, show me early EPS, because I want to see if that thing is really going to be the image I want. That is not done yet. I cannot show it to you.

You heard the experiment about pair programming, right? The experiment: tear down the walls. That is hard. Responding to change over following a plan: easy to say, hard to do.

Lean thinking requires a significant sense of reorganization and figuring how to do end-to-end value streams. And guess what? There are people in those end-to-end value streams that I do not know, and maybe I did not get along with, or maybe they are in sales, or maybe they are in marketing, and maybe I do not know what they do. They are part of the value stream. That is the nice thing about the value stream construct: all the people, materials, data, and information you need are inside the value stream by its definition. If it is not there, it is a poor value stream, so you need to add that.

That really, really stresses the company. Some of you have gone down the road through the value stream and ART identification workshop. That is a wake-up call. It is like, we are not organized that way now. What happens to my fiefdom? What happens to my job description if we organize around value? But it shifts the mindset.

In the case of Oracle Financials and their story, it shifted the mindset from finger-pointing to understanding the flow of value and having the same language, same goals, and basically having everything aligned in common. Their shift to value stream thinking brought them to a common alignment: this is the product, this is the service, these are the people we need to do it, etc.

End-to-end is exactly that. Here is a company, Fred IT Group, that was doing an e-prescription solution, and they wanted to develop it and deliver it in incredibly short order time. So they used value stream thinking and agile development to break down their siloed teams, get them to work together, build an Agile Release Train focusing exactly on that, have the right business people and the right technical people, and they pulled it off in the midst of changing requirements. They could not do that before. That is what value stream thinking and agile and lean can do in your organization.

We have a set of principles that underlie everything we do, and there are many, and I sure cannot tell them all here. There are a lot, so I hope it is going to stop at ten. They vary from highly technical, assume variability and preserve options, that is set-based design. We really coach people for set-based design. If you have real milestones in your life, if you are approaching real milestones without set-based design, you are taking a huge risk because you do not have the degree of freedom you need. You have got to have a simpler design option. You have got to have a buffer in the process or whatever. Set-based design is one of them. Building incrementally with fast integrated learning cycles.

The pains are that they are kind of abstract. Set-based design. Decentralized decision-making. Yeah, right, that sounds really good. How do you do that? Who do you decentralize decision-making to? What if the teams are brand new, and you are empowering them and you want to decentralize decision-making, but they are not yet competent in their role? What do you do then? Keep all the decisions? Give the decision? Watch me? Tough. Absolutely not easy to do.

The senior leaders do not always find their way there, and if the senior leaders, the C-minus level, do not always find their way to that set of principles, it really drives a business as everything else. Everything else is instantiation. It is a practice that follows the principle. Deming said people say our problems are different. It is a disease of Western management that our problems are different. He said they are different to be sure, but the principles that improve the quality of product and service are universal in nature. We need to understand those principles. And if our executives do not understand the principles, we will not be there.

The word middle management does not sound good, does it? It is almost a pejorative. Guess what? If you are the gentleman that was just here, and he has got two or three layers above that saying, yes, we can go deep down and dirty with DevOps or whatever, and they wave the flag, or your CIO or CIO minus one, you do not control or build the systems that the people work in. The people build the systems, right? The middle managers are responsible for those systems. If we do not reach them, people often ask me, if you are doing a digital transformation, bottom up or top down? Neither. Middle out.

Reach the people. Reach the middle. Help the middle understand how their world is going to improve, and they can make the change and their teams will follow.

But when they do get them, they get the type of results that you see here, DevOps-y kind of results stated in a DevOps-y way. In two years, Southwest Airlines moved from prior years' production of 28 releases with 45% quality to 349 releases with 93% quality. That is pretty scary. That shows what DevOps and agile development and the right leadership can accomplish, and we see that all the time.

We see leaders step up and take a course and be certified. Do they have to be certified? Did they put their badge on LinkedIn? No. Why be certified? I wanted to understand. I wanted to be able to demonstrate that I understood the material. One of our friends here, Scott Prugh, I talked to him one time about certification and asked him, do you think it was important or not? He said, I think it is because it proves that people learn the material.

Learning, getting ahead of the game, is great. Most importantly, we have to lead the change. In order to do that, the pains are best articulated here by the guy at Southwest. I will read it to you: I will tell you, we do not need an executive sponsor. I am so freaking, that was his term, sick of seeing that term. We need someone to model the change. You cannot delegate this out to your team. You cannot mail it in. They will not respect it. It will not stick. So we need an executive role model.

We see it. Divisions decide that it is at the tone by learning the methods and practices and leading the way.

As I approach the end of time, one of my heroes, Deming, comes back and says, it is not enough that management commit themselves for life to quality and productivity. They must know what it is they must do. These obligations cannot be delegated.

So I want that to be your take-home with one exception. There is one more thing. Gene always asks what I need. I do not need very much. Maybe it is what we all need. Maybe it is even what the world needs. And it is this: if you believe that leading in the digital age requires the mindset, values, and principles behind agile and scaled agile, lean thinking, DevOps, flow, and systems thinking, no matter the variant or no matter the label on the system, then for goodness' sake, please lead by example. And I promise you, others will follow you. We will do better. Thank you.