Categories
Podcast

An Engineer’s Journey to SAFe

Show Highlights

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.


Read the Transcript

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.

Categories
Podcast

Part VI: How Deconstructing the Agile Manifesto Makes You Better at Barbecue

Show Highlights

In this episode, Derek Lane and Matthew D Edwards deconstruct the final two principles of the Agile Manifesto to help software developers and engineers bring more value to clients but also, become better barbecue pitmasters.


Read the Transcript

0:00:00.0 M Edwards: Welcome back. Today, Derek Lane and I continue our conversation mapping the Agile Manifesto and its 12 principles to making better barbecue. In this episode, we cover the final two principles.

0:00:15.0 D Lane: I think what I’ve learned in the process with the Agile Manifesto over a couple of decades is that, it’s actually the reverse. When you first read it, it’s an introduction to a set of things that if you choose to pursue this in order to understand it, it will not only take you some time, you’re going to have to go back and then wrestle with what you thought you understood before.

[music]

0:00:44.7 M Edwards: Welcome to The Long Way Around the Barn, where we discuss many of today’s technology adoption and transformation challenges and explore varied ways to get to your desired outcomes. There’s usually more than one way to achieve your goals. Sometimes, the path is simple, sometimes the path is long, expensive, complicated, and/or painful. In this podcast, we explore options and recommended courses of action to get you to where you’re going now.

0:01:36.9 M Edwards: Alright, so we’ve covered a lot of ground so far, and I suspect that’s one of the challenges that people may have with reading the manifesto and the associative principles is there is just meat in every phrase or segment of these sentences, like this actually takes a while to sit down, dissect or deconstruct to understand, or to figure out how you apply it in your life, how to go live it. This is an amazingly heavy piece of material or set of material for people to think through and apply. I love it, and I love the fact that we’re walking through it.

0:02:12.7 D Lane: I would agree. It’s accidental in that people are unaware that it is actually the process. I think one of the benefits, we have this perception that a manifesto is a declaration upfront, and that if we just read it, we will immediately grasp everything that was intended by whoever put the manifesto together. And I think what I’ve learned in the process with the Agile Manifesto over a couple of decades is that it’s actually the reverse. When you first read it, it’s an introduction to a set of things that if you choose to pursue this in order to understand it, it will not only take you some time, but periodically you’re going to have to follow as we’ll talk about with principal number 12. You’re going to have to go back and then wrestle with what you thought you understood before. It didn’t go far enough, it didn’t go wide enough, it didn’t go deep enough as it needed to once you went a little further.

0:03:20.5 D Lane: And I think one of the real values of the manifesto is after folks have, I’ll say, five or more years of actually being embedded in a natural environment and really struggling through trying to learn agility, that’s when I feel like that’s a real milestone for them to come back and tease this apart and try to break it down word for word, and put it back together in the way that they currently understand agility and see what insights they’ve been able to learn by trying to apply this because it’s in the application that we understand the theory, which is kind of ironic because we believe we understand the theory just by reading it, but we really don’t. It’s only in the application that I think we extract, not only the intent of the writers of the manifesto, but the benefits that they themselves may have not learned yet, they themselves may have not originally intended, seven years later they may have come across it, but they didn’t go back and change the manifesto.

0:04:34.1 D Lane: That’s one of the things I point out in the 20-day Agility challenge is that this is still version 1.0. This hasn’t changed since February approximately of 2001. My understanding is the principles came a little bit later from the first page that we tend to call the manifesto. 

0:05:01.3 M Edwards: Well, I think the co-location of these folks, these folks coming together and working on this and realizing the words and the structures and the intent and the direction is illustrated in this 11th principle. The best architectures, requirements, and designs emerge from self-organizing teams. I would think the development of the manifesto and the principles themselves are good examples of, this team came together and the designs emerged, the architecture, all of the work emerged from the self-organizing team.

0:05:39.0 D Lane: Well, I think your observation is really insightful. The fact that there’s a bit of recursiveness here, that you took people from an extreme programming background, from a Scrum background, from a feature-driven development background, from an adaptive background in James Highsmith and other approaches. And a cross-section of skillsets, and that they weren’t all just coders overcoming from the same type of role and exposure, and when these so-called lightweight methodologies were at that point in their development, these guys got together as happens from time to time, and conferences of folks who are like-minded people, and when they decided to put together this particular meeting at the Snowbird, Utah, that’s when they were able to then make yet another iteration, incorporating a lot of the things that they have learned. And as I’ve heard it talked about from the folks who were there, the first of a three-day conference, the first two days or so, it was a lot of non-getting along. And we’re thinking all these folks, everything was just happy-go-lucky the whole time. And evidently, it was a lot of debate and discovery. But it was the emergence, and this is the principle of emergence that we find in the manifesto.

0:07:05.5 D Lane: The emergence of the pattern of, we value this over this, we value this over this, that was able to be extracted from a lot of what they had talked about in order to find a structure for common ground. And then they could begin to organize around that. I think this principle of emergence is, again, as we talked about earlier, with best practices, it exposes the fallacy of this idea of best practices, it’s just the best thing I know right now when I try to set that as the bar from now on, or for the next five years, if that I’m actually hurting myself. I’m discouraging innovation. I’m discouraging growth. I’m discouraging learning because we all have to do it according to a “best practice”. When this principle demonstrates that in order for us to really find out what the best practice is, it has to emerge from the application of what we’re trying to do. So in the context of software, that tends to be a software architecture. Again, when this came out in 2001, big business requirements documents were all the rage, it was cool, everybody was doing it. So requirements were a very hefty element in the delivery of software. And then we get to designs, and I often hear that, Well, user experience and human-centered design and human factors.

0:08:30.3 D Lane: This wasn’t really around at the time of the creation of the Agile Manifesto. But really, we do have it in here because this was the kind of thing that while there might have not have been an isolated skillset or degree plan or someone who had a title and a role on a project that was focused on user experience or some aspect of that, it really is included in this idea of emergence, in this principle. In that really what we’re saying is the best ideas, the best way to solve problems emerge from self-organizing teams. I think that’s a more abstract variation of this idea. And to me, that gets across this idea of emergence. So we really are looking for the application, we’re looking for iterative value to expose itself or to help us pivot and through that process, better ways of doing things will emerge, which now we’re back to the first page. We’re learning better ways of doing this. Well, how are we learning it? If we already have best practices? We’re learning it because we’re applying it, we’re doing it and we’re helping others do it, and those better ways of doing it are emerging.

0:09:42.0 M Edwards: Now, one of the things that I like about this particular principle, just reflecting on my own journey, is I’ve been in situations in large corporations where there was a designated architecture group and their responsibility was to architect things. And we ended up in situations where we were on the receiving end of all of the architectural thought and direction and plans, and our responsibility was less to question and most to just get it done. And then the architecture ecosystem wasn’t readily available to us because they had moved on to their next project. So we were given a set of deliverables from the architect, if you will, and our job was, “Get it done.” And what I love about this particular principle is, it says, “Hey, we could absolutely have some people somewhere else in the house who have been involved in the business development side of things, the product side of things. They’ve been here 147 years. There are only 148-years-old. They know things.” And it’s very valid. For those folks to be able to say, “Hey, have you considered?” or “You should consider.” Or “These types of things, I’ve had great success with.” But what I love about this is to say, “Hey, even if you are given fences on the pasture, still bringing together the team, the multi-disciplinary team to discover, explore, define, implement, iterate, that’s where the real innovation is happening.”

0:11:21.9 M Edwards: And so when we were bequeathed documents of instruction, there was no innovation, there was implementation following the directions. So I love this as a counterpoint to that. But let me offer this, I like your thoughts on this. I’ve actually heard other people say we are Agile, which in and of itself is not a correct statement. None of us are actually Agile. We’re pursuing becoming more, and we’re using these principles and practices and guidelines and ideas to foster, facilitate, enable, equip, encourage, and so forth. But I am not Agile. I’m actually a blunt force object oftentimes, but I’m not Agile always. But with that logic, I’ve heard someone say, “Because we’re Agile, we don’t actually need to have a roadmap, we don’t have documentation, we don’t have plans, we figure it out as we go.” And that has been received by other company cultures as a cowboy mentality that says, “Hey, you guys can’t tell me how much it’s going to cost, how long it’s going to take, and you’re telling me to just to trust you.”

0:12:30.8 D Lane: Yes, so let’s talk about Barbecue. If I’m going to have any shot at this, it’s not going to be that one. And the reason it’s such a big can of worms is because it is somewhat pervasive, it’s universal, we’re borrowing from this hierarchical thinking that we’ve brought along, and not only how we structure ourselves, but how we organize our plans and our thoughts for how we’re going to execute something. We’ve been taught that we have to do all the thinking up front and all the planning and the designing or whatever that might, requirements, whatever pieces or elements might apply in our domain. And then we’re going to come up… At some point, there’s a process where we identify some cost, and then we have some artifacts, for instance, like what architects might have given you in the scenarios you were talking about. And then there’s a group that’s going to implement it, and then there’s a group that’s going to put it in production, and then there’s another group that’s going to deal with the maintenance and support and the upkeep of it. And the sequential way of thinking is, in and of itself, very anti-Agile, because now we cannot respond to change, outside of the level at which we’re at. If we’re at the design level, we can’t respond to change in budget.

0:13:53.3 D Lane: Well, no, that’s not true, because we know someone’s going to come along with a less of a budget than was already set. You still going to deliver the same amount of stuff or more with less budget in the same amount of time or less. So we know that you do have to respond to change. But it’s always in a negative way, it’s always in, you got to do more with less type of ecosystem. So I think a piece of understanding the intent here and trying to create an environment, as we talked about in number five, that allows people and projects to succeed is that we have to stop thinking in terms of specialization, and we refer to putting people in a box before and then they’re limited to that box. You’re the DBA, you’re only the DBA. I can’t listen to you if you’re going to talk about customer requirements or anything else, because you’re the DBA. Now, we’ll defer to you on the DBA stuff, and we’ve gotta stop doing this, I think now that the teams that have moved to one of two directions, seem to be the most effective at this. One is everybody has the same title. We’re all consultants, we’re all team members, we are all developers, we are all whatever. So we get out of this mindset of, someone with a certain title also having a certain role and responsibility.

0:15:23.8 D Lane: We move away from that to where we’re saying, “We’re all responsible now, and we’re all required to contribute in whatever way our skills and experience and our minds might come up with, again, applying emergence.” That’s one approach. The other approach I’ve seen is everyone makes up their own title. And you can keep that title as long as everybody on your team agrees. So you can’t call yourself The Grand Database Wizard if no one on your team agrees that you’re The Grand Database Wizard. But what you could do is, if I could say, well, and I could get feedback, and again, this is emergence. So we’re coming to a point where we can agree, and now I’m the Grand Poobah of data stuff. Okay, great. Now, at this point, I can avoid being the DBA because I may have a preponderance or a set of training or preference to deal with data, but that doesn’t create this artificial boundary that calling me a DBA does. And so either one of those approaches, and there’s lots that can be done and that I’ve seen done in both approaches is one thing. And what that does is, that moves us to this concept of generalizing specialists. I remember hearing about this years ago from a guy that’s in the industry that I had a lot of respect for. He is one of those guys that always just seems like he’s light-years ahead of everyone else.

0:16:50.3 D Lane: He was introducing this idea, and it was the first time I heard it. This idea that the newer model that we might use it, it would be called the T-shaped person, that’s been around a little, I don’t know, 10 years or so, at least, that we’re no longer just a vertical in our database person, but we also have some experience with other things. We know how to do integration and we know how to do testing, we know how to do some design or architecture, we’re not limited to this one skillset or necessarily constrained in that way. And what I hear leaders say is, “We want more T-shaped people, but then everything they do reinforces the I-shaped person.” The reviews, the titles, the pay scales, the reward system is all based on an I-shaped person. So they’re not doing anything to really encourage the T-shaped behavior, it really just becomes potentially an albatross around someone’s neck, if they really demonstrate that well. So what we’re really looking for is someone who maybe isn’t, no one’s good at everything and no one’s interested in everything, but just make sure that we’re not artificially enclosing someone, and imposing boundaries on them, that may just be where their skillset is right now.

0:18:05.2 D Lane: But I know a lot of people who went to college, got a degree in marketing, got a job in sales, found out that they liked to code and they’re some of the best technologists that I’ve ever worked with. A complete shift of skillset, and they can do the marketing, but guess what? I didn’t even know what this coding thing was, so how would I be interested in that? I think that another piece that we’re missing, when we have the Chief Technology Officer or a set of enterprise architects, and I’ve been parts of all these groups at some point in my career, and they’re going to do all of the thinking up front, and then they’re going to kind of mandate these designs or architectures or tool selections or technology stacks or whatever it might be, it is true that the masses do not have the skillset to make a lot of these decisions. And I would submit, and they never will, as long as the people in the ivory tower continue to hoard, not only the expertise, but the time that they’re allowed to spend on it. If all my time, the opportunity. So what we’re doing is, we’re again, separating this idea, this opportunity to learn, we no longer have shared learning. So if someone comes to the architects and says, We’ve got this problem, can you help us figure out what technologies we should use and we gotta integrate with this legacy system, this third party system?

0:19:29.7 D Lane: Okay, now we’ve got a lot of stuff to track down, it made sense to me that the architects, first of all, as part of a cross-functional team, each one of them should be part of the team, not a team of architects, a team that’s going to go from idea, problem, whatever, all the way to production. Because the other thing that happens, which we all know from a waterfall environment, in the scenario that you described, the architects do something, they hand it off, now they’re on to the next problem or two problems later, they don’t know the impact of their decisions, because they never saw it in production. They never wrestled with getting these two wires to line up. So they lose that learning, again, that shared opportunity for learning. So now we’re back to, let’s talk about a self-organizing team, well, they emerge from self-organizing teams, let’s make sure we have all the skillsets, let’s talk about generalizing specialists so that we’re no longer trying to shoehorn people into a narrower set.

0:20:24.8 D Lane: We’re just saying, I’m a technologist. Right now I’m focusing on this, this is my primary skill to learn, but that’s it. And then we get into the really hard one, which a lot of people say they don’t do, but in our archaeology example, there’s not a lot of evidence that they’re not doing this, and that is the Big Design Up Front. So whether you’re Big Design Up Front is so-called design sprints, which is very popular, Silicon Valley, one or two weeks ahead, where all the UX folks, again, just like the architects are isolated from the teams, they’re going to make all of the decisions about the touch-feely stuff for some system and then they’re going to hand it off, or the architects or whoever, it doesn’t matter what the skillset is, those skillsets need to be embedded into the people who are doing the development, who are doing the design, who are doing the delivery, who are doing the support so that the learning curve is complete. The shared learning is across all skillsets, and now we’re getting back to the original principle, the best architectures emerge. They don’t emerge from the architecture group, they emerge from production.

0:21:29.6 M Edwards: If you take that idea and you go and some people use user stories, the idea of a user story that could be an Epic, which is a theme, it’s a big rock, and that’s broken down on the user stories, which are different types of users, and their stories. And their acceptance criteria at the end of that basically says, this person should be able to do this, this person shouldn’t be able to do this, the use of the system, character is just da-da-da-da. We’re not talking about this here with any great depth, but another set of good books that’s really great for reference, so the books written by Mike Cohn on user stories, user story applied, estimating, etcetera. And you know, one of the interesting things about the approach that he posits in that material is similar to what we’re already discussing. The team is multi-disciplinarian, in other words, those people who sit down and say, This is the EPIC, these are the stories. How they’re deconstructing the stories, and these stories deconstruct into these acceptance criteria, those people all represent the different stripes or ideas in this poly-culture, which is information security, data, analytics, software development, tools, tool change, delivery pipelines, all that stuff, all these things come together as one team.

0:22:46.1 M Edwards: So the best architectures requirements and designs emerge from self-organizing teams, and those self-organizing teams actually assume a polyculture, not a monoculture. And I think that’s one of the important things we’re talking about and differentiating here as well, which is, if I have the tribe of architects, it’s still a monoculture, but if I have a self-emerging team, a self-solving team that includes an architect-type thinker plus, plus, plus, now I have a polyculture. I have a higher probability of capturing a rich environment to deliver customer delight.

0:23:24.5 D Lane: But I think a lot of companies have gotten too busy following the approach that you outlined, where we’ve got specialists and they just hand it down the assembly line to someone else, and it loses that essence, the thing that makes it unique, the properties that allow the customer to be delighted in that unique way. I think a lot of that, it gets squeezed out of the process because there’s no way it can be handed down from the first group to the second group because there’s no one in the second group who experienced it with the first group. There’s no one in the 10th group who experienced anything from the previous nine groups. So, the process itself strangles the essence of learning that occurred at any point before it. No matter how it was documented, no matter how many help videos were created, it’s not the same. And I’ve run this experiment many times in coaching and training where we’ll have two different teams and they’re roughly comparable in most ways that we’re trying to measure in some way. And one team, we will do very much as everybody learns at the same speed, everybody learns, we’re going to slow down if we need to. The other team will be very much, we’re going to try to be agile, we’re going to do some stuff, but we’re going to be order taker, the architects are going to give us this, the product owner is going to give us this, and we’ll just do our piece and then we’ll hand it to the testers.

0:24:58.8 D Lane: And it is undeniable that the second group that follows that very much well-worn, well-understood approach, they’re going to appear to be faster at the beginning because the delta in what they’re doing versus what they’ve always done is very small. So their need to adapt to change is very, very small. Where the other folks are going to appear to be just completely losing it. Yeah, I mean, they’re not even the tortoise, the tortoise is running circles on them because they appear to be going so slow, but there will be multiple times at which they will not only leapfrog ahead, they will time travel. They will move ahead at a pace that is unpredictable because it will stutter a little bit. It’s not a constant pace, but what is constant is that they’re always moving forward. They’re always benefiting from this idea of a shared learning experience, and emergence. The best ideas are coming from this group who is now not just shared a problem to solve, but they have shared the experience and the journey for however long they’ve been able to be on it. And those are the teams everybody wants to be, on after the fact, because they’re like, they can tell these guys care, they have fun, it means something to them. They got everything, I mean, everything that you would want in a group, a working group that people that you care about.

0:26:29.0 M Edwards: I think that’s a really good segue to the last principle on the list. And I’d like to open it up by just talking about this. When I decided I wanted to get into ranching, I believed it was about the cattle. And a couple of old gents that talked to me, looked at me like, you’re fun. They looked at me and I know that they were saying, bless his heart, because how I was corrected as they said, No, sir, you are in the business of farming micro-organisms, microbes, in other words, you are a soil farmer. Because without soil, there is no grass, and without a diversified ecosystem of grass, there is no cattle, and without good healthy cattle, there is no revenue, so you might as well pick a different career. And so, I believed it was about the cattle, and they told me it was about the soil. Similarly, with this Manifesto and these principles, I believe that we’re actually talking about growing people, not delivering software. Everything about this is growing people. And to your point earlier, your team only becomes as great as you enable them to become. I mean, first of all, you have to hire people with great attitudes, great aptitudes. The type of people that sit on the bump of the chair or stand the whole time, and they can’t wait to get into it, so you have to hire those types of people.

0:27:51.6 M Edwards: But when you bring them together and say, You are a team, we need to be a team, let’s go party and just rock and roll on this stuff, they’re only going to become as great as you enable them to become great. So if you only let one person do the thinking and everybody else just has to obey, that’s not a team, that’s not growing a team, and obviously, in that other illustration, that’s not going to be healthy soil and therefore not good cattle and so on. But if you want to grow a team, to your point where it may look like they’re starting off really, really super slow, slower than a tortoise, but at some point, they’re going to time travel, this conversation is about growing people, not delivering software. Delivering software just happens to be the thing. But if we take all these ideas and apply them to any industry, software also, it’s 100% about growing thoughtful people who are working together to rock and roll. So, at regular intervals, in this last principle, at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. I love that. We’re basically saying, We’re giving people the opportunity to think, talk, see, recommend or observe and change.

0:29:15.0 M Edwards: And an interesting thing is, it has to be an environment where they know they have permission or they need to be able to say, these were amazing activities, amazing results, super happy to be here, let’s do this 47 more times ’til it doesn’t make sense. But at regular intervals, whatever that is, the team needs to be given permission to think and decide and evolve together, ’cause we’re in the business of growing people.

0:29:40.9 D Lane: Well, again, I think that’s a great observation. I think that that really gets to the essence of the first page of the manifesto is, it really is about people. And the way I kind of over-generalize in a nutshell, you know, kind of the 10 words or less, what is agile? What is agility? To me, it’s this idea that we have this relentless pursuit. For a long time, it was just the pursuit of value, but I think it’s the relentless pursuit of value. And I think it’s the idea that we constantly have people who are engaged in a positive way, and I think that’s what you’re describing, is people who want to be here, is people who want to continue on this journey, is people who feel safe to be able to raise their hand because they don’t understand something that everyone else seems to understand, as well as people who are just questioning what appears to be the prevailing thinking. We’ve been doing this for a little while, we’ve kind of been going down this path, how are we going to deal with X? I haven’t heard anybody deal with X, and I’m the new guy here, and I don’t know anything about it, but I really don’t understand, is it just me?

0:30:49.4 D Lane: And I think a huge aspect of that is knowing that it’s safe to do so, but doing so in a way that is constructive and not accusatory. We need to remove this idea that we have to judge everybody’s idea, and we have to remove this marriage that we impose on. If someone says something, it’s their opinion, it’s their idea, and we dislike it, then we respond in a way that indicates we dislike them. We have to remove this idea, and I think that’s really where we get to the true cross-functional team. Because of all of this, none of this happens without trust. The way that the team members get to that point of safety is that I know I can trust you. If I’ve got a delicate conversation, I’m not going to go to people I may know really well or have known for decades, I’m going to go to someone I trust, someone I trust that’s not going to reveal the confidence, that’s going to give me sound advice, someone that may not have any answers, but I know I can trust them to be on my side.

0:31:55.2 D Lane: And if they need to tell me something that’s for my own good because I can’t see it, I not only value them in order to have that conversation, but I’m willing to listen to them because I know that they’re doing this for me. They’re not just doing this for them, or because they don’t have the time or any of the other things, they’re actually taking me into consideration and trying to figure out, what’s the best thing I can do to help him at this point, and based on the conversation of the topic or whatever it is that’s going on? I think those are critical elements of having a successful team, period. And then when we add in the self-organized and the cross-functional, those are other characteristics of, again, successful, high-performing teams. Not just teams, these are the teams that everybody wants. These are the teams everybody wants to be on. And so, absolutely, I think the reflection or this iterative cycle of how do we get better, if anything, this 12th principle represents for me that the Agile Manifesto has incorporated in it within its structure, the requirement in order to achieve agility, you are required to create a learning environment, a learning culture. It is not possible for you to maintain agility without it.

0:33:14.8 D Lane: So a lot of the things we’ve talked about are things that stifle the ability to be agility, the ability to innovate, the ability to have a safe environment to say, I think we’re about to drive off the road. Is that what we want to do? Because someone else higher up the food chain is beating their chest or screaming or pounding their fists or whatever else they might be doing, which creates that environment that says, Okay, obviously, I’m the newest guy on the totem pole, there’s no way they’re going to listen to me. When in reality, the fact that I’m the new guy gives me a unique perspective and that should be valued by everyone else on the team. They should realize I don’t see things the way they do yet, and I can help them see some of their blind spots. I can help them see some of the weaknesses that they’ve been looking at it so long that they aren’t aware of it. I know I do that all the time. I try to make sure people see things before I kind of make them available to the masses. That doesn’t mean any of us will catch everything, but I’m trying to increase that value for everybody.

0:34:21.6 M Edwards: Well, let me unpack that just a little bit. When we’re talking about psychological safety for people who may or may not be familiar with that word combination, we’re not talking about padded rooms where nobody is ever going to say something that might hurt your feelings. We’re not talking about spaces where people don’t really say what they’re thinking for fear of offending someone else. Every human and every human on these teams has a responsibility to understand and communicate. And oftentimes that happens with questions, by asking questions like, What do you think about? Have you considered? What would happen if? What are our other options? Just questions that stimulate ongoing evolution, that fosters an environment of learning. A psychologically safe environment doesn’t mean we aren’t transparent with each other and direct and communicative, it does suggest that we honor and respect each other, which is, Derek, the thing that you just said, internally, all my lights are going off and I’m thinking that’s one of the craziest things I’ve ever heard good, sir. It’s possible, I don’t understand it. It’s possible, I completely missed the bus. It’s not making sense to me. Could you re-explain it in a different way, I’m being dense?

0:35:43.1 M Edwards: That’s a non-threatening way for me to say, dude, I think you’re saying crazy things, but I realize that I could also be the hoser here. So, let’s go a second at-bat here. There’s got to be an environment that fosters, encourages, enables, invites the opportunity to learn, and learning happens with questions. Declarative statements like this one shut conversations down. This is all about people all day, every day, all of the time, and until we figure out how to grow and enable and equip and educate and love people, you may or may not deliver whatever it is that you deliver software included.

0:36:25.4 D Lane: Completely agree. The thing that a lot of folks are confused about the Agile Manifesto, especially when they see it from the standpoint of software technology, developing a technical product, there’s nothing in here about version control or about what programming language to pick? Or do you need a client-server architecture, should you be using the cloud? Where does mobile fit? None of these things are here, much less higher-order things like, how reactive does your system need to be, how do you scale it, how do you deal with internationalization, how do you deal with security? There are really complex elements of good designs, good software products, services, architectures, how do you deal with all of that? It’s not here. It doesn’t tell me what to do. No, it doesn’t, because as you have so eloquently pointed out, almost all of these have to do with the people, they have to deal directly with how as a group, in order for us to come close to dealing with the complexity of the technology and the problems we’re solving with, we have to create an environment in which it’s safe for us to be ourselves, it’s safe for us to grow and learn, it’s safe for us to make a mistake, it’s safe for us to be able to share with somebody to say, You know what? That doesn’t make sense to me. I don’t like it. It feels funny. Is there a better option? Is there something else we could do?

0:37:57.5 D Lane: And it’s perfectly acceptable to say, You know what? It’s not that I disagree with you, but based on delivering for our client, I think given the short timeframe, we could still deliver something here, and then we could come back and address that in the future thing. And that’s perfectly okay. But the thing that rarely happens in the real world is that if we get that agreement and then we release it, we never come back to the thing and fix it. We not only have the technical debt, which folks nowadays at least, most of them have heard that expression, we now have people debt, we have debt that we have damaged our ability to trust, whether it’s someone inside the team or outside the team. Now we’re back to principal number six. The most effective and efficient way to communicate, because I don’t have to communicate with you face-to-face, I can make this decision unilaterally and it’s going to affect you, we’re not going to deal with that anymore, it’s not a high priority on my backlog. So if you guys can’t deal with it, tough, I’ll get some other guys who can.

0:39:00.9 D Lane: This is not a psychologically safe environment, this is not a learning environment, this is not about an environment that values people and interactions over processes and tools. Now we’re archaeologists again and we go say, where is the evidence of agility? The fact that we might be having stand-ups five times a day, or that we’re tracking things with user stories, these are all practices, they’re all optional. None of those are required for agility, they’re all just a mechanism, a means to communicate, a means to value ideas and to represent customer value or team value or organizational value, and a way for us to begin to try to figure out how do we communicate and share that information. I think that’s a big difference in how most people read the actual manifesto, they’re looking at it as the decrypt software development forum, it’s decrypting it, but not the part that they’re thinking.

0:40:01.1 M Edwards: So the best architectures, requirements of designs come from a self-organizing team is basically what it’s saying, and at regular intervals, that self-organizing team takes time to reflect and learn and change. Now, how do you see that happening in barbecue? What does that look like when you’re barbecuing?

0:40:20.1 D Lane: So I think the idea of a self-organizing team in barbecue is very apparent when we watch some of these TV shows, whether it’s public television cable channels or Netflix or whatever, and you watch a competition, and I don’t mean a competition with Myron Mixon or some of these guys who are world famous and have been for decades, I’m talking about the guy and his wife and the brother-in-law and the cousins who are on the barbecue team who are trying to compete, they’re going to be given a set of problems that they’re not expecting, now they’re ready for a lot of stuff and they practice, they’ve done what they could, but again, they don’t have any control over the weather, they may not have as much control over the fire as they think they do, the expectations of the judges may change the day of the event, they may be given some rules that they weren’t planning on, so now they’ve got to come up with, Well, now we have to make something that we weren’t planning on, Well, we didn’t bring a recipe for that, so the idea of the self-organizing team, Okay, well, what do you think? Well, I don’t know, we got this or this, we can make pork chops or we can make stew. Well, okay, I don’t know which one.

0:41:36.9 D Lane: So now we get to the point of, It’s not just reacting, is how much do I trust the other people on the team? I know that Matthew is really good at things that are of this type of nature or these types of seasonings, if we have ingredients that fit that profile, I might want to defer just because I will be able to trust him, and know he’s going to build something that’s going to be great, it may not win, but it will be great regardless, and that’s this idea of the self-organizing, the trust, and in barbecue like I said, it’s the most apparent there. Now, for folks that are at home, backyard, barbecue guys like me, I think that this becomes real apparent in just some examples that we’ve already given, like how much fat should I trim off of brisket? Well, there were some requirements that there was designed that people said that they had success with, and I tried those, it turned out that it’s not that they worked or didn’t work, necessarily, I can rank them on how much success I had, but if I found a better way of doing it, if it emerged through experience and practice and it was a better method for me, well, that’s why it emerged, I didn’t limit myself to saying, Well, this is the requirement, somebody else did all the design thinking up front, and so I’m just going to follow their instructions.

0:43:00.6 D Lane: It’s great as a starting point. And I definitely would warn people against starting out doing their own thing before you’ve learned how to follow some other people who’ve been before you, that’s going to slow you down quite a bit if you don’t, but I think that’s part of the learning curve, and that’s why we have things like Scrum, that’s why we have extreme programming, those are people who’ve gone before you, this is a starting blueprint, but the way that I often try to reset people’s expectations is they think, well we’ve been doing Scrum for six months, we’re experts at it and all that, and I said, Well, first of all, you understand, you should always do Scrum out of the box if you’ve never done it before until you start making changes. Second of all, you understand Scrum is for kindergarteners, this is the beginning entry point, this is not the master level, no that masters can’t use Scrum. That’s not what I said. Listen to what I said, I said, it’s the beginning point, it’s the entry point, this is the training wheels.

0:43:58.9 M Edwards: Excellent way to start.

0:44:00.1 D Lane: It’s a great way to start, and XP is a great way to start. And all I’m saying is that I think it’s definitely people-centric for barbecue, it’s people-centric, and I think you can apply a lot of these same things, you can apply a lot of the techniques, you can write user stories for your barbecue recipes, you can create a Kanban board for everything that’s going to go on the pit and keep track of, is it on the pit, is it off the pit, where is it at? There’s a lot of these things that will translate the different building blocks that you have, so principal 11, I think the best things emerge and they emerge with what you’re comfortable with, what you gain proficiency with, I think for principal number 12, after every cook, after every barbecue contest, you have to have a retrospective, you have to go back and say, Okay, what did we do, what happened? Why did we make those reactions, how did we recover? Did we think we did well? Was there a better way? Was there something that we knew about that we could have done that we just, didn’t occur to us, and if so, how can we make that more evident next time? So I think that that happens whether you’re part of the contest, or again, you’re just doing ribs in your backyard.

[barbecue sizzle]

0:45:13.2 M Edwards: So let me just bring it all the way back around to how we started this conversation, which was around the Manifesto in and of itself, while there is value in the items on the right, we value the items on the left more. Now, you could argue that that’s a declarative statement, but that’s not how I read it. How I read it is, Hey, we favor these practices, these principles, these tenants, these behaviors, that doesn’t mean there aren’t others, but these are the ones that we have found enable the greatest number of value-based ripples in the journey, and so I love that as the bookend to this whole conversation, because they basically said, Hey, here are the things that we have seen, here are the things that we think, here are the things that we favor and believe and suggest and recommend, and would love to talk to you about it. Now, we’re going to drill down harder on it with the principles as well. There’s value in the items on the right, so they didn’t make any declarative statement that says, You must not. You shall not. This should never happen. It wasn’t a set of negative statements, it was a set of positive statements that says, this can work and this can work, however, we favor this one over here because we feel like the results are richer, there’s a greater value proposition in the things on the left.

0:46:43.5 M Edwards: So I love the fact that it’s a positive set of statements, we favor this, this can work also. We favor this. Because they could have gone completely negative on it, which is to say, anything that has come before us is stupid, anything that’s contrary to what we document is also stupid, if there are new versions of this in the future, that’s stupid. This will stand the test of times forever, and that would be completely counter-intuitive or even antithetical to its entire point of existence, which is: learn, change, become. And to your point earlier, this doesn’t have a darn thing to do with tools or any codey things or any technical things, it’s about people everywhere in all of the directions.

0:47:33.0 D Lane: And so, one of the things we talked about early on in this conversation was the learning that I had come across that originally, or initially in my career, once I was introduced to technology and building technology, that when you try to build something, you try to figure out what the problem is, that people were about 10% of the problem and technology is about 90% of the problem, and with the caveat that, Yes, technology has grown tremendously, and we’ve got a lot more options available today than we did back into the dinosaur days that I’m initially referring to, but through that time, I’ve come to know or revise my thinking to believe that technology is now a 5-10% of the equation, and people are really 90-95% of the equation. And so when we’re dealing with people, and we realize this is really about people, and we realize that while there is value to the items on the right, as you said, it doesn’t mean there’s no value, there is value, we’re making that declaration, but we value the items on the left more, and why do we value them? Because of the first part of the manifesto and because of the principles that are how we illustrate that.

0:48:51.6 D Lane: I saw a quote recently that I thought it’s not attributed to anybody, so I’m not sure who originally said it, but I thought it was a great synopsis really of agility, and that is our responsibility in responding to change is to adapt. So to me, the thinking here is, the reason people focus on tools, the reason people don’t focus on people is because: tools are easy, people are hard. We don’t want to solve the hard problem, we want to show progress, we want to fill up the queue with busyness. And one of the things that I’ve learned is to never mistake activity or busyness for results. Lots of organizations are filled with activity, they’ve got busyness all over the place, nobody can ever get to everything on the list that they’re given, and they contribute to that list themselves, because of the other things, the constraints, the environment, the reward system, but now we’re back to wearing our archeologist hat, is there evidence of agility, is there a continuous frequent delivery of value with customer feedback to help us pivot or persist? And if there’s not, then we may not…

0:50:20.1 D Lane: When we’re back to executives wondering, Hey, we’re spending a lot of money training and making this change, is this really worth it? The answer may be no, you’re not getting the value you should be getting nor are you getting the value of you have potential because the environment you’ve created has shut people down, you’ve copied and pasted your previous organizational chart, and just renamed everybody that was a Project Manager to a Scrum Master, and the infinite number of anti-patterns that you and I have seen about things not to do, how many volumes of books could we write of these are things not to do? This is almost guaranteed to constrain, if not completely kill agility.

0:51:01.5 M Edwards: I have absolutely enjoyed this conversation, walking through the Manifesto, walking through the principles, and in particular, I have a few times in my life been more hungry [chuckle] than when we have paralleled these things to barbecue. But it makes absolute sense to me that if you don’t want to talk about software, let’s talk about barbecue and you can absolutely apply this Agile software development manifesto from top to bottom to a barbecue journey, every word in these sentences can be applied to barbecue, and I love it.

0:51:38.1 D Lane: Well, as I said, I’ve been looking to do this for a while, I really appreciate you pointing my brain and my conversation in this direction and helping me be able to focus on it for a little while. Thanks very much.

0:51:51.5 M Edwards: Thank you for listening. This is the final episode of the series with D Lane and the intersection of barbecue and the Agile Manifesto.

Categories
Podcast

Part V: How Deconstructing the Agile Manifesto Makes You Better at Barbecue

Show Highlights

In this episode, Derek Lane and Matthew D Edwards deconstruct principles 7-10 of the Agile Manifesto to help software developers and engineers bring more value to clients but also, become better barbecue pitmasters.


Read the Transcript

0:00:00.0 M Edwards: My guest, Derek Lane, and I continue our conversation mapping the Agile Manifesto, and its 12 principles to making better barbecue. In this episode, we cover principles seven to 10, and I recommend staying until the end because Derek shares how to keep things simple in order to make amazing brisket.

0:00:24.2 D Lane: It’s the pursuit, the constant, never-ending pursuit of value and value as defined by the customer. Now we’re back to number one, it’s to make the customer happy, to satisfy the customer’s goals. Is that to increase business? Is it to move into a new market? Is it to experiment with the product? Is it to reduce cost or reduce expenses? Is it to reduce the number of people it takes to maintain some part of their business? Is it to get the best barbecue that you can get this side of the Mississippi, whichever side you’re on?

[music]

0:01:07.5 M Edwards: Welcome to the Long Way Around the Barn, where we discuss many of today’s technology adoption and transformation challenges and explore varied ways to get to your desired outcomes. There’s usually more than one way to achieve your goals, sometimes the path is simple, sometimes the path is long, expensive, complicated, and or painful. In this podcast, we explore options and recommended courses of action to get you to where you’re going now.

0:01:39.1 Speaker 3: The Long Way Around the Barn is brought to you by Trility Consulting. For those wanting to defend or extend their market share, Trility simplifies, automates, and secures your world your way. Learn how you can experience reliable delivery results at trility.io.

0:02:00.9 M Edwards: The next one of these principles, working software, is the primary measure of progress. I love it, I love it, I love it. It kinda harkens back to the, “We prefer working software over documentation,” or even my original commentary, which is, “Hey, man, there’s a time and a place to show up with a PowerPoint or a Word doc or whatever it is that you’re generating, but the reality is that if you’re a technologist and the client hired you to deliver some technology, they want to see technology.”

0:02:32.9 D Lane: Again, if we abstract this a little bit, it’s value. Whatever the value is, is the primary measure progress, the delivery of value, okay? How much better are you at delivering value? We’re spending hundreds of thousands of dollars to have consultants come in, or we’ve hired extra agile experts. How do we know if it’s making a difference? How do we know if we’re getting better? The delivery of value is how we measure progress.

0:03:09.4 M Edwards: I like that question you asked, “So you’ve adopted X, are you delivering more value than you were?” That’s really the conversation.

0:03:18.1 D Lane: Exactly. For me, if it’s possible, and it’s really hard because there’s so many facets to what is agility. How do we know if agility is occurring? Or is possible? Or is improving? So that at any point in time, we have the ability to adapt. So how do we know? It’s the never-ending pursuit of value and value as defined by the customer. Now we’re back to number one, it’s to make the customer happy, to satisfy the customer’s goals. Is that to increase business? Is it to move into a new market? Is it to experiment with the product? Is it to reduce cost or reduce expenses? Is it to reduce the number of people it takes to maintain some part of their business? Is it to get the best barbecue that you can get this side of the Mississippi, whichever side you’re on? Whatever the pursuit of value is, to me, is the closest to a nutshell that I can put agility in. And in this case, how do we know if everything we’re doing, whatever that is, is making us better? The way we measure progress with agility is by delivering value.

0:04:37.4 M Edwards: So I’m standing beside you, we’ve been smoking this brisket for quite a while. I’m able to stand beside you when you lift the lid if and when you open the box. I’m able to stand beside you as you’re putting more wood in. I’m able to stand beside you as you succumb to the temptation, or to my persuasion to just let me cut into it just a little bit and taste it. But the reality is, I’m there beside you, we’re journeying together, and I know things are happening but I’m even more incited to continue on this journey with you. If you act like you didn’t notice that I took a little piece off that brisket when you turned around, or if you said, “Hey, I know it’s not quite ready yet, but let me give you just a little sneak peek of the sauce or the rub that I used.”

0:05:27.4 D Lane: Yes. And if you’re the customer, imagine how different whatever we call a project would be, if we have that customer going through the same experience with the team that is developing and delivering that value. Because now the level of communication, the level of transparency, the level of trust… You get to see, you know the effort I put into it, you know the decisions I’ve made, if we’ve had a discussion, you know pretty much why I did everything I did to the degree that you were interested or it made sense. And barbecue, in this case, is no different. It’s great to go to whatever your local barbecue place is, go on a day or a period of time when they’re not busy, call ahead if you want to. Ask if you can go in the back and see their pits, ask if you can talk to the pitmaster. You can just learn about what kind of wood they use or what their technique is. That gives you a different view, a different experience, a better appreciation for the value that you show up and get as a customer. You just get in line or you order from the menu and it magically shows up, that’s the way most people want to order their technology and their products, but the reality is that it rarely gets them what they want. It’s like ordering a very specific order, but what shows up is not really what you ordered.

0:07:01.1 M Edwards: And that’s where I have heard someone characterize in Past Lives that it’s fine to deliver as committed and the customer or the client may say, “You’ve done well, good job, thank you for your time.” But an exceptional experience for the class customer is when they are delighted, when they are beside themselves with happiness, because you not only did what you said you would do, but you delivered a version of that and or more. That helped them realize their goals quicker or differently or more evaluably. Working software is the primary measure of progress as it relates to the technology, but it still, to your point, rolls up to satisfy the customer and satisfy isn’t just, “Here’s brisket.” It’s, “Here’s brisket that you’ve now canceled the rest of your afternoon so you can just marinate, soak and enjoy the meat sweats that go with it.”

0:07:57.7 D Lane: That’s really I think what is intended by “satisfy the customer.” It’s the level that Simon Sinek talks about when he says that everybody needs to understand their why, the golden why. The idea, people don’t care about what you do, they care about why you do it, and that is very true with barbecue, but I think it’s evident in this particular principle. You said something else that I think is very much buried in this, it’s taken me years to try to find a way to talk about it. And that is that we often talk about backlogs and effort, level of effort, and, “When will I get to see something?” And, “When will things be done?” And we talk about commitment in that context. From my standpoint, I feel like one of the light bulbs that demonstrated that I got it, that I really was beginning to understand what agility is, is when I understand… When I began to understand committing to a backlog is wrong, it’s incorrect, it’s making… It’s efficiency in the same sense that we’ve always been doing projects, in a waterfall sense, it’s traditional that has carried over even into the agile space, and we haven’t realized it. We’re still polluted with these concepts, and it affects what we do and how we do it.

0:09:27.0 D Lane: Instead, I would submit that we should agree to be committed to the values and principles of the Agile Manifesto. I think if we’re committed to those and we agree that the decisions we make and the behavior that we subscribe to will illustrate and demonstrate the values and principles, we can trace it directly back to that. And the illustration that I use for a lot of teams is, if we were an archeologist and we were looking for evidence of agility in your company, would we find it? Would we find hieroglyphics that demonstrate that agility might have been here? Would we find frequent delivery of value? How frequent? What does that frequency mean in the context of whatever the value is you’re delivering? Would we find dinosaur tracks? Would we find fossils? Would we find evidence of agility? So whether it’s Lean or Agile or human-centered design, would we find evidence of that? And by evidence, I don’t mean burndown charts, I don’t mean sticky notes on a whiteboard, I’m talking about the kind of evidence that says… Not that says, “We were doing practices,” because you and I both know we’ve seen those things as evidence in environments where agility did not live. So that’s not evidence of agility, sticky notes on a whiteboard and burndown charts, burnup charts, whatever, that’s not evidence of agility, that’s evidence of a practice, or that’s evidence that someone thought this needed to be created and it was left behind.

0:11:12.7 D Lane: So what is evidence of agility? Evidence of agility is a group of people who trust each other, that’s evidence of agility. Now back to principle number five, let’s create an environment, let’s invite people who are motivated into that environment, let’s explain to them what our problem is, let’s trust them to do it. So there’s lots of things that are evidence of agility. And I think that the way we achieve that is to not commit to a set of backlog, a set of things in a backlog that is going to change and that should change as we learn more. If we assume that, then we realized, “Well, that’s really not a good thing to commit to, it’s too fluid. We should instead commit to the values and principles of the Agile Manifesto. If we do that, first of all, they’re not as fluid. Second of all, the deeper we understand them, the better we can apply them. And third, it becomes a common shared baseline ruler that we can all use and talk about how we can improve it? And how are we interpreting it? And are we applying it in a consistent way?”

0:12:28.1 M Edwards: So the net still is working product.

0:12:31.5 D Lane: Yes. The measure of progress is a working product, evidence of agility is the elements that allowed you to create a working product. So it’s the frequency of delivery, it’s the delivery of value on a regular basis, it’s the delighted customer, that’s evidence. The measure progress… So we can make progress while we’re still on our way, right? We’re going to drive from where we are to the other end of the country, we can make progress without getting to the end. We don’t have to wait until we get to the end to say, “Did we make progress?”

0:13:14.6 M Edwards: So archeological evidence, to some extent, of agility then is additionally articulated in the next principle, the eighth one on this list, which is, “Agile processes promote sustainable development. Explained, that means sponsors, developers and users should be able to maintain a constant pace indefinitely.” The reality of the situation is we’re talking about perhaps some form of psychological safety, we’re talking about a healthy environment, and we’re talking about a team that’s composed of people who are all equally able to say, “This is what I think, this is why,” and they together in the self-organizing teams that are saying together, “We know we’re in a marathon. We know the work that’s in front of us. We are able to adapt to change and invite that as necessary. As such, we’re not going to kill ourselves on this iteration. We’re not going to kill ourselves on the next six iterations, because this could be a 200 iteration project with multiple major release drops along the way that are publicized by the marketing teams and so forth. It’s lasting.” What type of team and people and environment do we need to create in order for people to last?

0:14:40.2 D Lane: The way you described it as the first statement, “Agile processes promote sustainable development,” being explained by the second statement. The sponsors, developers, and users. Well, this is the first time we’ve heard sponsor. Before we heard customer, we heard business and we heard developers. For the first time, we’ve heard sponsor in the sequence of principles. This is where we begin to realize that I can have a customer who could be an end-user and I need to delight them, I can also have a customer, which is the person who’s paying a.k.a. the sponsor to develop or deliver this product. What delights each one of them is not necessarily the same thing. And the more complex the value that you’re delivering, the more likely it is that what makes… That will delight them is not the same thing.

0:15:32.9 D Lane: An end-user for Google is very happy to get fast results, the fact that ads can influence the results means that I may not get what I want, the fact that my history influences the results and they’ve updated their algorithm for that, however that satisfies the desire of Google the company, that’s how they’re making money. They want their ads to be effective, they want the customers of the ads, the people who are paying Google to place the ads to be happy so that they continue to advertise on their platform. So Google, the person, the sponsor paying for the development delivery of products, their goals, what makes them happy, what makes them… What gives them a competitive advantage, is not the same thing as the people who are the end-users. And here we get a little bit of insight into that because we’re talking about the sponsors, the developers and users of that.

0:16:32.0 D Lane: So we realized that the ecosystem of people and the roles they play is broader than we’ve covered so far, you just need to think about those roles and the people, and you need to adapt, which is what agility is, is adapting as you learn more things. I think the next interesting thing about this principle is, remember principal number four, “Business people and developers should work together daily throughout the project.” Where are the business people in this principle? Because the sponsors could be the actual client who’s paying for us, who has end-users. Now we’re back to, “Okay, business people should be part of that development team.” And then of course, end-users are the end-users of that client, the people who buy things from the floors.

0:17:22.7 D Lane: So I think what’s happened here, and it’s a very subtle thing and I didn’t see it for a very long time, is that the authors of the Agile Manifesto did something that we run over so quick, it’s not even a gigantic speed bump, and that is that they went from, “Business and developers should work together daily,” into, “Okay. We assume that’s happening by the time we get to principal A.” And so it’s encapsulated in this idea of developers. And the developers here might not mean just the technologist in the case of software technology, it could be everyone. Now we’re back to our original idea, “Everyone involved in delivering value should be included in that.” So if that’s the marketing department, if that’s HR, if that’s legal, whoever it is, they should be part of that conversation. This means, now we’re back to principle number four, they should work together daily.

0:18:15.3 M Edwards: Right, they’re interwoven. This is a tapestry, these are not single threads that could be practiced alone.

0:18:22.0 D Lane: Absolutely, and that’s how I think most people see these as individual discrete values and principles, when in reality it’s really more of a network graph, every one of them is connected to every other one. So barbecue, how does this relate to barbecue? I think Agile processes promote sustainable development in that it is difficult when we talked about cleaning your pit before, and that you can get debris in the way that can actually get in the way of you delivering a consistent or a good product, at least on a regular basis, if you don’t… If part of your process, your regular process, not necessarily every time you’ve cooked, but if you don’t have something that says Every so often, I’m going to clean out the ashes, I’m going to check for debris, I’m going to wash my meat, we mentioned about that earlier, about… These are consistent things, doing these things.

0:19:22.4 D Lane: How does that… What does that mean with an agile process, how is it related to that? Because it gives us more consistent results, it becomes sustainable, we get to this idea of sustainable pace, which is also embedded in this, to maintain a constant pace indefinitely, the more common phrase we use is sustainable pace, that’s also in the first statement, promote sustainable development is sustainable pace because, in reality, you may need to work more than 40 hours, the intent of 40 hours was to say, Let’s don’t burn people out to the point that they can no longer think when that’s the critical value add that they have, so let’s don’t get them to the exhaustive point, whether you leave the project or with all their domain knowledge and everything else. Let’s stop before then. Let’s make it reasonable. Sometimes it’s going to be 45, maybe it’s going to be 50, maybe sometimes it’ll be more than that, but we should be aiming at something that’s reasonable and sustainable for everyone.

0:20:24.1 M Edwards: That makes sense. So in context of the archeological examples of agility, looking inside some particular culture or sub-culture, that brings us to the next one as well, which is pretty interesting because of the implications, how spiders into the team, the team construct, the team behaviors, the team attitudes, continuous attention to technical excellence, and good design enhances agility. That’s one of my favorite conversations here. Now, from my perspective, this leads to all kinds of things. So continuous delivery pipelines, continuous test, security by design. All kinds of conversations like that. Good design enhances agility. For years and years and years, we’ve had the merits of this architectural behavior over this architectural behavior, or the merits of this design structure, or this design pattern, and so forth, talking about lots of the tools and the toolboxes.

0:21:22.1 M Edwards: My favorite thing out of this though is still a people conversation, I believe this again, points back to people and relationships, continuous attention doesn’t just mean automate all of the things in your infrastructure is a code environment or you continues deployment environment. From my perspective, at the most fundamental level, continuous attention to technical excellence is not only having a group of people that are pursuing mastering their craft, but it’s practices like test-driven development, pairing, pair-switching, mob programming, finding ways to enhance and lift and amplify people, and people together, it’s still organic. It’s still relational, it’s still people. We can add tools, but it’s still people.

0:22:11.5 D Lane: I definitely think that’s a great way to interpret the continuous attention phrase, it’s definitely… People are who we’re talking about, paying continuous attention. I think this exposes… This principle exposes one of the long-held and long-promoted… We’ve always done it that way. It’s a good industry saying, and that is this idea of best practices. To me, that is… It’s severely flawed in a number of ways, the way that it’s often used in most companies, this principle exposes that while you may know the… You may have a level of skill, a pursuit of mastery that you mentioned, I may have a level of proven ability that delivers value in some way, but the point at which I say This is the bar, a.k.a. our expectation, this is our best practice, and we document it and we promote it, and we make sure everybody’s doing it, that is the exact second at which we quit innovating, that’s the exact second in which our agility begins to go down, it’s the exact second in which people will be reprimanded for thinking and trying to make something better.

0:23:34.6 M Edwards: Well, it’s consistent with other behaviors that we sometimes see in companies or teams or projects whereby we say, Well, that person is responsible for the user experience, that person is responsible for regulatory compliance, that person is responsible for data, and a challenge that comes along with those types of designations, similar to what you’re saying, is after it’s stated, it then becomes no one else’s responsibility as their primary thought process, so I tend to favor part of the Idea propagated by Mike Cohen and user stories, user stories applied, estimating all of that is that a user story and its associative acceptance criteria actually reflect all of the personas required in order to deliver that user story, which then is a component of perhaps a larger epic or whatever theme to the light of customer, but inside those acceptance criteria, those things actually reflect all of the rules.

0:24:36.0 M Edwards: And so technically, if we are a team, a self-organizing team and we together, composed of many different roles are responsible for delivering the software, security is everybody’s job in my opinion, user experience is everybody’s job in my opinion, and delivering well is everyone’s job, but one of the ways I’ve liked to mix it up instead of designating, and then you become this thing forever for this particular breakout, Derek, you’re handling user experience, but for the next breakout, you’re handling regulatory compliance. And so it forces everybody out of their behavioral patterns to say, “Well, this is my expertise, I do data, I don’t do user experience, that’s that other person.” Those are interesting conversations to have continuous attention to technical excellence, I think it requires you to think broader than just your personal favorite sweet spot.

0:25:37.8 D Lane: I completely agree, and I think another… In addition to that, which is a huge problem, people get essentially assigned and identified, so what you’ve described, as I heard it, was the assignment of some role or characteristic or responsibility, I think the same thing is also true with regard to the idea of, I introduce Matthew as the data expert on this particular thing, and that means now until forever, you have been put in that box, and that means that I don’t… Not only do you not think about things outside of that, I don’t listen to you about things outside of that, because you’re the data guy, you don’t know squat about user experience or about whatever.

0:26:31.1 D Lane: Well, okay, so I’m devaluing the fact that you are an individual and that we have interactions and that you are a knowledge worker, I am deferring all of those questions to a constrained, limited number of people, and I’m also ignoring some great innovation that I’m not all ignore it, I’m intentionally excluding it from ever happening because we’ve squeezed it out of the process, now we’re back to continuous attention to technical excellence and good design enhances agility. Innovation enhances agility. I think another characteristic here is there’s technical excellence, and then there’s good design, those are not the same thing, they’re discrete things that we’re called out here, I think in barbecue, technical excellence might mean…

0:27:23.0 D Lane: I have good fire management, I understand the mechanics of how a particular pit draws, how to deal with the managing… Not only the fire, but the smoke, I need to manage the heat, I need to… Is there a cold spot? Is there a hot spot? Is there a certain element that I’m going to put on the smoker that even for a short period of time is going to get way too much smoke so that it’s going to ruin the value, my ability to deliver value with that item? There’s a lot of things here that we could talk about that are the technical excellence part, good ingredients make a big difference in just an average set of skills, you can end up with a lot better barbecue if you really get good, and I don’t necessarily mean more expensive, I just mean, you have to… It comes down to quality, not price, but the design is also important, and that’s back to things I’ve talked about, like the order in which you want things to come off the smoker, so that everybody gets to eat everything, everything’s kind of completed at the same time. I have to plan what order to put things on the smoker, everything doesn’t go on at the same time. If I’ve got something that’s going to take eight or 10 or 12 hours, I may have to wait until two hours before that to put something on.

0:28:43.3 D Lane: Cobbler is not going to take that long, so I need to put it on an hour or two hours before, it’ll have more than enough smoke, it’ll be perfectly done, even if everything’s wrong when I put it on there, whatever that might mean. So now we’re getting to the point of both of those are intentional, and I think that’s the continuous attention piece, it’s intentional, only people can do it, you can’t automate it, and it improves our ability to innovate, to come up with ideas, to not constrain ourselves to the way we’ve always done it, not only by putting people in a box, not only by saying this isn’t the best practice, well, how are your best practice is ever going to get any better if they can only be best… Whatever your current idea of a best practice is.

0:29:24.2 M Edwards: I love that call out, the call out basically, you led with was once I define a set of best practices, it often leads people to stop innovating, so if I say this is the line, all projects hereafter need to have these 10 characteristics, these behaviors, these toolchains, whatever, whatever the definition of the spec is, this is the best practice. People will spend all of their timeline following and not as much time figuring out how to add context-driven value for the client. I think that’s also a really good amplification of why the manifesto may be written the way it is, which is, these are the things we prefer, these things are also valid. So they didn’t disqualify. They just said, we favor these things in this context, but nothing about it is declarative that says If you don’t do it like this, you will fail, it just says these have proven time after time to be valuable patterns by which we’ve all experienced value-based success with our clients.

0:30:38.0 D Lane: And I think to that point, oftentimes, especially large companies that will say, Well, that works again, this idea that works for a startup, that works if there are only 10 people, it doesn’t work when you’ve got hundreds or thousands of people. It does work. I’ve seen it work, I’ve helped companies achieve this, not the majority of companies I’ve worked with because they didn’t want to believe it would work, they were too… They believed any level of change is a risk, and so therefore it was riskier to make that type of change where something is believed to be the level of perfect-ness is related to the lack of risk associated with something, the fact that we’ve done something three times and repeated it.

0:31:23.2 D Lane: Well, it must have very little risk, not necessarily, but again, we tend to view things in these very binary terms, every day we should be learning, we should be innovating, we should invite those things, we’re already saying we’re welcoming changing requirements. But again, we’re in an environment where we’re going to find motivated individuals and we’re going to trust them to get the job done, if these things are true, [chuckle] let’s talk about the measure of progress and how much progress you’re really getting. Are you really improved to delivery of value or you just… Is it all on paper?

0:31:58.8 M Edwards: And so far, we’re still talking about people, we’re still talking about relationships, and we called it out a little earlier, but in my own personal experience, I have found the ability to adapt and add value to a client is absolutely directly proportional to the attitudes and aptitudes of the people on the team. So putting together your team, building your company, it’s people.

0:32:26.8 D Lane: I completely agree. I think another way to characterize that relative to this conversation is, does the team… When the team is discussing something, do they see possibilities or do they see constraints? That’s the thing we talked about, creating an environment and supporting them and then trusting them to get it done. Well, that’s part of the environment. And if your answer is, I don’t know, or no, they see constraints. Well, if you’re responsible for helping to build or support that environment, that’s a chance for you as a leader to say, we have a lot of room where we can improve with agility and I’m going to… This is the biggest way that I can help.

0:33:04.8 M Edwards: So do your people see possibilities or do they see constraints? That is lovely. Wonderful. Well worded. Let me jump us to the next one because this is fun. Simplicity, the art of maximizing the amount of work not done is essential. There are so many places to go, take that conversation. Simplicity, from my perspective, one of its implementations is know when to talk, know when to shut up.

0:33:39.7 D Lane: To me, this is two principles in one, the first one is, simplicity is essential. That’s the key idea. Now, the second part of that, okay, well, simplicity could be in lots of different ways, that’s very vague. What do you possibly mean? The art of maximizing the amount of work not done. I relay a lot of firsthand experience that I’ve had with teams where there was some desire by some leaders somewhere to say We need to do better, and I would end up working with that group as part of that group in some capacity and would… At some point, you see a direct crossroads where you can either continue to always do whatever it is we’ve always done, and we’ll keep getting those results more or less, plus or minus some negligible amount, and oftentimes that… Interestingly enough, that negligible amount, the fact that it moved could be considered a great win if the politics are heavy in an arena, but the reality is, and knowing the distinction from my standpoint, who decides what’s valuable…

0:34:48.8 M Edwards: Left alone, a developer, will struggle with the definition of done. If there is no declarative and there’s no client interaction and there’s no one sitting around, the developer understandably wants to do a good job, they want to deliver value, they want to do the thing that’s necessary in order to provide the wind that the client’s looking for. But absent a definition of done, there could be a whole lot of extra work produced that was never needed, and so one of the ways that I back into this is, if we’re doing these iterations or this frequent delivery and constant communication with a client, and we’re walking together, step by step by step-by-step, many moments a day, many days in the week, many weeks in the month, and so on, we’re going to discover the definition of done together, and that means we won’t have spent time building things that will never get used, or building things that no one asked for, or building things in a way that they were never requested because we were lockstep the entire time. So that’s one way I back into this also is if I have a frequent iterative relationship with you, communicative and then deliverable for re-factor loops and so forth, I deliver the thing that I need to deliver and nothing more and nothing less than we’re done, and that helps manage my cost of acquisition and also impacts my cost of ownership in the long term.

0:36:20.8 D Lane: I think you pointed out some very important things for a lot of the business-minded folks. I’ve used the same approach to help teams and leaders understand that the plan they have most likely includes some things that they don’t need. Well, how do we identify which one they are? Well, first of all, let’s make sure we’re building the right thing, have you talked to your customers? Well, we talked to three, but I’m an expert in this area. I’ve been doing this be 25 years. I’ve been in this role for 15. I know this like the back of my… Have you talked to your customers? And typically, I relay a first-hand experience about dealing with a product owner, even a brand new product owner, never been a product owner before, but someone who knew the domain and was willing to talk to the customers when none of the people above this PO were willing to talk to the customers because they were so convinced that they were blinded by their accepted understanding of what the customers needed, that they had built a backlog that was years out into the future.

0:37:41.3 D Lane: And we were able to talk to customers and identify a single feature set, and in a matter of less than a couple of months, we were able to start from scratch using a technology stack that was foreign to this company, and we were able to work in a very iterative fashion with new skill sets like user experience people, which were believed to be only if you’re doing a brand new product, there was a lot of you’re in a box, and we’ve defined and shaded the box this way, and we were able to very focus on the simplicity, and for the first time ever, in multiple decades at a user conference of this company, which is an international company, we were able to demonstrate working software, ever.

0:38:29.1 D Lane: Typically, it’s all PowerPoint, typically it’s all wave your hands and talk about it, and typically it’s all VPs or whatever doing these types of things. For the first time, our new product owner, he’s only been a product owner now for a few months, was able to get up and say, we talk to this set of customers and their profile is like this, this is a set of features that we heard from the market. Here, let me show you what we’ve built so far, and we’d like to get your feedback, and as I understand it, for the first time only standing ovation because it was the first time that the users felt like that you’re being heard.

0:39:09.3 D Lane: This saved multiple clients who were basically waiting for this particular conference and whatever was going to be shown to make the determination whether they were going to continue with this customer or not, and these are multi-million dollar international. This is the biggest of the big, this is not small fry, this is not a start-up, this is a company that’s gotten decades and they’re number one in multiple markets around the world, and yet they were struggling with putting things in a box and best practices and the way we’ve always done it, we know this our domain and our customers when in reality they didn’t, they somehow…

0:39:45.2 D Lane: And I’m not… This is not a blame, this is not a fault, it’s just a reality of some focusing on simplicity, the amount of work that we did not do that was on the list was worth millions of dollars of development time, not even counting support and maintenance and training and all of that, we did not do that and we delivered simplicity with a different approach to the point that that became now the experience that they were looking for. They were looking for other parts of the system to now begin to behave this way and take the user as a priority, so it demonstrated a way forward where before they could never do it because technologically, the legacy code, the technical debt was just insurmountable. But here we demonstrated a new path forward and again, got first-hand customer approval, we got the delighted customer, they were the standing ovation, they’re like, “Yes, this is what we want. When can we have it?” ‘Cause obviously now they’re seeing working software. Before we go on, I’m wondering if… An example for barbecue, for simplicity, might be useful. One thing that occurs to me is, we’ve talked a lot about brisket, and there’s a lot of different techniques as we mentioned for different folks, and they will swear that this is the way they get their superb repeatable results.

0:41:09.2 D Lane: But in the case of brisket, a common strategy, and what I was taught for pretty much everything I ever saw was that you need to trim off almost all of the fat, most people buy what’s called a packer, brisket. It’s the big one you see in the grocery store when it’s on sale for Memorial Day or whenever you can catch one on sale, and they’re typically in the order from 8 to 12 pounds, sometimes up to 16 pounds, half of that weight is fat. The butcher cuts it in such a way that there’ll be fat on across the back, called the fatback of the flat all the way across the backside of the brisket, and I was taught well, okay… More or less, it seemed that the general prevailing thinking was no more than an inch of that, that you do want fat in general because the fat’s what melts into the meat and moisturizes it, that’s the chemistry that’s going on on the smoker, but low and slow allows the fat to basically moisturize and tenderize the meet over a period of time to the point that it becomes the soft pasty thing that you get out the end, and you’re going, “Yes, this is what I wanted.”

0:42:24.8 D Lane: So no fat, which I’ve actually tried that because I found some people who said, “This is my strategy.” I’ve tried the no fat, for me that was more difficult, it was not as repeatable. The results weren’t what I was looking for, but all the strategies that I heard about cutting the fat, literally pun intended, across the brisket, got me more or less the same results, so when watching one particular guy on TV, he didn’t trim any fat of his. And I thought, okay, insanely enough, I haven’t tried that. It’s simple, you wash it, but don’t cut it, because trimming the fat from a brisket can take a good deal of time, so I don’t trim it, I put it on there and dadgummit if that wasn’t as good as anything else I had done, as far as the level of effort that went into it, so the simplicity of that turned out that it was essential in order for me to get an easier, a less time-consuming effort. And if you’re doing multiple briskets you multiply that times four or five, 10, however many you’re doing, so this becomes… You’re actually simplifying the whole process considerably, it becomes now a much easier process for a much less experienced person to be able to get consistent results. Wash your meat, don’t worry about the fat on the back, place it on the smoker… Use rub or marinade, or if you’re doing anything in particular there, and then put it on the smoker when it’s…

0:44:05.0 D Lane: But there’s a few other things, like I’ve learned, for example, let your meat come up to room temperature. For years and years, I would take it out of the refrigerator and we were concerned about the meat sitting on the counter for more than 10 or 15 minutes, not being in the refrigerator, but in reality, the density of the fat will keep the overall piece of meat at a safe temperature for a significant amount of time, so it’s really not an issue unless you’re going to eat out half the day or something like that. So even an hour, not a problem. So there’s things like that to just make the whole process simpler, managing the fire can be the same way, there’s lots of simplicity things, and they become about maximizing the amount of work not done. I don’t want a 295-step method because it’s complex, and my barbecue is the best, I would like to have a method that’s four steps that I could teach my grandkids.

0:45:08.4 M Edwards: Thank you for joining Derek and I, as we explore the Agile Manifesto. I hope you return for the final episode of this series when we cover the last two principles, I also encourage you to subscribe to the Long Way Around the Barn.

0:45:25.8 Speaker 3: The Long Way Around the Barn is brought to you by Trility consulting, where Matthew 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:45:42.5 M Edwards: To my listeners, thank you for staying with us. I hope you’re 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.

Categories
Podcast

Part IV: How Deconstructing the Agile Manifesto Makes You Better at Barbecue

Show Highlights

In this episode, Derek Lane and Matthew D Edwards deconstruct principles 3-6 of the Agile Manifesto to help software developers and engineers bring more value to clients but also, become better barbecue pitmasters.


Read the Transcript

0:00:00.1 M Edwards: My guest, Derek Lane and I continue our conversation mapping the Agile Manifesto, and its 12 principles to making better barbecue. If this is your first time joining us, we’re covering principles three to six. If this one makes you hungry for more, go back and listen and be sure to subscribe as we drop two more episodes covering the last six.

0:00:25.1 D Lane: There are so many aspects of this that I think we ignore the barbecue face-to-face, the most effective means of communication and efficient is to give someone a piece of barbecue and watch their reaction.

[music]

0:00:41.5 M Edwards: Welcome to The Long Way Around the Barn, where we discuss many of today’s technology adoption and transformation challenges and explore varied ways to get to your desired outcomes. There’s usually more than one way to achieve your goals, sometimes the path is simple, sometimes the path is long, expensive, complicated, and or painful. In this podcast, we explore options and recommended courses of action to get you to where you’re going now.

0:01:13.1 Sponsorship: The Long Way Around the Barn is brought to you by Trility Consulting. For those wanting to defend or extend their market share, Trility simplifies automates and secures your world your way. Learn how you can experience reliable delivery results at trility.io.

0:01:34.4 M Edwards: Let’s talk about principle three. So to deliver working software frequently, from a couple of weeks to a couple of months with a preference to the shorter time scale. Now, that harkens back to obviously number one, which is early and continuous.

0:01:51.0 D Lane: It also is representative of the state of software development in 2001 when this was written, it was written in February 2001. We have to realize, “Okay, that’s just after the end of 2000,” what happened in 2000, Y2K. Everybody was running around trying to retrofit legacy systems, so you had long development cycle, it was very common for things to be 18-month projects, these were very long type of delivery cycles that’s difficult for folks who are new to technology in the last five or 10 years to imagine it taking five years to deliver the next release of their web app or their mobile app, that’s incomprehensible. But that was reality at the time, that was a huge disruptive type of idea to be thinking that literally in a matter of weeks to months, we’re going to actually not just meet with the customer and show them what we have, we’re going to deliver working software. So correlating this to barbecue is a little more like that waterfall type of thing. The thing that’s useful to understand here is barbecue is a unique genre of food compared to almost anything else, at least in the U.S. that you can go to, you can go almost anywhere, and they open an hour, or the people who cook are there 30 minutes to an hour before the restaurant opens, you can order anything off the menu and get it in 30 minutes to an hour, from a steak to a salad to whatever casserole they have.

0:03:27.2 D Lane: Now, they may have a few things that may take longer than that, but they got there that early that morning and they made that so it’s relatively easy for them to pull it out, you cannot go to a barbecue restaurant if they’re out of brisket and say, “I’d like some brisket and have them whip it up… I’ll wait an hour.” No, you won’t. It won’t happen. “Well, we’re out of ribs,” no, that’s why when you go to a barbecue restaurant, it is common for them to have the menu and have a big line drawn through or something, and they say, “We’re out of this,” because the process it takes to make it is just time consuming, it’s the reality of the low and slow process, and so this idea of delivering from a couple of weeks to a couple of months can affect the planning or the sequencing of how you want to barbecue, if you like to, for example, cook beef ribs, there’s lots of places that quit cooking beef ribs because of the amount of time that it takes and the amount of space they take on the smoker for the number of people maybe who wanted them, so maybe they cut back to one day a week or one day a month.

0:04:39.1 D Lane: So on a certain day, first Saturday of the month, they’re gonna have beef ribs and it will literally say stay on the menu until they’re gone, and they will sell out every Saturday because once folks notice there, and that’s the only place, it’s not only a supply and demand type of problem, it’s literally a matter of, that’s the amount of time it takes for us to make this particular product, and you would like, I don’t wanna wait another two months or another three weeks or till a month from now on Saturday before you have it again, I want some right now, just like you said, I’m getting hungry right now. I would like some of that right now.

0:05:13.7 M Edwards: So one of my favorite parts of that third principle is deliver working software, and then the next word frequently, but deliver working software. My favorite part of that is, we typically tell people when we’re working with our own teams, we’re working with clients, we basically say to you, we want to deliver, we strive to deliver, we do deliver working, tested, demonstrable, production-capable software every iteration. The reason that I think that that’s important is, I don’t care if you have a working PowerPoint, do not show up and talk to me about a working document, I don’t care if you have 15 JPEGs of marker boards that you’ve worked on for 37 weeks.

0:06:00.3 M Edwards: When it comes down to serving the client, delighting the client, delivering what the client wanted. Can you imagine going to a barbecue restaurant and you said, “Dude, I want some ribs,” and they’re like, “You mean like that picture?” “Yeah, like that picture.” “Yeah, we don’t have those. But we have a great picture.” “Well, forget your picture, I’m freaking hungry. Find me some food, man.”

0:06:26.0 D Lane: “And we’re going to charge you full price for that picture.”

0:06:28.2 M Edwards: Yeah, so the clients aren’t interested in your working documents.

0:06:32.2 D Lane: No.

0:06:33.4 M Edwards: Or working tested documents or working, tested, demonstrable, production-capable documents, they want some freaking software that’s what they want. That’s my favorite part of that is deliver working software. And then also the qualifier: frequently, continuously.

0:06:50.4 D Lane: I would agree. I think that, again, to generalize this a little bit more, deliver working software could be deliver value, that means it has to be customer ready, and so this is another case in the case of barbecue where in software, you can take a lot of shortcuts and because it’s hidden in the code, your customer may never see it, they won’t know it, they’ll see the results of those shortcuts, but they won’t see the shortcuts themselves, you take shortcuts in barbecue, it may show up in just how it’s presented, it just looks sloppy on the plate or something, but it may also mean that now it’s a health hazard, there’s something you should have done that you didn’t do, you didn’t keep the product at a certain temperature for long enough and bacteria can be… And that’s true for all cooking. But those are things you need to learn specifically about barbecue, so they’re taking certain shortcuts, to me requires us to add in, essentially, the principle in my mind should say deliver value frequently with the preference for the shortest time scale that is feasible.

0:07:57.7 D Lane: So feasibility is directly related, feasible for certain value is different than feasible for other value. And in this case, because of the circa when this was written, we get from a couple of weeks to a couple of months. That’s really, I think, the context that the writers of this had, and again, 2001. And so it’s not that that’s wrong. It was very much effective and true back then, and a lot of people said it will never be possible to deliver every couple of weeks, I remember people saying that. I mean, big name people in big publications. It was not believed, maybe 100 years from now we’ll get there, but not any time soon. So now that we’re 20 years later and we realize, yes, we’ve been there for some time, and it was very doable back then, it just required things to be done in a more drastically different way, and a lot of those changes have become more mainstream now, so it’s not as drastic as it would have been in 2001, ready for number four?

0:08:58.1 M Edwards: Yeah, let’s do it. Business people and developers must work together daily throughout the project. So again, we said set right off the bat, that first principle cascades, it’s the top of the Christmas tree for everything that follows. And this point back to that again, actually work with the people, so business people and developers must be together, work together daily throughout the project, that seems so simple.

0:09:31.8 D Lane: And yet it is so far from simple for anybody who’s on it, even in either one of those groups. The thing that this points out to me is an inherent flaw in how organizations are organized. There should not be a separate group of business people and a separate group of developers, if they’re both working on the same product for the same market. They should all be part of the same group, there shouldn’t be two separate organizations. And this is where in business, we often find, especially in western organizations, we find a very hierarchical organization based on Taylor-ism or Ford-ism very much the assembly line type of pyramid, of folks up to the top. And you will find the person at the top of the business pyramid is different from the person at the top of the technology pyramid, and you’ll even see whether it’s the chief technology officer that’s in charge of all the technology and development, and it’s the VP of business development or whatever that’s in charge of business, they have different reward systems, they are rewarded in different ways for achieving different goals that many times, the bigger the organization, the more likely it is that all of the things they are each being rewarded on are actually at odds with each other.

0:11:00.4 D Lane: I worked for a customer one time and they were taking applications for loans, so the VP of Business, the goal they had set for that organization was to increase the number of applications by, I don’t know, 20% over some three month period of time, and that way they could increase the number of the ones that would go through the process and get approved. Now, the technology folks, they were being incentivized to identify fraudulent attacks against their loan system. So they were actually being incentivized to decrease the number of loans and make it harder to get through, and both of these are simultaneously going on and neither group knew about the other group’s priorities. And this is very common, especially in large organizations, but the number of times I’ve seen this or I talk to people and they tell me about this kind of scenario, it’s very common, so the simplicity, as you said, of this particular principle number four, is really encouraging us to rethink how we set up our organizations, it’s encouraging us to think about how we create our teams instead of having a technical team and a business team and a marketing team, and whatever team.

0:12:26.6 D Lane: Why do we do that? We do that because we’ve always done it. Okay, that’s not a good reason. Well, we do that because it’s efficient. Efficient for what? For delivering the customer value? I will challenge you and say, I don’t think that’s what the efficiency that you are optimizing for, so we’re taking the efficiencies from, again, the Tayloristic type of thinking, the assembly line type of thinking from Ford, we’re taking that and we’re still applying those efficiencies and modern business, but we don’t live in that business world anymore, especially in a knowledge-based world where we’re building technology and everybody has to be an expert in their niche or their space, or the number of tools and languages and domains that they have to understand, the level of expertise is much higher, their ability to think is required. It’s no longer optional as a person on an assembly line might have been where once I learned how to put these three pieces together and pass it to the next person, that was the degree of thinking I needed to do. Again, that becomes automatic pilot, that’s automatic pilot. Once I can learn that, I don’t have to learn anything else.

0:13:39.1 D Lane: So if I want to be promoted, I have got learn something new. Everybody on a software development team, it has to be able to think at all times if they’re not, or your management or the leadership is including them telling them, “You don’t need to think, I’ll do all the thinking for you,” that’s the kind of results you’re going to get, that’s a very dangerous thing to do, especially if you’re a software is life or death threatening or a huge financial system.

0:14:04.3 M Edwards: One of the reasons that I’ve heard, more than once, was that, as organizations grow, they need a better method of managing people, and so that then moves into, “Well, what do I do when my full-timer has been here a year and he comes to me for a raise? Well, how do I know how much money to give him? Well, I need to establish some type of step-by-step hierarchy of their vertical job line?” But what we’re really saying here, and it even goes down to one of the principles lower in the list, self-organizing teams, what we’re really saying here is, if you listened to the customer, and the customer said, “I want this experience or this outcome,” then part of the behaviors you’re going to exhibit is, well, in order to get this client from here to here so they could realize that outcome, I’m going to need this type of thinking and this type of thinking and this type of tool and this type of thing, what are all the things that I need in order to help this client realize their desired outcome? That’s a self-organizing team, but really it can only happen usefully with value. If the business and the developers as an example, are working together as a team.

0:15:25.9 D Lane: Yes, absolutely. Instead of saying business people and developers, which again, this is coming from the context of software technologist originally, we could simply say, everyone involved in delivering value for a specific customer segment, product, whatever, however the delivery packaging might be, needs to work together every day. If I’m not on the team when you’re learning this, because I already “know it,” then I will let you go through that learning curve and then I will meet you on the other side. We didn’t have the same learning experience, we didn’t learn the same thing, and this is huge because this is what this is really getting at, it’s not just, do these people talk, it’s are they going through the build, measure, learn cycle as a group of people who are going through the same learning curve at the same time.

0:16:17.1 M Edwards: They must journey together.

0:16:19.2 M Edwards: They have to do it together, and that’s really where the team work, not only happens to get through the journey, but the mental… It’s not synchronicity, but it is a shared understanding that is achieved by going through a learning at the same time, that shared context and understanding, it might have been if you had a team of nine, people that one or two folks, when you finish a particular delivery, what you delivered and what they initially understood was exactly the same for the most part. But many other people on the team that their understanding shifted or there were new elements that were added or they were able to understand some new aspect of your particular product or your market or your domain, by interacting with the customer and helping the customer go through that process as well. So again, while it focuses on business people and developers, we could extend that a little bit more by saying everyone involved, which would include the customer.

0:17:22.9 M Edwards: Principle number five. Build projects around motivated individuals. Okay, that’s fun. We’ll come back to that. Give them the environment and support they need, and trust them to get the job done. Now, those are two different things, they’re put together and they make sense, but build projects around motivated individuals.

0:17:47.1 D Lane: Well, we could definitely spend a lot of time talking about, are folks motivated and what motivates folks?

0:17:55.8 M Edwards: Well, you don’t pick up barbecue unless you actually want to taste barbecue. You’re a motivated individual.

0:18:02.0 D Lane: I would say in general, that’s true. That’s one of those rules. I always, eventually find somebody who’s an exception to that, somebody who will learn how to cook something because someone they love, likes it, but they will never actually eat it themselves, so they don’t know whether it’s really good or not, they completely depend on. Now, wouldn’t that be an interesting measure of success. If we delivered products to our customers, and our view of how successful or how well we did was 100% driven by the response of the customer, I’m not talking about our management, I’m not talking about our leadership, I’m talking about the actual person who is funding the development of this product. If we really got to number one, to the exclusion of however proud we were about the job we did, the level of craftmanship, the level of confidence that we brought, that had to be suspended until we heard what our customer said, boy, would the world be a different place.

0:19:07.2 M Edwards: So build projects around motivated individuals. The way I read that too though, I mean, there is a rabbit hole on motivation, right? But build projects around motivated individuals, the way I read that is, this project is going to get to where it needs to go, because the person that we are building around. So if I have a client, for example, when that client says, “I absolutely have to get here or we’re all going to die,” or, “I absolutely have to get here or my company is going under.” They’re highly motivated, they’re highly engaged, they’re highly invested. And to go and work with that client, you’re going to get to a finish line, to an MVP 01, to a first iteration or however you want to designate, you’re going to get there because of their conviction.

0:19:57.1 M Edwards: But that also applies to the teams, I believe. In other words, to have a client with conviction, and a team without conviction, that client is not going to be everything. That team has got to be monster attitude, also great attitude, great aptitude, an ability to listen, an ability to ask questions. The team has to have conviction, the client has to have conviction, and nothing is going to stop them, except possibly the employer, which is where we’re going in that next sentence, which is give them what they need in order to rock and roll. So if you have a team that’s convicted and says, “We’re butt kickers,” and a client that says, “Oh, we’re gonna win,” and then the environment gets in the way, it’s pretty hard to overcome that. So, the way I read that, and you tell me what you think is, find people that like to win, find people that like to have the ball, find people that like to be in the game and they want to get somewhere, and then give them what they need to rock and get out of the way.

0:21:05.6 D Lane: Well, what about this principle where it says, “Create an environment that supports them and trusts them.” Why don’t we hire people that we trust? So the reality is, is that you are encouraging these folks to leave, you’re encouraging them to learn what they can for the 12-18 months they’re going to be there until someone else recognizes their value and has an environment that allows them to achieve and develop and achieve their full potential. So, if instead of looking at this idea from this quote management position, where we’re trying to control people, if we instead looked at it in the, what if we were… Again, that’s what it’s being optimized for. If we looked at it from a leadership position and we said, “How do we value people in their interactions?” Which includes clients and employees and to all people. “How do we value them? How can we create that environment, give them the support they need?”

0:22:06.7 D Lane: Because we’re hiring people we trust, we’re working with people that our mission is compatible with achieving their particular goals, and we’re going to trust them to get the job done, that level of motivation, those companies, how do they control it? Well, they control cost, because everybody wants to work for that company. They control cost because they can actually pay people more and have a fewer people, because those people are motivated to do way more. So your revenue per employee ratio is going to be drastically different. The ability for us to know what this environment looks like is very difficult for the majority of folks who even work in a so-called agile or lean environment, because as you said, the company environment that they’re in is working on a different model. It’s not optimized, it’s not efficient for the people, and it’s not efficient and optimized for the delivery of value.

0:23:16.2 M Edwards: So if we look at principle six, the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Now, obviously, this was written well before the era of COVIDs and all of the different types of distancing and all of that type of thing, and lots of teams were already geographically distributed. That’s not new, there are very many companies, very many teams that are geographically distributed, but they all deliver against one set of objectives as one team for one client, that type of thing. But what I love about this is it’s basically saying, “Hey, don’t just text, don’t just Slack, don’t just set it and forget it, send an email and just wait for a response,” contact somebody and have direct interaction with them, develop and build, grow this relationship, ’cause you’re on a journey together.

0:24:16.4 M Edwards: You start it together, you live it together, you’re in a ditch together, you’re in a pothole together, you fell because of a speed bump together, and you made it to the finish line together. That requires constant vigilant communication. I think that that parallels in a very lovely, lovely way to the idea of barbecue after you start that fire, it’s constant attention all the way to the end. Am I on the right track there?

0:24:44.6 D Lane: I think you’re right. I think one of the ways that we can illustrate how this principle is often misunderstood is going back to the second value comparison. We value working software over comprehensive documentation. The number of programmers I’ve heard that says, “Agile says we never have to document anything,” is a high number of people. And I’m like, “Okay, where does it say that?” And eventually they’ll dig this up and they’ll show it to me and I say, “Oh, I see,” so it says working software over documentation. Yeah. No, actually that’s not what it says. It says working software over comprehensive documentation. And again, a comprehensive documentation in the year 2000, 2001 was a much different thing than the documentation we have today. Trying to explain this to a college hire, 20-something is trying to explain something to them that they have never experienced.

0:25:42.5 D Lane: First of all, the most effective and efficient method of conveying information is face-to-face. This will often, I will hear this as, well, it says now that we have all these virtual teams so we can’t do Agile, like, that’s not what it says. “Help me understand how you got that out of this?” “Well, it says that we have to do face-to-face conversation to do Agile.” I’m like, “Well, no, that’s actually not what it says.” What it says is, the most effective and efficient, or, I got that in the wrong order, but efficient and effective. So the most efficient means of communication is face-to-face, the most effective means, now, those are not the same word, they definitely… We tend to use them interchangeably sometimes, but they do have a subtle difference in their meaning. So efficient means that there’s a level of succinctness or a level of sufficiency that I can say is true with efficient communication.

0:26:42.7 D Lane: Effectiveness means, but did it work? Did you understand what I was saying? And if you didn’t, did you let me know and was it visible? Was it immediately visible? Did it become visible to you with small amount of time, a little bit of effort as opposed to weeks or months later? Now we’re back to documentation, let’s counter that. If there were 200 pages of documentation, which used to be the reality, read this Business Requirements Documents as BRD, and then we’ll let you start talking about how we’re going to build the system. Well, how many folks read that 200 pages? And the reality is, 200 would be a very small set of documentation. It was more on the order of tens of thousands, if not larger. An excellent skimmer, and what did you miss? You missed something, what was it, how important was it? Was it effective? So to me, what this is saying, and a lot of these are very… Their Scrum is built on top of this. I can map the Scrum guide directly to these values and principles, but I see a lot of extreme programming here.

0:27:49.3 D Lane: Again, where I’m looking at this and I’m saying, the most effective and efficient means of conveying information to a team, well, that’s typically someone outside the team. Okay, well, that might be the customer, so why don’t we just have the customer come sit with us, that’s one of the XP 12 principles, work with a customer every day, okay? And I don’t mean work with a customer through Slack, I mean side by side, sitting down working. And then the next one is that we’re going to within a development team. Okay, well then now we’re back to business and developers should work together daily. So again, we’re back to face-to-face. Well, okay, we’ve got COVID, nobody works face-to-face anymore. Can you communicate? Yes, it’s a reasonable proxy, given the dangers of face-to-face proximity with a pandemic, but it is not a drop in replacement, but it also doesn’t mean that we should ignore that face-to-face isn’t the most effective and efficient, which to me, I thought they were very intentional in how they structured this particular principle.

0:29:00.9 D Lane: We’re not saying it’s the only way to communicate. We’re saying it’s the most effective and efficient, so there are some best aspects to it, but there are times when we realize that’s not true. So, a co-located team, a team where everyone is literally physically sitting next within ear shot of each other, those are almost always the most effective teams.

0:29:24.9 M Edwards: Those are ideal. 

0:29:28.0 D Lane: That’s an ideal scenario for everyone. Now, there’s so many aspects of this that I think we ignore. The barbecue, face-to-face, the most effective means of communication and efficient is to give someone a piece of barbecue and watch their reaction.

0:29:42.6 M Edwards: Right on. It amplifies for me again, relationships are everything. And that’s so far, everything that we’ve talked about has talked about the value of the relationship, the value of the behaviors that enhance or amplify or enable the relationship, but it’s all about the relationship. So if you’d like to deliver value and value in a way that’s actually well, heck, valued by the client, if you want to deliver value to the client in the way that they appreciate, it’s constant communication, constant relationship, constant presence with each other. It’s not talking every once in a while. So far out of all the things we’ve talked about, I think they all continue to amplify relationships matter.

0:30:29.7 D Lane: Absolutely. I think the way that you emphasized the particular term “relationship” is what gets at the face-to-face aspect. I can have a lot of relationships remotely, but they’re not the same, typically the same level, the same quality as being face-to-face, being literally, and whether it’s good or bad, it’s typically not the same level of the same quality.

0:31:00.5 M Edwards: Thanks for joining us, keep coming back and we’ll keep serving up conversations on barbecue as we cover the last six principles of the Agile Manifesto.

[music]

0:31:13.9 Sponsorship: The Long Way Around The Barn is brought to you by Trility Consulting, where Matthew serves as the CEO and president. If you need to find a more simple, reliable path to achieve your desired outcomes, visit trility.io.

[music]

0:31:31.2 M Edwards: To my listeners, thank you for staying with us. I hope you were 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.

[music]

Categories
Podcast

Part III: How Deconstructing the Agile Manifesto Makes You Better at Barbecue

Show Highlights

In this episode, Derek Lane and Matthew D Edwards deconstruct the first two principles of the Agile Manifesto to help software developers and engineers bring more value to clients but also, become better barbecue pit masters.


Read the Transcript

0:00:00.0 M Edwards: I’ve had a large breakfast to prepare for this episode, if this is your first time joining us, welcome. I hope it makes you hungry enough to listen to the previous one and the ones that follow all including my guest, Derek Lane. Derek and I are mapping how understanding the Agile Manifesto and it’s 12 principles can not only help you in your journey to add value to your clients, companies and teams, but can also help you understand and improve your barbecue journey along the way, get your forks out, we’re cutting up the first two principles in this episode.

0:00:34.8 Derek Lane: Let’s elaborate a little bit on it from the barbecue standpoint, as I said, when I first started learning how to drive a smoker, I was really just focusing on one thing, so I’m just going to cook brisket or chicken or whatever it is until I feel like I’ve gotten it to release level, I feel like I can release it, it’s an actual major release, a 1.0, I made a lot of minor releases along the way, I found something that’s repeatable and something that the folks who are… my family or whoever is eating here likes. And now I can learn something different.

[music]

0:01:16.6 M Edwards: Welcome to the Long Way Around The Barn, where we discuss many of today’s technology adoption and transformation challenges and explore varied ways to get to your desired outcomes. There is usually more than one way to achieve your goals. Sometimes the path is simple, sometimes the path is long, expensive, complicated and/or painful. In this podcast, we explore options and recommended courses of action to get you to where you’re going now.

0:02:08.0 M Edwards: We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we’ve come to value individuals and interactions over process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more, and that is a wonderful statement, it doesn’t say, these are the things we believe, therefore, all of the other things that aren’t those statements are wrong and bad and horrible. They’re basically saying all of these things may have a time or place. The things that we value, we choose to amplify and pursue are the things on the left, but it doesn’t discredit or devalue the things on the right.

0:03:07.8 M Edwards: And so a lot of folks spend time on this, and that is very, very meaty. I hate to make that pan, although it is funny, it’s a very, very meaty, very short piece of information, but then at the bottom of that page, when you go to the 12 principles, there are 12 principles. I’ll read the first one and then, let’s talk about these things. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. That’s huge already.

0:03:39.4 Derek Lane: And definitely very difficult to do. I think back to the original, the first comparison that you made with the values, one of the things that we try to amplify in the 20-Day 

Agility Challenge that we have referenced before, and we’ll talk a little bit more about, at 20dayagilitychallenge.org, is the model that shows each of those value comparisons as a set of scales, where you’ve got one of those values on the left and one of the values on the right, and when it says, we value this more, it means, from my standpoint, we always give that more weight, we have a preference, a deference for that, given that we end up needing to compare, are these two things seen to be at odds with each other. It helps us make a more informed decision in light of being consistent with our values and principles, and as we ship to the principles I think the same thing is very similar as we discuss principles in a coaching standpoint with software development or product development teams, and we are running the same thing with barbecue, is these things will seem to be at odds with each other.

0:04:55.3 Derek Lane: So we have to determine what is the decision process for, how do we solve this, how do we resolve this particular issue? So one of the mistakes for years that I made and without knowing, and a lot of it was the way I was coached, the way I was trained, was to go through that process and then we get into the mechanics of scrum so  I’m constantly trying to figure out, is there’s something that could be improved? And I realized, why are people not referring to these values and principles? Why am I having to keep restating them? Well, because I told them at the very beginning, in whatever training we did that they were really insignificant.

0:05:40.0 Derek Lane: We spent 30 minutes to an hour talking about it, and then we spent the rest of the training time, the rest of the day, the rest of the week, the rest of the next six months coaching on stand-ups and whatever it was that we talked about, building and managing backlogs, those things can be useful, but those are the practices, and one of the things that’s really useful to understand is that the Agile Manifesto is not about practices as a general statement, it’s more about values of principles. Again, the same thing can be correlated to barbecue. Barbeque, if you really want to know the difference between good and outstanding barbecue, as we talked about before, the fundamentals are already there, you can’t tell how many fundamentals this particular pit master is using at the same time because they all flow together. They’re using many different principles and mechanism simultaneously, so there’s a lot there that even they’re not aware of, it just becomes so much a part of who they are. So the highest priority, to me that pretty much says, “This is the thing we’re pursuing.” What is the whole reason we’re doing any of this, that’s our highest priority, any time we have a chance to prioritize, this is what we should prioritize for, and to me, that’s where this starts.

0:07:02.1 Derek Lane: What’s the next most important thing? Well, it’s to satisfy the customer. Well, this brings up a really interesting idea, I suspect when you were growing up and learning just even before getting out of high school, you’ve probably heard many times, “The customer is always right.” You heard that particular statement or a cliché. Well, obviously today, in today’s climate, the customer is rarely right, because everybody has an opinion and everybody’s going to tell you the 57 million ways that you’re wrong.

0:07:35.6 M Edwards: [laughter] It’s tough.

0:07:37.6 Derek Lane: It is.

0:07:39.6 M Edwards: It’s a practiced behavior. For sure.

0:07:40.9 Derek Lane: Absolutely. And what this is saying is that the highest priority is to satisfy the customer, meaning we need to understand what it is will satisfy the customer, and oftentimes they don’t know. As we talk about barbecue, often times we don’t know what’s going to. And this is one of the great things you see exhibited in every one of these TV shows where there’s a barbecue contest and they’ve got the proverbial three judges, and they’re all saying, “Well, I like this one because it was… The ribs fell off the bone.” And the other one says, “Well no, to me, the rib shouldn’t fall off the bone, they should be almost falling off the bone.” And the other one says, “Well for me, I should be able to twist the bone and pull the ribs straight out.” And then that’s perfect. Okay, well, these are definitely opinions, but depending on which one is your customer, depends on how they value the characteristic you’ve been able to achieve.

0:08:31.0 M Edwards: That’s an interesting thing that you’re bringing up, and I’ve been in multiple conversations about this, is we as individuals, aspire, many of us aspire to become the masters of our craft, knowing full well that if you really understand craftsmanship, will only ever plus one infinity. I heard the customers say they want to go to X, but I already know that they’re thinking too small and they should go to Z, and because I have success and they called me, therefore I should take them to Z, but really what this first statement is saying is your highest priority is to satisfy the customer, and that means listening to what the customer is asking for, meeting them where they are, and shepherding them to where they want to go. I might know more than the client at this particular time on this particular subject, but it’s irrelevant. The client said, I would like to have hot dogs on the grill. I know that the hot dogs are not going to be fulfilling on the grill, but with that egotistical, perhaps self-centered statement, I also overlook the fact that they currently have no grill and they haven’t had grilled hot dogs.

0:09:53.3 M Edwards: So if I can help them get a grill and I can help them get grilled hot dogs, as much commentary, I might go with the hot dog, that is helping them move forward, and that is how they’re defining value. So this is a really interesting and conflicting statement, for people who are choosing to become their best and do their best on a regular basis, but then don’t understand why the client may not be where they are, and then having to remove yourself from this equation, my highest priority is to satisfy you, my customer. You want to go some place I’ve already been, rather than trying to make you come to where I am, I’m going to go to where you are and help you experience the journey, experience learning and experience delight. I think that this first principle, in and of itself, sets the stage for all cascading decisions here after. I love this first principle.

0:10:48.9 Derek Lane: I agree. Those are great insights. I think one of the things that we fail to see when we first read the Agile Manifesto, including these principles, is the subtlety and the depth of how we improve over time our own learning journey, and these things are very subtle, they’re very difficult to ascertain until you’ve made many mistakes over time, and you begin to see these patterns.

0:11:21.0 M Edwards: Which goes back to your illustration of some of the barbecue masters or competitors, because of their journey, they may not even tacitly recognize or recall for you, “These are the 14 things that I do, I do them in this order, in this combination because… ” Really what’s happening is they’ve done it so long and they’ve practiced so many different iterations and combinatorials and so on, they may not even realize how they have blended or how many steps were actually in there or how to deconstruct it and teach it. So it’s gotta be a journey, but really if you take one of those barbecue masters and say, “Teach me.” It may take them a few minutes to figure out, “Alright, what’s the most important thing to say first.”

0:12:08.3 Derek Lane: Yes, because teaching and learning, not the same activity, and while they’re related and they can, each one can amplify the other as it’s often stated, and I’ve definitely learned one of the best ways to learn something or to demonstrate the things you have left to learn is to try to teach it, teach it to someone who’s at your level or lower. And you will expose the things that you thought you had a high degree of understanding or mastery or ability to communicate and you will learn, “Okay, this isn’t working, I realize I only really know three ways to say this and I need to learn seven more.” And this gives you the chance to expose that about yourself. And this is part of learning how to be, in my case, a continuous learner, but learning how to be an effective continuous learner, being interested in lots of different things is one thing, being interested and effective in learning those things, I’ve learned, is another level that I can improve.

0:13:15.2 M Edwards: Let me push us forward just into the second sentence as is written, through early and continuous delivery of valuable software, those are three conversation spots right there, through early, so this isn’t established the agreement, receive trust, disappear and come back six months later with what you perceive to be mad magic, but rather early, which is, “Hey, I know we just started this conversation three days ago, I’ve had some thoughts, I have some deliverable, some prototype, something for us to look at, poke at and talk about and change, it’s now, I start the relationship now, I start delivering now, and then I continuously iterate and continuously deliver along the way, so we’re only able to discover value through the eyes of the client by learning to ask questions and then practicing shutting up. Ask questions, shut up, ask questions, shut up and deliver iteratively. This first principle sets the stage for entire relationships, entire engagements, entire product delivery experiences. Every one of these is a wonderful entree of meat.

0:14:27.5 Derek Lane: Absolutely, I think you’re completely right. So let’s maybe elaborate a little bit on it from the barbecue standpoint, as I said, when I first started learning how to drive a smoker, I was really just focusing on one thing, so I’m just going to cook a brisket or chicken or whatever it is until I feel like I’ve gotten it to release level, I feel like I can release it, it’s an actual major release of 1.0, I made a lot of minor releases along the way, I found something that’s repeatable and something that the folks who are… My family or whoever is eating here likes. And now I can learn something different. To me, what I’ve also learned is now that I want to try different things as you grow and expand the number of things you cook, I no longer want to cook just chicken or what goes with chicken. Well, I want to cook something else. I want to cook some smoked beans. I want to cook some… You know, I want to cook some cobbler. Okay, so now we’re getting… Okay, now I’m not just cooking one thing on the smoker and everything else in the house, I’m cooking the whole meal on the smoker, and one of the things this holds through early in continuous delivery.

0:15:41.9 Derek Lane: Because working with the smoker tends to be a rather drawn out process compared to most folks who go in the kitchen and 30 minutes to an hour, they’ve whipped something up. Not the case here where we may have hours, even a day or so of time actually cooking, because it is low and slow. So one of the things I’ve learned to include in my plan, in my strategy, is I want to have satisfied customers, I want folks… So I figure out, “When are you coming over?” And if you’re coming over in the middle of the day, well, guess what, I’m cooking lunch too. While the brisket or whatever may not be ready until dinner until 5:00 or 6:00 or 7:00. There’s going to be something in the middle, so we’re going to have the hot dogs, hamburgers, fish, chicken, we’re going to have something else, cobbler, we’re going to have cobbler, a crisp. There’s so many different variations of these recipes, and we’re going to have one of those or two of those, we’re going to have some different… If I find out that folks, like in the South, especially in Texas, something with jalapeños is typically very big, so whether you stuff them with brisket or cream cheese and you wrap them in bacon or chicken or you put onions or whatever the recipe is that you have, those typically take anywhere from about 45 minutes to an hour and a half.

0:17:11.6 Derek Lane: Well, now all of a sudden I’ve got… And it’s no different to when you go to a restaurant, you serve like an appetizer, well, the point of that is to not just hold you over because it’s taking the chef longer to cook here, it’s to create an experience and to allow you to incrementally improve. Here we are through early and continuous delivery of valuable barbecue, but because I’ve done this continuous and early, they can go back and say, “But that chicken or those kebabs or that cobbler, that is the best I’ve ever had.”

0:17:43.5 M Edwards: Right. So you’ve managed the relationship all along the way, which then helps build and manage and set expectations as well, which is basically saying, “Hey, we have together step by step for some period of time, there were some things you absolutely loved, there were some things you wanted me to modify again for next time, and then when we finally did get to… ” We were calling the brisket, for example, we’re calling the brisket the culmination of a wonderful day, and then I just didn’t rock it. It wasn’t amazing. There were all those other things that were amazing along the way as well, it’s a really interesting way to manage the expectations with the client. Alright, so let’s talk about the second principle, welcome changing requirements, even late in development, Agile processes, harness change for the customers competitive advantage. That is gold. I love every word in that sentence, and it flies in the face of so many expectations we set for ourselves when we’re running projects, scope request, scope changes, all of the drama that goes with that, contract changes, etcetera, but the reality is, this statement is saying, prepare for, expect, and in particular, my favorite word, invite change, don’t be afraid of the dark rooms without flashlights, invite the opportunity to become more and to add more value for the client.

0:19:22.0 Derek Lane: So we just talked about the first principle, which we really focused on the highest priority is to satisfy the customer, what is number two about, it’s we’re harnessing change for the customers competitive advantage, it’s still about the customer, the customer is still the goal, the focus.

0:19:41.0 Derek Lane: The way that the customer interacts with us is going to be through their learning process as well. The number of times I’ve had a customer be convinced, whether it’s a turn key thing or just the next incremental quarterly release that they have, I know exactly what it is my market wants, this is what they want, this is what… The number of times that they actually validated that with the market is a very small number. The person who’s driving this tends to be a product person, a sales or marketing person, someone who maybe is an expert, they’re certified accountant or lawyer or business person, a financial person, they may be an expert in their domain, but when we’re dealing with trying to achieve something for a customer, we actually have to do the thing we talked about, you have to talk to and listen to your customer. There’s any number of things that could change, that could cause, as time passes, the customer to change their view about what they want, and many times, back in decades ago when the delivery, the development and delivery process was much longer and was expected to be because you just couldn’t build technology and software that fast and deliver it.

0:21:04.3 Derek Lane: You could take six months to a year. The customer could come look at it, like you said, disappear, come back a year later, look at it, and you could show them, this is exactly what you asked for. And they will almost always say, that’s not what I want. And you said, but that’s what you asked for. It says so right here in the contract, but it’s not what I meant. Okay, it doesn’t include this, and we just heard two months ago about this, but if we don’t do that continuous early conversation, and if we don’t do the focus on change in requirements so that as we learn, again, the lean startup to build, measure, learn. We don’t do those things in that order, and it’s just a big circle then we are going to miss this chance to be able to help the customers be and stay competitive.

0:21:53.6 M Edwards: Yeah, that’s a really good call out, it’s just an interesting thing, even if you look at your own personal behavior, not you personally, but if I look at my own personal behavior, there’s what… First of all, it’s my own kids that helped me learn that I wasn’t as great a communicator as I believed that I was, one of my kids, just said, “Dad, you’ve probably heard this, but you seem like you have forgotten it. There’s what you said, there’s what you meant. There’s what was heard.” And of course, she nailed me, so I was very happy to know that my daughter heard me and that she was applying some of the things that we had talked about through the years, and then she used it on me, that was less pleasant, but she was absolutely right. And so I reflected back on that with clients, how often have they said, this is what I want, but I didn’t hear what they meant, and then I didn’t reflect back to them what I heard so that they could refine. The conversation in and of itself is an objective, to your point, there’s an inspection re-factor loop involved in the conversation over and over and over again, so to welcome changing requirements doesn’t mean that you have no backlog, it doesn’t mean you have no product road map, it doesn’t mean you have no priority, it doesn’t mean it’s the Wild West.

0:23:17.7 M Edwards: I have heard someone say, “We do Agile, therefore we don’t have product plans and project plans, we just adapt.” That’s not true, that’s not the implementation that makes the most sense for the client, that’s… They’re blowing money out the window and just hoping like stink that it’s going to actually work out into something magical, so that doesn’t mean you don’t have a backlog, priority or road mapping and that stuff. What is basically saying is, we have a plan, but I’m going to continuously talk to you, I’m going to continuously deliver and we’re going to continuously re-factor if and as we need to, and it’s possible that you’re going to need less than you thought, or it’s possible that you’re going to need something different than you communicated, but this is a really hard behavior.

0:24:05.3 Derek Lane: Yes, it is. And so to tie it back in to what we’ve talked about earlier, we go back to the value comparisons, the value options here, we value working software over comprehensive documentation, what is often included in that documentation, big plans, requirements documents, lots of specifications, things that are tied to delivery dates, we value customer collaboration over contract negotiation, doesn’t mean there’s no contract, no, it’s when we know the least, but that’s when we’re locking things down, that’s when the VP of whatever is signing the thing and then expecting another department who wasn’t involved in the discussion to deliver on it. So we’ve created this dynamic of conflict by avoiding these particular values and principles. Here we are at principle number two saying, no, we should invite change because we’re going to learn something, we’re going to learn something as we’re trying to build the right thing the right way. As we understand it, and as we incrementally expose it to the customer, the customer is going to give us feedback to help us steer towards what they ultimately will agree is success, but they don’t know what that is yet, because they haven’t been there yet. It’s still nine months before we get there, it’s still eight months before we get there.

0:25:25.5 Derek Lane: Help us find a flexible way to work with you, but still have a way for you to predict and control your costs so it’s not the Wild West. So there are definitely ways to manage this and from both party’s standpoint.

0:25:39.3 M Edwards: So obviously we would be remiss if we didn’t say to invite change can actually be abused, I can invite change, but there has to be some type of common sense balance here, which is… Look, we have to get to the market by third quarter because we understand our competitor’s going to be there in the fourth quarter, we have to deliver these widgets because that’s what we are, that’s our sweet spot, and we also believe that’s going to edge out or nullify some of the things our competitor is going to bring together, as well, I have to consider my risk appetite for the organization, I have to consider my budget, my resources or team members that are available, a lot of things. So after you get done looking through all this, the highest party still satisfy the customer early and continuous delivery of value, which is then… That includes change, so if you’re doing early and continuous, there will be change no matter where it is on the pipe, but you still have to balance it, because I guarantee that you would change your tune if we were going to deliver this build and deliver the software for a company 12, but we use your bank account.

0:26:48.0 Derek Lane: No, that’s good. I think that, first of all, it’s useful to understand everything and anything can be abused, it can be misused and what I’m sharing here and what I try to incorporate in the 20-Day Agility Challenge is many of things that I’ve misunderstood and tried to learn over time, both for myself and my experiences as well as working with other folks, so I think that we have to accept as the default, but it is worth stating upfront, any and all of these can be misunderstood and therefore abused in extreme ways and say, “Well, we’re doing this in the same way.” Wait a minute, that’s not possible, in the same way that the contract you negotiated with the customer will be abused in order to create a death march for you to build something that when you get done and you work all the overtime that’s included in the fixed bed, we’ll still not meet the customer’s needs. So if you’ve ever been on one of those projects and almost everybody’s been on several of those at some point… We all have experienced that. So the reality is that the second thing I’ll mention is the emphasis you put on number one, they’re delivering value, not valuable software, I think is key.

0:28:04.1 Derek Lane: And then the last thing I’ll mention here on number two is maybe related a little bit more to a barbecue, changing requirements could be that maybe somebody shows up who wasn’t for barbecue, and I didn’t originally know that we’re coming, and it turns out that they’re allergic to half of what I’ve done there, or they’re vegetarian… I’ve got people, my members of my family who are vegetarians, so if I don’t know they’re coming… If I don’t expect them to come to a barbecue event, then I’m not going cook things that I know that they would like, because most other folks aren’t necessarily going to like those things, just like I wouldn’t build a product for a customer knowing that that’s not what that customer likes, that’d be ridiculous. So it’s just the reality is that… But we may have somebody show up, I don’t know, somebody brings a date, well, it turns out they’re a vegetarian, okay, great. Didn’t plan on making a certain number of things, so I need to adjust, change in requirements. Even late in development, hey, we’re going eat in four hours, I need to figure out what I’m going do.

0:29:10.1 Derek Lane: So now I’ve got to say, “Okay, now what is on the list of things that you can eat?” And then maybe I can come up with something, maybe I already have something in my tool bag that’s something I’ve used before that is somewhat repeatable that other folks who like to eat the same things might have said was a good enough to try it again. And here’s something that is really not stated here, but this is reality, and it works in the business world as well. I can also just invite that person to come help me cook for them, a pit master in the sense of I want to become a master of my domain, it’s like, “Okay, everybody leave, I want to know how great I am because I can control all this stuff, I can master all this stuff.” That’s really not barbecue; now, we’re violating value number one of valuing people and interactions over processes and tools. So now we violated that and we’re also about violating principle number two, so there’s nothing wrong with me saying just like Extreme Programming does, “Hey, Mr. Customer, why don’t you come and sit with me? Sit with me today. Help me understand.

0:30:20.3 Derek Lane: I think I understand what you’re saying. Let me show you what I think you’re saying, but you can very quickly help me see if I misunderstood something, if we have a terminology problem, if something means something in your world, we’re using the same words, but it means something completely different in my world, we can more quickly resolve that misunderstanding that misalignment, and we can quick, get more quickly to what Eric Evans in domain-driven design calls ubiquitous language.” So that we are saying the same words and they have the same meaning, both of those things have to be true in order for number two to… For us to be able to actually execute on number two in an effective way.

0:31:05.3 M Edwards: I hope this episode reinforces your appetite and appreciation for always keeping your customers at the center. Remember to put people first. And always invite change. Now, after this conversation, I need to get some food. I hope you join us for the next episode where we discuss principles three, four, five, and six.

0:31:32.2: The Long Way Around The Barn is brought to you by Trility Consulting, where Matthew 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:31:48.6 M Edwards: To my listeners, thank you for staying with us, I hope you’re 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.

Categories
Podcast

Part II: Deconstructing the Agile Manifesto to Make Better Barbecue

Show Highlights

In this episode, Derek Lane and Matthew D Edwards dive into the Agile Manifesto word-by-word to help software developers and engineers bring more value to clients but also, become better barbecue pitmasters.

Key Takeaways

  • They are both “people sports.” Barbecue and software are meant for someone to enjoy it.
  • Mastery and knowledge wins over equipment every time.
  • Get the fundamentals down before scaling. However, you don’t have to understand all the fundamentals to make progress.
  • Be ready for the things that will get in the way before you even start. 
  • The best recipes (comprehensive documentation) adapt to what you have on hand.

Read the Transcript

0:00:00.0 M Edwards: D Lane and I picked up our deconstruction of the Agile Manifesto and how it relates to iteratively improving your barbecue. Yes, two of our favorite things, barbecue and Agile. So if you’re trying to listen to this podcast on an empty stomach, maybe take the time to go get some barbecue so you can fully participate in the rest of this material. If you’ve missed the first two episodes in our series with Derek, I encourage you to go listen to episodes 15 and 16. 

0:00:39.2 D Lane: The way I know it’s really good is you take one bite and you want to sit down and just have a party all by yourself. That’s when I know I’ve done something, I’ve done something valuable, I’ve achieved some level of success that’s beyond, “People can eat it”, or, “Well, it’s not that bad,” but my brother-in-law’s… No, you take one bite, you just sit down, you’re like, “Okay, I need to sit down and enjoy this.” This does not happen very often.

[music]

0:01:08.2 M Edwards: Welcome to The Long Way Around The Barn, where we discuss many of today’s technology adoption and transformation challenges, and explore varied ways to get to your desired outcomes. There’s usually more than one way to achieve your goals. Sometimes the path is simple, sometimes the path is long, expensive, complicated, and/or painful. In this podcast, we explore options and recommended courses of action to get you to where you’re going now.

0:01:40.3 S3: The Long Way Around The Barn is brought to you by Trility Consulting. For those wanting to defend or extend their market share, Trility simplifies, automates, and secures your world your way. Learn how you can experience reliable delivery results, at trility.io.

0:02:00.5 D Lane: If we start out with the Agile Manifesto, and the part most people are familiar with, and that’s at agilemanifesto.org, it says, “We’re uncovering better ways of developing software.” If I replace that, and say, “We’re uncovering better ways of making barbecue by doing it and helping others do it,” that sentence says so many things, and I have learned now, and I’ve adapted this to a lot of coaching, if I’m doing training to help people understand, I will take that sentence word by word and decompose it. There is so much meaning that just gets ignored, because we tend to focus on these four values that are in the middle of this page, and we tend to ignore the beginning and the end. But that sentence is powerful, especially when it comes to barbecue, because you will not become good, much less great, at barbecue unless you practice. And it is very difficult for you to practice on your own. You’re always wanting to share stories, you want to say, “I tried this, what can I do here? Should the fat side be up? Should the fat side be down? Do I pull the membrane off the ribs?” There’s a million things.

0:03:15.3 D Lane: “How much rub do I put on? What goes in the rub? Do I make my own rub? Do I buy my rub?” I mean, it’s okay, which is the standard build-or-buy kind of decision that we have in technology all the time. So there’s a lot of that learning curve that’s really just encapsulated in that one sentence, that oftentimes gets skipped over in both the Agile and, in my case, the barbecue world. Through this work, we’ve come to value individuals’ interactions over processes and tools. Barbecue is a people sport. This is not… I’ve seen… There’s gadgets, there’s people selling all kinds of… There’s the biggest, the best smoker, there’s the stainless steel that and the other. I will tell you that you can take a garbage can and a fire and somebody who knows what they’re doing, they will outperform somebody with the most expensive equipment.

0:04:10.6 D Lane: So it’s not about the equipment, it’s not about the, “Do I have a wireless thing that talks to my phone to tell me when something reaches a certain temperature?” It’s not about any of that. It’s about the people. I value, in this case barbecue, over comprehensive documentation. As someone who did not have access to the internet, it wasn’t available when I was learning, my learning curve was reading lots of books, reading from other barbecue experts, reading from people, and what I learned was…

0:04:38.3 D Lane: One of the things I learned was that there are a million ways to do it, and a lot of them will reach some level of success, but what I also learned was it that if you’re going through the learning curve and you’re at the beginning part, do not mix metaphors. Don’t take something from what one person says and mix it with what something somebody else says, because you will not get a result; you don’t understand why they did those two things in their own context, much less the ability to take them out and strategically tie them together, to cherry pick them. It just doesn’t… It won’t give you the results you’re looking for. So if you find a book that you like, stick with that book, learn what that guy has to learn and then go to the next, or website, or whatever.

0:05:21.7 M Edwards: That’s a really good callout there. I am young, or new, to raising cattle, and I have found that for every rancher out there, there is their own perspective or methodology on how to raise cattle. And I have found, perhaps similar to what you’re saying then, that I need to thoroughly understand and implement the ideas as taught by one person first.

0:05:52.9 D Lane: Yeah, the same is true very much with Scrum and XP and all these other things, and I think that’s one of the situations people find themselves in when they try to go either directly to something like the Scaled Agile framework, SAFe, if they try to… Or DAD (Disciplined Agile Delivery), or any of the other larger “scaling” frameworks, is that they didn’t master the nuts and bolts of the simpler thing first. One of the things I often hear Agile coaches say is, “You need to walk before you run.” And I was taught that years ago, and I learned that that’s actually not correct. Biologically, that’s not correct. The first thing a baby does is run. They don’t run well, they fall, but they don’t walk in a controlled manner. So the first thing, this idea that we crawl before we walk, we do crawl, there is this crawling thing, but we really don’t go to walking, we go to running. There’s this wobbly, I’m trying to catch myself, catch myself, and then I either fall or I grab a parent or the nearby object. And so that’s not the same kind of running as we’re seeing in the Olympics kind of thing, but of the common characteristics that we have that we share as humans, it’s the closest to running. It’s closer to running than it is walking, which is a very refined, controlled movement, or crawling.

0:07:26.2 D Lane: And so this idea that we go straight from crawling to walking is really incorrect, and we need to adjust how we adapt our learning models and things to that, as well.

0:07:40.0 M Edwards: But you’ve asserted about the Agile Manifesto is people kind of flow past the first sentence, and so you’re saying, “Hey, in order to actually make use of this thing, we need to deconstruct this one sentence, one phrase, one segment at a time and understand what are its ripples, what are its implications?” And that’s what you’ve been doing in order to map that out to tenets or behaviors or frameworks as it relates to barbecue. And one of the things I also want to call out that is important, is there are fundamentals. And so, for example, in order to be a musician, you need to understand the scales, you need to understand things like triads, you need to understand inversions; you need to understand fundamental things that says, “Hey, there’s all these notes, and what are all of the notes in like the C scale?” Well, knowing the C scale is a fundamental.

0:08:34.5 M Edwards: Now, maybe not everybody tacitly knows that they know the C scale, dependent upon how they got into music, but in order to get from the fundamentals to there, they had to first know the fundamentals. And your point, I believe was, “Hey, you could pick up Scaled Agile Framework, ’cause that would be fun and amazing,” but it assumes that you understand some of the most fundamental behaviors that exist. And this entire Agile conversation, Agile as, body of knowledge or set of collective ideas, which is, “Hey, how does a team operate?” And then after that, you’re building up, and then sell similarly, then I think that what you’re illustrating is the same thing with barbecue is, there’s the build versus buy.

0:09:20.6 M Edwards: What are the most fundamental things you absolutely have to know and understand. And I love that you called out that somebody who actually understands the art of what they’re doing makes the mechanism or the medium pretty much irrelevant at that point.

0:09:37.0 D Lane: I think another thing that was in there that I didn’t specifically bring out is, it’s one thing to understand the mechanics, the fundamentals, and you don’t have to understand all the fundamentals to make progress, there’s this idea that we’re constantly learning, that we should evolve. When we get to the principles, we’ll talk about this principle of emergence, and I don’t know how much time we would have to spend on that. But the idea that over time the best ideas, the best options, are going to emerge. As I learn… Your ability to play music progresses as I learn more fundamentals. The thing that is fascinating to me that I can correlate to music is that when you learn one instrument, now you go try to learn a second one. There are things that will translate and there are things that will not.

0:10:30.4 D Lane: The fundamentals of music will transfer, but the way you play one instrument, the way you play another instrument, even if they’re very similar instruments, could be drastically different in order for that instrument to achieve what it is uniquely created to do. And that is no different with Agile or with Lean. If you’re going to do something and you learn the Eric Ries Lean Startup approach to something, that’s great; in there, he has a lot of connectors to other fundamental mechanisms. You could use Lean UX, if you like, but they would all still work with this premise of that, I’m gonna build, measure, learn; that I’m gonna build a hypothesis, I’m gonna figure out how am I gonna test the hypothesis, I’m actually going to test the hypothesis, I’m gonna look at the answers and say, “Do I need to pivot or persist?” 

0:11:28.5 D Lane: This is true here, this is true with barbecue. The same thing is absolutely true. I need the fundamentals, I need to learn, “Okay, if I’m going to cook and this is the way I did it, brisket, I need to quit switching and cooking different things every weekend; I need to cook brisket every weekend, until I get some level of acceptable… Basically a release.” I need to get to the point where it’s repeatable, and the thing we’re going to eat we’re actually looking forward to. And so, across any of these mediums, the principles and the patterns are the same. And kind of the extension of that, which you alluded to, was that these things are related. We can learn the fundamentals in each of these areas, but they’re all related.

0:12:19.1 D Lane: The next value is customer collaboration over contract negotiation. Lots of times we are so specific in barbecue, we are trying to follow this recipe the way that it’s written, to the line. My mom, my grandma, all the women in my family are great cooks. If I ask them for a recipe, they will have to stare off into space for a while to remember what they did, ’cause none of them use a recipe. Well, how can they be such great cooks and never use a recipe? Well, because they don’t always have the same ingredients, because they need to adjust, they need to adapt. Well, gee, doesn’t that sound like every day in building a product? So the idea of, we’re constantly figuring out what it is, if I’ve got a barbecue recipe and I find out that someone’s allergic to curry…

0:13:10.3 D Lane: Well, if I’ve got a curry in the one of my dry rubs, I need to know, “Okay, I need to adapt.” If I’ve already used it on something, I need to tell them, “Don’t eat that.” If I’m making a rub, and one of the things I’ve learned is I want to find out what people want before they’re gonna come over to eat. And if there’s an allergy, if there’s something that they don’t like the taste of, then I’m going to adjust to try to incorporate… To make this a good experience. Now we’re back to valuing and respecting people over, “Well, this is just how I do it. These are award-winning ribs. How dare you tell me… Just don’t eat the ribs.” I’m like, “No, no, no, can we make some good ribs for this person, too? Doesn’t that demonstrate a level of skill that’s beyond the fact that you came up with a recipe that is repeatable?” And I’m not saying that’s not… That’s a level of achievement, but let’s go beyond that.

0:14:06.0 M Edwards: That’s a real good callout, and we do see that parallel in technology ranks on a regular basis, where someone may illustrate or suggest, “I have created; everyone else needs to accept,” or, “This is what I think, and because of my title, therefore, I have now given you what you need to think.” So we see those types of things in the technology space on a regular basis, which probably maps out to the unlimited… The agility conversation that you have in terms of servant leadership, which seems to be still the same level of service, when you’re saying, “Hey, it’s not enough to be predictable, repeatable, and make great meat. I need to be able to create based on what’s available to me for the people that I’m going to interact with, so I can bring value to them in a way that they value.” As opposed to, “I have made these, eat them, serve me, leave the money in the jar at the door.”

0:15:11.8 D Lane: Yeah. The idea… At the point at which… This is one of those kind of reality checks. At the point at which you think you have become a master, that’s the point at which someone needs to help you understand you’re not even close.

0:15:29.0 M Edwards: I have received that serving of crow many times in my career. [laughter]

0:15:32.4 D Lane: Many times. As have I. So there have been many times where I’ve gone into a new project or something, and I’ve got all the answers, I know exactly what to do, I’ve mapped it all out in my head, I put it on the whiteboard, I created a PowerPoint, whatever I needed to do to prove to someone that I had it all figured out, I had all the answers. Only to, obviously, quickly learn that I not only didn’t have all the answers, I didn’t have all the facts, I didn’t have all the information. And now we gotta do a value number four, responding to change, but I didn’t even deal with change yet. I’m just saying that’s a whole other thing, is that now we’ve gotta deal with change over following a plan. This is the one most people tend to focus on, because it’s the thing that is the easiest to see, it’s the easiest to identify with, especially in business.

0:16:19.0 D Lane: Responding to change in the context of barbecue comes in, again, in lots of different ways, but one of the more common ways it comes in is in fire management. The level of smoke that your particular smoker is going to put out has… Any of the great barbecue folks will tell you what was called clean smoke. Clean smoke looks more like, if you’ve just driven…

0:16:46.6 D Lane: Let’s say you’ve driven your vehicle for an hour and it’s 100 degrees outside, and you park your vehicle in the driveway, and you go outside and the vehicle’s turned off and you just look at the hood. You will see the waves of heat that are rising, because it’s hot outside, it’s hot, and it’s even hotter on the engine, but the difference in temperature now is closer, so you’re seeing those waves as the transfer of energy happens. Now, when we go to barbecue and we’re dealing with smoke, that’s what clean smoke looks like. Sometimes it’s even called blue smoke, ’cause it’ll come out a really soft, it’ll look a little blue, it can look blue or grey. But the darker it is, the thicker it is, that’s what you don’t want. What that means is they haven’t cleaned the pit in 20 years.

[laughter]

0:17:34.0 D Lane: That’s really what that means. Because their belief is that if they cleaned it, it would no longer have the ability to produce the same level of food. So there’s things like that that you learn over time, which is you need to keep your smoker clean. That doesn’t mean shiny, we’re not talking about military boots here, we’re talking about removing debris. Now, translate that to Agile. Is there such a… Can you imagine something that would be considered debris when we’re trying to apply Agile principles or values?

0:18:11.6 M Edwards: I just thought it’d be perhaps classified as friction in a continuous flow-based process. Like you’re able to achieve this goal with this number of steps, this number of actions, and then someone may have proactively inserted some type of quality process, inspection process. Or it’s a conversation of how many steps does it actually take; for example, with Amazon, what’s the fewest number of key clicks it takes to separate you from your wallet? Well, their answer is one. [laughter]

0:18:43.5 D Lane: Yes. They’ve been able to get it down to one.

[laughter]

0:18:48.8 D Lane: So I’ve seen this a lot of times where some of that debris could be a disbelief by the people that I’m there to help, I’m here to help teach them, whatever… Or coach or whatever. Or I’m on the team and I’m there trying to be a contributor. But they don’t believe it when management came and said, “We’re going to adopt this approach.” Or, “We’re going to move in this direction.” Why don’t they believe it? Because the last time management said that they changed it or the last time they bought into it… There was a situation where I was coaching a team, they were going through a transformation, they really didn’t have to deal with a lot of the typical organizational cross-dependencies that happen in large organizations that were relatively separated, and after several months we were able to make progress with everybody except for this one team member, and I couldn’t figure out what was going on, so finally I sat down, I was able to get them off to the side and talk to ’em, I said, “What’s going on? You seem to be really enjoying this. Oh yes. This is fun. This is great, this is exciting. Why are you still doing these things the way you’ve always done them?”

0:20:03.7 D Lane: “Well, because last time we did this and did something like this, and I followed what my leader said, I ended up losing, I got docked for vacation, I ended up getting penalized, I end up getting… ” Oh, okay, well, that’s some debris that’s in the way of this individual being able to believe what their management is saying, the management saying two different things, and you know which one they’re believing, they’re believing the one that the reward system is attached to. And this is a fundamental… This is a hidden thing, and it’s hidden in most people’s smokers too, because they don’t know that periodically, you’ve gotta go in there and it’s not just weeping out the ashes of the wood at burn, you need to check the chimney, you need to check a few other things, the smoke exhaust, whatever it is, there’s some places you need to check for some things that might be hidden, they’re not obvious, they’re not in front of you, they’re not on the checklist.

0:21:02.2 M Edwards: So that seems to map out to a couple of different things. Working software over comprehensive documentation. The way I’m interpreting the things you’re saying suggest that, yeah, there’s a plan, but there’s some additional things that don’t get documented, more communicated that you need to be aware of and you’ll discover and you’ll need to figure out how to adapt to, and then responding to change over following a plan, that idea also perhaps maps, which is, “Hey, I didn’t plan to have to clean things today,” or “I didn’t think I was gonna get black smoke today,” or “What the heck has taken so long, what did I do wrong?” I mean, responding to change is, I have a plan, but, oh my gosh, this happened. And many people just call that Murphy’s Law, which is, “I’ve got a plan, and then things are going to happen and I need to adapt to that,” so I like the illustration of, “Get on the bull and you’re gonna take the ride that’s given.”

0:22:00.7 D Lane: Yeah, that’s definitely true. A more common one with barbecue is, is that no matter what the weatherman says for five days in advance, you’re sure it’s gonna be 75 and nothing, you get out there and it’s 42 and wind or… I’ve run my smoker in every condition there is, snow on the ground, ice on the ground, and a matter of fact, I think that was probably one of the longest smokes I’ve ever had was a 20-something hours with a smoker during the winter time when it’s snowing, and it’s blowing snow. Try to keep your fire lit then, where normally you gotta check it every 30 to four, five minutes. You kinda have to babysit it. So the ability to adapt to that which you’re given is, just the expectation of that, in my mind, is a degree of mastery, the acknowledgement and awareness is one, but the expectation of it. I expect things to change. I expect it to, I’m not saying I’m not planning for success, that’s not at all what I’m saying, I am planning for success, but I am ready for the things that will get in my way before I get there.

0:23:18.2 M Edwards: That’s a great call. A great tenet, a behavioral tenet, if you will, which is anticipate, even invite change. And so part of the value and the whole point of an iteration isn’t just to deliver, it’s to also gain feedback so that you can make whatever you delivered even more valuable as you go along, so to iterate, “I delivered this, now with your feedback, I can deliver this better and better,” and so on. So the idea of iterative delivery makes a lot of sense. Responding to change doesn’t mean, to your point, I’m planning to fail. What it means is I have a plan, and now, oh client, I’ve delivered this, I invite you to give me feedback that might require some change, and you know what, I’m okay with that, because I want to deliver something that matters to you, which goes all the way back to one of your original arguments was, “Hey, why don’t you talk to the people in advance of picking the meat and doing the meat and delivering the meat, ’cause maybe they wanted bell peppers.”

0:24:26.0 D Lane: Right. And to expand on the idea in iterative barbecue, when you start, at least for me, most people start with one thing again, with a brisket or with ribs, they’re gonna cook one thing. Now, I’ve got a couple of different smokers, I’ve got one that I can cook for 150, 200 people on. When I cook, it’s going to be… I’m gonna cook a lot of stuff. Now, the point here is to say that I will schedule… This is my plan. I will schedule the order in which I’m going to put things on the smoker, something will always go wrong because it wasn’t prepped because it wasn’t… Because I didn’t have the rub made, because I forgot something, because an ingredient ran out, I didn’t expect to use this ingredient in three different things, and something happened and I didn’t have enough. There is always going to be something. So my schedule, my plan, basically the order in which I’m going to put things on so that I know what order they’re going to come off, that’s one set of change, I have to adapt to. The other set of changes is that I cannot control fire, I can’t control chemistry, there will be something that will need to come off early, and there will be something that we’ll probably need to stay on there, the 30 minutes or an hour to be at the level of done that I’m looking for.

0:25:55.0 D Lane: There’s a lot of principles in barbecues that are all over the Internet, like 3-2-1 for ribs. The idea that you’re gonna put them in there, put some ribs on the smoker for three hours, then you’re gonna take them off and wrap ’em and put ’em back on for two hours, then you’re gonna take them off and let them sit in a warmer for one hour, that 3-2-1 method is very popular and I’ve used it, it’s a great set of training wheels to get started with, but a thermometer is better.

[laughter]

0:26:34.2 M Edwards: And that may be a learned thing.

0:26:36.8 D Lane: It is a learned thing. I have learned, I trust the thermometer. I’ve met people, I’ve gone to restaurants where they have a pit master who can literally touch a piece of meat, they can touch anything that they’re used to cooking, that they put on their pit, no matter how big their pit is, they know the hot spots, the cold, they can touch it, and they will be able to tell you how much longer it has or whether it’s done, that’s a level of… Like a magician, there’s a level of mastery there that very few of us are ever gonna attain, so I’m perfectly happy to stick with the thermometer. I trust the thermometer. When the thermometer is not working, I get another one. It doesn’t hurt to have two or three… If you’re concerned, you don’t get two or three opinions on something, it wouldn’t be any different than we would tell a team if we didn’t know the answer and they didn’t know the answer, let’s get two or three opinions, let’s find out, let’s don’t just always listen to one person.

0:27:33.9 M Edwards: One of the parallels that I have heard from you, you may not have said exactly or explicitly like this is part of the manifesto itself, is suggesting that we have a plan, we have one or more sets of patterns, we have people, we have intent, goal, we have all of the things, but the responding to change part illustrates the fact that even though we’ve done all of the things, things are still going to happen that we didn’t plan or may happen different than anticipated, and our responsibility is just to adapt. I have the framework, I have the training, I have the tool. Everything will work exactly the way I’ve said it to. And if it doesn’t, it’s probably a people problem and that person needs to get back in line, and it’s an interesting contradiction between the way life actually is and the way we want it to be when we’re at work or when we’re doing planning, which is order. I control all of the squares in this waffle, no syrup will leave each of the squares, they will all stay in their squares, they will be evenly distributed, and this will be a gorgeous waffle, that’s just not the way it works.

0:28:53.2 M Edwards: And so this desire to say, I want my cost of acquisition to be exactly what you said it would be, and I want my cost of ownership to be exactly what you said it would be. And then to discover along the way that there were second and third order dependencies or ripples that required change, and then adaptation, is an irritant. “Well, that’s not what you said. So you must not know what you’re talking about.”

0:29:16.7 D Lane: I think you’ve got it. We assume or we infer that if we know, the level of confidence is directly related to what we feel we know ahead of time, but none of us know the future. We know, none of us know the future, but we all expect that the degree of expertise that someone has is directly related to their ability to tell the future, and that is a completely insane connection to make, and yet in business, it is made every day, all day long. Yes, you can make an educated guess depending on if you’ve done this in how long, but now that’s assuming that the playing field didn’t change, that’s assuming that you don’t have a new competitor, that’s assuming that the market didn’t change. We’re making a lot of assumptions there. The speed of change, the pace of change that’s happening now is directly impactful to your ability to tell the future. When you or I were around a couple of decades ago, you have several years to adapt, there are companies. They’ve been around for 50 to 100 years or maybe even longer, they are still under the impression they have a couple of years, several years to adapt.

0:30:40.9 D Lane: If that were true, then it would not be possible to literally go from a napkin idea to having a business up and running in 48 hours or less and actually taking money and selling something or doing something. If they set their sights on your market and they are listening to their customers, they will beat you every time.

0:31:00.8 M Edwards: I think it’s outstanding, I love that. The common denominator there is people, people, people, people, and your point is have a plan, love the people, be involved with the people, engage the people, provide to the people, and then map across, make sure that you respond to the context of the change. I love that part. One of the things I’d like to know is, do you have any final thoughts for us on how this all comes together in one package, and then what is your favorite kind of meat to grill or… I’m sorry to barbecue.

0:31:34.7 D Lane: I guess the thing I’ve mentioned is, is from my standpoint, we only made it through half of the manifesto, we made it through the four values. The 12 principles are just as important. From my perspective, one of the things I’ve learned about the manifesto, the way I look at it is these are two sides to the same coin. You will not be able to achieve one side without the other side, as far as my favorite thing to put on the smoker, if it’s a short smoke, if you want to go less than four hours or less, it’s hard to beat catfish.

0:32:08.8 M Edwards: Wow, that already sounds amazing.

0:32:10.3 D Lane: A lot of people would never thought about putting… ‘Cause it’s not the kind of thing you get at a lot of restaurants, but the first time I put a… And it doesn’t matter what kind of fish, but here in the South, it’s a little easier to find catfish, and so you put some catfish fillets on there, you don’t need a lot of seasoning, and you make sure that they do not get over the fire as they will burn too quickly

0:32:34.6 M Edwards: I look forward to more of our conversations here after, thank you for taking the time to talk to us about what you see and hear your journey, the barbecue, the manifesto, and we’ll figure out where we’re going from here. Thank you, Derek.

0:32:47.5 D Lane: Oh, thank you, Matthew, it’s been great.

0:32:53.5 M Edwards: In our next episode, we continue talking barbecue, and we tackle how the 12 principles of the Agile Manifesto are really a roadmap to becoming a barbecue pitmaster.

[music]

0:33:10.8 S3: The Long Way Around The Ban is brought to you by Trility Consulting, where Mathew 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:33:27.0 M Edwards: To my listeners, thank you for staying with us. I hope you were able to take what you’ve 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, the company, and clients. Thank you.

Categories
Podcast

Part I: Deconstructing the Agile Manifesto to Make Better Barbecue

Show Highlights

In this episode, you’ll learn how Derek Lane’s journey in technology and study of the Agile Manifesto coincided with his pursuit of barbecue craftsmanship. These two pursuits eventually mapped together for Lane, and he’s sharing how you can apply the Agile Manifesto and its principles to making better barbecue. 

Along his journey, he created the 20-Day Agility Challenge, a free program where participants commit 15-30 minutes a day to focus on improving their agility. He and a group of colleagues also founded a free online community, Unlimited Agility, where people can take the challenge with others and continue to enable, equip, and educate one another.


Read the Transcript

0:00:00.0 Matthew Edwards: In this episode, I pick up my conversation with Derek Lane as he shares his journey in technology, software development, the Agile Manifesto, and best of all, how it all relates to barbecue.

0:00:17.0 Derek Lane: Every weekend I would try to smoke something. It was definitely this pursuit of craftsmanship. I’d start out with something… The idea is you start with something simple, you’re gonna do chicken, you’re gonna do ribs, and that’s the idea. Well, I’m in Texas and Texas brisket is king. I don’t know how many mistakes I made, I’m sure there were many, but I do know that when after probably about 12 to 14 hours, taking a brisket off that none of us could eat it. I learned a very valuable principle at that time, and this is back when you could still buy briskets for 40, 50 cents a pound. I mean, if it’s on sale now, it’s $2.50, $3, and if it’s not, it’s quite a bit more than that. So it’s a very expensive hobby, is my point, for you to make something that you can’t eat. Some of the techniques I learned, some of the principles that I learned were really to try to figure out how do I make that dollar go a little longer?

0:02:12.3 Matthew Edwards: Today, I wanna talk about something that’s near and dear to my heart, and I believe it’s near and dear to your heart, which is not only meat, and today we’ll talk about barbecue, but also then Agile, what is Agile and how might barbecue and Agile have this weird interrelationship that maybe not everybody else cross-maps in their head, but today we’re gonna talk about meat, barbecue in particular. Does that sound reasonable?

0:02:40.3 Derek Lane: Well, barbecue always sounds reasonable to me.

0:02:43.1 Matthew Edwards: Tell us a little bit about where you’ve come from, like just highlights of your journey, general mindsets, where you are today and where you’re heading, and then let’s mold that into one of the things that you use to teach people and guide and coach and mentor, and just generally pair with folks, which is this analogy or this mapping between barbecue and Agile and where we go from there. But first, teach us a little bit about you, please and thank you.

0:03:09.6 Derek Lane: Okay. Well, originally, my career kind of started as what I call hard engineering; architecture, civil engineering, mechanical engineering, computer drafting, that type of thing, and this is back when DOS was still the primary PC operating system. As a matter of fact, it was relatively new, so that’ll give everybody… Definitely dating myself there. Did that for several years and was able to learn, I guess, back all the way up through what was considered the best computer engineering and drafting systems at the time, and really felt like I had kind of explored a lot of what I wanted to learn, and felt like, “Hey, this is pretty early in my career, and I feel like I’ve already kind of seen all the landscape, what’s next?” And about that time was kind of the emergence of these new things like Microsoft Windows and Linux and other operating systems that are going out there, and that also led to open source software.

0:04:16.2 Derek Lane: So at some point I decided, “Let me go on the other side of the screen. Let me see what it’s like to actually write a lot of code.” And at some point around the late ’90s, it was ’99, 2000, was working on a project for a startup, and somebody mentioned to me that something I was doing looked extreme, and was it extreme programming? And I thought he was making a joke because XP was used as a lot of other things for a lot of other abbreviations, I guess you’d say, and I thought he was making a joke, looked into it, and this is all really pre-Internet, so you had to call the book store, you had to go down to look in the library. I mean, this is back before you could just look it up on Amazon, and found Kent Beck’s book, “Extreme Programming Explained: Embrace Change,” and was just fascinated by the style of the book. Every chapter is two to three pages long, the fact that he was communicating in a very abstract way, but was talking about how do you deliver the pragmatic aspects of value. And when I got through all of it, I really felt like, “Hey, I’m doing a lot of this stuff, but I’ve never heard of this extreme programming. Where is it? What is this?”

0:05:38.6 Derek Lane: Now my background kind of… I guess the formal training I’d received was definitely in a waterfall spiral and ultimately unified process, so really big things which were all state-of-the-art at the time, and realizing XP was one of these things now called the lightweight methodology. And so then I learned about feature-driven development and ultimately about Scrum and Crystal and many others, got to try some of those at different points, and eventually realized, “You know what, I’ve written a lot of code, I’ve architectured a lot of systems, I’ve used lots of different technology,” and that’s still interesting and fascinating to me, but the thing that seems to be the hardest thing is the people problem. When I was learning software, my opinion was that technology was about 90% of the problem, that there were so many technologies. Back then you had to decide what kind of database you were gonna use. I mean, there were so many decisions that you had to make from a technical standpoint, and then you had to get all those things to work together. So people was really the small part of the problem. Of course technology became more standardized, but became more variable too, because now you’ve got more technologies, you’ve got more languages, you have lots of new ideas on how to build things, and eventually I moved over to, “Hey, there’s lots of people who can write code.”

0:07:00.1 Derek Lane: Ultimately, once I understood a little more about the Agile mindset and learned about Lean, Lean startup, Lean enterprise, those types of things, just how to manage waste, how to identify and manage all the different kinds of waste that are part of the process, ultimately, I got to this idea of saying, “Okay, that’s the real problem. How do you get people to decide what they want when they really don’t know, how do you get people to work together and actually work together, not in the same room or the same department or meet every once a week? No, actually work together, and being able to see the nuance of the interactions of people and how that resulted in what was delivered, or whether anything was delivered at all.” And so I decided, “Well, let me spend a little more time learning this, this human aspect of delivering products.” And that’s kind of where I think I’ve spent a little more time. So I’ve spent a little less time, but I kinda inverted my formula. I think it’s now probably 90% to 95% is a people problem, and it’s really about 5% to 10% a technology problem. But to be fair, that obviously with things like free Amazon Web Services and Google Cloud and the proliferation of technology that’s available, that’s definitely had an impact as well.

0:08:22.0 Matthew Edwards: So the journey that you’ve been on though is really a journey of realization, and I will amplify right now that this journey of realization, in my opinion, my interpretation or my perception of the things you said is really a by-product of the type of personality who’s constantly wanting to know more, wanting to see more, wanting to understand, asking why. In other words, you don’t just accidentally discover, “Hey, I’m doing things that are like this XP thing, I wonder what that means,” you choose it. All that stuff is done on purpose, so right off the bat, what in my opinion you’ve already illustrated is you have a hunger to learn and become and evolve, you’re always looking out the window saying, “Alright, I’m doing this thing, but am I doing this thing well? Am I doing it usefully?” And you believed everything was 90% tech and 10% people, and then through the years you’ve discovered that, “Dude, it’s 90% people and 10% tech.” That realization could have been prompted to you by reading it in a book, but it really sounds like you’ve discovered it by living.

0:09:26.6 Derek Lane: Yes, it’s a constant learning curve. And as I moved into software, it was the same way. And I’ve had a lot of frustrated folks who say, “Why are you spending time with that? Why aren’t you spending here doing the thing that we’re paying you to do, or this one thing that we’ve already spent time on? Why are you looking at this other thing?” It’s been a… I’ve been chastised more than once for that. So yeah, it wasn’t until probably I would say in the early 2000s that I learned that there was actually a diagnosis for it, that people actually have been classified as a continuous learner. This idea that there’s actually something wrong with me may be true, but they can’t blame it on the fact that I like to learn new stuff and that I’m always working to learn how to get better. They can blame that on something else, but they can’t blame it on that.

0:10:18.6 Matthew Edwards: But if we fast forward then on that journey, this has led you to a current endeavor or activity that you’re working on called Unlimited Agility, or in particular something that you’ve used as like the tip of the spear called the 20-day Agility Challenge. And I believe based on what I’ve studied and learned and discussed and considered as it relates to what you’re doing, the entire focus is on enabling, equipping, and educating people.

0:10:42.1 Derek Lane: Essentially the 20-day Agility Challenge is my attempt to take a lot of the lessons I’ve learned, almost all through mistakes or misunderstandings on my part, and put them in a format that over a period of 20 days an individual can be challenged against the Agile Manifesto, and the unique aspect of this, or what my hope is, obviously it’s difficult to have your hands in the middle of something and not get some of you on it, but my hope is that the person is challenging themself against the Agile Manifesto as I understand it today, not against Derek’s way of doing things, not against Derek’s version of Agile.

0:11:26.6 Derek Lane: My hope is that this is independent of me as much as can be, and I’ve gone through a number of folks that I’ve worked with over the years that I respect a lot to go through and review it, to give me feedback, to tell me how we can improve it, actually applying the principles in the manifesto to building of this particular challenge that the… One of the things about agility is that you have to decide, as you said, are you going to really pursue this or are you just gonna do the minimum that someone says you have to do to check the box and go on down the road? If you’re really going get better, whether that… You don’t have to be a coach or scrum master, if you want to understand agility and how it applies to business, to everyday life, to some organization that you’re involved in, you’re going to have to work at it. So that’s the intent of the 20-day Agility Challenge.

0:12:18.0 Derek Lane: And then with some feedback there, early on, I was like, “Well, this is great, it’s designed for an individual to do it theirself, but everybody’s not the kind of individual who wants to do this by themself. They’d rather go through it with a group. So how can we do that?” So we created an online community that’s free to join called Unlimited Agility, and that’s one of the things… The goal is really to focus and pursue servant leadership, because that’s so abstract, through the means that we’re more familiar with, which it might be Lean or Agile, or growth mindset or human-centered design, DevOps, any of those things fit in there, ’cause that’s the pragmatic, that’s the tangible thing that we see, but servant leadership can still be the underlying set of principles there and be a contributing factor to the outcome of applying Lean or Agile or so forth.

0:13:17.0 Derek Lane: So one of the things that we do in the community is we offer cohorts for folks who want to go through the 20-day Agility Challenge with others. Again, the point is not to go to the cohort and get the answers to the quiz, that defeats the purpose, that’s not the intent at all. It’s really just to say what can we do to help you ask yourself another question so you can really determine why do you believe this about Agile? Why do you think Agile is this? Why do you think Agile is not this? Where did you get that idea? How did it come to be? And a lot of folks just haven’t taken that time. And then the second thing they haven’t done is really dig into the Agile Manifesto. So that’s kind of my first attempt. And I’m working on… We’ve been trying to get a book out that would even explore that a little bit more and add to it for everybody who doesn’t have access to online, or at least a consistent connection, those kind of things. So we’re hoping that that will grow into more, but we’ve got other things there we can talk about maybe next time.

0:14:17.2 Matthew Edwards: I wanna amplify right before we move on from that, it’s a focus on servant leadership, it’s a focus on craftsmanship, which that whole journey, like Pete Breen wrote an excellent book on software craftsmanship quite a while ago, just talking about this was a journey, it’s not something you accomplished. And so you’re really talking about becoming more tomorrow than you were today, and more today than yesterday, but it’s a continual journey. That’s one of the things I wanted to amplify, is the servant leadership, the pursuit of the craftsmanship, and the other interesting thing too that your desire to foster is a psychologically safe judgment-free environment where everyone is valued, is really what you communicated there, and the intent is a safe place to consider and think out loud and get some alternative perspectives or additional or modified perspectives. Tell us about how you’re mapping some of the tenets or behaviors or patterns, the types of things that you see in your love and journey of barbecue, tell us a little about the barbecue journey.

0:15:25.5 Derek Lane: I guess I’d mentioned around 2000, 1999, 2000 is when I came across Kent Beck’s book. And it was a couple years later that I kind of decided, “You know what, I have never learned how to cook.” So I could cook a burger, a hot dog outside, but that was the extent, that and toast, that was about the extent of my cooking ability. So what I decided to do was, back then, you could go down and for 100 bucks, you could easily buy a smoker. Now, the popularity of this has gotten to where they’re hundreds and hundreds or even thousands of dollars for even a kind of a low level or entry level smoker, depending on what you’re looking for. But I got one, I made the brilliant first time person mistake, which is it was un-assembled when I got it, and I assembled it in the den and then it wouldn’t go out through the back door, one of those kind of things, so I had to take a couple of parts off so I could get it on the porch.

0:16:27.2 Derek Lane: And I think ever since then, I was doing… Every weekend I would try to smoke something, it was definitely this pursuit of craftsmanship. I’d start out with something… The idea is you start with something simple, you’re gonna do chicken, you’re gonna do ribs, and that’s the idea. Well, I’m in Texas, and Texas brisket is king, so brisket’s gotta come up on the dial pretty quick. And I think the first time or two I did chicken or sausage or something, and that’s not… Again, this is not grilling, this is smoking, so it’s low and slow, is the phrase that goes with really that type of barbecue, as opposed to turn it up to 900 and try to flame kiss everything. So at some point I got a brisket, I put it on there, read everything I could read, and that… Again, this is pre-internet, so it’s go to Barnes and Nobles or go to wherever, find a couple of books, put your head in them for a couple days, try to figure out what they’re saying, and then we’re gonna go try it. I don’t know how many mistakes I made, I’m sure there were many, but I do know that after probably about 12 to 14 hours, taking a brisket off that none of us could eat it. I learned a very valuable principle at that time, and this is back when you could still buy brisket for 40, 50 cents a pound. If it’s on sale now it’s $2.50, $3, and if it’s not, it’s quite a bit more than that. So it’s a very expensive hobby, is my point, for you to make something that you can’t eat.

0:18:01.3 Derek Lane: And so I had to find more… Some of the techniques I learned, some of the principles that I learned were really to try to figure out how do I make that dollar go a little longer? How do I stretch it out and go from there? And one of the things I did after talking to you was actually, I’ve threatened to do this for years, and I’ve never actually sat down and done it, but was to actually go through the Agile Manifesto, put my barbecue hat on and say, “What really maps to this idea of applying Agile values and principles to creating good barbecue?” And if you’re interested, I thought maybe we could spend a couple minutes going through that.

0:18:42.3 Matthew Edwards: Also, right now we’re recording this podcast in the morning, I am already thinking about lunch and dinner.

[laughter]

0:18:50.2 Matthew Edwards: Eventually we did have to stop for lunch, and we continued to meet and discuss the Agile Manifesto, its 12 principles, and how it very much translates to creating better barbecue. Make sure you don’t miss them. Subscribe to the Long Way Around the Barn.

Categories
Podcast

Podcast: Unlimited Agility

Show Highlights

The Agile Manifesto is often thought of as a historical event or document, but Derek Lane is hoping to redefine how it’s introduced and revisited because the principles are time- and battle-tested in how it brings value to people. As 2021 marks the 20th anniversary of the Agile Manifesto, Lane and fellow colleagues have formed a community, Unlimited Agility, where you won’t find answers, but you will find like-minded individuals to challenge your beliefs and help you grow in your thinking and your work.

Key Takeaways

  • The Agile Manifesto isn’t a one-stop visit, it doesn’t make sense until you continually revisit it and recalibrate your understanding.
  • Parallel concepts exist – Craftsmanship, Servant Leadership, Lean, Scrum, Kanban – and looking at the Agile Manifesto through their lenses help to broaden understanding 
  • Take the 20-Day Agility Challenge and join the community.
The third Unlimited Agility Conference is being planned right now. This conference was created to promote practitioners of servant leadership who are local and regional leaders who work every day, side-by-side with individuals, teams, and organizations. 

Read the Transcript

0:00:00.0 Matthew Edwards: My guest today was around 20 years ago, when the Agile Manifesto was written, and has watched it evolve in the minds of people, teams, companies and cultures through the years since. He is a community builder, author, speaker and Agile coach. The list goes on and even includes a barbecue life coach, in the event that’s interesting to you. Derek Lane visits with me about how the organization, Unlimited Agility, is building a community for people to consider their journey and how it compares to the original intent of the Agile Manifesto.

0:00:37.4 Derek Lane: I guess I had realized I had learned a lot, I felt like I’ve kind of validated that learning and been able to learn better ways to introduce people to it so that they have a better appreciation for it, and they understand this is not a one-time stop, this is not the… I’m gonna go visit the Capitol or Disneyland. It’s one time, that’s all I’m going to go my whole life. No, this is somewhere you need to come on a regular basis. You’re not going to get it all the first time, and some of it’s just not going to make sense. You’re not ready for it. You need to go back if you need to go back, and you need to go back.

0:01:14.2 Matthew Edwards: Welcome to The Long Way Around The Barn, where we discuss many of today’s technology adoption and transformation challenges and explore varied ways to get to your desired outcomes. There’s usually more than one way to achieve your goals. Sometimes the path is simple, sometimes the path is long, expensive, complicated, and/or painful. In this podcast, we explore options and recommended courses of action to get you to where you’re going now.

0:01:45.8 The Long Way Around The Barn is brought to you by Trility Consulting. For those wanting to defend or extend their market share, Trility simplifies, automates and secures your world, your way. Learn how you can experience reliable delivery results at trility.io.

0:02:06.6 Matthew Edwards: One of the things I’m curious about learning from you, Derek, is Unlimited Agility. Will you teach us a little bit about what you’re intending to explore? What is the motivator? What’s the desired outcome? How did you get here? And where do you wanna go? And then tell us a little bit about the journey.

0:02:23.2 Derek Lane: Sure, okay. I guess this all kind of started in January this year when I… For whatever reason, a random thread was running through my head and I realized from, of course, last year, I knew this, but it wasn’t time yet, that the 20th anniversary of the Agile Manifesto would be happening in February. I’ve gone through a number of different learning curves as we’ve discussed some of those over time, and I’m constantly trying to figure out, “How do I make this better and is this something I should stop doing and do something else?” In recent years, I’ve gone through a reboot of what the Agile Manifesto is and how it should be presented, versus how I’ve been taught and seen other people coach it over time.

0:03:06.5 Derek Lane: I think the difference is, is that most people, when they’re introduced to it, it’s at most, no matter what, it’s a half day, one class, a two-day class, whatever it is, it occupies anywhere from half an hour, to a couple of hours. And the Agile Manifesto is introduced as a historical event, a historical document, and it’s just really watered down and then it’s focused on practices and maybe some concepts, but we move quickly to the checklist, the 12-step program.

0:03:34.7 Derek Lane: This is Agile, Agile is supposed to be this, so this is what it looks like. Well, through the lens of Scrum, it looks one way. Through the lens of XP, it might look different, through the lens of Kanban, it might look significantly different. Through the lens of Safe, it looks radically different. So depending on what your introduction point is to the Agile Manifesto, and agility, has a huge impact on your reference point of what it is and what its importance is, and the ability to achieve or be able to accelerate this idea that we call agile or agility. And then there are parallel concepts and domains out there such as Lean, and we have even more abstract ideas, such as craftsmanship. What is craftsmanship? We have this idea of servant leadership, what does that mean? There’s lots of debate about these things, and when it all kind of zeroes in on the Agile Manifesto, I guess I had realized I had learned a lot, I felt like I’ve validated that learning and been able to learn better ways to introduce people to it so that they have a better appreciation for it, and they understand this is not a one-time stop, this is not the…

0:04:48.8 Derek Lane: I’m gonna go visit the Capitol or Disney Land. It’s one time, that’s all I’m going to go do my whole life. No, this is somewhere you need to come on a regular basis, you’re not going to get it all the first time, and some of it’s just not going to make sense. You’re not ready for it. You need to go back if you need to go back, and you need to go back. I think it’s a missing element in how Agile is often thought of as either a goal or now people are trying to update it as a journey or a destination, but I think we’re still missing this element that I’m now calling regenerative agility, which is this ongoing… Returning to the source to validate what we think we’ve picked up, throw away the stuff that was really junk, build on top of what we have now, pick something up new and then let’s go on again and then let’s come back again. So it’s very inherent, for those who know the Agile Manifesto and familiar with it, to see this idea of both iterative and incremental improvement, because learning is at the center of all of this, this idea of constant growth and improvement.

0:05:48.8 Derek Lane: Again, my idea was, how do I take something I’ve learned and give it back to the community? How do I find a way to honor the work… I talked to a number of folks, a number of former co-workers and colleagues and things, and came up with what now I call the 20-Day Agility Challenge, and the idea is basically a step-by-step period of time, from anywhere from as little as 15 minutes a day to as long as you want to spend.

0:06:20.2 Derek Lane: Typically, it’s not more than 30 minutes to an hour, but the idea is that you… Each individual would challenge their own beliefs on what Agile is, against not what I say, but against what the Agile Manifesto says. So it’s a deep dive inspection into every element of the Agile Manifesto over a period of 20 days. And then at the end, it’s like, “Well, this isn’t all there is. What do we do next? How do we take this and move on?” The 20-Day Agility Challenge is free, it was intended to be available, it’s delivered right now through email, and it’s available for anybody at 20dayagilitychallenge.org, so anybody can go out there and sign up. But in the beta testing of this, a lot of feedback came in from some folks saying, “Well gee, Derek, this is good, it’s designed for an individual challenge, but there’s a lot of people who aren’t ready for that, or that’s not really their approach to things, they do a lot better in a group,” and I agree, so while some folks… And we talked about options, will pick some co-workers or somebody and go through this, not everybody has that option, or not everybody is going to be the kind of personality that’s going to go try to round up people to do this.

0:07:34.1 Derek Lane: So we decided to create an online community where we could create regular cohorts where folks could get together from around the world who wanted to go through this and create kind of an accountability group, so everyone would have at least a couple of accountability partners that could go through the challenge themselves, they would have someone to discuss this with, and then we actually have a couple of times a week through that 20-day period where someone who’s already been through the challenge will help facilitate it. So far, it’s been myself and a couple of other folks. Our goal is… There’s no answers here, this is not a matter of… We’re not filling in the blank. This is not quiz time. The goal is for you to challenge your own beliefs against what the Agile Manifesto says, for us to figure out, how can we help you if you get stuck? And we have interesting questions and really good discussions and topics have come up, and some of them are online, just through the chat type situation, and some of them are more through a Zoom type situation, so much more interactive as far as in person.

0:08:35.7 Derek Lane: But that led us to creating a community, and then that led us to a kind of a more foundational realization that there are other concepts that people struggle with besides agility. Lean, for example, which I mentioned, the growth mindset. What does that even mean? Servant leadership, craftsmanship, all of these things. How do I get from here to… Are these things related? Or are they… Is Scrum the same as Agile because someone told me that? And if it is, then what is this Kanban thing and why aren’t we doing that? And so there’s all of this complexity between these concepts, a lot of them are abstract, and then the general interaction that people have more on the day-to-day basis with what we typically refer to as the practices, and so we’ve kind of expanded that a little bit. That led us, interestingly enough, to creating an arena for people to practice, to try out these new skills, to share what they’ve learned besides just an online community, so we’ve created the Unlimited Agility conference and we’ve held two of them so far, we’re running them quarterly. The next one will be in November, and the idea there is to really invite people who aren’t necessarily the big name people. This is not “Come and listen to someone else,” this is “Come and interact with someone else,” this is “Come and share your experiences.”

0:10:00.7 Derek Lane: And so we think we’re pioneering a new approach to virtual conferences, we got to thinking about what are the things that people don’t like, the things that don’t work, the things that are different in a virtual environment, an online environment, then from a physical conference. And I wrote a LinkedIn article to try to enumerate a lot of those, but what we’ve learned so far is that in a physical conference, one of the things people like is the physical interaction. After a speaker gets done with their session, maybe I could go catch them afterwards and ask them questions, or get coffee or get dinner. Well, we can’t do that in a virtual environment. Even if we have breakout rooms, it’s not really the same thing. But what we did is we decided, well, what would happen if the speaker was to sit in the audience with the attendees? You can’t do that in a physical conference, it’s just physically not possible. Newton’s second law, I think, might have something to say about that. So what we decided to do is we have all of our speakers record their sessions, and we’re using a modified TED Talks format, so none of them are more than 20, 25 minutes long.

0:11:05.4 Derek Lane: But the idea is that now because they’ve done that, this doesn’t mean they’re going to record and the speaker is gone, this means now the speaker’s in the audience, and they can interact with the audience. They can say, “Oh, I meant to add this here.” They can say, “Here’s another reference, it wasn’t occurring to me at the time.” But this is the first time that we know of where a speaker gets to actually participate and put theirselves in the role of the attendee for their own session. So we’ve created this new kind of way of thinking about delivering content, and it’s much more communal, it’s less serial, and it allows then, that extended conversation to go on, people can literally ask a question at the moment it occurs to them during the session and get a response from the speaker in more or less realtime. So we’ve kind of combined this idea of the Q&A and the director’s cut with the idea of an interactive session. It’s just interacting in a different way than we think of, if we were physically in the same room and I could raise my hand, and eventually you might call on… Or you might not.

0:12:13.4 Matthew Edwards: Well, let me reiterate so far what I think I’ve heard, which is the motivation here, as I understand it from you, is to give an opportunity for people to reflect upon where they are in their journey in relation to the original intent or communication of The Agile Manifesto, and it was motivated to some extent, in context of the upcoming 20th anniversary. And so out of that, the conversation is, “Hey, how have we evolved? How are we doing?” And so you’re looking to create a type of environment where people are able to come together and say, “Hey, I was thinking through this, this is how I’ve typically understood, this is how I’ve applied it. How are other people doing it?” So it’s kind of like a conference, not really a conference, it’s kind of like cohort, but the assumption is Agile Manifesto, where are we and you in relation to the manifesto? So what do you believe? What do you practice? And why do you believe it? And then how are we doing evolving? It sounds like you’re creating a safe environment for people to evolve together with a single point of origin, which is the manifesto.

0:13:28.5 Derek Lane: Yes, it’s that. I would say that it… However, a slight difference, I would say, is that it started with this idea of focusing on the Agile Manifesto, but it’s now expanded to include Lean principles and what is servant leadership, (Robert) Greenleaf’s work. And so it’s no longer… While the name Unlimited Agility is still, I think, an accurate description, it’s not limited to agility in the sense of the Agile Manifesto. You also have Agility by being a better leader. One of the things we’ve learned from folks like… Was it Adam Grant and Simon Sinek? And those folks, is that they’re talking about leadership, they’re talking about a different kind of leadership than most of us have been exposed to and have been trained that way. They’re talking about leaders where the employees are first, they’re talking about leaders where customers are right, but it’s not a matter of just the customer is always right, it’s a matter of, “Well, the customer is right, but they’re right, why?” Because we need to validate that if what we’re doing isn’t valuable to them, they’re not gonna continue to be our customer. So it’s no longer a technology-centric in the way that, often, Agile is thought of.

0:14:47.2 Derek Lane: Because Agile starts out by saying that this is the Agile Manifesto for software development. There’s nothing wrong with that, but with the change of literally a handful of words, we can abstract the software-specific aspects of this and realize that we don’t have to change 99% of the rest of these values and principles, and they literally apply in almost every context.

0:15:11.7 Matthew Edwards: So what would you say so far in this journey, has been an unexpected surprise? Whether a pleasant surprise or a distasteful surprise where you realized, “My goodness, what was I thinking? I need to make a change.” What type of surprises have you experienced along this journey?

0:15:30.4 Derek Lane: Well, I’ve definitely been through the, “Gee, I thought this was gonna be different or easier, or fewer steps,” a number of times. I think the challenge that has always been there, that it’s not unique to this effort, of helping… Of communicating to people that there is no checklist that’s going to make you agile or lean, or smart, or fast, or profitable, or… Fill in the blank. This is not a 12-step program. Agile is not a 12-step program, and I’ve been saying that for years, and I’ve been saying that about a number of different things besides Agile, but the challenge is that the force, the gravity of a black hole is pulling so many people in business, so many people in technology, to hurry up and get it done, to check the box to do the next thing. It’s all about the task and the project plan and the delivery date, and it’s not about value, it’s not about people, and that’s what the Agile Manifesto starts out by telling us that, this is all about people. Some people seem to already be a bit like Neo in the Matrix, they already have a… They suspect something is not right about the way things are going, but they’re not quite sure what it is, and then there are other people who are well aware that… They don’t know what to do about it.

0:16:53.1 Derek Lane: Nothing they’ve done has worked. And so I think a community like this can really help them because first of all, it’s going to put them in touch with people who have either been or are currently in the same spot that they are, so just the fact that we know now that there are other people that are just like us, that’s a huge psychological benefit, that creates a certain amount of community there. And then we’re hoping to create these other mechanisms for folks to be able to then exercise and practice and learn new ways of doing things that are maybe external or tangential from their normal everyday lives. But then as they learn and meet people from around the world who have had success with something and they get a new idea, and now they’ve got a sounding board and accountability partners, an expert, so-called, that… Someone who’s just a little further down the trail than they are, they can go ask these folks for help and say, “What do you think? What would you do? What could I try?” And I think it gives them a whole new range of options that are very personalized, and… Because they’re creating this new community, and our goal is for it to be a self-sustaining community where the members of the community decide where we need to go next. And we’ve got a long list of potential things on a backlog, but right now, now we’re back to, “We’ve gotta validate those…

0:18:22.1 Derek Lane: The community finds those valuable now,” versus later, versus never. One of the other benefits of our format is that a lot of people who have a lot of experience, and you’ve done this, you’ve been in a room and you’ve heard somebody, they’re just a little timid, they might talk a little softly, but you’re like, “Wow, man, you’ve got some gold there. Why don’t you share this? Why don’t you speak up?” And that’s just not their personality. But with our format, they can record and get a lot of feedback. Through the process of recording, they can record their session, and then they can from a safe distance, because social media has proven… People are perfectly… Feel perfectly safe with the keyboard in front of them, between them and their audience. And be able to then interact with the audience and gain that confidence and be able to still share a lot of the values and experiences that they’ve had. And I think in the last conference, we really had a lot of transparency from some of the speakers who were saying… Explaining, “Here’s some stuff that didn’t work,” and being willing to be vulnerable. I think that’s… It’s becoming a little more acceptable in some arenas, I think, with the help of folks like the TED Talk from Brene Brown and other folks like that, that are encouraging leaders to realize the value of being vulnerable with the folks that you lead, and the value that that gives them to help them be better leaders.

0:19:48.5 Derek Lane: Now we’re getting back into servant leadership, so it’s amazing how all of these things are interconnected, the patterns are repetitive, and they appear to exist in each one of these domains, or in this case, in lots of these different concepts. So if we can maybe… Dismantle is not the right word, maybe if we can reveal enough of the pattern so that people can see the parallels of something they’re more familiar with, then they will gain confidence and they can grow quicker in an area that maybe they’re not as familiar with.

0:20:22.9 Matthew Edwards: So after you have one of these conferences, the types of material that’s reviewed during these conferences, does that continue to be available to the attendees or folks later?

0:20:35.4 Derek Lane: Well, the discussions that happen on the… Essentially the chat boards, the Facebook and Twitter-like features of the community, those are available and open all the time. So because we wanted to make this available to everybody, we created some separate levels of membership. The entry level or the lowest level that’s free as far as charging goes, is available to anybody who wants to just basically go on and create an account, but what we’re doing to try to help… Again, to kinda hopefully make the community self-supporting and self-sustaining, is we have from the day of a conference, which always happens on a Thursday, it’s open to the public, so anybody who basically registered for the conference gets access to all of the materials for the conference, including a speaker’s roundtable that we do at the end where the speakers get to ask each other questions, and a number of other interesting things that we try to come up with. But after that, the idea is that any of the paid level memberships will have access to all of that archive and that material, so yes, it is available and it’s online, but after that kind of window of a week, then it’s available to any of the paid level memberships.

0:21:48.2 Matthew Edwards: So Derek, what do you think you need next in order to evolve it to the next level?

0:21:53.2 Derek Lane: Well, I would say, just to tag on to the previous idea, the conference is free. Again, we have a free level of the membership, the 20-Day Agility Challenge is free, so we’re scheduling to have three or four of what we’re calling either lakeside or fireside chats, depending on what time of year it is. So we’ll have two of each, each year, if we’re fortunate. And that’s really more of the idea of a sit-down interview with someone who is considered more of a leader and expert in some area. That’s something that we’ve already got cued up, and that’s coming in the pipeline. Our goal is to really be able to give 10% of the profit that might come in from running the… To charities that we’ve validated. So we’ve already verified and validated three charities, and we hope to be able to… We’ve got another couple in the pipeline, and we would like to be able to set that up to where that’s just a part of everything we do, so that as people can register for free for the conference, instead of paying for the conference, they could donate to this charity.

0:22:55.6 Derek Lane: We feel like that’s a way to practice this idea of servant leadership and be able to… But in a real physical, tangible way, to any of the charities that they might feel more affinity for. So that’s something that we’re looking to expand on as… We’re really just looking for additional volunteers. As we get more volunteers, we’re able to do more things. We’re looking for folks to help with… We’ve got another set of websites that we’d like to get up and running, that we just haven’t had the bandwidth to get up and running. So those are skills that would be greatly valued and help. We’ve got stuff cued up as far as trying to make workshops available, so we want to have both some free and some, again, some paid content that would help support the community so we can do more things. And those will be in a number of different areas. I think to start with, we’re kind of saying, “Here’s some introductory level things,” but not introductory in the way that, again, that it’s often communicated. We want to be able to do something that we feel like is kind of “We’ve learned more, and here’s maybe a better way to introduce some of these ideas.” But we have a number of additional, like I said, things on the backlog. I think where we’re going is to grow a group of volunteers that are interested in exercising that servant leader or that craftsmanship muscle, and we want to give them a chance to do that.

0:24:31.8 Matthew Edwards: I went out and looked at your sites previously, and looking at them again today, and so for someone who wants to learn, what’s the front door URL you’d like people to go to to get a look into it?

0:24:44.8 Derek Lane: Sure, the 20-day Agility Challenge is 20, it’s the number two zero 20dayagilitychallenge.org, they can go there and register for the 20-Day Agility challenge. They’ll basically receive that… It literally is a matter of putting your name and your email in. You can also do this, again, with a cohort, that’s where you can go to the community and join the community, and there’s a separate group that’s just for the 20-day Agility Challenge Cohorts. For the Unlimited Agility community, it’s members.unlimitedagility.com. Their regular triple W website is one of those we’re almost ready to launch, but not quite there yet. So the membership website is up and running, and that’s where you can go and choose a plan. Again, we just encourage folks to choose the free practitioner plan, and that’s all the way at the bottom, as the options that you have for membership. But the landing page there tries to describe what the community is and what we’re trying to do, and it shows the charities that we’re currently supporting right there, and tries to answer any of the typical questions, there’s some FAQ type stuff on there.

0:26:02.6 Matthew Edwards: Right on. That’s outstanding. Derek, we have covered very many topics to a lot of depth and breadth, across our time talking together, and I just want to thank you very much for taking all this time to give us insight into your journey and the types of things you’ve learned and where you are and where you’re heading, and in particular, the work you’re doing with the 20-Day Challenge and the Unlimited Agility. That sounds amazing, and well done. Thank you for your time, good sir.

0:26:32.7 Derek Lane: Hey, thank you. Thanks for your interest, I appreciate it.

0:26:35.5 Matthew Edwards: This is just the beginning of our conversation with Derek Lane. Our next several podcasts deconstruct the Agile Manifesto using the analogy of learning how to barbecue. Now, if you would love to smoke meat or would love to improve your ability to smoke meat and other items I would never have thought possible, and you have a desire to always become more today than yesterday, using the Agile Manifesto as your guide, I encourage you to keep listening. Derek should write a book on this topic, but until then, you’ll have to settle for listening to raw, candid conversation that might also make you hungry along the way.

0:27:16.6 The Long Way Around The Barn is brought to you by Trility consulting where Matthew 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:27:33.3 Matthew Edwards: To my listeners, thank you for staying with us. I hope you’re 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.

Categories
Podcast

Podcast, Part III: Bridging the Gap Between the Art and Science of Data Analytics

Show Highlights

Science is the iterative testing, results change over time with variables. For data science, what’s true today could dramatically or incrementally change tomorrow based on one variable. The art of it is accepting that there will be exponential opportunities to discover more, learn more, and communicate more to find value and purpose in data.

This final episode with Jacey Heuer provides insights into how individuals can seek opportunities in this field and how organizations can purposefully mature data science and advanced analytics.

Missed the first two episodes? Listen to them both: Part I and Part II.


Read the Transcript

0:00:58.1 ME: In our third session with Jacey Heuer, he helps us bridge the gap between the art and science of data analytics. We discuss what is required of people and organizations to explore, adopt, implement, and evolve today’s data science practices for themselves and their organizations.

0:01:18.2 Jacey Heuer: And so I really look at this as, again, bringing it back to science and art. Science gets you to the insight, the art then is how you tell that story and paint that picture to create comfort with some of that uncertainty that you’re now revealing in your data.

0:01:35.2 ME: So as it relates to individuals and organizations and the adoption of a more formal data behavior, through your experience and your perspective, the study, the work that you’ve done, how do we make this a normal, common daily conversation for people and companies instead of this emerging knowledge area that some people are studying?

0:02:05.9 JH: You’re right, the passion is a key component of this, right? I think passion across anything you’re engaged in is important to be able to find that and it’s a true driver motivators finding your passion. Mine is learning, happens to be with data science, and those kind of come together well for me. Just going a bit deeper into my personality with this too, is data science, as much as there’s science involved in it, there’s a lot of art involved in it. Personally for me, my background, I have an art background as well, in my past. When you think about left brain, right brain, creativity, logical, all that kind of stuff, it’s usually more binary, more definitive, and for whatever reason, I have some bit of a crossover in that. I can find enjoyment in both sides of that and it works well for me with data science, but what I think about from the standpoint of trying to wrap your brain around, what does this mean, how do I gain comfort in sort of the mindset that it takes to deal with and feel okay with ambiguity, uncertainty, right?

0:03:11.9 JH: I think so much and so often in business, which rightly so, it’s, I want to know definitively, 100% accuracy, what’s gonna happen in the future and so on. That’s a fair mindset, and I think there’s a lot of good leaders and people realize that’s not possible, and you make your own decision too. Given the information I have at hand, what’s the best decision I can make, and you go with that. Data science is really taking that human decision process, which you’re already dealing with, uncertainty, whether you’re aware of it or not, and just putting more support to quantify some of that unknown through data. And in that does require a new mindset of, the information I’m taking in may become more broad because I’m getting more data supporting the breadth of my decision-making, but then that also then becomes the realization and vulnerability of really seeing the uncertainty that the decisions I’m making, distilling those in my mind, that uncertainty in a way that I may not be aware of, but now because that data’s present, I’m aware of that uncertainty and becoming more potentially concerned with that uncertainty.

0:04:23.9 JH: And that’s where the side of the data scientist becomes vital and important, it’s a storytelling. And so how do you tell that story and manage the uncertainty that you’re now highlighting to a leadership or an individual that they might not have been aware of before? At least consciously aware of that is maybe the better way to state that. And so I really look at this as, again, bringing it back to science and arts. Science gets you to the insight, the art then is how you tell that story and paint that picture to create comfort with some of that uncertainty that you’re now revealing in your data.

0:04:56.1 ME: That’s similar to just about any career, I imagine, but I know explicitly in the technology side of things where there can be absolutely fabulous software developers who have not yet discovered that they have to also be able to communicate the goal and the journey and the value and manage that message and I wonder if that’s not a learned behavior for any human, but the fact that you’ve articulated the relationship between art and science all as the same collective responsibility, that’s really powerful.

0:05:37.1 JH: Science inherently is journeying into the unknown. Science is meant to constantly test and retest and so on. That’s what good science is, but there’s rigidity, there’s a tool belt that can be applied to that testing. It’s a known set of tools, generally. The art side, the learning there comes through experience, comes through vulnerability, comes through the willingness to test out, does this… From a data science perspective, does this plot with the dots on it mean more than the plot with the lines on it, does the bar chart mean more than the pie chart and so on and so forth, and how do I combine those together to get that message across, and at the same time, beyond the visual, it’s… Your written and verbal communication as well becomes essential ’cause you’re the one creating the confidence in this new idea that you’re bringing to the business.

0:06:37.7 JH: You’re bringing across… A good example I have would be the concept of distribution density plots, so it’s a very statistical term, basically all it is, you think about a normal distribution bell curve, it’s putting some statistics to that bell curve, just for example. How do you convey what that means to someone that has no statistics background? When you say the word density plot, their eyes glaze over. Being able to distill that down to elementary terms, do it in a way that gets your point across and drives the decision that, I think requires just stepping into the arena, finding and seeking out bits of that opportunity to challenge an idea, challenge a mindset with some data-driven visual, some data-driven insight and put it out there and see what happens. Again, science versus art, science, I think you can practice, you can get through history of defined techniques. Art is more, what works, I just have to try it.

0:07:47.4 ME: So I will amplify that to walk into my next question. Your statement was just, “I have to try it.” And part of my curiosity from your perspective is, let’s talk about someone in an organization who’s just now discovering the whole field of data on purpose. Doing data on purpose. So we’re not talking about just your historical typical, “Let’s create a 2D plot in Excel and call it a day.” We’re talking about trying to understand multiple dimensions of many seemingly unrelated things that when put together may actually reveal something that would never have occurred to our minds, we wouldn’t have seen because we weren’t looking for those types of things. For someone that’s just now figuring things out saying, “Hey, I really think that this might be a thing, I want to look into this.” We’re assuming that they’re starting in kindergarten, they’re starting with near zero. Where would they go? How should people get involved, get their feet wet, jump in? What do you see? What do you know? What would you recommend?

0:08:57.0 JH: Luckily, especially within the last decade or so, the learning options online, the open free learning options online have accelerated vastly. Like with a lot of things, a Google search for data science is a good starting point. There’s a number of open free coding academies. Coursera’s a great one, Udacity, things like that, not to market for anything individual, but it’s starting there as just this data science road map. What do I need to learn? What are the foundation skills to kind of build on? And getting a sense of what the scope looks like, I think starting with just that Google search can help define what are some of these terms and areas of this space that pop up and begin to emerge, things like statistics and programming, R and Python and SQL and kind of this whole space, just starting there with that cloud of what’s out there, to me, is always a good way to begin any project. What is my space that I’m living in? Really then what’s probably been most useful to me, it comes down to learning some of the core concepts and technologies, and then seeking out opportunities to practice and apply those, even if you’re stumbling your way through practicing, applying those, start trying to force those into whatever you’re working on right now, and it may not be the solution for your project at hand, but can I take a sliver of it and make it work from a data science lens to build up my skill set?

0:10:34.7 JH: To really give a maybe more concrete answer to things to focus on, I think it’s… Traditional statistics is a great place to start, and again, there’s a number of resources that are great for that, just through a Google search, statistics being what is the difference between mean and mode and what’s your range, min and max, how do I define a distribution? Things like that. Starting there, then moving into probability, probability is a big concept in data science, machine learning, so getting your mind around that space. You don’t have to be an expert in it, but at least becoming familiar with terms of probability. Probability Bayesian inference is another area that’s out there that goes hand-in-hand with probability as well, those three areas, traditional statistics, probability and then Bayesian inference, which has a lot of probability in it, are three sort of core foundational areas of this spaces, stats to be involved in. And then it’s moving into the technology side, so now you’ve learned and got a grasp on some of these statistical ideas, pick up R, Python. I’m an R guy.

0:11:46.3 JH: Python tends to dominate. Depending on your source, Python might be a little bit in front of R, it could go back and forth. Either one, the mindset I have is become an expert in one, but be familiar across both of them. ‘Cause you need to be able to operate on both sides, and either one of them, you can be working in R and you can leverage Python, you can be in Python, you can leverage R and go back and forth. There’s a lot of capability in the libraries and packages that are out there. And then as you develop the skill set of your technology, some of the base statistics, now start venturing into your machine learning, your AI. And depending on your source and your mindset, all of this really comes back around to developing the skill set to be an expert line fitter is what it comes down to. I say that kind of tongue and cheek, but really, anything you’re doing from a modeling perspective, it’s your taking your data set, which may be X number of columns wide, you can re-imagine that as being X dimensions in space, you have one dimension, two dimension, three-dimensional space, which is what we all live in. You can plot three dimensions on a plot relatively easily, but as you go up into higher dimensions, you can’t really plot that.

0:13:06.4 JH: That’s where a lot of the mathematics come into play then it’s how do you navigate a multi-dimensional space of data and be able to, out of that, to kind of, your thoughts earlier math, you distill meaning from something that in this multi-dimensional space, you can’t visualize and there’s no simple way to get your mind around it. That’s where machine learning and AI and stuff comes into play then. It’s those tools are effectively putting a pattern, finding the pattern in that multi-dimensional space that lets you either split it up or pinpoint a data point and so on. So that’s kind of the foundational skill set I think I would focus on, thinking about it. And then from that, there’s subsets and offshoots, you get into TensorFlow and PyTorch and all these other things into the cloud, all that, but that’s the core of where you really started when you’re talking about “What do I need to get into and start learning to go down this path?”

0:14:01.9 ME: So you led with, “Look for opportunities,” and then after that, I believe you said, “You need to go learn some fundamental elements of statistics.” And there were three different areas you were focusing upon. Then, “Go learn about some of the technology.” Then after that, you were talking about how you can start to take the statistics plus the technology and start discovering, seeking or otherwise applying that. So you’re starting to become operational at that point. So the first two steps are really classes of preparation, if you will, classes of data, prepare steps, but you start to become operational after you have those two classes of things under your belt in terms of familiarity, experiential pursuit that type of thing. So really three big steps. What you just communicated is a time-based journey of course, but I think one of the most valuable things you may have said there is, ultimately you have to seek the opportunities, or this was just an academic exercise of reading about this, then reading about this and then tomorrow there’s new subjects.

0:15:11.2 JH: Very true, and really, the reason for that is, space is so broad. I don’t think it’s unique to data science and this discipline, but there’s so many methods, so much research out there, problems are… There’s no standard, typically no standard problem. And so it’s really that process of, “I have a problem, now what are some methods that I can maybe force on that problem?” I tell you, I think the power… And again, I think this is common across many skills and disciplines, but it’s as you add breadth to your knowledge base, really a lot of the power you bring to your role as a… Your emerging role as a data scientist is not necessarily the expertise you have in a particular method or approach, but it’s the knowledge base you contain of what are alternatives to solving this problem. So now I have instead of one tool that I try to force onto this problem, I’ve got a selection of 10 tools that I can explore that space. I may not be an expert in all 10, but at least I know I can try 10 of those and find the one that seems promising and then really dig into that and become a deeper expert to solve that particular problem. That’s where, again as you step further into this career, your breadth of knowledge becomes greater and a lot of that skill set and value comes from, “I’m not a one-trick pony.” For lack of a better term, “I can pull from this tool set and find a better answer, the best answer.”

0:16:47.6 ME: Well, that is consistent with what you said earlier, which is, you’d like to be an expert in at least one, but functional and useful in both or all. To some extent, I can be an expert and a generalist, and that will take me further down the road than, “I have a hammer.”

0:17:05.0 JH: A lot of that, I think is just tied to the availability of information in this space. So I have the tools at my disposal to go and learn, and again, going back to some of the prior comments, having the passion to learn, being driven by some learning, identifying when you have that knowledge gap and then going, seeking out and learning that new tool set that previously you may have just been, kind of aware of, but now I know I might need it to answer the questions, so let’s go dig into that. Capitalizing on that motivation and building that knowledge from there, I think is essential as well.

0:17:44.7 ME: If I’m an individual, regardless of where I am on my career path, I’m new in my career, or I’ve been around for a while, or I’m in the later third of my journey, whatever it is, is really irrelevant. And if I’m an individual and I’m in a company and they’re not asking me, they’re not talking about any type of analytics, they’re not talking about BI, they’re not talking about any of this stuff. And I’m interested in doing this stuff, it’s probably on me to figure out, “Okay, where is my company? Where are they wanting to go? What problems do they want to solve? And how can I apply these things I’m exploring to proactively propose and find and encourage opportunities? And that might actually be a wonderful journey, it could be a wonderfully educational journey, or it could be a tough journey in the event that you stand alone with that appetite to learn like that.

0:18:37.0 JH: That’s the reality. Whether you’re in a role that isn’t defined traditionally as a data scientist or data analyst, and you’re trying to spark your journey into that, and the organization hasn’t adopted yet, or you’re in a role that, you’re a data scientist in a larger data science team and the organization is fully invested in it. I think for many organizations, there’s still an education gap of what really is advanced analytics and data science and what are the questions that we need to leverage them to solve for us? How do we ask that question? When do we bring them in?

0:19:15.5 JH: I think that’s a universal continuous thing, and it requires to solve that, it requires again, the term vulnerability, is the vulnerability and the willingness to push the idea forward as you continue to gain your knowledge, continue to gain insight and learnings, bring those up to those in the organization who are the decision-makers, the project owners, whatever it might be as, “Here’s a new way of thinking about this.” Likely, they may have heard of it, probably haven’t heard of what ML or AI actually means, wouldn’t say imposing, but putting that perspective out there, making them aware of it becomes as much of your role as anything, if you want to bring that… Develop that skill set, and bring that impact to your organization, you really need to drive that thinking and drive the mindset shift that it requires to incorporate advanced analytics data science into an organization.

0:20:11.3 ME: So if I’m a C-Suite leader, and I have all kinds of amazing responsibilities that go with my role in the organization, just like your role in the organization, and I’m feeling the pressure to make my numbers, and manage my market, and address the current economic situation, all of the things. And you’re the aspiring data person, and you come to me and say, “Hey, Matthew, I’ve been looking at this stuff. I’ve been studying some things. I have a couple of thoughts.” How would you approach me? What would you say to me? Not that I’m belligerent and stubborn and cranky, but rather I’m just on the move, and I’m looking for concrete chunks, if you will.

0:20:48.2 JH: It’s a great, great thought exercise and an important one. What’s been powerful for me, it’s showcasing… As you call it, showcasing out of the possible, but doing it in comparison to current state. So being able to… Whatever your question is, just for the example here, showing, here’s the report, the current process, the current output, what it looks like now, and I’m delivering that to you, so I’m maintaining my relationship with you. I’m not falling short or anything like that, but I’m taking some of these new learnings, and it takes a time commitment, but passion should drive that, to now, let’s layer in a slice or two of something new on the side of that. Maybe I’m forecasting for next quarter for you. And traditionally, it’s just been… What happened last year, we’re gonna add some percentage to that year over year, and something very simple.

0:21:43.8 JH: And now I’m gonna go in and at its current state when I’m enhancing it, by putting some confidence intervals on it, and giving better scenario analysis around if you do X, we see Y. And start to tell that story of what’s the next level. And it may not be perfect, but you’re at least creating awareness of the capability that you’re developing, and bringing to the organization. And hopefully, through that beginning to create excitement around “Hey, I’m the leader, the executive. I could see the improvement here, let’s dig into that further.” And you start to get the wheel spinning and that progress rolling from that.

0:22:20.6 ME: That’s very tangible. Here’s what we’re currently doing, here’s what we’re using it for, and what it seems to mean to us. Here’s what we could be doing, and here’s how it may actually add additional dimension or insight or view or value. That’s really good, that’s very concrete.

0:22:37.3 JH: It’s powerful, and I’ll say, what can be scary in that, fearful in that is, you have to put yourself out there again. I go back to this just because I’m not the stereotype, IT mindsets or data science mind… Personality, and things like that. But again, it’s not waiting for the business direction sometimes, but just taking a chance and stating, “I think if we did this, this could be the improvement.” And at least starting that conversation. It’s that awareness, that seed of awareness that becomes powerful and that it might not be right, but at least you’re creating visibility to a capability that either exist in your skillset or it can exist, and now starting that conversation.

0:23:24.6 ME: Well, let’s shift it a little bit then. So these companies that are starting to realize, “Hey, we need to be a little more aggressive, a little more assertive about what data, how data, when data. How can we get to where we really want to go, and how do we make this data thing work for us?” But if I’m a company, and I’m looking for people, where am I going to find people? If I don’t have people saying, “I’ve been thinking about this, I want to do this, and I’m starting brand new.” Where am I going to find these folks? Are there data conventions? And you guys are all hanging out like, “Pass the tea. Let’s talk about this.”

[chuckle]

0:24:03.5 JH: Candidly, I don’t know if I have a proper answer for that or a great answer for that, other than I think in the space… Data science as much as… We’ve talked about the hard skills of data science, the art of data science, I think the other piece in there to be aware of it’s the subject matter expertise for that organization that becomes essential. You could think of a diagram of this with those three elements in it. That subject matter knowledge becomes essential to really developing impact out of advanced analytics and data science for the organization. I think often for an organization to define success in this, it’s finding individuals that are again, driven by learning, have curiosity, and motivated to learn, preferably in this space, but having in place mechanisms that allow them to ramp up the business knowledge that they bring, that organizational knowledge. What product are you manufacturing in the nuances of manufacturing that product? How does thes sales team sell that product? That business knowledge and the nuances of that are key to success in data science.

0:25:24.0 JH: Using myself as an example, when I turned into an organization, I tried to focus the first few months on just strictly relationship building. Finding that conduit into who are the people that represent the space in the organization, that can become my source of… My vessel of knowledge that I can tap into. Because when I’m working with data and trying to build a model, there’s endless questions around “Do I pull in column A or column B? Do I combine them? Do I create something entirely new? Does this mean anything?” Because what I think is meaningful in the data may be statistically significant, all this kind of stuff, when it actually goes out to the field, and you get feedback and that expert knowledge on, “Well, we actually don’t operate like that, so your insight is meaningless.” If I can get that knowledge, or at least a representation of that, that’s where a lot of power exists, that my underlying skill sets, technical knowledge, storytelling abilities, all that stuff can come together, and leverage that subject matter knowledge. So I don’t know if I answered your question well Matthew, or not, but I think organizations developing pipelines or… Pipelines isn’t the best word… Environments that are conducive to that transfer of knowledge between the subject matter expert, and the…

0:26:38.3 JH: Data scientist, the advanced analytics, and those using the data. That knowledge sharing, I think is where a lot of that power resides.

0:26:47.2 ME: So that’s a way they can discover the value and use and help grow and foster a culture that grows people, but you didn’t yet tell me if there are conventions where there are data scientists like you all sitting in smoking jackets, having tea, discussing the latest algorithms of the breakfast.

0:27:07.4 JH: So those do exist depending on your space and need and so on, right?

0:27:13.6 ME: Right.

0:27:14.9 JH: The term data science is just over a decade old in formality. If I’m remembering correctly, I think it’s credited with originating at LinkedIn as kind of where it started with formerly, and don’t quote me on that. A lot of the build-up and hype to this sort of where we are now with data science… Let me rephrase, not build-up in hype, but growth in this discipline and the rate of growth in this discipline overtime started with the technology companies latching onto researchers that were presenting on neural nets, artificial intelligence, machine learning at their dedicated conferences. So one of the conferences that has been around for decades, is called NIPS N-I-P-S, it’s now NeurIPS is the new term given to it, but it’s all… What was up until a decade ago, a conference attended by maybe a couple of hundred researchers off in kind of the corner, to now it’s annually attended by thousands of people that come to this. That’s where a lot of the original poaching occurred, these researchers brought from academia into practical application data science going forward now. That’s a extreme example.

0:28:37.8 JH: I think there’s many different organizations out there. I think of TWI is one, IIA, Institute of International Analytics, and so on. There’s all these different organizations that, again, to your point, Matthew, it’s maybe not sitting around in smoking jackets and so on, but gatherings of analytics and analytic mindsets that bring a lot of talent together and a lot of skill sets together that can be sources of experienced skill sets, experienced individuals in these resources. And then to give credit to the universities. Again, over the last decade or so, more universities are offering more programs related to business analytics, data analytics and so on. That pipeline is filling up, becoming more robust, becoming more refined as well, and there’s a quality, new grads beginning to come out of universities as more learnings are applied there.

0:29:35.8 ME: It’s a normal, normal problem. So educational institutions are themselves businesses or else they cease to exist. It’s not a free world here, so these folks have the responsibility and the desire and the goal to enable and equip and educate and all of the types of things. A reality though is the gap between learning these concepts to… Even illustrated by your earlier point, go learn about statistical things, whether it’s statistics in and of themselves, probability base, and all of those things. Then learning the tools that are the Python and anything else that makes sense, and then figuring out how to operationalize that and then starting to get into splinters. That’s a journey that has to be lived. Journeys aren’t ordinarily lived in college or university. Journeys can be enabled. The fact that universities are offering more and more data education is outstanding.

0:30:28.9 ME: But it’s fun to see how this is evolving. It’s fun to see where it’s going. To your point, 10 years, thereabouts, plus or minus, plenty of places to go on the web, many conventions to go to, seeing how it’s evolved from a small subset of researchers to a more populated thousands and thousands of people who are interested now. What a wonderful evolution of an idea that we’re getting to watch, unfold right now. And then as far as what does it mean? Heck, that’s part of the whole challenge. What is it? When is it? What does it mean? How we make use of it? This has been a phenomenal conversation with you, good sir. Thank you very much for taking the time to teach us about so very many, just aspects of the journey of data and your journey with data, and even very much thank you for taking the moment to just give some pointers to people who want to learn how to have a journey like the one you’re having. Thank you.

0:31:28.4 JH: Thank you, Matthew, and I couldn’t agree more with those thoughts that are… Right. It’s a great journey that this whole space and discipline is on, and there’s a lot of runway left in it. And because of the uncertainty, there’s a lot of room for creativity and impact to be had as more people venture out and become skilled in this space, as well. So it’s been a… I’ve enjoyed the conversation and learned more about myself and hopefully be able to share some good thoughts as well along the way, so thank you.

Categories
Podcast

Podcast, Part II: The Artistry Required for Data Science Wins

Show Highlights

In the second episode of this three-part series, Jacey Heuer helps us dive into the evolving roles and responsibilities of data science. We explore how individuals and organizations can nurture how data is purposefully used and valued within the company.

Missed the first part? Listen to Part I.

Individual Takeaways

  • Adopt a scientific mindset: The more you learn, the more you learn how much more there is to know.
  • Hone storytelling capabilities to engage and build relationships that ensure the lifespan and value of data is woven into the culture.
  • Set one-, five-, and 10-years goals and aim to achieve them in six months to fail fast and advance the work faster than expected.
  • Create buy-in using the minimum viable product (MVP) or proof of concept approaches.
  • Prepare to expand your capabilities based on the maturity and size of the team focused on data science work. As projects develop, you’ll move from experimenting and developing prototypes to developing refined production code.

Organizational Takeaways

  • When your company begins to use data analytics, roles and responsibilities must expand and evolve. Ensure your people have opportunities to grow their capabilities.
  • Data must be treated as an “asset” and viewed as a tool for innovation. It can’t be tacked on at the end. Ideally, it plays a role in both new and legacy systems when aggregating data and capturing digital exhaust.
  • Engage and find common ground with all areas of business by helping them comprehend how data science “expands the size of the pie” rather than take a bigger slice.

Read the Transcript

0:00:05.5 Matthew Edwards: Welcome to the Long Way Around the Barn, where we discuss many of today’s technology adoption and transformation challenges, and explore varied ways to get to your desired outcomes. There’s usually more than one way to achieve your goals. Sometimes the path is simple, sometimes the path is long, expensive, complicated, and/or painful. In this podcast, we explore options and recommended courses of action to get you to where you’re going, now.

0:00:37.3 The Long Way Around the Barn is brought to you by Trility Consulting. For those wanting to defend or extend their market share, Trility simplifies, automates, and secures your world, your way. Learn how you can experience reliable delivery results at trility.io.

0:00:57.0 ME: In this episode of the Long Way Around the Barn, I picked up where Jacey Heuer and I left off in our first conversation on data science, which has now become a three-part series. Today’s conversation focuses on how both individuals and organizations can leverage data analytics and machine learning, to evolve and mature in their purposeful use of data science.

0:01:22.0 Jacey Heuer: It takes a diligent effort from the data team, the advanced analytics team, to engage with the architects, the developers, those groups, to get your foot in the door, your seat at the table. I think getting to that state means that data is seen as a valuable asset to the organization, and is understood as a tool to drive this evolution into a next stage of growth for many organizations, to achieve those dreams of AI, machine learning and so on, that lie out there.

0:01:57.7 ME: We start by diving into how the various roles fit into today’s data science ecosystem.

0:02:04.8 JH: To the primary roles that I define in a mature team, as it relates to the actual analytics, the data analyst, the data scientist, machine learning engineer, and their MLOps, and what’s becoming a newer term though, taking this further, it’s the notion of a decision scientist.

0:02:24.1 JH: There’s a lot of roots in, you could say, traditional software development in terms of defining, and what is becoming defined for data science, and I’ll say the space of advanced analytics. Generally speaking, not every organization, every team will be structured this way, but I think it’s a good aspirational structure to build into, and it’s the idea of that you have your data scientists and they shouldn’t… The real focus is on prototyping, developing the predictive, prescriptive algorithm, and taking that first shot at that. Then you have this data analyst role, which is really more of the traditional analytics role, where it’s closely tied into the organization, they’re doing a lot of the ad hoc work on, “I want to know why so and so happened. What’s the driver of X?” things like that.

0:03:20.2 JH: So there’s a little bit of predictiveness to it, but it’s a lot of that sort of, “Tell me what happened and help me understand what happened in that role.” And then you could start extending this out, and you start thinking about the machine learning engineer. That’s really taken the step now to go from the data scientist who’s made that prototype, to handing it off to the machine learning engineer, and their role is to now bring that to production, put it into the pipeline. Oftentimes, that may be also handling the productionalizing of the data engineering pipeline or the data pipeline is all right.

0:03:52.7 JH: So being able to go, in a production sense, from the data source, maybe it’s through your data lake, through transformations, and into this model that often it’s written in Python. R and Python are those two languages that dominate the space. Python is often the better language because it’s a general programming language, it integrates well with the more applications, things like that, but R still has its space or its place. I’m partial to R. Nothing wrong with either one.

0:04:23.1 JH: But that machine learning engineer, they’re really tasked with bringing this into production. And then the sort of next step in this is the MLOps. And machine learning engineer falls into that, MLOps, kind of a bigger category, but it’s that role of once that algorithm is in production, it’s up on the mobile phone, it’s up on the progressive web app, it’s being used, now it’s an ongoing process of monitoring that and being able to understand, “Is there drift occurring? Is your accuracy changing? Is performance in that model changing?” This gets into, if you’ve heard of the ROC curve, AUC, and things like that, that monitor performance of that model. And that in itself, can be… Depending on the number of models that have been deployed, can be a task. If you have a few hundred models out there and a changing data environment, there’ll be a need to update, to change, it may be that individual’s task to go in and re-train the model or work with the data scientist again to reprototype a new model.

0:05:31.4 JH: So that’s the general, I’d say the primary roles that I define in a mature team, as it relates to the actual analytics; the data analyst, the data scientist, machine learning engineer and their MLOps. And what’s becoming a newer term though, taking this further, it’s the notion of a decision scientist. This is really the person that is crossing the gap or bridging the gap from, “We’ve implemented or discovered an algorithm, discovered a model that can predict so and so with a high accuracy,” whatever it is. Now their role is to be able to take that and drive the implementation, the buy-in from the business partners to help them make better decisions. So they’re much more of a… Have a foot in both camps of, “I understand the models, I understand the technical side, but I can sell the impact of this and influence the decision that the business partner is making.”

0:06:31.2 ME: What is the name of this role, again?

0:06:34.5 JH: The term that I see for this and I like to give it, it’s decision scientist, is what it is. So it’s much more on the side of really focused on changing, improving the decision and having a tighter role on that side of it, as opposed to what can be more technical, which is the data scientist or machine learning engineer. They’re much more focused on the data, on the programming and so on.

0:07:00.1 JH: And reality of this is, many organizations won’t be at a maturity level to have those distinct functions and roles. And there’s going to be a blend, and it’ll be maybe one or two people that have to span the breadth of that and be able to balance traditional analytics with discovering new algorithms, to productionalizing it, the doing some data engineering, to MLOps, to speaking with the business partners and selling the decision, the new decision, the decision process to them, and so on. And that’s good and bad, obviously. You can overwhelm a small team with that, but you can also find great success in that. There’s a mindset involved in this. I don’t know who to quote this to, but it’s a good mindset that I like. It’s essentially, establish what your one, five, 10-year goals are and try to do it in six months. So you’re probably going to fail, but you’re going to be a lot further along than that person who is trying to walk to those longer-term goals.

0:08:02.0 ME: You’re saying that the larger the organization, the more likely these ideas or behavior classes will be shared across different roles but that then suggests, then small organizations or smaller organizations, one or more people may be wearing more than one hat.

0:08:19.6 JH: I think the better term is more mature data organizations. You could be a small or large organization, but what’s the maturity level of your usage of data, the support of the data needs, data strategy, data management, things like that. Often, it is… Kind of follows a sequence, where it may start with this data analyst role making the initial engagement. A business partner comes to the data team and says, “Hey, we have a desire to understand X better.” The data analyst can go and work on that, develop some initial insights. And out of those insights, that’s where the data scientist can step in and now take those insights and let’s build an algorithm for that. We understand that we reduce price, we drive up quantity, typical price elasticity.

0:09:03.8 JH: We see that in our data, our industry, our market reflects that. Well, let’s go and build an algorithm that can optimize pricing across our 80,000 SKUs. So we build this algorithm and we bring in environmental variables, variables for weather, regional variables, all this kind of stuff and really make this robust. Well, now we need to put it into production. So I hand it off to ML Engineering, they go and build this pipeline, write it in Python, maybe the data scientist worked in R, we do a conversion in the Python, they tie it into a mobile application, so sales reps can have pricing information at their fingertips while they’re having conversations.

0:09:45.6 JH: So now you have the sequence playing out, where again, often in a less mature data group in an organization, that’s going to be one or two people wearing those multiple hats. And if that’s the state, you’re a less mature organization, I think the best approach to it, and it kind of follows the notion of Agile methodology and things like that, but it’s really this MVP notion. The best way to eat an elephant is one bite at a time, is a real concept when you’re trying to grow your maturity of your data team. And let them focus on really developing the different pieces of it and getting it in place before expanding them to have to take on something more. Identify that project that you can get buy-in on, that… Expect to have some value for the organization and go and build that out, to really develop that POC and that first win.

0:10:36.6 ME: That’s interesting. That’s a fun evolution. One of the things we’ve watched change through the years is the idea of information security, regulatory compliance stuff. In days gone by in the software world, there were requirements which turned into designs, which turned into software, which turned into testing, which turned into production stuff, and that’s largely sequential. The serial dependency is going into production so waterfall-y And then as we’ve evolved and rethought the role of testing as everybody’s role and information security is everybody’s role and all of these things, and we introduced continuous integration, continuous delivery, it’s really thrown a lot of things on their head.

0:11:15.9 ME: Nowadays, we’re able to actually attach tools, and granted, sometimes they’re just literally hanging ornaments off trees, but we’re able to attach tools like vulnerability assessment tools, we can write penetration test suites or smoke suites, we can attach them to a pipeline that says, “For every new payload that comes down the line, apply these attributes, characteristics and ideas to it, and make sure that it’s heading in the direction that we all choose.” You can fail the build right there or you can flag it and send a love note to somebody and then you remediate it in a meeting later with coffee.

0:11:54.1 ME: And now, we’re all able to be together in one cross-pollinated team, bring in Infosec on purpose, so design with Infosec in mind, on purpose, from the beginning. And so, acceptance criteria and user stories and epics and all of these things have attributes that says, “For this, these things must exist and these other things can’t exist.” And now information security can be tested during the design, as well as the development continuously, instead of surprising people later like an afterthought, like salting after you’ve grilled the meat, as opposed to before, that type of thing. And even that’s its own religious conversation.

0:12:35.2 ME: With the data stuff, I’m curious. Do you feel like data is being included in… You mentioned Agile, so I’ll talk about scrum teams, delivery teams, strike teams, that type of thing. These cross-pollinated teams composed of developers, designers, human factors, folks, data folks, all of the different types of folks, one team, one priority, one deliverable, one win, one party, that type of thing. Do you feel like the idea of data is being proactively included in the design and development of ideas, or it’s an afterthought, or you’re getting Frankenstein on a regular basis and somehow you have to make magic out of a pile of garbage? How are you seeing things evolve and where do you hope it’s going?

0:13:18.1 JH: The Frankenstein is a good illustration of that. I think, often, data as it is for analytics needs is an afterthought when it comes to application design and development and everything that goes along with that. And a lot of that, I think it’s primarily due to the relative youth of advanced analytics, data science, machine learning, and so on. In reality, the moniker data scientist is maybe a decade old or so, there’s been statisticians and so on before that, and data science is really kind of just the next step down what was that path.

0:14:00.9 JH: So for example, for me, having practiced data science in a number of mature organizations, mature being they’re 90-plus years old or been around for a while and built systems to meet certain requirements, transactional requirements, things like that, and they perform their purpose well, but that purpose wasn’t necessarily with a mindset for, “How can we maybe improve this or leverage the knowledge that can come out of those systems to be applied elsewhere in the business, the data that can come out of that?”

0:14:33.5 JH: And the term I’d give that, it’s these applications are creating data exhaust, to give it a term, where it’s a byproduct, maybe it’s getting stored in a SQL server some place or some database, and maybe there’s some loose reporting being built on it, but it’s probably not easy to go and query, maybe it’s a production database by itself, so if you try to query a lot of it, you’re running into concerns of impacts on performance for the production database and production systems, and so on. And so one of the practices that I’ve been really focused on with this experience is injecting the presence of data science advanced analytics into that application design process, into the design of those new systems, to give a lens into, “What does the algorithm need to be performant? What kind of data do we need? And let’s ensure there’s a thought process behind how that data is being generated, the flexibility to test potentially within that system, how data is being generated and where it’s going, how it’s flowing out, how could it be accessed, how can it be queried?

0:15:53.2 JH: There’s a good example, this is going to be a bit of a technical example, so forgive me for this, but one of the systems in a prior organization I worked with, would move everything in very embedded, complex XMLs was how the ETL process happened. And so from a data science perspective, that’s not an easy thing to shred apart and dig into, to get to all these layers and hierarchies within a super complex XML, but the system performs to its purpose within the organization, and it does what it’s supposed to do. So from that side of it, it’s a great system that works.

0:16:36.0 JH: It’s an old system, but it works. But from the data side, it’s a mess. It causes us to have to Frankenstein things together to try to work with it, was what the outcome was. The idea is evolving, but I think it takes a diligent effort from the data team, the advanced analytics team, to engage with the architects, the developers, those groups to get your foot in the door, your seat at the table, to ensure now, as we go forward and new applications are being built and designed, there’s a mindset for, “What does data science need to be able to leverage this and take us from data exhaust into data gold or data as an asset?”

0:17:19.6 ME: This is a wonderful, wonderful, awesome mess that you’re talking about. We’ve watched the same thing through the years with testing, where it was always test in the arrears, but then people wanted to understand, “Why is the cost of acquisition and cost of ownership so darn high? Why does it hurt so badly to debug software when it’s in production?” Well, test in arrears is the answer, guys. So test-driven, moving testing or quality behaviors as far upstream as possible means consider quality while building, not later. And we’ve watched the same evolution in security, whereby we design with security in mind, as opposed to try and bolt that stuff on later.

0:18:04.6 ME: And that digital exhaust conversation that you’re talking about is a standard problem, even for old school production support people, whereby somebody built some software, they dropped a tarball, threw it over the wall, somebody pumped it on to some old rack and stack hardware in a brick and mortar, and now the developers went home and the infrastructure people have to figure out, “How are we going to make this sucker run?” And then after that, “Why is it broken? Oh gosh, we don’t have log files.” So we have all kinds of challenges through history of no logging, some logging, way too much logging, you’re killing me.

0:18:42.0 ME: And the Infosec people in particular have been on the wrong end of the stick for that and testers were too, where they had to go figure out why, not what, why. Well, hello logging. And Infosec people, they have inconsistent logging, so they trap everything, like they’re the Costco of data, just trying to find any action, so that they can then attach tools and do sifting on it. So we’ve watched software, in particular, change from, “I do my job, now you do your job,” to, “We are doing this job together,” and it sounds like you are smack in the middle of that outstanding, awesome, messy, sometimes painful evolution, which is, “This is a thing, but not enough people understand the value of the thing, so they’ve got us sitting in this room without windows.”

0:19:33.7 JH: Yes, you hit the nail on the head, Matthew. And that ties back into the conversation of roles and so on. If you go back to the development of a software engineering team or Infosec team, cyber security, things like that, we’re getting established, finding how we fit into the organization, depending on… There’s a lot of opinions on this too, right now, in terms of where should advanced analytics data sit within your organization? Do you report up through IT? Do you report up through marketing? Where do you touch? That’s another sort of big question that’s out there.

0:20:12.2 JH: My preference and what I’m coming to understand really works best is to really establish its own pillar in the organization. So the same way that you have marketing, same way you have IT, finance, you have data, having a chief data officer that has a C… And reports up to the CEO and everything underneath of that, that is really when I think getting to that state means that data is seen as a valuable asset to the organization and is understood as a tool to drive this evolution into a next stage of growth for many organizations trying to achieve those dreams of AI, machine learning and so on, that lie out there.

0:20:53.9 ME: A lot of these paradigms might be continually challenged, if not destroyed and re-factored. So the idea of these verticals have, how do I separate data from marketing, from IT, from ops. A lot of those things are HR, Human Resources derived frameworks, but they aren’t delivery frameworks. And so we’ve continued to have this interesting challenge in companies, of, “I have all of these vertically organized people, but they have to deliver horizontally.” So how that gets addressed on the CDO side or embedded or whatever, companies are going to figure that out on their own, they usually do. Although across whole careers, not necessarily on Saturday. An interesting thing you’ve said to me though, although you didn’t really say it like this, it makes me think that the idea of data by design is actually a thing, and that when we’re building systems, when we’re building out epics and user stories and acceptance criteria, the people that are there, the developers, the designers, the data folks, sometimes that gets messy where people think it’s an old kind of a database perspective as opposed to, “What do I actually want to know? What am I actually going to do?” And let that influence the design and the implementation thereafter. Without asking those questions, this is a Frankenstein conversation all day, every day. Data by design needs to become a thing and data needs to be included in strike teams or delivery teams on purpose on a regular basis.

0:22:30.6 JH: The importance of the presence of that knowledge on what’s needed to bring that data to value, to become an asset. So you mentioned asking the question of what do we need and what do we want to know, that really has to come from the data scientist, the advanced analytics team, having a voice in that conversation, to be able to say, “If we’re building an application that is going to provide recommendations for a product to an end user, well, in that application, I need to know potentially what algorithm is going to be applied, how it’s going to be applied, and what does that algorithm need to perform from a data perspective. How easy… Is it going to be a online versus offline learning environment, which essentially the differences between streaming versus batch in terms of how we model and build predictions. What does that mean? What is that going to take? Do I need certain REST APIs built in to access data in some way, or is it going to be a batch dump overnight, into the data lake for us to build something on?”

0:23:34.7 JH: All those questions really need to be designed and have a perspective from a data scientist or an engineer that has knowledge of the data science requirements, the process, and preferably it would be the joining of those two together to allow them to work and bridge that gap. But it’s in… The success that I’ve had in driving those conversations, it’s been, “How do you get creative in trying to convince people that doing so expands the size of the pie and doesn’t just take a bigger slice of the pie for me or for you?” So finding that benefit, that software developer, that systems architect, whoever you’re working with, engaging them in a conversation in a way that lets them see the benefit to them, from a data science perspective, so that you get that buy-in because I know now, with their support, my life’s going to be easier because I’m going to get the data, the access that I need to build a stronger model, a more robust model.

0:24:36.0 ME: One of the other interesting things that you said I’d like to amplify is, you talked about how in some environments where the idea of analytics wasn’t taken into consideration in advance, you end up having to go find out if data exists at all and if it does exist, in what state is it captured, if at all and is it fragmented, dirty, is it sporadic, what do you have available to you, and what state is it in? You have to do that before you can even decide, “Okay, here’s the problem we want to solve, here are the things we need to know, here are the desired outcomes, or the things we want to decide along the journey. So I need this data. What’s in the system already?”

0:25:19.4 ME: So that impacts people’s perceptions of the adoption velocity of data people too, I would think. In other words, somebody says, “Dude, all I want to know is… What I want to know what’s taken you so darn long.” And your answer is, “But you never looked at this before, so we don’t collect all of the data. Some of the data we do collect is in 700 repos spread out across… Who knows? Time and space, and most of it’s dirty. So before I can even get to my job, I have to find the data, clean the data, get the data, and then get people to re-factor stuff.” That makes it look like you guys are slow. So how do you handle that? What kind of experience are you having there?

0:26:04.9 JH: Yeah, so that is… Directly ties into the power of storytelling. The power of storytelling of the journey, not waiting until we have, “Here’s a shiny object, we built it and let’s show that,” but showing the journey that we’re on to get to that object, that output and so on. because you’re right, the reality is that often, the mindset from those requesting the insight is, “There’s got to be an easy button. You’re a data scientist, we have data, just click your button, hit your mouse and tell me my answer.” In many ways, those questions that are being asked of us are all in themselves mini-innovations, because they’re not standard run-of-the-mill questions. It’s…

0:26:53.8 JH: You captured it well, Matthew, in terms of, “We’ve got to go and find this data, clean the data, experiment, iterate on those experiments, potentially bring it to production, whatever, build an interface for it to be consumed” and so on. And so it’s important to be vulnerable and honest with that journey and educate those stakeholders on, “This is the reality of the current state, what we’re working with. We’ve dug into… You came to us with your question, we’ve gone out and did our initial assessment exploration, this is the current landscape that we have and because of that, this is going to be the roadmap, the timeline to achieve what we need, and we’ll engage with you as we go forward.”

0:27:39.0 JH: “We have a weekly, biweekly, whatever that time frame is, dialogue with you to update on progression, pivot and iterate and so on.” But it’s that storytelling that is essential. Going on a bit of a tangent here, that’s… I think, in terms of resources to go and educate and become a data scientist that are out there, those programs do great at learning the technical side of data science, but it’s that relationship, the storytelling side, again, that is as critical as any ability to write an algorithm, to program in Python and so on. How do you inform of what it takes, give transparency to that process, to build that relationship with your business partners, is essential.

0:28:30.5 ME: That makes sense. So the storytelling and the relationships. And it sounds like really, leadership needs to have an understanding of the value and need for analytics to start with, but then they need to have an additional understanding of, it needs to be data by design. And so, you could be walking into a legacy house and you need to figure out how to retrofit. Well, that’s going to have a slower adoption velocity than if I was starting with a brand new system, zero code on a blank screen and I can do data by design. And so the relationship, the communication, the story, that’s probably a pinnacle part of your entire existence, which is communicate.

0:29:11.2 JH: It is, and a good framework for it, that I think can help that story, it’s one, it’s positioning as… Often, it’s a capability, you’re developing a new capability for the organization, which is advanced analytics, assuming you’re not mature, it’s a different state. But that capability building, there’s really four pillars to that. It’s people, process, technology, and governance is kind of what I put into that. And so how do you, within those four pillars again, of people, process, technology and governance, what do you need to accomplish within those pillars? What gaps do you have? And tell the story around that. How do I go and resource this properly? Is it a data issue? Is it a application design issue? Is it a… We don’t have the right question coming from the business? We can’t answer that. This is a better question. Within that building of the capability, put the story together and I think that becomes useful to that dialogue, that relationship building with the business partners.

0:30:14.3 ME: As the idea of data, data science, data analytics is evolving, as its own body of knowledge, its own set of practices, you’re actually doing software development in Python and R. That being said, even though your output includes mathing, lots of it, the reality is, you’re delivering software in some way, shape or form that needs to be integrated into a larger ecosystem of some sort. So different question for you. Based on your experiences and the things that you’ve seen and just the general industry, given that it’s actually a software engineering craft, in addition to all of the wonderful analytical math and algorithm, all the things that you’re doing, do you feel like the data science industry itself recognizes that they are software developers, and therefore they also need to be pursuing software craftsmanship?

0:31:11.7 JH: Yes, mostly. That’s…

0:31:15.4 ME: I realize that was meaty. But anytime somebody says, “I build software,” we need to build reliable software, and that requires lots of good engineering practices.

0:31:26.4 JH: It does, right? So it’s a great question, and the reason I say yes, mostly, is because this relates back to the notion of the different roles and disciplines, data scientists, machine learning, engineering and so on, but I follow this as well. I’ll say, I came into this discipline from the statistics side, and not from the software engineering development side. And being vulnerable here, being candid, it shows in the way I write code. So it’s very much I write code for experiment and iteration and prototyping in that data science mindset. And you’re right, what’s needed though when you take that into production, you need quality code meets the Python style guide, stuff like that, commented well, if you believe in commenting, all that kind of stuff.

0:32:16.8 JH: That’s where that software development really comes into play. And I think the reality is, there’s probably a bit of a mismatch in skills there, if you can… But I think it’s evolving and becoming more refined as we go forward. There is a skill set difference between those two, even from the standpoint of… As we develop and leverage things like GitHub and code repositories and stuff like that, and everything that goes along with software, software engineering, software development, that’s a growing… Has a growing presence on the data science side as well, the collaboration of algorithm, coding and building a notebook, all that kind of stuff. So it’s a great question, but I would say it’s still predominantly kind of an experiment, prototyping side, and then… How do you refine that into well-written production code, on the other side of that.

0:33:16.6 ME: It’s an evolution for everybody. Even historical hardware-based, the rack and stack, brick and mortar, data center type folks, the infrastructure type folks, the people that were historically doing those types… Those focused operational behaviors, that world has changed out from under them as well, where we’ve moved into cloud engineering, and if I can have a 100% software to find everything, then that means all of a sudden, software developers can actually define all of their own infrastructure and networking and failover and all of the rubbish. But at the same time, now, the infrastructure folks actually need to become software developers. So we’re watching lots of amazing and awesome things change, and the data world is just another lovely facet of how we’re evolving, building things that are useful to us. Really, ultimately, you just have to figure out like we all are, is, “What problem are we trying to solve? What are the desired outcomes and what are the things that are necessary to get from there to there?” and then design it and do it in such a way, and especially attitudinally, be willing to change.

0:34:30.2 ME: “I am going to break something. I’m not as smart as I think that I am, and I have to be reminded daily,” and I do get reminded. It’s just an evolutionary thing. I think this journey that you’re on is phenomenal, and it’s not because you have all the answers, it’s because you don’t. That’s what makes it phenomenal. And I think people miss that, when they consider iterative development or iterative change, is, “It’s okay, tomorrow, I’m going to be plus one.” Is that where you think your industry is, is absolutely, plus one? Are you thinking you’re 10X daily like, “Dude, we have a long way to go”?

0:35:12.2 JH: No, I like the way you kind of illustrate that, Matthew. And what’s in that, I think, is most valuable there, it’s the realization that we don’t know everything, and the participants in the room don’t know everything. I think when you’re pursuing, whether it’s a data science objective, whatever it is, having that understanding that we’re all learning, is as valuable as anything, and allows for… I’ve used this term a few times, vulnerability to be present and to be comfortable with that, where I don’t know everything there is to be known about topic X, you may know more than me, but let’s be open about that and build our knowledge collectively, again, expand the size of our pie, as opposed to one of us taking a bigger slice, is I think, an important mindset to have, not only in building and maturing data science, advanced analytics, but in whatever you’re taking on is essential, the scientific mindset. Really, the understanding that once you realize that, you know enough to know that I don’t know, that is a good state to be in.

0:36:28.1 ME: There’s the interesting pure science of this whole conversation, the creation of and evolution of an idea, and then there’s the operational science of this idea, which is, “This business has allocated a million dollars to this project, and it has some amazing set of features that need to exist, that serve these users and these industries, and there’s a definition of done, desired outcomes and all that,” there’s a box. And so somehow, you have this amazing challenge of telling a story that makes the idea of data, where it is in its life span, and the value of data, as it relates to this business and project come to life for somebody to say, “Yep, we should be doing this for sure.” But then you have to figure out how to get inside this existing, moving organism as well, which is, “We build stuff, we move it into production, we generate revenue, serve clients, make them all smile.” You’re building a plane and flying it at the same time, and even though this isn’t a Zoom video for people that don’t know, we do Zoom so that we can interact with each other in video. Jacey, you’re still smiling this whole time like, “Yeah, this is a bunch of crazy, and I love every second of it.”

0:37:43.6 JH: Yes, it’s enjoying the journey, enjoying the grind, whatever term you want to give to it, is essential for, again, not just the path I’m on or you’re on, Matthew, whatever it is, falling in love with that journey and the chaos of that, and the opportunity to learn within that space. My personality, I’m driven by learning. If I see this as an opportunity to learn, that’s what motivates me to go and pursue it and take that on, and data science, advanced analytics, this whole discipline space is rich with that. It’s learning every day. For me, it’s learning a new algorithm, a new mathematical concept, a new development idea. How to integrate, move into a cloud environment. That’s a whole other beast in itself, as all the services of cloud and transforming from on-prem to cloud and everything goes along with that. So the space for learning is vast, that’s exciting, and it should be.

0:38:50.8 ME: So as we start to wrap up, I wondered if we could get your viewpoint on the idea of data and all of the roles, just example, the roles that you’ve talked about, they may or may not exist in all of the different companies or all of the different HR frameworks or whatever it is we want to talk about, and the value of data and when data and how data and where to include them, and when should it… The front… Did you do it in arrears? Am I good with Frankenstein? Why is… What’s my adoption velocity? Why did it cost so much money just to get this data? What is going… That crazy, crazy mess. If someone is going to say, “Hey, I want to figure out what data analytics is, and I want to figure out how I can leverage these things to evolve my company,” how do people figure out where to start? Is there a clean answer or is it context-driven? Is it just always messy?

0:39:44.8 JH: My perspective on it, it starts with understanding, “What are the desires of the organization?” Obviously, “Are we developing a new product? What’s our strategy look like?” All that kind of stuff, in terms of that vision going forward. And from that, it’s understanding, “What’s the current data landscape look like?” And that’s a beast in itself, in defining that. But it’s really getting your mind around that as a starting point, can often inform, “What are we capable of? What can we do now? And who or what resources do we need to level up and move forward?”

0:40:25.0 JH: As poor as this can sound, I think oftentimes, companies like to just jump to, “Let’s get a data scientist, they’ll solve it.” Well, the data scientist comes in, if they don’t have the data to work on, they’re just kind of floating out there, trying to figure that out or missing that piece. And so, data as a foundation and working on that, I don’t think it’s ever solved, but focusing on that, building it so it becomes a true resource and not just exhaust, that is… That’s, I think, the initial, essential key focus to launch off of. And in that, it may be a combination of data science and data engineering coming together, whatever that is, but I think, in my perspective, that foundation of building a strong, robust data environment is essential to any success that can come out of that, come out of the venture and the path into advanced analytics, machine learning, AI, and so on.

0:41:25.2 ME: If you don’t know what you want to know, or you don’t know where you want to be after this effort has happened, adding a data scientist isn’t going to change anything other than your budget, your run rate, but it’s not going to change your outcomes. So, it’s kind of like, you shouldn’t ever go to the grocery store on an empty stomach and you should know why you’re going there before you walk in, or don’t send me. That’s the net. You really need to know where you want to be, or else don’t just hire somebody.

0:41:55.7 JH: From a data science perspective, hearing the terms, “Go and discover something for me in the data” is often a little cringe-worthy. because then it’s a… You need that objective, I need to know, “Am I trying to make lasagna? So this is the ingredients I have to go get from the grocery store to make lasagna.” Sending us on that, just a wild goose chase, to say, “Go and find X millions of dollars in the data.” It’s possible, but it may not be super probable. But having an objective, “We’re trying to solve this question, this business problem,” then now we have something concrete to anchor around, to go look for in the data and build this for a purpose and objective and so on.

0:42:38.9 ME: Well, I think we ought to go explore some more of these subjects together. So for today, what I want to say is thank you, and I look forward to talking with you again real soon.

0:42:49.8 JH: Thank you, Matthew, I appreciate it.

0:42:55.0 Speaker 2: The Long Way Around the Barn is brought to you by Trility Consulting, where Matthew 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:43:11.4 ME: To my listeners, thank you for staying with us. I hope you’re 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.