In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann explores concepts around agile. This is a very important topic because many times we go into an organization and find that there’s a lack of clarity or a lack of common understanding about what agility really is. Often, it’s the agile itself that is confused with a popular framework on the market, or, it is seen to be implementing a different methodology than what they already have.
In this episode, Dan explores a couple of these misunderstandings around implementing agility, what exactly defines agile, some of the principles behind the Agile Manifesto and how to correctly engage with them.
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now, here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:16] Welcome to this episode of the Agile Coaches’ Corner. I’m your host, Dan Neumann. Today we’re going to be exploring concepts around agile, and the reason that’s important is a lot of times we go into an organization and find that there’s a lack of clarity or lack of common understanding about what agility really is. Often it’s that agile is confused with one of the popular frameworks on the market, or agile is seen to be implementing a different methodology than what they already have. I want to explore a couple of those misunderstandings or potential misunderstandings with our time together today. One thing I’d like to do when working with a team or a group of people in a training session is to have them do an exercise and it starts something like this. Well, go ahead and close your eyes. Well, if you’re driving, open them up really fast. The rest of you, maybe just close your eyes and imagine that you’re in a room and on the left wall are the words, individuals and interactions. And over on the right hand wall it says processes and tools. And I want you to think about a project that you’ve been involved in or are involved in. And when things get particularly tricky, where along a spectrum from relying completely on individuals and interactions to solve things, or over on the right using processes and tools, and place yourself somewhere along that spectrum. So take a mental walk and put yourself either near the individuals and interactions on your left or the processes and tools side of the room on your right. Now imagine if those words said working software on the left and comprehensive documentation on the right. In your projects, where is your comfort level with how much one relies on working software over comprehensive documentation. And then I would have them do the same thing with customer collaboration on the left and contract negotiation on the right. And lastly with responding to change on the left and following a plan on the right hand side. And so what we do then is go through those four spectrums if you will, and see where people’s comfort levels lie in the projects that they’re working on. And the reason we do that, and I often do that before introducing the concept of the Manifesto is because those are the four value that are in the manifesto for agile software development. If you haven’t seen it, hop on to agilemanifesto.org and if you don’t have a chance to write that down, we will put the hyperlinks into the show notes so you can go find those. And that’s the manifesto that embodies agile software development. In its entirety it says we are uncovering better ways of developing software by doing it and helping others do it. And through this work we’ve come to value individuals and interactions over processes and tools. Working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. That is, while there’s value in the items on the right, we value the items on the left more. And in this case the we is the 17 people that were the signatories and the creators of the manifesto for agile development back in 2001 and so at the very highest level that is what defines agile, the valuing of the items on the left over the items on the right. And really a lot of people forget or don’t know that the signatory said there is value in the items on the right. There is value in processes, tools, documentation, contracts and plans. It’s just that they have placed more value in the items on the left, the individuals and interactions working software, collaboration with the customer and responding to change. And it’s those values that have allowed the agile approach to be more successful or being a better way of delivering software than some of the alternatives.
Dan Neumann: [04:51] And the reason I ask people to place themselves on the spectrum before reading the manifesto or before sharing it visually or on a handout, is because it gives them a chance to reflect where their individual comfort level is along that spectrum. And it’s okay if somebody is very comfortable with processes and tools and not so much with individuals and interactions. It just really helps us get a place to start as we explore agility. The other important part of that exercise is it’s not binary. People are not either agile or not agile and I think that phrase, well it’s not agile, gets thrown around like a weapon of kinds, or rolled in there like a grenade. Well we can’t do that because it’s not agile. We can’t have a certain level of documentation because it’s not agile. We can’t present a plan in a Gantt chart because it’s not agile, are some of those kind of protests that I hear. The last time I checked in the manifesto and the principles, there’s nothing that says anything about how the plan is displayed. It’s up to the people doing the work to figure out how much documentation is appropriate, and it just so happens that the people who wrote the manifesto placed more value in working software over comprehensive documentation to the detriment of working software.
Dan Neumann: [06:16] The next important part I’d like to point out to people is that amongst the names of the agile manifesto signatories, there were a lot of different approaches to software development that were represented there. There were folks that were part of the extreme programming movement. There were folks, part of the Scrum movement, there are folks who are doing the crystal software development method. There was at least one person who was doing embedded software. There were people working on financial systems, so this wasn’t something that was just hip and trendy for websites and agile only makes sense if you’re doing delivery of a certain type of system, and I think that’s really important and also a misnomer because one of the other protests is well, we can’t be agile because we do…And fill in the blank. It doesn’t matter. I’ve, I’ve heard all manner of different things where people feel like they can’t be agile because of the type of work they’re doing. And again, going back to the manifesto, regardless of the type of work, you can still place value in the items on the left over the right, the degree to which you have processes that are documented and followed and testable and auditable, or the degree to which you have documentation or contracts or plans will vary based on the type of work. But I think I’d be hard pressed yet to find a type of work where agility simply could not be done because of that type of work.
Dan Neumann: [07:51] So just a couple of things that are on the manifesto itself, at least at the values level, and where I see even more value is going beyond those statements of values into the principles that are behind them. And so for folks that do go to agilemanifesto.org, below the signatories, the names of the people who signed up, there’s a link to the 12 principles behind the agile manifesto. And I think these are really important because what you’ll notice first is it doesn’t say anything about Scrum. It doesn’t say you have to be doing extreme programming. It doesn’t have any of the popular frameworks of their time or of our time that are listed there. So you don’t have to be doing Scrum to be agile, you don’t have to be doing pair programming to be agile.
Dan Neumann: [08:53] The exercise I do with the principals, there are a couple of different ways of doing it, but I really want people to engage with the principals. So one way of doing that is to give each person all 12 and ask them then, which of these principles do you feel is really well-represented in the work you’re doing and which of these principals maybe is a challenge? And which ones when you read them, do you go, I don’t even know what that means? And so it’s a chance to really engage with them. And so people might read, welcome changing requirements, even late in development, agile processes harness change for the customer’s competitive advantage. And so that is the second principle on the list. And this is one where a lot of times I hear people say, well, we have to change late in development, but we don’t really welcome the change. We do it because we have to. What’s interesting when I see people talking about that principal is often they leave off the second sentence in that principle entirely. The part where it says agile processes harness change for the customer’s competitive advantage, and in a lot of organizations they are literally doing change based on opinion or late because there wasn’t the planning that may have been more appropriate about how to not have that change late, and it is fairly unusual for that customer’s competitive advantage piece to sneak in. And so it’s really important to not just welcome change for the sake of it or because it’s opinion-driven, but to really have a substantial positive benefit for making that change late.
Dan Neumann: [10:38] The other challenge with that principal is the welcoming part. People a lot of times do it under duress. It’s not because they want to or because it’s easy or because they’ve built a system that enables it. It’s because they have to and that’s where the challenge then goes to the development team to look at practices that can really make it possible for those changes to be made. There are patterns that can be followed. There are different ways of crafting your tests of automating them for sure, so that when we make a change late in development for the customer’s competitive advantage, we know immediately, or very soon after, whether we’ve broken something that we did not intend to break. And so we get that fast feedback loop. And so that is one of those principles that I find us doing a lot of exploration on.
Dan Neumann: [11:30] If I were to look at another one that seems to generate a lot of conversation and we’ll touch on three of them. So the first one is that welcome changing requirements. The second one is the most efficient and effective method of conveying information to and within a development team is face to face conversation. That’s down near the bottom if you’re looking for it, or solidly in the middle of the principles. We’re obviously in 2019 at the time of the recording and gosh 2020 will be here before we know it and people say, well yes we have chat tools like Slack, like Microsoft Teams and we have application lifecycle management tools. We have Azure DevOps or we’re using JIRA or we’re using Trello boards or whatever the case might be and they say, well we have all these other things and so we don’t maybe have as much face to face which is true. That doesn’t mean that the statement that says, the most efficient and effective method of conveying information to and within a development team is face to face conversations. Yes, you can use email, you can use messaging and there are advantages and disadvantages to those types of communication methods, but the most efficient and effective one is that face to face conversation and so at times, especially when it seems like the communication is going off the rails somehow, stopping and making sure that we are having that face to face is critical for teams to really be effective and the degree to which they are having that face to face conversation is likely to enhance the degree to which that team is able to be agile and more aligned with the values and the principles of the agile manifesto.
Dan Neumann: [13:25] The last principle I want to explore as part of this podcast is one that I think generates a fair amount of confusion and boy, I wish I could have been in the room back in 2001 when there was the discussion around it because the way it’s written, a lot of folks at first pass don’t really quite get a good sense for maybe what’s being talked about and this is down near the bottom. It says simplicity. The art of maximizing the amount of work not done is essential. A lot of times people just don’t really know what that one is. They’ll put a little question mark down next to it. They’re not sure if it’s present or not present. They just don’t really know where to start with that one. So where I like to kind of direct that conversation is a lot of times software development has been so focused on getting the requirements from the customer and doing all the things that the customer needs, all the bells, the whistles, the ifs, the ands, the buts, all the exceptions scenarios. And then not only do we take those things that are in the requirements, but then we tend to take an architecture mindset for it. And gosh, what about all these other scenarios that the customer might want in the future. What do we do with those? And so we tend to over build from the requirements and we tend to over build from the architecture standpoint and they’re all of that extra fluff. The gold plating is one term for it. All of the extra complexities do a couple things. One, it creates a lot more code to maintain and test. And the other thing that it does is it defers risk of removing the risk until late in the process because we are putting in so much extra stuff that really isn’t needed. And so if you want to pursue more agility, one way to do that is to start looking with a critical eye at what’s being asked for and how you’re implementing it and really trying to figure out where there are opportunities to not do something, or not do something yet. Can we do something simple that covers a significant majority of the scenarios and get some feedback on that? Can we put in place an architecture that is sufficient for what we’re trying to do now and to not put a lot of energy into making it overly sophisticated because it’s some unknown point in the future we might want something else or something more robust. And so that also helps with a laser focus on delivering working software for your customer as a highest priority because we’re not serving the architecture as our highest priority and we aren’t delivering whatever was documented at some prior point in the future as our highest priority. We’re really ruthlessly looking at how do we satisfy our customers early and continuously deliver valuable software which is the highest priority according to the principles in the manifesto, and then how do we do that with technical excellence, with the maximizing the amount of work and not done and have that architecture and design and requirements emerge from that self organizing team? And so it’s really important to spend some time and internalize to some degree the principles that are behind the manifesto if your goal is to pursue agility and therefore be more successful in delivering working software and valuable working software for your customers. And it’s okay, maybe you look at the values and the principles and you go, Hey agility’s not for us. What we’re doing is working just fine. That’s okay too. You don’t, you don’t have to be agile. But if you are curious about agility, it’s important to move that conversation from a framework of the day or of a particular approach to scaling that maybe has a lot of market traction to it and really focus on the essence, the underlying values and principles behind agility.
Dan Neumann: [17:35] And so I’ll leave you with agility’s not binary. It’s not that you are agile or you are not agile. Think of it more like a spectrum. And along this spectrum, think of the degree to which you’re aligned with particular values or principles, and that will be an indication of the degree to which you’re functioning in an agile way or not. So if you’ve not familiarized yourself with the agile manifesto, hop on to agilemanifesto.org and read about it. Be sure to click through onto the page that has the 12 principles on it. I find them to be much more actionable and richer than the four value statements of the manifesto itself. And if you’d like a PDF with the manifesto and the principles on it that you can print out cleanly and you know, hang on your cube wall for those of you who get really excited about having the values and the principles at your fingertips, or if you have an open space, that’s cool too. You can print it out poster size, it looks pretty good. You can head on over to agilethought.com/podcast and download that copy as part of the show notes for this episode.
Dan Neumann: [18:42] So with that, this is the point where we usually talk about what people are reading. And I must admit, a lot of my colleagues are way more avid readers than I am. That said, while I have not finished the book, I am maybe a third of the way through a book called, The Truth About Animals: Stoned Sloths, Lovelorn Hippos and Other Tales From the Wild Side of Wildlife by Lucy Cooke. And I gotta be honest. It’s interesting, not so much the things that I’m learning about the animals themselves, but it is an interesting history of the scientists that were trying to understand things like how freshwater eels reproduced because, well, Lucy goes into a lot of detail about it, but they trek from the ocean into rivers where they mature before returning back to the ocean to breed. And so if you go back several hundred years, there was no technology for tracking this type of behavior, and so there were lots of misinterpretations, lots of confusions, lots of mistakes made as people were trying to solve this riddle of the eel. So it’s just kind of interesting to think about how popular myths and misconceptions can spread around and become viewed as fact. And um, just kind of an interesting insight into animals. And now I’m, I’m onto stoned sloths, I’ve just started that. So we’ll see. Maybe there’ll be something agile inspiring about stoned sloths, but we’ll see. So not a bad read, but uh, we’ll see. What kind of insights come out of that. Thanks for listening today and I look forward to hearing what topics that might be of interest to you. So you can tweet those to us with the #AgileThoughtPodcast or email them to us at email@example.com thank you.
Outro: [20:35] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.