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.
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.
