Categories
Podcast

The Long Way Around the Barn

There is usually more than one way to achieve your goals. Sometimes, the path to the goal is longer than it needs to be because we are all challenged with similar things: We often see what we know or see what we want to see. 

In this podcast, we look for options and recommended courses of action to get you to your desired outcomes now. 

Categories
Product Design & Development

Assessing Viability of a Technology Initiative

As a technology leader, you’re responsible for assessing projects, making decisions that add value, and creating opportunities for your team to succeed. You often spend time overseeing more than one project or initiative and are required to focus on two or more of the following types of activities:

  • Building and refining product roadmap(s) to confirm that future work is valuable to the organization and your team. 
  • Reporting project updates to managers or stakeholders.
  • Educating yourself and your teams on tools or products that have evolved to ensure projects remain viable.
  • Understanding what applications and tools are being used, how they talk to one another, and if they are integrated in a secure way. This focus might be highlighted if:
    • Your organization acquired a new company.
    • Your organization was acquired.
    • You inherited a new team or project.
    • You are new to the organization. 
    • You are shifting left in your security journey.

These responsibilities often have a two-fold focus – customer value and the company’s bottom line. On top of managing multiple things with this split focus, you’re working in a rapidly evolving industry. You are constantly assessing high stakes and high opportunities. Decisions don’t seem to slow down. They only keep piling up. 

Decision-making made practical  

Some people feel excited, anxious, or have different emotions altogether when making important decisions. Those feelings are valid – identifying what matters and what doesn’t can be hard if where to start seems unclear. 

You can leverage the Assessment Framework to understand where you’re at, where you’ve come from, and where you’re going. A robust project evaluation ensures all context has been discussed and considered – increasing the odds of product or project health, security, and viability. 

Ideally, this process will provide you one of the following recommendations:

  1. Project is working well.
  2. Project is not working well, but it is correctable.
  3. Project is not working well, and is not recoverable in a way that makes business sense.

This framework was originally described by Matthew D Edwards in his article, Distill What You See Into Action.

Download the Assessment Framework to determine the health and business value of your initiative. For even more accurate results, include your team to consider and broaden your perspective. 

Making Your Assessment Actionable

If you desire an outside perspective for assessing the health of your project or initiative, reach out to Trility. Our teams can help by conducting the assessment and leading a discovery process, building out an actionable roadmap, and partnering on areas of work where your team may need to leverage future-state skills.

Categories
News

Trility Consulting Joins Inc. 5000 Fastest-Growing Companies List

When the founders of Trility realized they needed to form a company instead of individually contracting on extremely tough projects, they knew they’d bring value to clients and provide challenging work to those who joined the team. Little did they realize how quickly the teams and expertise they pulled together would make the Inc. 5000 list in their first year of eligibility.  

“Trility is a team of people always and only working towards one goal: Add the most value to our client experiences possible, moment by moment, each and every engagement. The by-products of that singular goal are revealed as satisfied clients, happy, healthy  teams, and cultural, company, and financial health. It is because of our teammates that we collectively, clients and Trility alike, experience value-based success.”

Matthew D Edwards / CEO

The Inc. 5000 is an annual list that ranks the fastest-growing private companies in America. Trility is eligible as a privately-held U.S.-based company with four years of sales with a minimum of $100,000 revenue in the first year and a minimum of at least $2 million revenue in the most recent year.

Trility opened its doors in 2017 with two Fortune 500 clients and has achieved consistent revenue growth by working with companies of all sizes and across 19 industries. Each of them seeking different solutions but sharing one trait – they view technology as the way to thrive amidst market, economic, regulatory, or competitive headwinds. Despite the challenges of a pandemic, Trility and its clients remained resilient. 

Edwards shared, “We are blessed to have great clients. We are even more blessed to have great people in our company who choose to become more each day than they were the day before. And they repeat this every single day of their journey with our clients and our company. I am proud to stand beside the people at Trility.”

Iowa-Based Companies

Trility joins 31 other Iowa-based companies who also made the Inc. 5000 list: VizyPay, MCI, Higley Industries, The Art of Education University, Pet Parents, Moxie Solar, Trader PhD, English Estates, Eagle Point Solar, Eco Lips, PowerTech, Heritage Group, Itasca Retail Information Systems, Heartland Roofing, Siding and Windows, Spinutech, MedOne, MediRevv, Trility Consulting, Dwolla, Highway Signing, Express Logistics, Schaal Heating and Cooling, Kingland Systems Corporation, JT Logistics, Clickstop, McClure, Peoples Company, Aterra Real Estate, GrapeTree Medical Staffing, Involta, and Ivy Lane Corporation.

Among the 31 Iowa-based companies, the average median three-year growth rate was 140 percent and total revenue reached $823.9 million. Together, this list of companies added more than 7,338 jobs over the past three years and remained competitive within their markets given 2020’s unprecedented challenges. 

About Inc. Media

The world’s most trusted business-media brand, Inc. offers entrepreneurs the knowledge, tools, connections, and community to build great companies. Its Inc. 5000 list, produced every year since 1982, analyzes company data to recognize the fastest-growing privately held businesses in the United States. Complete results of the Inc. 5000, including company profiles and an interactive database that can be sorted by industry, region, and other criteria, can be found at www.inc.com/inc5000.

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
News

Approaching Talent Acquisition with Empathy

In working relationships, Scott Albert communicates naturally with transparency and empathy. These personal traits have served him throughout a successful career, enabling rapidly expanding organizations by developing strategic sourcing. He is excited for his fingerprint to be a part of Trility Consulting’s continued growth.

Scott had opportunities to transition into sales over the years but it never felt right to him. The talent acquisition aspect of scaling a business is where he belongs, “I find joy in helping someone improve their situation. Understanding where candidates are at in their careers, where they want to be, and if a move makes sense for them. It isn’t something I take lightly.” By following his passion, Scott has helped hundreds of candidates advance their careers and empowered businesses to grow.

At Trility, and especially in People Operations, we want to care for, enable, and equip all teammates. Delivering what we said, and when we said is the minimum standard when serving others. Scott Albert has seen success in his career because he has a core desire to go above and beyond. He operates with authenticity and true caring.  

Jennifer Davis/ Vice President of People Operations.

Trility is excited to welcome Scott to its team of lifelong learners. The advice he frequently shares with his wife and three kids will be a welcomed reminder to our teams, “It’s okay to fall, as long as you get back up and try again.”

Connect with Scott Albert

Interested in joining the Trility team? Email or connect with Scott Albert on LinkedIn. Check out Scott’s articles for interview advice or career tips.

About Trility

Comprised of technologists and business consultants, Trility helps organizations of all sizes achieve business and technology outcomes. Clients appreciate that our teams solve problems contextually and bring their people along to ensure a reduced cost of ownership long after the engagement is done. Headquartered in Des Moines, Iowa, our people live everywhere, and we serve clients from all corners of the United States and globally.

We’re Growing

Trility Consulting made Inc. 5000 list for fastest growing companies due to achieving 131% financial growth in three years and continues to have career opportunities for people interested in becoming more today than yesterday.

Categories
News

A Passion for Research and Strategy to Drive Content Marketing

A professional journey can take many turns throughout a person’s lifetime. For Claire Damon, hers took a dramatic one before finishing college, “I spent a year in New Zealand during college, and it shifted my perspective. I developed an interest in social justice and the environment that led me to not seek out a ‘true’ marketing job right out of college.”

Instead, Claire spent time as a research analyst in the technology industry where she focused on learning how software is created and, specifically, how algorithms impact results. This eventually piqued her interest in inbound marketing and led her back to marketing by taking a role in the nonprofit sector before joining Trility as a Content Marketer. 

Claire’s drive to bring value and validate results is something Trility seeks out in every candidate. However, her passion to learn and research means she keeps widening her perspective and brings thoughtful, concrete strategies and ideas for our team to leverage.

RHONDA O’CONNOR/ DIRECTOR OF MARKETING

Proven Success

At her previous position, her fundraising strategy helped the organization address the challenges that COVID brought in 2020. “In lieu of a gala, I pitched a 10-minute documentary to capture Abide’s story of what they were trying to accomplish in North Omaha. The Lights of Hope campaign exceeded the goals we set during a very challenging time.” 

An Iowa native, Damon moved to Des Moines and sought out a full-time role in marketing that would provide flexibility and growth opportunities in a team environment. “I was impressed with Trility’s track record of keeping its commitments to its clients and the transparency throughout the interview process,” shared Claire. “It reinforced that I would have the autonomy to own my work and responsibilities.”

Connect with Claire

Connect with Claire on LinkedIn.

About Trility

Comprised of technologists and business consultants, Trility helps organizations of all sizes achieve business and technology outcomes. Clients appreciate that our teams solve problems contextually and bring their people along to ensure a reduced cost of ownership long after the engagement is done. Headquartered in Des Moines, Iowa, our people live everywhere, and we serve clients from all corners of the United States and globally.

We’re Growing

Trility Consulting made Inc. 5000 list for fastest growing companies due to achieving 131% financial growth in three years and continues to have career opportunities for people interested in becoming more today than yesterday.

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.