Dean Leffingwell

 TRANSCRIPT: 

Speaker: Miljan Bajic  00:40

Who is Dean Leffingwell? 

Speaker: Dean Leffingwell  00:42

So I keep some pictures of some of my keynote talks with a picture of a 10 year old with a colander on his head and a bunch of wires and goggles on like some kid aerospace engineer, that’s me, I still think of myself in that persona. When I was 10 years old, I remember sitting in my living room and seeing Sputnik on the TV. And I thought, wow, that space, that science, that’s off outside of the earth and not necessarily. And by the way, it’s really scary, those are the Cold War days. So I decided at that point, I was going to be an engineer. So I think of myself as an engineer, a systems engineer, first and foremost as a software and as an entrepreneur second. And then of course, you know, my major pride in life is being a parent, I’ve got four daughters and five grandchildren and I just got back from spending a week with them. So I’m a combination of those things. But from a business standpoint, I’m a systems thinker, I’m an engineer, I love software. I love the art of it. But I also missed as I entered the field, the engineering of it. When you study aerospace engineering and I did and biomedical engineering, there are laws of physics that apply and you come to depend on them. So when you build really big bridges, you know what the statics and the dynamics of that bridge is. And when I entered the software field, it was it was kind of pure art. And that’s a fascinating thing, because it still is pure art and science. So my goal has been to add engineering discipline to make better reliability and efficacy. Kind of grew up in the medical business, writing software for medical systems and helping others write it, making sure they’re safe, and yet leave the fun and the art in it. And honestly, I think that’s a paradigm for why I like agile so much. It’s fun to be on an agile team, there’s an art in it but there’s also a discipline process. And a lot of people you know, who are not familiar with the industry look at agile as we don’t need your stinking requirements, we’ll write what you want. We know that’s not true. We know that actually to create good working software in a time box is an extremely disciplined endeavor. I like structure. I like thinking and structure. But I like the greater freedom that comes with being part of an agile team. I like the creativity of software. So I started out as a developer, I wasn’t that great at it, moved into management within a few short years, I started my first company when I was 27 and you know, some, you know, some 40 something years later, I look back and say what a lot of careers in there but they all had software in them.

Speaker: Miljan Bajic  03:16

Great. That is, you know, and I spoke with the Dave West, I spoke with Debeed and some other people that you had huge influence on and they had nothing but just great stuff to say about you. And maybe when you reflect on those 40 plus years and you’re dating yourself here as you know Dean…

Speaker: Dean Leffingwell  03:37

Absolutely. Look, I have Froggy voice today so everybody will know already that I’m not 35 years old, so.

Speaker: Miljan Bajic  03:46

So what do you think of the current state of agile and agility? And what have you learned and maybe where do you think things are shifting? What do you think on that? 

Speaker: Dean Leffingwell  03:59

Well, obviously for me, the big shift is agile just for small teams in a small company or can people at Raytheon or Capital One or AT&T or CVS Aetna, people working in very rigorous environments, people at the Air Force, is it not for them because it’s so loose and free? And what do you if the challenge you’re facing can’t be solved by two one piece of teams? Well, that’s really the challenge. And I got into agile because it was the next best method that I found. But I found within months that it didn’t scale. I coached some small entrepreneurial teams and one of my between career hiatuses that was incredibly powerful. I remember one team in particular, that was iterative and incremental and yet they really weren’t agile, and within literally six or eight weeks, they were on a different game. We were delivering value incrementally, the board goes, what did you do to those guys? Did you fire them all, hire them all? All I did was coach them in agile methods because I think the intrinsic motivation to do good work lives in every developer and the structures that we’ve imposed were the best structures we had at the time, like waterfall. I mean, it’s so fun to waterfall now, right? That’s just a blast. So we should go ahead and write the code without understanding what the requirements are. Or I know, let’s write the test first for a piece of code where I don’t even what I’m supposed to be building. So the reality is there’s a logic in waterfall, it’s very logical, and it just doesn’t work at scale and it doesn’t work at the velocity we need. So I’ve been a follower of those methods throughout my career, certainly wrote about waterfall. I mean, I wrote many words on requirements books that were people followed and followed today. So where we’re at, I think is that, you know, 10 years or so after we started this company, we’re at a state where now scaling agile is a known thing. It might be argued by maybe a fringe case that you shouldn’t scale agile, you scale XP, no, but you’re gonna have lots of XP teams. And they’re probably going to need to operate within the context of an architecture. So we’re at a place now where probably most of the global 2000 enterprises, whether it be IT or tech or not, are using agile, either as the branded method, or Scrum of scrums, or just as being really good DevOps teams that can shoot stuff out the door really quickly. However, we’re also in a state where the interesting thing that’s fascinating about my career, and yours as well is the problem is always bigger next. Every time we come up with a new tool, we build bigger systems. So there was a time when the space shuttle was huge, and the first satellite had a few 1000 bytes in it. Well, now cars have 100 billion lines of code. So we have this, we now have systems to thank, right? AI is a real thing. We use it every day. We don’t necessarily talk about it, but you can’t get in your iPhone without it. You certainly can’t, you know, you certainly get our recommendations based upon it. And so the industry is driven by systems. I like to think that my mission and the company’s mission, this is not on our website, but it’s what I believe, is we help people build the world’s most important systems. So the state of Agile is certainly more advanced, I’ve combined it with lean, because I needed that that body of knowledge to extend agile, and that’s relatively mature. And I think a lot of those thought leaders Dave West and Pete Barons and that person would say, you know, we know a ton. So the problem is not that we don’t know what we need to do now, the problem is execution, culture, mindset, you know, getting everyone in alignment to the method and the practice common taxonomy, etc. So we have more than enough in our arsenal. Safe is a is a big framework and that’s because people build really big systems with it. But it also scales. Our company runs safe. My daughter is a startup with one team, she runs portfolio safe and a single team. And they iterate, they do a demo every week, two week sprints. So those methods and practices scale to any extent and it’s up to us to apply them. And whether the thing is agile is not what that thing says on paper, it’s whether the people that do the work can do agile with that thing. 

Speaker: Miljan Bajic  08:25

And I think that’s the key. And then it goes back, I heard you say this, somewhere where like, you know, you within the safe framework, you’ve collected a lot of good things that I think you even said, like I stole or borrowed a lot of goods thing from other. And it is a collection of a lot of good patterns. But when it comes to people actually understanding those patterns, right, when you look at it, there is a gap between the competency and actually, and you put that even back into the measurements, that competency part because you can have the tool or you can have these patterns but if you don’t know if your people in the organization don’t know what to do with it, then it can backfire. And I think you get a lot of crap for safe and most of us do because people don’t know what they’re doing with Safe. A lot of times just, you know, with good intentions just that don’t fully understand what’s behind those practices and patterns.

Speaker: Dean Leffingwell  09:27

Yeah, and then we have you know, there’s all kinds, there’s Scrum bots and there’s safe bots as well. I come from one of the longest afternoons of my career was spent in Asia and I won’t say where was one of the world’s largest enterprises who had applied safe by looking at the big picture and that was it. And they’re going we’re really having trouble and each questions like no wonder you have [inaudible 09:50]. You don’t really understand the responsibilities of the product owner and No, they don’t actually own it. They can’t. So there’s a lot in safe, we make no apologies for that. And all of science stands on the shoulders of our forebearers. I mean, I think I probably have as much influence from Deming as I do from the combine community in my thinking. The goal of safe was to reduce, right, by induction 10s of 1000s of pages of brilliant work and is something people can read and apply. So we have, you know, a very light work around, for example, Lean UX. And, let’s say design thinking. My bookshelf has this many books on design thinking. Well, how much does an executive or a tech leader need to know about design thinking? Are they going to personally create empathy maps? No! But they need to know they exist and they serve a purpose. So safe is that distillation and we stand on the shoulders of others, for sure, other stand on our shoulders as well. I didn’t have to invent Scrum or Kanban to see how brilliant they were. But if you try to apply Scrum, without a sense of workflow, you’ve got a hand tied behind your back. And if you do Kanban with pure flow, without any kind of planning model, then you’re going to probably iterate more than you need to without stopping and thinking what are we trying to build. So in my view, none of these methods were perfect by themselves for the large enterprise. So little by little over the course of a decade, we started doing things like you know, if there’s more than two teams, there’s probably going to be some architectural governance necessary. And there’s such a thing as intentional architecture, there’s such a thing as emergent architecture, both matter. And we put that in perspective and say, absolutely, architecture emerges. But it can emergent by you, like, you know, like the monster from the swamp or it can be planned to a certain level of abstraction and then implemented with emergent design. Those are the things we think about as a systems engineer and safe is a system. I mean, if you want to pick on safe, the thing I would pick on is the fact that it is a system. So you can’t just say I’m going to do this but we don’t need any product owners or let’s run safe big time, but we’re not going to do value streams because it upsets my organizational model. The downside to safe, you have to do it, because it is a system, it’s a car and it has all the elements of a car. Have to be there or it doesn’t work. Now, having said that, you can start with essential safe, and there are ways to get started. But the reality is that at enterprise class, if you’re building a system that takes a few 100 people or a few 1000, you need virtually everything that’s in there. You don’t have to do it all, you don’t rip the band aid off, you don’t have to through Lean UX and you know, and really great epic decomposition or adopt lean portfolio management, or worry about model based systems engineering, what you need to worry about if you’re building a big cyber physical system, but the stuff that’s in there is in there for a reason. And it’s the minimum set that we can provide to help people scale Lean and Agile to enterprise class problems. I mean [inaudible 13:09] aircraft and robots and incredibly complex medical systems with safe, you got to have a lot for those people. They might go, for example, I think we’ve been working on recently is you know, safe is basically a set of value streams in a portfolio. Well, what happens if I have more than one of those and I have some cross cutting initiative that hits multiple portfolios? Well, they don’t say Safe is complex and it shouldn’t be more complex, they say, help me, I have this problem, we have GEPR and we have to do it across eight value streams or you know, Seven Arts and it’s not optional or we have this compliance issue or we have this initiative where we need to figure out a better way to understand what our customers are gonna leave us. Those are really big problems and it takes a pretty serious framework. So we’ve distilled and continued to still the works of others and the only invention in there probably is safe itself. And in addition, I would take some small amount of pride in lean portfolio management because that simply didn’t exist. If I could have found it, I would have. Instead when [inaudible 14:22] it took, you know, five or seven years to really get that to where that actually really works well.

Speaker: Miljan Bajic  14:28

You mentioned that safe is a system and you know, I think you’ve described it as a flow based system. What do you think most leaders get wrong about flow and when it comes to organizational flow, economics of flow and things like that because I think that a lot of times that’s lost on people.

Speaker: Dean Leffingwell  14:50

I think the heart of flow is a very small batch and hard to think big and implement small. So we’ve been taught to think about the problem, what’s the whole system, what are all the elements and how to do it. But busting that down into really tiny vertical stripes, down to a user story level is really, really hard. So the concept of flow is all about kind of implementation at the micro level and knowing that this story is going to be fed by another story and that even a story can be split in half during the implementation. So safe is a flow based system and certain things like weighted shortest job first, only work in flow based systems. You don’t use weighted shortest job first to force rank a big group of priorities that are all going to be done at same time. You use weight first to pick the next job. So the influence of flow and frankly, the DevOps community which gets flow for sure, they didn’t call it that initially. They just started [inaudible 15:57] too. Those are the heart of I would call that really modern software engineering practices, the rest of the things, the way you manage the portfolio, okay, that’s flow based as well but at macro level. The project management practices that we use, you know, why you meet and when you meet, those are helpful, but the heart of safe is a flow based DevOps centric way to deliver good, solid, highly specific, high quality software more quickly. 

Speaker: Miljan Bajic  16:30

So coming back to the leaders though, like you know, a lot of times I see leaders that don’t fully have the background that they don’t understand, like when it comes to organizational structure, architecture, governance, you can impede the flow or you can create more just by not understanding what you’re doing. So like, what are some of the things that you do? I mean, I’m assuming you help them understand through value stream mapping just to visualize the bottlenecks. 

Speaker: Dean Leffingwell  16:54

We start by acknowledgement of their roles and responsibility and empathy and by training them to the new ways of working. The first four or five years that I spent implementing agile at scale was mostly Scrum and Scrum of scrums with some XP thrown in. It was kind of before Kanband was really there for flow. And I will say we’ve succeeded in part but we didn’t succeed in the largest part because you can’t just Scrum inside an enterprise that is not quintessentially agile. So after one of those events and frankly, a flare up that we all just decide to throw up our hands and said the heck with it. I was asked to say what went wrong and what would you do different? And I said, I would never again approach implementing agile or agile at scale without training the leaders first. And that company took me up on my bluff and they said okay, you can train them first, how much time do you need? And I said two days. And they pretty much laughed. They said our leaders don’t have time for two days of training. Well then I don’t have time for your initiative. Because I can’t do what you need to know and two days. And the reality is that’s a starting point. It’s not like, you know, you take a two day class, you walk out some kind of genius, no, all you know is what you don’t know but you have a taxonomy and no places to learn. So the first course that I ever wrote wasn’t called leading safe, but it is leading safe now. And that is really a franchise course. We’ve trained, I don’t even know the numbers, over a half a million people, leaders, first line managers, architects, PMO people, project managers, Scrum masters, all the way up to C minus one and C minus two in leading safe. That’s two days, it’s one day of principles, lean agile principles and flows including. It’s about a half a day of PI planning, because the reality is the people that do the work, have to plan the work. And then the other half a day is okay. And here’s everything else that’s in safe that you might need to know. But those are the key lessons. And it’s a principle based method that we plan face to face or at least we plan contemporaneously because and the people that do the work plan the work, so there’s no centralized planning in safe. So if you take a set of teams and say they need some architectural governance, their leaders need to be trained in the new model and frequently, we’ll get them together to plan together, that’s kind of the essence of safe. And don’t forget to demo every week and you’ll probably be fine.

Speaker: Miljan Bajic  19:23

No but those are some of the like fundamentals right? And I think and you talked earlier about like, you know, the importance or you alluded to importance of having the same terminology or having the same understanding. And I was just thinking as you were also saying, like, I was talking to Michael Cohn and he said, like, you know, usually he goes in organizations and they say, you’re gonna fail or he’s like I tried to scare people away and I was thinking, well, you know, Mike Cohn can do it, Dean can do it, but everybody else can do it. I mean, like, you know, why not? You have the authority to say that and to decide who you want to work with and what type of conditions you need in order to work with the clients. So it’s probably easier for you to say that but I think all of us coaches, trainers, consultants do exactly the same thing.

Speaker: Dean Leffingwell  20:16

You mentioned taxonomy. And I will tell you, I probably underestimated the power of taxonomy. And it wasn’t purposeful that I set out to say, I’m going to create a taxonomy, I just started seeing the words, I needed to describe certain behaviors or responsibilities. And I remember spent quite a few years back that we had a couple of early experiments with translating safe. And we were in Germany at the time, and we were dealing with a large International Bank, and we were proud to tell them, we’re going to translate safe. And the VP said, please do not do that. I have people in Vietnam, I have people in India, I have people in China, I have people in the UK, I have people in the US. I said we need a common term for things that are common. So if epic gets translated in some other thing, we’re not gonna know what we’re talking about anymore. And if you want to do a quick spike to figure out how to translate lean portfolio management into simplified Chinese, there isn’t any way. So we decided not to do that. Now we do translate our training materials, because learning about it is different. So it’s very difficult to you know, if you’re not an English first speaker, to learn effectively from an English speaker for English slides, however, the framework itself is not translated and there’s no plans to do it, because as soon as you do that, dispersion will set in, and the people in India will think this story isn’t epic, right or, you know, emergent design is intentional architecture or pick your phrase and it all will fall apart. So integrating a common taxonomy is a huge benefit and we stick with that. Now, it’s not perfectly aligned, and will never be because it was ever perfectly consistent, you know, that’s the end of the road, right. If we stopped and made it all consistent. But it’s consistent enough and it has conceptual integrity, so that the meanings are the same. So there might be a term that, we had a big discussion today and the framework slack about release versus deploy. Okay, there are times we use deploy, and there times we use release, and we don’t really discriminate necessarily, which is which in that case. It’s okay. Right? People know enough about deploy and release to get by that. Would it be better if every instance of the word was the same? Maybe, maybe not. Because some people do release management, they don’t do deployment management. So those are just the [inaudible 22:46] areas where you have conceptual integrity by agreeing to a meeting, even though the word is not necessarily exactly the same in every usage.

Speaker: Miljan Bajic  22:55

So maybe that made me think about like, what like, if you reflect on the last maybe 10 years, the last five, like what were the biggest surprises over the years? Like you just didn’t expect and that hits you like, oh, wow, you know, I didn’t…  So either something that you like implement the framework or what were some of the like, oh, shoot… I don’t know?

Speaker: Dean Leffingwell  23:17

There were a number of surprises for me, aha moments. One is when I started, when I became an agile coach, the productivity and culture and engagement of the team skyrocketed. So I’ve been involved in VP or CEO of software company my entire career, I’ve never seen the type of change, we certainly didn’t have this waterfall, we didn’t have Word wrap, we didn’t have with FTD. So I’ve never seen the impact that happens when you decide that a team only has 10 people and somebody is going to worry about the backlog and we’re going to have a servant leader and we’re going to work together to ship software every day, every week. That was amazing. That’s why I do what I do now because and my mission is to bring that goodness to everyone. I’m on an agile team, I’ll bet you are. I‘m never gonna work in a company where that’s not my environment. So that was surprise number one. Surprise number two is while I recognize the problem in the industry with scaled agile, I actually didn’t want to start this company. I mean, there was people who started the company around me with my permission, I didn’t want to start another company because that would have been one to many. I’m honestly surprised that what an amazing velocity we have, and how with a relatively small company can have a huge impact. And it’s pleasing to see just today I had two vignettes go across my desk kind of in demo mode. One was a company that said with safe we were able to dramatically enhance distribution of our COVID vaccine. Another one said this is the only Large scale change I’ve ever had, that once we initiated we had pull from an entire development community. Those are heartwarming wins and things that really motivate you to say this is really good stuff. So I’m surprised, not that we’re successful but I would not have envisioned a relatively small company could have the impact that we have in the industry. So this is, you know, either lots of good business experience coming together with various business models. I’ve been a CEO and a director of companies all my career, or maybe it’s as my dad would say, even a blind pig gets an acorn once in a while. [inaudible 25:39] we hit a bottle rocket and that’s been really fun.

Speaker: Miljan Bajic  25:44

So maybe I agree. And it’s also like it’s still short period of time. And I know, there’s also a lot of critics of safe and I think a lot of times just because lack of understand whatever it is, and there’s always going to be critics but are you surprised or you know, any comments on that? Because I think unlike any other framework, I think you and safe get more crap than anybody else.

Speaker: Dean Leffingwell  26:16

So leaders have critics, right? Anytime anybody disturbs a market, you’re going to have critics. That’s just natural, it comes with the territory. What has surprised me, however, is that in our world of respect for people and culture, and the notion of Agile as we’re continuously discovering ways of doing new work, how some of those critics have been well beyond the pale, and not about the method or the customer results, but just, you know, in the nature of, you know, bizarre personal attacks, from people who consider themselves to be thought leaders. I can maybe understand that, but honestly, I can’t respect that, because that’s not the way we behave. So critics for sure, bring it on, I think we put criticisms in two categories. Some are just really unfounded. I mean, you see things all the time, I saw one the other day that said, you know, safe overloads the teams. I guess we could or somebody could, but safe, does capacity allocation and has uncommitted objectives to make sure that not everything that you plan for you have to commit to. That’s just bizarre. Others are over time, especially are pretty good, solid technical concerns. Well, it says version five, but it’s actually the eighth major release of safe. So when we find things that we think have merit, we fix it. And the rest of it is just you know, water off a duck’s back, it’s just not a concern. If leaders spend their time looking behind them and saying, Oh, I need to address my critics, they’re not looking to the future. So we look to the future, we look to business outcomes, we’re rewarded every day. I mean, the criminal justice system of the FBI is built on safe and they told my team, the whole company face to face that there’s a lot less bad guys on the street because we [inaudible 28:12]. Okay, well, critics be damned, that’s [inaudible 28:17] honest outcomes. And those honest outcomes are great, we’re happy boys and girls. And we just serve the ecosystem, right? And these ecosystems are based on economics, make no mistake about it. There aren’t any philanthropists that I’m aware of wandering around saying, here’s my method, and I’m giving it away for free. So the economic determined, there’s an economic factor in all of that, that affects it. But I don’t think that gives an excuse for, you know, a sensible thought leaders to reduce themselves to statements of not fact and statements of inference and implying motivations that aren’t present. We don’t do that and I wish they wouldn’t, I don’t think that’s appropriate, but I don’t control that part of the world. I only control how we [inaudible 29:05] others and you know, never heard us or anybody that I can influence speak like that about anyone else in the industry that makes a contribution. So that’s our culture, it’s the way I grew up and it’s the way I also believe that if you’ve got to criticize a competitor, there may be something wrong with your offering, right?

Speaker: Miljan Bajic  29:25

Well, either that and I think sometimes it’s just like, you know, picking at the you brought up earlier, the big picture, it’s like well, it’s challenging anyway. If you’re gonna, like, you know, just pick on somebody because, you know, they’ve tried to visualize a lot of concepts on a single page, like you said it’s tough. So maybe to kind of turn around a little bit on a fun side, like, what are some of the challenges that you’re dealing with when you try to visualize so much stuff on a single image? Like what type of discussions are you guys having and what are maybe some interesting or fun stories that you might have around…

Speaker: Dean Leffingwell  30:01

Well, there are configurations of safe now, which there weren’t initially. But I will tell you the original debates were should we have a matrix view? Should we have a role based view? Should we have a asset view? Should we have responsibility view? And the answer was always No. I drew the first big picture in a discussion with a few 100 PMO people that weren’t enamored by this agile method thingy, and I had them in small groups, 45 minutes a session, because it’s a big, you know, kind of Agile day. And I decided that before I went into that, there’s a whiteboard on the wall and I said, they know how they work now, they know they struggle for sure but they don’t know what an answer might be. So I’m going to draw an answer so they can envision a future case. And I said, yes, there’s agile teams, but they’re going to work together. And we’re probably gonna, we’re allocating space work because teams branch their code, we do that, I do it, you do it. We’re not supposed to, we’re supposed to check it every day, well [inaudible 31:03] need to upload. And we want to create a situation where they bring that code together. And you’re responsible for governance. So rather than us giving a report about what it should be, why don’t you come see what it is. So we’ll turn to objective evidence and help you do your job. So I started sketching it out and showing the pattern, showing the teams working together. And I said, you know, architecture matters in building big systems so somebody is going to be responsible for that. That was the genesis. Then we decided only one page. And I had a fun conversation with one of my daughters who works in a nonprofit and she has asked, these new learning modalities that she’s trying to deliver. So she’s got a storyline together and I said, put it on one page. And we all laughed about it and looked around and said, yeah, one page tends to work dad so we put it on one page and start there. Now, what you wouldn’t know unless you started integrating backwards is that page is never the same. So here, each release, we take things off when we put things on. Otherwise, the density is already a retina burn and I admit it, right. It’s a retina burn. So what happens is, when things get to be known, we no longer have to talk about them. And when we talk about them, we take them off the big picture and we put new things on. So things like, you know, DevOps needed to be integrated front and center. There will be a time when DevOps is kind of assumed, and kind of integrated, we won’t have to devote that real estate. So maybe we’ll devote it to the next technical challenge. But for now, if you don’t make DevOps front and center people don’t get it. So when you see anything on safe, and you see real estate know that we put a ton of thought into that icon and we had to figure out how much space we could do to that, how many iterations we show, you know, how a P.I. boundary looks, how bold it is, and we debate that stuff constantly. But we do it as a team with input from the field, we have safe fellows and SBCTs from all over the world and they help. But in the end, we have to decide that this goes on to BP or it doesn’t. And we have honestly little luck with, we have an area for advanced topics, there’s a ton of good value there. For example, you know, the whole discussion on team topologies and some of the examples and advanced topics, people don’t find that. They go to the big picture and click. So if a thing is important, it has to be there. And therefore we use the big picture as to put the things that are important now. And when something is no longer important, it’s going to leave the big picture and something new that’s important will come on. So you know, the amount of space we devote to backlogs, the amount of space we devote to expressing iterations, the amount of space we devote to teams, the icons, they’re all thought with consideration of the fact that this is going to fit on an eight and a half by 11. And in an elevator, I can teach somebody safe. And when we use it face to face, I’m in front of a big picture and I literally put stickies [inaudible 33:56] on culture, and it gives people an orientation. 

Speaker: Miljan Bajic  34:01

And I think that’s what’s powerful about it are orientation and at least, you know, when I’m talking to people, and it gives them some type of map, a discussion point or something that we have in common that, you know, that we can understand.

Speaker: Dean Leffingwell  34:18

Yeah even though if you don’t agree with it, at least you can talk about it.

Speaker: Miljan Bajic  34:22

Well, I think most of the time, it’s incomplete. Right? Like you said, you’re selecting based on where the industry is going, what you think it’s by nature and I think it’s a framework that’s made up of collection of good patterns. And, again, with people that don’t know what they’re doing, you know, a lot of you know, bad stuff can happen. What are you thinking about next? I’m sure you have a roadmap for like, what’s coming challenges that we’re facing, what are some of the things with 6.0 maybe or what’s in your mind?

Speaker: Dean Leffingwell  34:55

So we’ve been dealing in a couple of areas. We’re certainly been addressing this what we used to call the portfolio portfolios problem. And really now we’ve surfaced that under the enterprise article, that is a big issue. We have six or seven additional themes, we’re looking at, you know, what effect does the cloud have on development today? Oh, my goodness. Well, we don’t really talk about that, right. We actually don’t talk about data which as we move forward in the marketplace, and we think about, you know, smarter systems and customers hearings and that type of thing, those are all being incorporated. So we’d have eight major themes that we’re working on, I don’t generally pre-disclose those outside of confidential arrangement. What I can assure you is there’ll be a six, might be a five-two or five-three, I don’t really know. We basically build up a bolus of enough new to warrant changing the BP and then we ship it. And we do a ton of work behind it. We’ve got I think, eight new articles on our backlog in this PI and none of them require a change to BP. So as those accumulate we’ll say, you know, we could have rendered this better if this is a busy area, we don’t need to talk about food anymore, because everybody’s doing too well. And here’s somebody that didn’t get this. They assumed this, I read this big misconception that the system demo was a team demo. And that at the end of PI, you bring all those demos together. That’s just not true. Right? The system demo was a demo of integrated demo of all the new functionalities that has been developed by all the teams in the last week or two weeks. So that’s a misconception. We really try hard to deal with that. But there’s only so much you can do about misconceptions without being defensive about it. But I saw that thread that says, we don’t use safe, we don’t recommend it because they only integrate at the end of a PI. That’s not true. It’s absolutely not true. I mean, we do continuous delivery of the framework and the PI boundaries are completely decoupled from any releases. I don’t know a time where we sat down and said, okay, we have objectives for the PI, but rarely is it I’ll release that thing by that date, it can happen. It’s not bad to have a forcing function. But we do continuous delivery, our customers do too. But if you don’t want to use safe for some other reason, you say, oh system demo, or they only integrate once every PI, that’s not true. But unless somebody clicks, somebody else would go guys, you don’t do that. That’s terrible. That’s like your waterfall busted up in the eight week chunks. 

Speaker: Miljan Bajic  37:30

But you would also like, I’m assuming, like, if you understand what you’re doing, you would also just make that assumption. It’s only like somebody that probably doesn’t have experience that’s looking for like step A through Z, that I need to do and you would make that assumption. So I can see why you know, it could get… You spent a lot of time based on what I heard on the new metric guidance.

Speaker: Dean Leffingwell  37:55

We did because that’s hard. I have a you know, off again, on again, love hate relationship with metrics, because many metrics change behaviors in ways that support the metric, but don’t change the underlying behavior principle you’re trying to get to. And we all know the, you know, the CMMI experience and what it’s like to be audited by others and I swear we will never go there. So I was really late to metrics in terms of my thought leadership. What we did do is we compiled things that work. Cumulative flow diagrams, right? The program predictability and we put them in an article that was honestly a collage. It’s like, here’s lots of interesting metrics to talk about. And we organized it by level because we need an organizing model. Well, that never really worked, frankly and there was no way that you could go to an executive and say, how do we really measure progress in this digital transformation? We’re going to invest x million dollars, we’re going to train people, we’re going to refactor the PMO, we’re going to hire product managers, we have to bring in some Scrum masters. Show me what kind of progress you’re making. So at some, that has been on the backlog for probably two or three years, for some reason, in the last six months, partially because we had some people that really cared about it, we said, let’s rethink that from scratch. And we backed all the way up to say what are we trying to measure and why? And it started out with, you know, four inputs and one output and simplified it and it finally evolved to really, there’s three things. We do measure competency, because you can’t improve if you don’t measure competency and mostly that comes through training, but not only. We need to measure flow. This is a flow based system. And frankly, if you don’t measure outcomes, we’re all wasting our time. So the key that we said these are the three things that matter. Now CFD, okay, that’s part of flow, a predictability measure that can be part of flow, a set of iteration metrics, well, okay if you want to measure a percentage of coverage of unit testing that can be part of flow. So we had to repackage things in this major carrier. But it’s been a real hit because people get that. Say I need to improve my competencies, I need better flow and I need better outcomes. So that really simplified, I think that’s another example of induction. Right? There’s so much there that you couldn’t understand any of it, and when we simplified, simplified, simplified and reduce it to the three things that really matter, then I wouldn’t say the article wrote itself, because I think it’s the second highest record for most revisions. I have the leadership mantle there, the organizational agility article went through 18 major revisions. That’s not probably by the way, that’s how far off I was to begin with. Metrics [inaudible 40:47] 13 or 14 before it went live, but as soon as we collapse on those three, we said that’s, we’ve got it. And then [inaudible 40:54] it’s a flow based system, we’ll show where you measure outcomes, where you measure flow and how you adjust competency. So we’re really pleased with that and I think, very pleased by the reaction because people do need to measure. You can’t improve what you can’t measure. I mean, Taiichi Ohno said, you know, without standards, there’s no caisan. And so you have to do that. It’s just that it’s been done so badly and so often that I was just burnt and I didn’t want to walk out into that. And you know, I actually don’t care how safe you are. I care whether you’re getting the outcomes that Lean and Agile at scale matters. So there’s no, there’ll never be in under my watch a third body that comes around and assesses your safeness. Never! But I know who can assess your safeness and that’s the people that are implementing it. And they can do that as a self-assessment, they could do that as a coach assessment, they could bring in an outsider, and they can introspect and say, you know, I know we’re have good predictability but I don’t think the velocity is there or we have some performance issues that are gonna need to be addressed on the team. Only the teams can do that and empowered model, they’re empowered to do more than they were before. So you got to give them the tools they need, you got to give the executives tools they need. And if we don’t crack up and metrics again for a few years, that’ll be fine by me.

Speaker: Miljan Bajic  42:16

Great. No, it is. And I think there’s also like, you know, when you look at these, you know, from outcomes flow competency, you can actually look at, you know, for instance competency, you can look at, you know, individual competency, organizational competency, even like from skills you can look at, you know, competency as far as skills versus emotional intelligence, like, you know, how big is the cup versus how full is the… like, it’s just the I really liked that aspect. And maybe we could talk more about that another time. But I want to get maybe last topic here, safe for startups, Luke Holman, recently wrote an article about startup but first route. I wanted to get your thoughts on that.

Speaker: Dean Leffingwell  43:00

So safe does scale. We didn’t design it for startups, I’ll be honest. We didn’t design it for our company. We run our entire company on safe but guess what? The operational value streams don’t fit as well on safe as [inaudible 43:14] value streams do. So there are some stresses and strains on that. But kind of by example, my daughter started a company a few years back to basically build some intelligent technology, some applications, potentially some machine learning around autism, diagnostics and remediation. And in order to kind of get her started, I gave her my usual you know, lean startup books, and, the Crossing the Chasm and all those kinds of things. But then she started asking questions like, well, you know, how do we meet? Well, you’re just a single scrum team. Well, what’s that? Well read this article and see. So there are a single scrum team, but they run two week sprints, and they use the portfolio. So we actually do PI planning, we bring in other stakeholders for PI planning. We just converted the system demo from every two weeks to every one week because we’re approaching some milestones that we can’t really afford to miss. So most times when her company struggles with process we just go back to safe. And they don’t you know, they’re not as release train. They don’t they don’t have a system architect. They don’t need it. Their lead developer is a system architect. Most of it, they don’t need, but the stuff they do need, they need really badly. So you know, if you think about agile, it’s basically the plan, do, check, act cycle, right? And you have get that all the way up. Well, they’re just one team, but they really benefit from safe and as I mentioned, whenever they get in trouble, we find solace, we find words. I mean, we had a discussion about the system demo. And I said, Marcy, have everybody read the article. And she read the article and she said, Dad, we’re not doing that. So now they are, okay? And all of a sudden she’s saying, Dad, I think I’m seeing higher velocity. Because we’re really focusing on the outcome, we’re focusing on what the user would see, not what our process is or what you know, what infrastructure we’re deploying, or how we’re doing with Amazon Web Services. These demos are now about what my user sees. And she says, I think the velocity went up and the developers are going, our velocity did go up. Are they working harder? I don’t know. Are they working more effective? Absolutely! So the principles of Scrum, principles of flow, the principles of systems thinking, how would they not apply to a startup?

Speaker: Miljan Bajic  45:29

Exactly! I think like you said, like, it’s that cycle. It’s just like, how short does your feedback loop need to be? And, you know, for startups is probably a lot shorter, like you said and your adjustments. So that’s really, at the end of the day, what it comes down to.

Speaker: Dean Leffingwell  45:47

You know, the principles matter. I remember, many, many years ago, working with a leader in one of my organizations. And we ran one way experience generally because we were in an unknown area, we’re inventing the future, we couldn’t afford to wait two weeks to learn anything. And we came to a time where there was a release scheduled in about three weeks and the leader, you know, basically the, you know, the scrum master agile leader said let’s do four week, four day iterations. And everybody’s going well, how does that make any sense? Well, you and I know. And what he said was, otherwise there’s not enough time to fail. So when you talk about the scalability of a framework, and understanding your principles, cutting down to four week iterations makes sense as you approach a deadline. But he could have said, hey, there’s only three weeks away, we need to dispense with all these dang meetings and we’ll just do one three week sprint because it’d be way more efficient, a lot of people would have said, well that makes sense. But he didn’t and I didn’t and they said absolutely makes no sense. And talking to my daughter about her situation and development, she said, well, there’s not much, we’re still really early in development, there’s not much the demo. And I said time for demo.

Speaker: Miljan Bajic  47:05

Exactly. Get some feedback. So maybe the last thing, what would you like to leave us with? A message, anything that you would like to say or maybe anything that I didn’t ask you?

Speaker: Dean Leffingwell  47:17

Honestly, it comes down to leadership. And I think respect our leaders and have empathy for them, we need to recognize that they probably weren’t raised, they probably didn’t go up in this model and it’s going to take a journey for them to get there but we have to be relentless, we have to not be arrogant  but we have to stick to our guns, we have to know this is what agile is, we have to coach our leaders and when we find a leader that’s exhibiting wrong behaviors, we have to say that doesn’t work in an agile model, it doesn’t work to motivate others. So in the end, it’s about leadership because most of the rest of us work in a system and we can’t change that system. Only the leaders or managers can change the system. So focus your attention on the leaders, have them get whatever training they can, do a book club, read Reinertsen, attend leaning safe, do whatever, but get people’s minds around the lean agile mindset because it’s not a trivial mindset. It’s you know, lean boot camp and lean manufacturing used to be six weeks of training. These are not trivial thoughts so it’s going to take for our leaders to get it but they need to. If they don’t, they will be displaced for sure. And if they do, they’ll have an opportunity to contribute to the next digital age.