Pains and Gains of Leading in the Digital Age
Many in our broad Lean-Agile-DevOps movement have a common purpose, to improve the everyday lives of developers building the world’s most important systems. In turn, that serves an even greater purpose, which is to improve the lives of the billions of people who use those systems for their basic, security, comfort, livelihood, and happiness.
But we are a diverse collection of thinkers and opinions abound as to how to best achieve this. What we can agree on is that the right kind of leadership matters.
In this 20-minute plenary session, Dean Leffingwell discusses the “Pains and Gains of Leading in the Digital Age.” He shares experiences that illustrate just how sharp these pain points can be, the mindset, core values, and principles that can be used to address them, and how the most successful enterprise leaders are leading by example.
Cofounder and Chief Methodologist, Scaled Agile
I was so delighted to meet Dean Leffingwell in 2013 at the, uh, agile Conference because when I saw, uh, 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 a tripwire from 1997 to 2010, we had no mechanism to coordinate and synchronize activities across mental 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 many unnecessary disorder, last minute emergencies, uh, and chaos. So imagine people had the same reaction when they first saw the periodic table, or, and there are certain type of people like me that we love the fact that bananas in any grocery store have the U P C code, 4 0 1 1, uh, and Organic Bananas, 9 4 0 1 1. So you don't have to eat all the fruits and vegetables, right? You just, it's very helpful to have these numbers if you're 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. Uh, anyone who doesn't think he can learn something from Dean, given his vast experience, uh, and the books he's written, uh, is fooling themselves. So I asked Dean, uh, to talk about what we need most from leadership, uh, and what this community can do if it's not there. Here's Dean.
Am I live, first of all, the last speaker? Isn't that why we're all here?
I, I will soon wander off my slides for sure, because I was actually enamored by Agile, not by Scrummer, Kanban. Kanban didn't exist at the time 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, he wrote some code and then he wrote some other code and I, and said, well, what's the other code? He said, that's a test code. And he said, and I said, well, why are you writing the test code? Don't you know that your code works? He says, I wrote it. I know it doesn't work. Okay, <laugh>, so I'm Dean Leffingwell. Gene introduced me overly, graciously. How, how do you think he knows what year he met people? Do has like a special notebook that says, I met this guy this year. 'cause I had no idea where, when I met Gene, until he reminded me of that. Um, and I'm, the first question you're probably asking yourself is, why isn't this guy retired? I mean, come on. Couple reasons. Number one,
Most of the people that have died that I knowed were retired. I don't wanna take the chance, right? What the heck? What the heck with that? Number two, the mission that I've been on since it seems like time immemorial is, is not completed. And I want to talk about that mission a little bit. I wanna talk about some of the pains and gains of leading in the digital age, specifically what we, what we as leaders can do and aren't doing sometimes, and, and just some tips and some observations from the field. This is a, this is a, um, basically as a seminar that highlights real world stories from the field. I'm gonna add those as well, but wherever I go,
This little guy follows me. This is me at age nine. Well, it's not really me at age nine. Okay? It looks, it, it, it's, it's 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'm gonna be an engineer, because that's gonna be really cool. It's a space race. It's national defense. We're gonna travel in space, we're gonna inhabit other planets. I'm gonna be on a, I used to sit at in grade school and draw pictures of, of, uh, of airplanes and, and jets and things that I was gonna 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 is kind of microprocessor based programming, not a heavy S D L C, but the resources you had, the instructions you have, the, the requirements that you were given, it was easier to write code that was bad and met the requirements that it was to change the requirements even then. And I decided at that point in my career, I thought I could do something better about it. And I've, I've, I've 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, happier employees? I got tired of, my first company was r d company. In that company, I spent, you know, 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, it was a thing that was, that would save lives. So I got tired of that and thought, you know, I'm gonna work on this. So all my life, I've been working on it. And you're gonna get the, the, the accumulative opinion of what I've re resolved on my own over the last six years. It doesn't have to be your opinion. I don't offer it as yours. Even, even within my own team. Our opinions vary. That's the nature of a high performing agile team. But, but the fact is, I have an opinion that the, the real root cause is the fact that we need a different set, a different way of thinking and working. And 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 wanna talk about some of these challenges and some of these pains. Now, we've adopted the, in our company, in the framework over various periods of time, it evolves a little bit a set of very simple core values, because I think simple is great. It's a pretty big framework. So having something simple is great. And I, I, I propose that there are four that you, we could pretty much all agree on that if your enterprise work this way, your leaders work this way, they're the, the, the, um, the teams work this way, you'd be better off and they're alignment. Pretty obvious. Transparency, respect for people, relentless improvement. But guess what? Pains down this regard. Alignment is not a natural state. Alignment happens when people who don't 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, so alignment is not free. When you see executives that aren't aligned, it's because they haven't taken the time to be aligned. We have language for this. We rarely say in our company that we don't agree. We say we're not aligned on that. And that's a big difference. It's 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. Strategy align on strategy, align on execution. Everything you align on is gonna require some help. Transparency is really hard.
I'm growing up as a leader pretty well grown up. Now, I grew up in a kind of different environment. The different environment was a trucking company. I drove a truck, I drove my dad money, said, okay, let's, you know, drive this, drive this truck this far, whatever. You know, he wasn't, there was no transparency in that. There's no why behind that. It said to just do it. And here's the thing. He never asked me to give you an idea how bikers have to evolve. He never asked me. And by the way, how do you feel about that? Okay, that was, that wasn't in his language. Transparency means that you have to be, 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, if every, if you're asking for transparency, transparency from everybody else, and you don't give it, you are just hypo the hypocrite of the day. And people totally get that and totally unknown. Know that. Don't underestimate the knowledge and the insights of the people you work with. They get it. You be transparent. We're not so my backlog's transparent, but oh gosh, it turns out the, the lien portfolio of management, Kanban, that's locked out. I can't get into that. Or yeah, I blew that, but I'm not, I'm not, I'm not person enough to stand up and say, I did that.
Relentless improvement. We don't call it continuous improvement because that's just a boring word, right? Of course, we, of course we evolve, continue. We, we continuously improve. But I've go to an ex executive and your one enterprises and sit down and ask them, do you continue? Do you have a, do you have a value around continuous improvement? They'll say, they'll say, absolutely. And I'll say, well,
Do you improve relentlessly? And they'll say, what do you mean by that? Now I'm 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're doing right now to do relentless improvement and respect for people. Vote right in the Agile manifesto, it's in every, it's in one pillar of every house of lean that's ever been created in including the derivatives of, of dozens. Of dozens of, I've never seen a house of li lean that didn't 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, to, to throw up a, to a total quality, a total, a quality circle if some problem happened, or do a root cause analysis if, if there was an issue on the floor. So respect for people is always there. And we always respect people, right? Well, we don't always.
And when we just, we see it, we recognize it. And I, I left a meeting, I won't tell you <laugh>, which one, just the other day about right in this room where a group said, eh, then the manager walks in and everybody's looking, well, that's not respect for people. A manager probably doesn't deserve respect, or maybe he's got a team that doesn't understand that they need to have empathy from him as well. But it doesn't have to be like that, and it isn't always. So while I've basically been pushing my shoulder against leadership and managers and executives that grew up in Taylorism and various forms of management, and, and I've worked with leaders that were command and control people and servant leaders of leaders of all kinds. I find those leadership styles generally independent of results, because it's the intangibles in how they lead inside that style that really works.
That, but, but we do see it. We see it, we see it here. Uh, just recently at our, at our summit from Southwest Airlines, in the midst of covid, we never had the 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. It people aren't affected. That's leadership, right? That's really respecting people. This we don't know. We're, our revenue went to zero. We're gonna keep our, keep our people on staff until we go down for the count. And it gets a little more, a little deeper over time. Uh, our customer here, Porsche, uh, the VP of engineering said it was bringing the people together, talking very often to them about why we're doing it. The why. You don't have to force them to push them. You have to convince them about the why, why they wanna do it.
They realize then it's okay, it's necessary. And, and it's fun. I love the last, the last quote here at Porsche. It's necessary to have fun, otherwise we won't get that kind of product. <laugh>. Um, they did not give away a Porsche at the summit or anything. Really. Just disappointed with that, but it still still GS me a little bit that they didn't. But, uh, I can't really get out of Porsche anymore anyway. I have to like crawl. This is really hard. Okay? Embracing a lean, agile mindset. What a simple concept. Again, we've 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, I turned teams that were, I was working in kind of the venture capital world I was working. I turned teams that were really not performing to extremely high performing teams with Agile. And by the way, some of those are the same people I had coached at Rational using the rational unified process. Same people, different process, dramatically different, different result. So that tipped me to Agile.
I was lucky. I actually attended the Gold rots seminar on the goal one time when he was talking about my, one of my, my first company. We, we, we, um, basically purchased a small manufacturing operation and then we started to lose money hand over fist. So that started to be a real worry. So at that point, it's like, hmm, I've gotta 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, right? Value streams come from lean. Make no mistake about it. You, you, you can, you can, you can, you can see that here. Well, you could, if I actually pushed the button. You can see that here, that basically simple words we hear now, like precisely specify value by product, project to product. Whoa, 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 <laugh>, okay? Because it is the container and the mental model for organization in a way that whether it's, whether it's matrixed or whether it's kind of line based management, it collects the people that together to do the job that needs to be done, to work together to produce an outstanding outcome. Okay? And there's value delivered by its definition. And if you can't tell what products your services you sell or who your customer is, you can't achieve that. Both, both, both schools of knowledge are extremely deep and extremely rich. There's as many books in our libraries on lean as there are and agile, and they're both incredibly powerful. T d D and xp and agile development and Scrum, and the role of product owner and lean thinking across the enterprise.
So in my mind, growing up like 10, 15 years ago, these all came together and said, well, this is great. These aren't, these aren't, these aren't 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 won't be, they will, they will revert to their specialty skills, their eye skills, their individual silos. You'll work with a designer that says, well, I work in e p s, I'm gonna, I just kind of, just kind of need a sketch in PowerPoint. Well, no, I, I do e p s. Well, well show me early e p s, because I, I wanna see if that thing's really gonna be the image I want. No, it's not done yet. I can't show it to you. And people who that, that you, you heard the experiment about para programming, right? You heard the experiment tear down the wall. So, okay, that's, that's stuff that's hard. Responding to change over, following a plan, easy to say, hard to do.
Even the thinking requires a significant sense of reorganization and figuring out how to do end-to-end value streams. And guess what? There are people in these end-to-end value streams that I don't know, and maybe I didn't get along with. Or maybe there, they're in sales or maybe they're in marketing or maybe I don't know what they do. They're part of the value stream. That's nice thing about the value stream. Construct. All the people, materials and data that you need and information you need is inside the value stream by its definition. If isn't there a crappy value stream you need, you need to add that really, really stresses the company. Some of you have gone down the road through the, uh, value stream and art identification workshop. I'm pretty sure some of you all have done that. Anybody here do that in this building? That's a wake up call. It's like, we're not organized that way. Now, what happened to my fiefdom? What happens to my job description if we organize around value and more, but it shifts the mindset. And 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 and in common. So their shift to value stream thinking brought them to a common alignment. This is the product, this is the service, this is the people we need to do it, et cetera.
And end to end is exactly that. Here's a, here's, here's a, here's a company, Fred IT group that was doing an e-prescription solution and they wanted to develop it and deliver it, and basically incredibly short order time. So they used value stream thinking and agile development to to, to break down their side load teams, get them to work together, built a, built an agile release train focus exactly to that. Had their necessary, had the right business people and the right technical people in, and they pulled it off in the midst of changing requirements. They couldn't do that before. That's what value stream thinking and agile and Lean can do in your organization. We have a set of principles in safe that underline everything we do. And there are many, and I sure can't sure can't tell them here, but there's a lot. So I guess I need to click to find out how many there are. Hope, hope it's gonna stop at 10. They vary from kind of highly technical, assumed variability and preserve options. That's set based design, right? We really coach people for set based design and make sure that, that, that if you have, how many of you have have, have milestones in your life?
We're DevOpsy. We're all agilely, right? Anybody have real milestones? If you're approaching <laugh> real milestones without set based design, you're taking a huge risk because you don't have the degree of freedom you need. You've gotta have some, some sort of, you've gotta have a simpler design option. You've gotta have a buffer in the process or whatever. Set based design is one of 'em. Building incrementally with fast integrated learning cycles. The pains, the pains are, they're kind of abstract. Oh, set based design, uh, 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're empowering them and you wanna decentralize decision making, but they're not yet competent in their role? What do you do then? Keep all the decisions. Give 'em a decision. Watch, make it's tough, right?
Absolutely not easy to do. And the senior leaders don't always find their way there. And if the C and the C minus level, they don't always find their way to that set of principles that really drives the business. 'cause everything else, everything else is, is instantiation. It's a practice that follows the principle. And as Demming said, people say, our problems are different. It says it's a, it's a disease of Western management. That's that our problems are different. He said they're 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 don't understand the principles, we won't be there to talk about it. The word middle management,
It doesn't sound good, does it doesn't have kind of a, oh, middle management. It's almost a pejorative. I mean, we hear not in this building. I didn't hear it. The, the, you know, the, the, the, I won't even use the words there. Guess what? If you are the gentleman that was just here and he's got two or three layers above that says, yes, we can go deep down and dirty with DevOps or whatever, and they wave the flag, or you're a C I O or c i o minus one. You don't control or build the systems that the people work in. Okay? You don't do that. The people build the systems, right? The middle managers are responsible for those systems if we don't reach them. Now, people often ask me, if you're doing a digital transformation, you know, bottom up, top down, neither middle out, reach the people. Now we're probably that, or some of us are C-level people. There's a pretty, pretty robust audience. But 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 'em,
They get the time of, they get the type of results that you see here. DevOpsy kind of results stated in a, a DevOpsy way. And in two years, Southwest Airlines, you kind of remember a couple years ago, anybody remember read about South African Airlines? Remember that Not able to book traffic, why it issues
The same. People stayed and adopted new methods in practice. In our case, they adopted safe. And with the next year, they move from production from prior years. 28 releases, 45%, uh, with quality to 349 releases with 0.93 with 93% quality. That's pretty extraordinary. That's in the year. That shows what DevOps and agile development and the right leadership can accomplish. And, and we see that all the time. We, we, we see leaders step up and, and take, take a course and be certified. Do they have to be certified? Did they put their badge on LinkedIn? No. Why'd they be certified? I wanted to understood. I wanted to, I wanted to be able to demonstrate that I understood the material. One of our, our, our, our friends here, Scott Pru, I talked to him one time about certification and asked him did he think it was important or not? And he said, I think it is because it proves that people learn the material. So learning, getting ahead of the game is great. Most importantly, we have to lead the change. And in order to do that, the pains are best articulated here by the guy at Southwest. I'll read it to you. I will tell you, we don't need an executive sponsor. I'm 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 can't mail it in. They'll not respect it. It will not stick. So we need an executive role model
And we see it, uh, division CI set the tone by, by by, by learning of methods and practices and leading the way. And as I approach the end of the time, one of my heroes, Deming comes back and says, you know, it's 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's one more thing. Gene always asks What I need, I don't need very much. Maybe it's what we all need. Maybe it's even what the world needs. And it's this.
You believe that leading in the digital age requires mindset, values, and principles behind agile and safe, scaled agile and lean thinking and DevOps and flow and systems thinking, that's set. No matter the variant or no matter the, the, the, the label on the system, then for goodness sakes, please lead by example. And I promise you those will follow you. Thank you.