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.
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.
Read more articles from Trility’s team.
Read summaries about projects Trility has delivered.
