Episode Description:
Dan and Sam have covered a lot of ground in previous episodes about agility but never the full scope of what exactly is considered agility. Many people have their own unique definitions of what agile is and what it looks like…but when you really dig in, these are often ways that do not seem to be in alignment with the Agile Manifesto or principles.
So, in this week’s episode, Dan and Sam are diving into another fantastic listener question to address this topic. Chris on Twitter asked, “What is agile?” They take a deep dive into the history of why the Agile Manifesto was declared, the need that the principles and values were born out of, and ultimately: What is agile.
Key Takeaways
- Why was it important for the Agile Manifesto to be declared? What is the history behind it?
- It was created in reaction to what was happening in the software industry in 2001 (predominantly waterfall and other predictive methods with bad track records for delivering on time)
- In response to “scope creep” (AKA changes or uncontrolled growth in a project’s scope at any point after a project begins)
- Because it is very difficult to predict what you need to do when you’re trying to solve a new problem every time
- Out of necessity (as any work that requires creativity and a high degree of uncertainty about the outcome you’re trying to achieve [such as software development] is difficult without a set of principles and values)
- Because every problem is unique with software development
- In the Harvard Business Review in 1986, an article was published titled, “The New New Development Game” that outlined the need for a new way of working where teams could be given objectives instead of tasks and they work together as a unit to accomplish their work
- The “relay race” method was clearly not working and agility offered a better model, better compared to playing rugby
- “Agile wasn’t: ‘Let’s get together and think about a new way of doing things.’ It was: … ‘Hey, we’re doing some things. It seems to be getting better results than the industry as a whole. What are we doing that’s common across the different methods?’” — Dan Neumann
- Those that came up with the Agile Manifesto didn’t put it together to justify their existence; they put it together because they recognized the success they were having through its methodology and wanted to figure out the commonalities
- What is the Agile Manifesto?
- It’s the thing we point to when someone says, “What is agile?”
- If you’re asking if something is agile, you can reference the manifesto’s values and principles
- What is agile?
- It’s creating competitive advantage and being the disruptive force
- Delivering working software as your primary measure of success
- A collection of values and principles as laid out in the Agile Manifesto
- It is the ability to deliberately respond to change and demand; not just react
- Controlling risk
- Building stuff that people actually want and will use
- Solve the problem that the customer has called for and not gold plating everything
- Agile practices are simply that; practices — they’re good in some circumstances and not good in others
- Are you changing just to change or are you harnessing change for competitive advantage? Is change happening to you or are you creating the change?
- Change is not just about keeping up with your competition but making your competition keep up with you
Mentioned in this Episode:
Transcript [This transcript is auto-generated and may not be 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, and joined by collaborator Sam Falco.
Sam Falco: [00:23] How you doing Dan?
Dan Neumann: [00:24] Wonderful.
Dan Neumann: [00:25] Sounds like we’re going to step on each other. It’s part of this fun, right? But we’ll hope to still make it an amazing experience for people who are listening. So diving right in today, we’ve invited people quite regularly saying, Hey, go ahead and uh, you know, send us some questions at podcast@agilethought.com. I didn’t anticipate properly that I would get a question on LinkedIn, not LinkedIn on Twitter. One of the other platforms? And it only took me about three months to notice that I had a direct message. So for that, I apologize. I’m trying to use, trying to use Twitter better. The question came in from a listener named Chris, and he was wondering what resources there might be for what is agile for people that are trying to understand that.
Sam Falco: [01:17] That’s interesting. I mean, we talk about agile a lot, but everybody’s got their own perspective on it, our own definition of it. And so you’ll hear people say, Oh yes, we’re agile. But when you dig in, they’re still acting in ways that don’t, don’t seem to be in alignment with the agile manifesto or principles. And maybe before we start talking about what it is, it might be important to dig into why, why was it necessary for an agile manifesto to be declared? Where, where does this come from?
Dan Neumann: [01:53] Agreed. So I think one of the places that the agile manifesto comes from is a reaction to what was happening in the software industry at the time preceding 2001, wasn’t the manifesto. And that was the predominance of waterfall and horribly under successful track records for delivering value projects on time with scope, people cared about for the money, somebody who was interested in paying for it.
Sam Falco: [02:25] Right. And it wasn’t just waterfall. There were a lot of big design, upfront frameworks or methodologies that were not producing the results. Waterfall is the most commonly known as the most, uh, was the most prevalent, I think. And it’s interesting to me, because if you look at the paper where waterfall was first described, published in 1970 by Winston Royce, and he describes one way, we might start professionalizing software development and he describes this and there’s the pretty diagram. And later in the paper, he pretty much says he doesn’t think this will work and probably shouldn’t do it that way. I may be overstating the case, but he was not saying, this is, this is going to work. And people started applying it and very quickly it became apparent that no, this doesn’t work. In Royce’s paper, he was also saying these should be short cycles and that you should have at least two, one as a prototyping phase. And then your delivery phase, once you’ve learned something, unfortunately that part of his analysis sort of got dropped because, well, let’s just go faster and faster if we just do it right the first time, how many times have we heard that phrase? We just want to do it right the first time. It would be awesome if human beings were capable of doing things right the first time, but not so much.
Dan Neumann: [03:47] My favorite part of doing traditional management when I did was the post-mortem, we’ve just spent 18 months on the project. Uh, it sucked, what are we going to do better next time? You know, we can do better next time. We’re going to get the requirements, right.
Sam Falco: [04:08] Spend more time looking at those requirements and analyzing them. And then the developers will know exactly what we want them to do, because we will tell them in excruciating detail.
Dan Neumann: [04:19] And we’ll hold the customer to that requirements because they signed off. Darn it. Right.
Sam Falco: [04:26] And customers loved it. Things like what you signed off on it. So pay me.
Dan Neumann: [04:31] No, no one likes that. Yeah. I, uh, I did about a decade under waterfall stuff. And my, my favorite quote, when the haggling over a change request was from an Irish engineer named Edgar. And he goes, that’s what we call the same, but different. And I’m like, I have no idea what you mean, Edgar, but yeah, all kinds of fascinating behaviors in a predictive, get it right the first time single shot through type of approach.
Sam Falco: [04:59] Right. And that’s where the fear comes from. You hear this phrase all the time, scope creep, and I’ll hear it in my Scrum trainings. And I’ll hear it when I’m coaching someone, whether it’s Scrum or not, whether any agile framework, how do we prevent scope creep? Well, I think the lesson we should have learned by now is that you do not prevent scope creep and in an agile way of working, you learn that that is called learning and take that into consideration and adapt to change. But we’re getting ahead of ourselves.
Dan Neumann: [05:32] Well, let’s, let’s not get ahead of ourselves.
Sam Falco: [05:34] Let’s continue talking a little history. I have a history degree. So I like to use this every now and then.
Dan Neumann: [05:38] Well, we’ll, we’ll, we’ll, uh, we’ll, we’ll try and contain you though. So there’s the waterfall and other predictive methods that were, uh, highly prevalent at the time. And we should probably give a nod to our friend, our friends, Taylor.
Sam Falco: [05:52] Yeah. Frederick Winslow Taylor, who tried to what he called Scientific management to work. This is a reaction to the industrial revolution where by we can, we can analyze the work, Dole it out, uh, time it, uh, know exactly what the work is going to be, and we can establish best practices for everything. And that actually has its place in simple, or maybe even complicated domain work here. I’m relying on Snowden’s can F and framework for, for domains of, of management and work for those things where we know more than we don’t know, or we know everything about the problem we’re trying to solve. You can use that. You can do a predictive analysis. Here’s a fun side note. Uh, Taylor was the inspiration for the main character in the original movie, cheaper by the dozen. Having watched many children was much more efficient than, than just raising a few. Um, just something I read one time and I thought, well, that’s just odd anyway. And now, now you know it too.
Dan Neumann: [06:57] And know back to Taylorism. So, So I had, I had a coworker once, so, um, we have a child, my wife and I do, and one of them, and this person was trying to explain to me how, you know, once you have like three kids, they just take care of each other. Um, the fact that she had zero kids made the advice dubious.
Sam Falco: [07:22] That was, that was Taylor’s theory. But anyway, getting off of the, uh, the children,
Dan Neumann: [07:27] There were parts in Taylorism about, you know, reducing motion waste. So if you know, traveling movements that are unnecessary, not working towards the outcome, removing waste and, um, and there’s some value in that there is some value in certain things.
Sam Falco: [07:41] Yeah. The problem is when we try to apply that industrial paradigm to knowledge work, and this is true, whether it’s software development or, or, you know, marketing campaigns or whatever, involves a high degree of creativity and uncertainty about the outcome you’re trying to get to and software development very quickly outstripped the ability to predict what we can do because we’re solving a new problem. Every time let’s take for building a house, humans have been building houses for a long time. We have a lot of data around how long it takes to lay brick and for the mortar to dry and to get pipe in there for the, for the plumbing, et cetera. We don’t really have that with software develop because every problem is unique. We’re not solving the same problem over and over again. You’re doing it wrong, right? And I mean, how many times have we seen people say, Oh, I know exactly what I want. I want you to rebuild. I want you to build exactly what my old system does, but not as creaky.
Dan Neumann: [08:40] Re-platforming is in my experience, a, a fraught activity fraught with danger. They, they don’t go well because it isn’t just give me the old system, but on the new architecture it’s Oh, and roll in some enhancements and roles. And some things you are going to discover. And the rest of the new ideas, you can come up with over the next 12 months.
Sam Falco: [09:00] But make sure that we still have all the old features without any analysis of whether or not anybody’s using those or needs them. But it becomes quickly apparent to anybody who’s paying attention to the waterfall is not having the desired effect. I won’t say it never works projects were delivered, but the failure rate was somewhere in the 80%. I can’t remember the exact study or the exact number, but it was like 85% of waterfall projects failed to deliver the value they were expecting to deliver.
Dan Neumann: [09:29] And so measured and measured against original timeframe, expectations, original budget expectations. So it was pretty easy to fail. Did you do everything that you thought you would on time for the same dollars? Well, yeah. Good luck with that.
Sam Falco: [09:43] Right. And so, as early as 1986, we see that waterfall is not working. There is a paper that comes out the new, new product development game by Hirotaka Takeuchi and Nonaka in the Harvard business review. And they are analyzing the way waterfall is failing and they compare it to a relay race. In waterfall of course, each group does its work and hands it off to the next, you have your requirements gatherers. They hand it off to analysts to then hand off the task, et cetera. And they said, well, that’s not working. And what we need is a way in which teams can be fed objectives instead of tasks. And they work together as a unit to accomplish the work. And their comparison was to a rugby team. The way a rugby team works together to move the ball up, up field.
Dan Neumann: [10:36] Which I think the analogy works, even though I couldn’t tell you what’s happening in rugby. The ball moves. And eventually they celebrate.
Sam Falco: [10:46] I do like rugby, but yeah, I do find it baffling. The first time I watched it, uh, there was a stoppage in play and I said, what’s going on? And my friend said, Oh, there was a foul. And I’m like, what did someone stab? Somebody? Because like, I didn’t see that there were any rules. The rest seems to be fairly violent too.
Dan Neumann: [11:02] Unlike, unlike a relay race where people. Y’all handing a Baton. And by the way, it often gets dropped in transition. This is more about everybody collaborating to move the ball together, down the field.
Sam Falco: [11:16] Right. No specialty or very little specialization. Um, cross-functional anybody can carry the ball, um, really reaching the limits of my rugby analogy here.
Dan Neumann: [11:35] Teach us about this, but that’s where the term Scrum then came from.
Sam Falco: [11:40] Right. Um, and this is the last bit of my, my, my rugby knowledge is that a Scrum occurs because there’s been a stoppage in play often because of a foul when Jeff Sutherland and Ken Schwaber were putting together what became Scrum, they built in stoppages in play. We have at the end of the sprint, we stop and look at what did we do and plan before we move forward. Every day, we have a stoppage in play, so to speak where the team gets together and figures out, what do we need to do today? But I think we’re getting a little farther afield from our original question, which is what is agile, why?
Dan Neumann: [12:18] Yup. So some of the, some of the things that weren’t working waterfall, some of the MIS application of Taylorism leads to distrust when you’re setting expectations with your stakeholders, about how much money and when, et cetera. So lots of problems with the industry as a whole leading up to the pre 2001 state when the agile manifesto was created.
Sam Falco: [12:47] Right. Enormous amounts of distrust between business on the one, hand it on the other, not just distrust, but in some cases, animosity, a lot of finger pointing you. You never give us things on time. You can never settle on what it is you want, uh, et cetera. And so the agile manifesto comes about when the 17 people who were signers were all doing something different than waterfall and met to figure out what do we all have in common? What are we all doing that works that we could offer to other people to figure out how they should proceed instead of waterfall or any other big design upfront
Dan Neumann: [13:30] I think that’s a really important point to pause and amplify agile wasn’t, let’s get together and think about a new way of doing things. It was a distillation of, Hey, we’re doing some things. It seems to be getting better results than the industry as a whole, what are we doing? That’s common across the different methods, crystals, scrum, XP, et cetera, et cetera, et cetera.
Sam Falco: [14:08] Right. And it’s reflected right? In that opening statement, we are uncovering better ways of developing software by doing it and helping others to do it. These are practitioners. I actually had someone at one company who said, when I asked, where do you think the agile manifesto came from? Said, you know, some agile coaches basically put this together to justify their existence. Like now your cart before the horse, there. Agile coaches come much later. But yeah, these, these are practitioners. These are people who have been having success and they want to figure out what’s in common because none of them were saying, you must do what we do. All of them recognize that their framework was good for their context. It might be good for others, but some people would not find them as valuable. And how could you essentially roll your own? Now, scrum sort of ate the world of agile because it’s effective. And a lot of people adopted it. There’s varying theories on that. That are some are more cynical than others, but which is why we often hear scrum and agile being equated. But that’s why I kind of want to try to avoid talking too much about scrum right today, because we want to talk about agility.
Dan Neumann: [15:18] So back to agility, then the agile manifesto for me is the thing I point to when somebody says, what is agile? Uh, it’s got the four values on it. I think it gets truncated to individuals and interactions over processes and tools and yada yada, yada, one yada per each of the other three items. And then behind those four, those four values are 12 principles. And the degree to which a behavior or a mindset and an approach aligns with those 12 principles is the test for lack of a better word, I would use fo. r is the thing, an agile method or not, right? It doesn’t have to be an agile method that might not be applicable to your type of work. But if the question is, is this thing agile? Well, let’s look at, are we delivering working software? Are we frequently? Are we changing just to change? Are we changing? Even welcoming changes, even late in development for a customer’s competitive advantage. It isn’t just whimsical because, you know, we want to, so that’s the place where I would start. What, what is the agile,
Sam Falco: [16:34] Right? And that this is a slight tangent, but what the heck? Um, one anti-pattern I see is people say, Oh, responding to change means anytime I want, I can come in and tell you to stop what you’re doing and do something different. And that is exactly the behavior that led to the distrust in the first place, in a pre agile world, that business would come in with new requirements or changes that needed to be made. And it would shrink back from that because no, it’s not in the contract, that’s not in the original scope and have the change management. And so here we have animosity. And so that behavior gets painted as well this is agile. No, that is an anti-pattern. That is anti agile to just change Willy nilly, the manifesto says respond to change or following a plan, not react to change. So sometimes we look at change and say, we’re not going to do anything about that right now.
Dan Neumann: [17:36] And one of, while we, while we pick on words, are we harnessing change for competitive advantage or is change happening to us? So like harnessing, uh, a donkey, I guess, to, to pull a cart along like the donkey, he’s not just running around doing whatever donkeys do, but you know, are we actually harnessing the energy of this change for that competitive advantage? Right. Well, there’s our soapbox on change, right?
Sam Falco: [18:02] Well, just to add one thing, there’s a great statement in a book called agile software development ecosystems by Jim Highsmith. I think it’s out of print now came out early in the agile revolution and, um, which is worth trying to find because there’s a lot of the why of agile in there and a great appendix on roll your own. Here’s what you need. If you’re going to alter or alter an existing one or, um, make your own. But what Jim says is that harnessing change for the customer’s competitive advantage is not merely keeping up with your competition, but generating. And I’m not sure I’m getting the quote exactly right here, but generating chaos that your competition has to deal with. So it’s not just keeping up, it’s not merely staying a step ahead. It is causing trouble for your competition, that they have to adapt to
Dan Neumann: [18:58] Bringing it solidly back to yes,
Sam Falco: [19:02] You can rein me in.
Dan Neumann: [19:05] So what is agile? You know, it’s, it’s, it’s creating competitive advantage, right? Disrupting your customer like, like you were talking about being the disrupting force. Are we delivering working software as our primary measure of, are we measuring progress using working software as our primary measure by waterfall world? It was, we said, this was going to take 300 hours on this activity. And you know, we’re, we’re 200 through, are we two thirds of the way through the effort we are measuring time and activity. Tayloristic kind of concepts as opposed to measuring, using actual working software that we validated. So what is agile? It’s this collection of values and principles as laid out in the manifesto.
Sam Falco: [19:50] Right. And I think that we get to the heart of it. When we say that it is the ability to deliberately respond to changing demand. Like not just react, but deliberately respond with with thought and at the same time controlling risk. And that’s another factor that big design upfront I’m deliberately trying not to use waterfall for everything, right? But those predictive methods don’t limit risk because they take too long most of the time and they make it either difficult to change or when change happens, it throws our plan to, to such disarray that we can’t finish. So flexibility for sure. Um, but it’s with thought and we manage risk.
Dan Neumann: [20:43] I love bringing in the concept of risk and it’s easy to think of just the requirement side of agile, you know, are we responding to change? Do we have working software? I love also that there are technical and engineering principles behind this. Are we, are we maximizing the amount of work not done? Not just from a feature standpoint, but from a technical standpoint, don’t write code. You don’t need to write a technical excellence, enhances agility. This isn’t about just writing some crap. It’s writing enough code that’s good. So that when things change, the underlying foundation is also easily changeable to deliver those.
Sam Falco: [21:24] Right. And it’s funny because that gets labeled as an agile thing. That’s a principle that has been around maybe not in software, but build as little as possible. Right. Don’t, don’t build things. Nobody wants. Um, it’s articulated more clearly.
Dan Neumann: [21:46] I had a lot of experience with, Oh, we’re going to need this. Oh, what if, Oh, we should build it. Cause they might. My experience, at least prior to agile was about building a lot of stuff that probably would count as gold plating or just, you know, we think somebody’s going to need it.
Sam Falco: [22:05] Right. I’m thinking of my working career before software, there were often that idea that don’t do that. Nobody needs it right now. So I worked for a bookstore for many years and don’t unpack and sort those books onto a cart for shelving. There’s no room on the shelf, leave those in the box for right now. We don’t need them. Um, that kind of thing. Uh, and other, other jobs as well, where just don’t, don’t do a lot of work that we don’t need to do when I was doing the tech support, you know, solve the problem the customer has called in for, don’t try to do more than that. And you can always escalate to tier two and let them handle it. If it really is a more complicated problem, maybe I’m overstating my case.
Dan Neumann: [22:50] No, I, I see that with, you know, figuring out what the team is going to do in metaphorically, that big box of stuff, you know, around a feature, like leave that alone. Don’t start unpacking that if you don’t need to unpack it for some actual working software in the near term. Just leave it alone. Like you can, you can get to it later.
Sam Falco: [23:10] Right. And I think what I was getting at, um, and didn’t articulate well is just that many of the, what are referred to as agile practices are practices agile uses, but they’re not, they’re neither agile nor not agile. They’re just practices. And they are good in certain circumstances and not in others. And some of these things that we call agile predate the manifesto, they are practices that we know or knew about. Um, and we’ve just discovered these are valuable. So let’s do them. Is it agile? I don’t know. Does it help you be agile? I think is a better question in that circumstance.
Dan Neumann: [23:56] Sam, thank you for taking the time to explore the tweet that I received from Chris on the topic of what is agile. We covered some of the background that informed the way software is developed leading into 2001 waterfall methods. Taylorism, that bred distrust with business and stakeholders and a lot with it. So lots of, lots of bad things were happening there. And then in 2001, people who were using methods that were yielding more success than what waterfall or other highly predictive methods were at the time got together to say, Hey, what are the common threads about what we’re doing, which then yielded the agile manifesto, the values, the principles, and, and we had a chance to explore some of that.
Sam Falco: [24:50] So that was, that was a mouthful.
Dan Neumann: [24:52] I think that was a mouthful. So that’s, that’s the, what is agile that brings us to the, what is Sam reading these days what’s on your continuous learning journey?
Sam Falco: [25:03] The latest book I’ve picked up is called the surprising power of liberating structures. Liberating structures are ways to gather or encourage feedback and participation in solving problems and or even identifying problems and then solving them. There’s a website. I think it’s just liberating structures.com. We’ll have to check that before we put it in the show notes, we’ll put the appropriate link in the show notes that gives an outline of these. The surprising power of liberating structures goes a little deeper into the theory behind these, these activities so that you’re not running the same kind of event over and over again. Uh, you can be a little creative dig a little deeper. So I want to understand those more. I’ve only used a few of the structures that are described on the website, and I want to know why the others work when they work so that I can start using them appropriately.
Dan Neumann: [26:00] That totally makes sense. Yes. I multitask liberating structures.com is the correct URL. We will still put it in the show notes, but, but you did not mislead people verbally. And there are some structures I’m familiar with one to four, all, for getting individual ideas and then you’re getting them up into other ones. So, uh, applicable to what types of scenarios do you think?
Sam Falco: [26:23] Retrospectives. Um, whether it’s a team retrospective or broader, um, planning sessions, strategy, even, uh, more to the point, some of these, some of these structures are quite lengthy. They’re not something you do in an hour or two. There may be all day, but if you’ve got big decisions to make lots of people, there’s a lot of these structures will help draw out inferences understandings and thinking that that might not have come to the surface. If you just sat everybody in a room and said, so what do you think?
Dan Neumann: [27:01] Right. So I think there’s probably a deeper dive and a podcast dedicated perhaps to liberating structures in the future. So we’ll, we’ll throw that into the backlog.
Sam Falco: [27:11] I’ll be an expert by next week. I’m counting on.
Dan Neumann: [27:17] And I appreciate you letting me live vicariously through your learning. Uh, it’s far more efficient than doing it on my own kind of a Tayloristic approach. Really nice. Nice, nice, nice call back to them again. So until next time.
Outro: [27:38] 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 for this episode and other episodes at agilethought.com/podcast.
