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