The creator of the Scaled Agile Framework, known to many as SAFe, sits down to discuss what it means to develop and invest in a framework that encourages engineering rigor, predictable and repeatable outcomes, and personal fulfillment.
Dean Leffingwell, a methodologist, author, entrepreneur, shares his life's journey, starting with how Sputnik sparked his passion for space travel, then led him to biomedical engineering and the life of engineering and delivery patterns, frameworks, and ultimately delivering value.
0:00:00.0 M Edwards: My guest today is Dean Leffingwell, a methodologist, author, entrepreneur, and creator of the Scaled Agile Framework, known to many as SAFe. We talk about what it means to develop and invest in a framework that encourages engineering rigor, predictable and repeatable outcomes, and most importantly, personal fulfillment. Join me as Dean takes us through his life's journey, starting with how Sputnik sparked his passion for space travel, thereafter biomedical engineering, and the life of engineering and delivery patterns, frameworks, and ultimately delivering value.
0:00:36.2 D Leffingwell: "My life was a living hell. Everything was painful. I worked all the time. In pager days, I had my pager, now I'm always on the phone." And he said, "Since SAFe, I go home and rest knowing that things are in pretty good shape." What's that worth? That's the kind of thing that gets you up the next day to say, Oh, I think there's more that can be done. Because this guy got his life back, because now there's some routine, there's some rigor, and so some visibility. So he knows where his systems are, he knows how they're performing, and his people know that they're getting the psyche rewards for a job well done. And that's the real purpose behind SAFe, it should be fun to build these systems, they're really cool systems. We shouldn't feel bad about it. Yeah, we make mistakes. So what? But nobody else could build that system that your company just built. It's never been built before.
[music]
0:02:23.2 M Edwards: So, Dean, thank you for taking the time to get together with us and teach us. We appreciate it in advance.
0:02:29.4 D Leffingwell: You're welcome, thanks for having me here.
0:02:31.2 M Edwards: So for fun, I want to learn about you and your journey and the things that have made you smile and maybe some of the things that have made you frown along the way, and how you've evolved, but can you tell us what has motivated you to start the journey of creating something to teach, to enable, to equip people? In other words, at least in my journey, I've been influenced by Rational Unified Process. I've been influenced by lots of things, Agile, and then also including the evolution of Scaled Agile. So those are only some of the things I'm aware of and that I've personally found value in. I'm curious, and I think a lot of us are curious, as to what along your journey made you say, My gosh, somebody needs to do something about this, and I'm the guy that's going to give it a shot?
0:03:19.5 D Leffingwell: It was kind of incremental. And I start out with a stroke of good fortune. I talk to young people, not every day, but every few months or so I meet somebody, and maybe it's a child of a friend or a grandchild of a good friend or whatever, and we talk about what motivates them, and they want to know, Well, how did you do what you do? And I said, I started out lucky, I always wanted to be an engineer. So I kind of harken back as I think more through it more deeply, back to Sputnik days, and I was, I think, nine years old when Sputnik was launched. And it was all over the TV, and it was the arms race, it was the space race, it was new and different. We didn't know what life on this planet would be like in 50 years hence, and we didn't know that we wouldn't also be on other planets. And for me that was so exciting to think about participating in that larger journey of mankind. Now, it looks kind of silly at the time, but we didn't know that we'd still be on one planet, we didn't know necessarily that laws of physics can't even get us to the moon, other than on a rare occasion.
0:04:27.5 D Leffingwell: But at the time, it was like, “Wow, this world can evolve really, really in crazy ways.” So I was a scientist and engineer; all my life I've wanted to be an engineer. I was pretty good at that, I felt really comfortable around quantitative methods, and got really comfortable with the engineering sciences. So through my early career and early development, had a really small town high school, then I went to really good schools. I went to Illinois Institute of Technology, I went to University of Illinois and I got my degree in, you'll be shocked, aerospace engineering, because that's where the people that were designing the rocket ships and the fun things that were going to go up into space. I graduated right at the time when it was post-Moon launch and people were going, well, what do you do now? And who can afford that kind of investment? And the whole space scene kinda collapsed. It was one of those many zenith and nadirs. So that wasn't particularly effective. It's like, Okay, I'm probably not going to work in aerospace engineering. But in my graduate studies, I found a mini-computer in the corner, pretty much literally. It was a Nova 1200 that had been shipped to us. It had no software and nobody knew how to use it.
0:05:40.1 D Leffingwell: There was a manual, I think, but I don't even know if that was the case. And at the time, a part of aeronautical engineering I was interested in was what happens in space to people. It's very good to think about this piece of titanium out there, but what happens to people? And at the time, we were very early in just trying to understand the physiology of space travel. And our machines to do that were all analog computers and big punch cards; I don't even remember how they work but they were awkward as heck. And there was this mini-computer in the corner that nobody knew how to program. So I picked it up and started just self-taught programming, I never took a class in programming other than one Fortran course, and started to use that to do some physiological monitoring. And indeed, co-founder was at least asked to join my first company and we built mini-computers to monitor people's physiology, basically one of the first EKG machines. And that was fascinating and interesting, and I started my first company down that path.
0:06:44.7 D Leffingwell: So the company that I started earliest was Rela Inc., and this is back 40 some years, we did biomedical equipment development. We could put a computer in anything and hardly anybody else could. Well, at the point that I started becoming a programmer, there was this weird juxtaposition in my mind, which is that when I studied aeronautical engineering and physics, everything had a certain logic to it, and the laws of physics predominated. You built a bridge and it stood up or it didn't, right? And you could actually calculate that. You can say, okay, it's going to stand up for these reasons, it can withstand this. So it was very predictive, and that was comfortable for me, I felt like science should have some foundation. And then I was programming computers, and I could make a single bit error and bring the computer to its knees. And we were building systems for people, life-saving systems and life-enhancing and life-extending systems, it's like, how does it work that a programmer can make this machine not work for a person without anybody even seeing the code?
0:07:52.3 D Leffingwell: So there was no physics or engineering in software development. And I think to a certain extent that's really great, because it means that the creative art and the people practice will never leave it, but it's also not super great because we're trying to build an MRI machine or an electrocardiogram system or an infusion pump, it better damn well work and it should do what you want it to do and nothing else.
0:08:17.1 D Leffingwell: So I became interested in software quality really early, as a programmer. It's like, This is going to go on a person. I've done my best job, but am I going to make a mistake that kills people? And so I started migrating to really the study of software engineering practices, and early texts I've still kept, software engineering handbooks, and started to think about what kind of rigor you could add to this creative process? Because it was clear the future was all bits and bytes. The digital age was obvious for me 30 or 40 years ago. But there's no laws, no laws of physics, and you could do anything and that was incredibly creative, and scary as heck. How do you know you have it right? So, well, does it perform to the requirements? Well, what are the requirements? Well, we really need to write those down, because this infusion pump can't run away and it's going to have different viscosity. So I migrated to the kind of the front end, because if you could get the requirements right enough, then you could build a medical system that worked. And that was waterfall-based, I make no apologies for it. Waterfall, God is here.
0:09:29.0 D Leffingwell: So we were really rigorous. And I remember we had kind of process flow charts that were very waterfall-driven, that we actually sold to our clients. Said, We're not going to write any code before it's time. We're not going to design an arbitrary system, we're going to spend the time upfront to get the requirements right. And we look at all that kind of now as a bit silly, but yet every system conforms us to its requirements whether you know them or not. So the discipline at the time was very waterfall-driven, and I spent probably a good 10 or 15 years writing about it. OO (Object Oriented Testing) came along, and that started to change things a little bit, because it started to change the way in which we thought about the software. We started thinking about modeling the actual dynamic system. And then all of a sudden this rigidity of the fully prescriptive nature didn't fit as well. I was trying to model the dynamics of this system... I remember Mike Devlin on stage saying, "When did we get the arrogance to believe that we can invent this new world class system in one swoop?” I mean, who does that, that's just...
0:10:36.6 D Leffingwell: And you look backwards, you go, That's kind of a stupid plan, is we'll figure everything out up front, we'll write a bunch of code and it will work. And that led us to iterative and incremental development, and RUP which is now old-fashioned like waterfall and easy to criticize. It's like, Yeah, well, turboprops aren't very cool when you're looking at a jet next to it. But the reality is that was the technology at the time, and it was the first codified model that says, We're going to take multiple whacks at this. Now, there were big iterations. They were four and six weeks, and because the constructs that we had around its inception, elaboration and construction, transition seemed sequential. The reality is it was interpreted as a waterfall overlay on a series of iterations, so there were like elaboration iterations. Okay, we now look backwards at that and say, Well, we could do more than liberation and iteration, but that was the first structure codified, and frankly promoted to the extent of being useful. At Rational, what I learned was to how to develop what I think really is the crux of the sign of the IP, the science inside our work, which is heavily peer-reviewed work by knowledgeable experts.
0:11:50.4 D Leffingwell: And I had the unique fortune of, not managing Grady, Jim and Ivar, because they're not manageable, and they would tell you the same, but they were in my department's budget. [chuckle] And what I did was I observed how they worked and thought and frankly argued, and how they came to conclusions like what the shape of a cloud would be. And once that decision was made, they moved on. Now, in the Booch method, an object was... Shape of a cloud, sorry. In the Booch method, the object was in the shape of a cloud, it was kind of cool. But in OMT it was a rectangle. Well, they picked a rectangle. And those decisions were critical decisions, but they made them and they moved on. And then when they decided that that's what we're going to do, then three people said, I'm going to represent an object using this icon, now I can think about modeling. So I saw them do that work, and when I joined Rational, very smart company, very proud of my time there and the people there, John Love at the VP of Field Sales came to me at literally the celebration party of acquisition and said, Well, what do you want to do now? And I looked at him like as a trick question, and I said, What do you mean, don't you want me to run my old business inside Rational?
0:13:11.3 D Leffingwell: And he kind of smirked a little bit and he said, "Dude, we're pretty sure you don't want to do that." [chuckle] And he was right. I mean, the last thing I thought was my next ambition would be to run my same old business in a larger company. And I said, "I find really interesting this intersection of modeling, Objectory and tooling, and I think there are some amazing potential software engineering disciplines in there that could really improve outcomes, and I want to do that." And they said, "Okay, you got it." So I picked up what at the time was Objectory, the UML team helped promulgate that, started merging the two so that the UML knew about the process model and the process model knew about modeling, and 4+1 views, okay, you could have 71 views of architecture; 4+1 was memorable. So I saw how they created an IP stack, and because I also ran Rational University was responsible for where we turned those ideas into courses. So the root of what we're doing at Scaled Agile right now is a business model of this as, if you can get a group of like-minded independent thinkers to agree on a concept and peer review that heavily...
0:14:24.0 D Leffingwell: There's a strong probability there's really good IP in there. And that if you can promote that and promulgate that, people will use it. The neat thing about that part at that point, I'd been through a couple of businesses, started two or three, had seen methods and practice evolve, and there was this Agile Manifesto out there which was kind of... You could smirk at that, too. Yeah, we don't need your stinking requirements, and it's the home of Dilbert. But I was completely free of any corporate trappings. So I met you about then, Matthew, because you were running one of the sharpest XP shops. I remember it well, at the time, and I remember the instrumentation that you had. I remember the big daily stand-ups, I don't know if you do, but you'd have 20 or 30 person in the daily stand-up. So we didn't have... You didn't have the notion of the scrum team, but you understood XP. I migrated to it, and here's why. Because it's, A, it's more fun, and, B, it produces better quality code. But I never lost my zest for highly reliable code. So I met people like you. I met a guy by the name of Dave Muirhead, who taught me a little bit of XP. He wrote some code, I pretended like I was peer programming, in reality I was just watching him code. And then he'd stop and put some more code together. What's that? And he goes, Well, that's a test for the code.
0:15:40.7 D Leffingwell: And I said, Well, why are you writing a test for the code you wrote, don't you think it works? And he goes, "I know it doesn't work, I just wrote it, how can it possibly work? I know it doesn't work. And I'm... Before I'm going to take accept responsibility," and those were his words, "for this story," that was the vernacular of XP, "I'm going to make sure it works before I put it in the baseline." And for me that clicked as a discipline, and said, Wow, this is not... This is not some really lightweight, we don't need no stinking requirements, I'm going to code what I want and hope my boss loves it. This is the most seriously disciplined, high quality craftsmanship being applied to development. So all of a sudden waterfall and RUP looked old and stale, Agile was king. I got the good fortune to meet you and lots of folks like you, we've stayed in touch over the years, lots of mentors, and then I started trying it. Now at the time, I was kind of an investor and advisor in about a half a dozen software companies in Colorado. And that was convenient because Rational was a pretty tough road warrior gig, and my kids had grown up with me on the road a lot, so I got to stay home.
0:16:50.7 D Leffingwell: And then I just became an Agile coach like you. I did the same thing you did. And I started seeing the difference it would make, even in RUP shops. It would be, in six or eight weeks you could change the culture, the attitude and the results with Agile. Agile was like an order of magnitude, better instantly. And for me, as a student of these things, it's like, Wow, look at that. I'm sure your experience as well, it doesn't have to be a monologue here. I mean, we met up at probably about that same junction of our careers.
0:17:22.8 M Edwards: Sure, Oh, I can tell you, what I really loved was the idea of order. Like a predictable, repeatable opportunity to understand why. So if someone said, Go do this, and then I go do these things and I get this result, I can understand why. Whereas without that, it was often times heroic, where you have people who get out of bed with varying levels of energy, or they have variable things going on in life which impacts their contribution for the day, and why isn't always immediately observable. So I loved RUP because it gave me an opportunity to understand the value of a framework, or a value of a thought paradigm. I remember going to the classes, I remember cherishing the books. I know it sounds a little silly, but I got the books, I read the books, I loved the books, and I tried to figure out how to add value using those ideas. My evolution from there was really what I came to understand was patterns matter, but discipline matters, and the easiest way to eliminate waste from anything is transparency. So my evolution from RUP into what was eventually these behavioral practices that we generically call Agile, the Agile Manifesto, what I loved about that transition and especially when we got into extreme programming, was it stripped everything down. So what did not change was patterns.
0:19:04.0 M Edwards: Patterns must exist. A healthy heart has a predictable, repeatable heart rate. An unhealthy heart has an erratic heartbeat. Similarly moving from RUP, which enabled a healthy heartbeat, to XP, which also enabled a healthy heartbeat... To your point, was a giant transition, as if on steroids, because it stripped everything down to, "We're all standing here in this circle talking about this thing, and either you know what the thing is or you don't. Either you committed or you didn't. Either it worked or it didn't." It just stripped us all down almost... To embarrassingly transparent with each other, like, "Oh my gosh, my code actually sucks," or, "Oh my gosh, I worked really, really hard today and delivered nothing, but I gained lots of knowledge." I loved the transition to XP, but what transcended RUP to XP for me was the value of patterns, discipline, and transparency, and those three things are what I found amplified a high-performing team.
0:20:13.6 D Leffingwell: I remember in your shop, we've talked about the benefits of transparency and discipline and patterns. But you know what? Creating big solutions that work is really fun, right? So the engineer in us and the kid in us that says, "This should work, and that's really fun." And it doesn't mean it isn't hard, but hard and fun have a correlation when you're getting results. So when the outcomes improve with Agile, it's more fun. We grew up in systems where it was easier to write code that didn't work, to be discovered later, than it was to change the requirements. That's not fun, right? That's like, you know you're wasting your time, and you go home at night feeling bad. But you shouldn't have really do that with Agile. I mean, there are constraints, and life is imperfect, but wow, if this doesn't make sense, you're not going to do it in Agile. If the PO says, "Let's do this." And the team goes, "That makes no sense." The team's going to be listened to, and it has a innate empowering element that I think unlocks the intrinsic motion... Motivation of why we do what we do. I have an avatar that's a little kid with a colander on his head and some tentacles sticking out of it.
0:21:25.9 D Leffingwell: I'm still that kid. That kid wants to have fun, and I will tell you with Waterfall and RUP, in both cases, they were helpful and rigorous, but I don't remember the fun. And when I got into shops like, "Here's where you guys had a pig in a poke," there, using an idiom, right? [chuckle] Handed this big blob... It was still fun to make progress against that, and to know you're making progress in a predictive way. So a sense of order and the ability to have more fun... And when I saw that fun and discipline go together, well, that was new. I don't remember that part before. It seemed like discipline was the opposite of fun always, and fun was the opposite of discipline. Well, it's not the case in Agile. So when you and I met up, I was doing some consulting and finding shops like yours and trying to figure out what was working, listening more than talking. Now, I had enough experience that I got paid to talk, too, but that just got me in the field to listen to people like you that were well advanced in your thinking, where I was...
0:22:26.2 D Leffingwell: But I started then applying basically this Agile method at scale. And because I wasn't accountable to anybody anymore... There was no brand on my shirt other than what I believe to be true that day. Basically, I stripped down to XP, and I tried it in a couple of shops, just pure XP. And guess what? It didn't work. It didn't scale. It lacked the architectural patterns. It lacked the coordination and the cooperation. It lacked the fact that if you're building a system, the system's behavior is more than the sum of its components. It's to how those components interact. And if you don't care about those interactions, you're going to create a system that's basically crap. So scaling Agile a team at a time didn't really work. And we had issues with alignment... Why we're building, what we're building. We had issues with architecture. So little by little, I started adding the things in, not to kill Agile, but to say, "Look, we need to architectural governance over the system. There's 400 people building this system, and it's monitoring a huge distributed network that's basically mission-critical. We gotta talk about this, and we need to work it out."
0:23:43.4 D Leffingwell: So through that process, then, I wrote my second book... Well, in the Agile space, called Agile Software Requirements. And the reality is that book is really called Scaling Software Agility Now Actually Working, but that title wasn't any good. So it has requirements bent. It's not a requirements book. It's a book about how to build a really big system using Agile, and that was readable enough and knowledgeable enough that I started getting invitations to big companies. Companies like Nokia Corporation and Computer Associates, DB Tools Group, and they said, "Can you help us scale Agile?" I said, "I'll sure try." I said, "I've written what I know, but we're learning every day." And then in 2010 or so, I was at an Agile Alliance Meeting, and four or five people that I knew and had worked with kind of interactively said, "Can we meet?" And I said, "Yes," and they said, "We'd like to start a company." I said, "I'm not starting any more companies. I've started my last one. My last one was one too many, and I don't want to do it." And they said, "But there's... But I think we can help the industry here. I think that you've got in this book and in your mind and in our minds a way to commercialize this," to use the crass term. "And to frankly help more people and build a big business." So I threw in the towel. I said, "Well, I don't want to start the company. You guys start the company. I'll license my IP."
0:25:10.1 D Leffingwell: And then down the road, of course, the founders have their inevitable ways of trying to figure out what's going to work, and then I rolled my IP in the Scaled Agile. And that was only 2014. So the reality is, as a business... a combined business, we're just seven years old. But what we discovered is that those books don't stand alone, and even we can't consult enough, and the reality is, is a change of this type has to happen by the people doing the work. And what people are not shy about is they will invest in themselves. So we started to understand the training, like the stuff that you took with OO and the stuff in Agile, was a way to monetize and grow the business. So one of our guys built a website. I built the courses. Another founder went to some early partners and said, "Could you work with this and do service delivery?" Because we were of such a belief that scaled Agile is going to change everything. And it did. And we knew that what could 10 people do in Boulder, or even a 100, or even a thousand, and we said, "We don't want to be restricted to that. So let's just focus on the IP and initially training."
0:26:30.1 D Leffingwell: Now, we're much broader than that now. We have a complete operating system that people run. It's kind of like Toyota production system. You don't learn it. You run it. So we've moved on in our thinking, but the training franchise has been super powerful for us, and the training was a cash flow we needed to grow and scale. And then as we got successful, the larger partners... the C-Primes in Accenture who initially thought, "Who are you guys? Why would we follow you?" Well, their customers were following us, and their customers were saying, "We want to work this way. We like this body of knowledge. So if you want to support us, please work this way." So then over time, we grew the partner network. So the partners do all the service delivery and that means that we're a highly leveraged model. We're not as big as some people think, but we have a really big impact, and at the last summit we announced one success story, which is over a million people have taken our classes, and that's basically... And it's not even the seven years. That's in the last five. So I didn't predict that success. I just believed that it was a better way of working, and then I believed that if people find a better way to build the world's most important systems and they're digital...
0:27:40.3 D Leffingwell: There's going to be some value in that. And it turns out there has been value in that, and we talk about what we do through our case studies, but I'll also tell you there's hardly a day goes by at work that somebody doesn't lobby in an email or something in our internal Slack newsletter that says, "This big pharmaceutical company that isn't talking about SAFe just did this with SAFe," or more public companies and more public entities like the FBI criminal justice information system says, "We're using SAFe and we want to talk about it, 'cause we think it's important." And we get such incredible rewards from that that... You know, you talk about ups and downs... Running a business... I was a CEO up until two years ago. It's not easy, and your work every day isn't easy. Stuff happens, right? Not everything you do at work is fun. But if the work you're doing is meaningful and creates the big F, then you can suffer through the small Fs. Whatever they have... The restructurings or... My case, too much debt early in life for the companies. You suffer through those because you're on the right mission. So I found about five or six companies, depending how you count them, all but one were doing exactly the same thing.
0:28:54.7 D Leffingwell: How can we help people, mostly people building the world's most important systems, do a better job? Because when they do a better job, they're happier, and when they're happier, they do a better job, and then they're again happier. There was this virtuous cycle, and I will credit Agile, is certainly the name of the game today. I know some people... I remember one company that said, "You can help us, but do not use the word Agile here." I mean, it's not a pure play, if you will, but Agile unlocked that in a way that, in the course of my career, nothing else did. So when I talk about Agile, I teach classes, I start with the manifesto, and some of those guys aren't fans of me because of the way we've scaled Agile. They think that maybe... Maybe they have different paradigms. I won't even guess what their view is.
0:29:41.4 D Leffingwell: But the large enterprises that have 1,000, 10,000 people. Places like the Air Force, Portia Corporation. I'm just making sure I'm talking about ones that are published case studies – Global TV in Brazil, People, MetLife – those are the companies that have found a way to us, and from a business model perspective, it's kind of cool when the stuff that you provide is most appreciated by really large enterprises. There's more people there. So that's another thing you couldn't really plan, which is that we've created a model for scale, and mostly the big enterprises are the one to scale, so that kind of brings us to the current state, which is that the other thing. We do not suffer from the arrogance of our own ideology.
0:30:32.0 D Leffingwell: I look back at Version 1 and 2 and 3 of the big picture. I can hardly look at it, and I know right now in version 5.1, I know it's... Not exactly, but I have a whole set of things we want to do different. So we started revving the framework really frequently, and I remembered about version 3, somebody came along and says, "This was like the smartest thing you've done, revving the framework," and to me, it was like, "Well, how could I not do that? How would we pick a model that worked in 2009 and see it applies in 2021?" So we've been able to put together a team of people... Mostly they recruited us or me, the people on my team found our company and said, "You're doing what I want to do," and we have the larger group of SAFe fellows out there that are good agents and add value. We always go to them first. Also the SPC trainers, we have about 100 of those. These are our peeps. They're our customers, and they're filled with good ideas. So when we go to make a change now, it's brutally abused by every opinion out there, and then we integrate and we decide, and we pick a thing that's never perfect, but it's better than it was before and continue to evolve.
0:31:47.3 D Leffingwell: Sitting here today, we're just filled with ideas. There was a little debate in Slack this morning about... It's not quite the right label for that, because that's not the sentiment anymore. Okay, how hard's it going to be to change a label that appears in 1000 pages of coursework? Really hard. Okay. Let's get over it. Let's go on. Let's go on from there. So that kind of brings us to the current state and our continuation of essentially the same business model, the same strategy, which is, "When will the world not need really, really more and more capable digital systems?"
0:32:27.6 D Leffingwell: I don't know. I can't imagine that time. When it is, then if that happens, I'll definitely be obsolete. But in the meantime, we're good to go, because the problem has always remained ahead of us. Now the Air Force talked about their big program, and it's a big material program for our nation. There's 10,000 people engaged. Well, some might say, "Well, de-scale that." Well, you try to de-scale that. There are seven vendors. There's a huge supply chain. There's a legacy of 10 million lines of code. I'm not going to solve that problem with two pizza teams. This is the problem we're given, and this is a problem we need to address, and that takes a system of scale, and that takes big patterns, and it takes patterns from the team level to which... You know, I'm on an Agile team. We think often about our practices. We run retros. We don't run them every two weeks, that's... Honestly, I think that's silly.
0:33:18.1 D Leffingwell: But every quarter we say, "What did we learn that we could change?" That's part of the basic Agile, but that goes all the way up to the portfolio level, where the portfolio teams in our organization and others now, every couple of weeks, look at the backlog, and say, "Are we making the right investment?" So that Agility now scales from the individual team level all the way to larger enterprise, and recently we have this... It's called Portfolio. Portfolio's an enterprise portfolio because they're really big companies with a common way of working, and they discovered that the things they want to do next cross multiple value streams. If you're in the business of making vehicles, that's an entire ecosystem. That's not constrained to the ABS system. So these cross-cutting concerns are also challenging and very difficult because we have to impose those cross-cutting concerns. Some are safety-related, or, let's say, GDPR. Nobody wakes up and says, "I really want a day today to spend all my time figuring out how to make sure that we can support the right to be forgotten." That's actually a ton of work. But that comes with the territory, and therefore we have to scale to make sure that the large enterprises that have these challenges can find comfort in our set of patterns and know that we're not resting.
0:34:31.2 D Leffingwell: And initially, I think there were years where it's like, "You guys changed the framework again? What. You're killing me." But lately when I interview our key stakeholders, they go, "Well, that's what you do, and that's what we do is we evolve with you." So we've lost the notion that there's an answer. And we've found the notion that there's a Best Current answer, and I like to make jokes about SAFe Version 8, because I say it's going to be a pill. You're going to take a pill, and every developer write the test first, and every leader will be an empowering decentralized decision-maker. Well, prior to the pill, there's a lot more we have to put into SAFe, and that's what the team and the whole company is dedicated to doing.
0:35:13.2 M Edwards: Well, it actually makes sense that it's a versioned, living, evolutionary idea, because everything else that we're talking about is versioned and evolutionary and always changing. So it would be, sadly, ironic if the behavioral framework that we're using to build a system that's a living, changing system itself doesn't ever change. So I love the fact that it's versioned and changing. I love the fact that you guys are doing retros and challenging ourselves, and it sounds like you're saying, "Hey, this made sense yesterday. Does it still make sense today? And what do we need to change?" And the fact that you're not gold plating or worshipping your own product is actually outstanding, and is why you'll continue to see how to add value. That's wonderful. I have loved watching the evolution of SAFe. I have also enjoyed hearing all types of commentary from different sides, whatever, dodecagon, you pick whatever the shape is, but so many different views.
0:36:15.6 D Leffingwell: I enjoy it, too. [chuckle]
0:36:19.9 M Edwards: I can tell you this. I have been the CEO of this company now... It'll be five years in January. And I've done a lot of different things in my career, a lot of privileges I've had to work with awesome people at awesome companies, and so on, all privileges. All growing opportunities, and sometimes joy, sometimes not so much joy, and mixes in between. But I can tell you, in my consulting career, I had opinions and thoughts that I communicated sometimes in consulting engagements about how a CEO or the C-Suite should do their job. And you know what's changed now that I'm a CEO and part of a C-suite is some of the things that I said before were logical and deductive and reasonable, and also not sitting in the trench of warfare and not standing in the mud. So I could make health observations and organizational change recommendations, and I could facilitate and foster and encourage and enable change, but that's different than being the CEO sitting in the chair.
0:37:31.7 M Edwards: And so what I've realized through time... And it's interesting how I can continue to age and still discover I don't know as much as I thought I did. But in these last five years, I've discovered that I don't actually know as much about being a CEO as I thought I did, and similarly about software, I've discovered that technologies continue to change. Perspectives on how to build something useful changes. The frameworks I have found to not always exist, and if they do, they're static, for example. So all of this talk to just say, one, I realize that there are variable opinions on things, but you know what? There are opinions on XP. There are opinions on Crystal, opinions on Scrum, Enterprise Scrum. There are lots of opinions, but to try and build a product or a solution that is actually useful is its own endeavor. Now to try and build a system or an ecosystem at scale is an additional complexity.
0:38:41.0 M Edwards: And so what I like about what you've done, is you haven't said, these other ideas, those are bad ideas. That's not what I've heard from you and I've known you for quite a while, that's never what I've heard from you. What I've heard from you is, I get that, I like that, now how do I scale it? And that's why I like the evolution of SAFe. Now you have other conversations, right? How is it implemented? How is it being used? How are they evolving? What's the general health of the culture that's using it? What's the health of the products and services that are being used? There's just so many different views. But a question for you on that is, in this journey you've created something with the desire, not alone, not in a vacuum, but you've been a creator of something with the intent of enabling and equipping people; is there anything in particular that you would recommend to folks that haven't considered SAFe? For example, Hey, here's what SAFe is, here's why SAFe is created, here's how we have envisioned that it's utilized as an enabler, but in order for you to find the most value in this idea, you really need to understand these fundamental ideas first, or else you're never going to get the value of the entire SAFe framework, for example.
0:40:04.2 D Leffingwell: And I think our best shot at that is the principles in SAFe. And we didn't actually start with that, to be honest, we were probably at version four or so before a few of us said, No, wait, there's some really common underlying principles here. And we spent some time and we drafted nine, and that became 10, and I remember the discussion with marketing, because when we added... How do you add a principle? Did you get it wrong? Well, we missed one. Okay. Well, what about all these cups that we have with the nine principles on it? Explaining really complex things simply is a gift, and I honestly don't know if I have it. When I look at the framework, I can look at it two ways. It's a gift to reduce it to a page, and it should be a gift that it says I can't explain it even further. But I have trouble explaining it either, I can't distill it down further. It's time to market and employee benefits, those are the why, but can you describe SAFe more simply? I struggle with that. Because at a point where we decided it's eight and a half by eleven, that's what you get, everything else is behind the scenes. So I don't know if SAFe is overly simplified for the problem domain, or it's too complex, I can't tell.
0:41:12.8 D Leffingwell: What I can tell is people seem with enough effort to be able to get it and make it work.
0:41:16.8 M Edwards: Well, there's the latitude in there to think. And so for the environments and cultures that actually enable people the opportunity to evaluate and think and decide, in my opinion, you're able to take the frame... Just say you take the eight and a half by eleven and look at the picture? I believe that it leads you down the path to say, Well, what is that? Why is that there? But the other interesting thing about people in general is, lots of people, in my opinion, me included, and in particular, things make sense to me when I have a need to understand it. But until I have a need to understand it, it's fuzz. And so you can look at that eight and a half by eleven and not know why you care yet.
0:42:02.1 D Leffingwell: There's probably another bias that I'll share here in this audience that I don't call it specifically very often, is my first company basically did R&D for hire. And that's not a recommended business model, okay? [chuckle] Because your customers want fixed, known certain things, and yet you're inventing. And you can't just say, “Well, we'll invent and it's going to take a while or it's not and you can pay us whatever cost.” You can't really do that. So, at the same time when we were structured in these waterfall situations, and even non-waterfall situations I ran into just the other day, where there's a big SAFe shop that's really struggling, and the reason they're struggling is they are so over-scoped that they just don't have permission to say no. So their PIs are way overloaded and they're really, really struggling. And frankly, after 20 years of developing some really cool stuff, and going home as a CEO and as a developer feeling kind of beat up, I started saying, This just doesn't seem fair. Nobody else could build that infusion pump or that adventure ride; why do we feel bad? We're being abused for the defects and the overruns. It's like, This is one of the world's coolest systems, it's brand new.
0:43:18.8 D Leffingwell: It's basically a beta for a brand new thing. And that again came back to my motivation, that says, We as a development community, be a little bit personal, when we build these good systems it should feel great. [chuckle] And you should go, Wow, that was really cool. Are there issues? Absolutely. And did we miss some things? For sure, but it shouldn't be constant beating about the head and shoulders because you couldn't invent FOO in one year. We gave you a year to invent FOO and it took you a year and a half. Okay. We're mad. Sue me. [chuckle] There was never a FOO until we created it. So my innate empathy is with people in the trenches who have this intrinsic motivation to create great work, whose systems and processes prevent them from doing that, and who end up knowing, no matter what I do, it won't be enough. And at this shipment we're going to take a beating. And they're not even admitting to the board, or we're not telling the customer. We can't tell our government client that this dog isn't hunting. That's just not right. I don't think that's the right way to treat the human capital. And it's not that we're special...
0:44:32.1 D Leffingwell: We are kind of special, we know how to code, that's good. It's that every human being deserves to be fulfilled. And when we pick a discipline like this that can create great systems, that should be fulfilling too. And when it isn't, that just seems like a crime against technology and nature. So I spent my career just trying to improve that a little bit. And I think on the point now where we see in the results people saying, We couldn't have done this without SAFe. And it's like we used to... I remember one recent vignette, not public, that just came in on the Slack channel, that said, "I'm basically a CIO," or VP of Dev, I don't remember, "My life was a living hell. Everything was painful, I worked all the time. In pager days I had my pager, now I'm always on the phone." And he said, "Since SAFe, I go home and rest knowing that things are in pretty good shape." What's that worth? That's a kind of thing that gets you up the next day to say, Oh, I think there's more that can be done. Because this guy got his life back, because now there's some routine or some rigor, and so some visibility. So he knows where his systems are, he knows how they're performing, and his people know that they're getting the psychic rewards for a job well done. And that's the real purpose behind SAFe, is it should be fine to build these systems.
0:45:52.3 D Leffingwell: They're really cool systems. We shouldn't feel bad about it. Yeah, we make mistakes. So what? But nobody else can build that system that your company just built. It's never been built before.
0:46:02.1 M Edwards: Right on. Well then, how about this. Closing us out. Across your journey, and pick whatever parts make sense or where it makes sense, thematically, I mean, are there some things that you have learned that you would share? And when I say learn, I'm saying in the context of you're a gent that started out desiring physics and engineering and learning programming or development, and saying, I like to understand this framework, this structure; if I do this, then this. Your journey has led you to say, Hey, I want to figure out not only to how to have a predictable repeatable, but this should stinking be fun. Like, I would like to enjoy the sunshine and the joy of the day and like people and work with people. So you have tried to figure out how to bring engineering rigor, or at least the opportunity for engineering rigor, to the software development space. At the same time trying to enable opportunities for people to learn and grow and change and experience fulfillment, to your point, suggesting that everyone desires or deserves to be fulfilled along the way. What would you recommend to folks that are just starting their technology journeys?
0:47:24.1 D Leffingwell: Well, a couple of things. Number one, you gotta be distinctively good at something. Now, one could argue that the framework is very broad and it's not particularly deep in any area. And that's probably true. I mean, there's more written on XP than there is in words in SAFe. But I'm a fan of distinctive competence. I don't believe that, on average, people hire people that are smarter than other people. And when companies sit around and say, We're better than them because we're smarter than them, I don't believe it. And I ask a slightly different question and say, How are you different from them? Because you can always be different. And in the differences, that's where the distinctive competency can grow and foster and creates the differentiation you need to succeed in the market. So be good at something and find the thing that you can be good at as a company or as an individual and get really good at that. And then secondly, I think the biggest challenge in my life and personal life and the things I remember, are my mistakes. And I remember them vividly. It's annoying how vivid the mistakes are. And they're mostly times when I didn't conduct myself in a way that I would think any natural leader really should.
0:48:36.7 D Leffingwell: And I have this tough border line between passion, enthusiasm and drive, and being supportive of mistakes and errors and things that don't go well. And I've navigated that well sometimes, sometimes I haven't. So I remember six or eight times where I absolutely either killed the messenger or I berated someone who was doing absolutely their best job. And I just wish to heck I hadn't done that. And I kind of remind myself as I go forward to keep the passion and the emotion and the enthusiasm, but to never go too far the other side, that dark side of the really... You gotta be tough to succeed in business, but you don't ever have to be difficult. And I don't think that anybody would ever described me as being mean, but, for sure, some people would say, Yeah, he can be difficult. I'd rather be less difficult, so long as it doesn't compromise the ability to gain consensus and agreement around the things that really matter. So that's the personal side. The business side, be really great at something. If you're better, and you can always find a thing that you can be better at. And when you are, you're going to have special value, and that special value, that's the leverage, that's the multiplier.
0:49:58.6 M Edwards: And, Dean, I know that across your journey, discussing the things that you've learned and the things that you've done, and the highlights and the low lights along the way, that there's absolutely no way that we can understand value, and honor all of that in just a 60-minute amount of time together. But thank you for taking the time to just talk to us today and teach us and just share with us a little bit about your journey and what you've sought to be and become and do, and how you've worked to improve, because this is another teachable moment. So thank you.
0:50:36.9 D Leffingwell: Thank you for having that cool XP shop that I learned so much from.
[chuckle]
0:50:44.9: The Long Way Around The Barn is brought to you by Trility Consulting, where M Edwards serves as the CEO and president. If you need to find a more simple, reliable path to achieve your desired outcomes, visit Trility.io.
0:51:01.7 M Edwards: To my listeners, thank you for staying with us. I hope you are able to take what you heard today and apply it in your context, so that you're able to realize the predictable, repeatable outcomes you desire for you, your teams, company and clients. Thank you.
Read more articles from Trility’s team.
Read summaries about projects Trility has delivered.
