In today's episode of the Rabbit Hole, we are joined by our friends Sophie Creutz and Raymond Lam to take a shot at unpacking the Agile Manifesto! We often speak about the Agile approach and thought we would take it down to the foundational level, speaking about the components of this essential tool for developers and teams. From the emphasis on collaboration and the human side of things to the ability to change course when necessary and the priority around working software, we look at the tenets of the manifesto and weigh in with some examples and reflections. Towards the end of the episode, we talk about the Waterfall model and some of the obvious differences to the Agile method. So to hear it all, make sure to tune in!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 229. When to Pair Program
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast, living large in New York. I’m your host, Michael Nunez. Our co-pilot today.
[0:00:10.5] DA: Dave Anderson reporting.
[0:00:12.4] MN: Our time lord.
[0:00:14.1] SC: Sophie Creutz.
[0:00:16.9] MN: And the emperor.
[0:00:18.0] RL: Raymond Lam.
[0:00:19.6] MN: There you go. Today, we’ll be talking about the Agile Manifesto. I knew we woke up this morning and say hey, we got to do some cool titles, I stay with host, so glad that we have –
[0:00:29.3] DA: We’re jet lagged and physically or just mentally, so right? Bring in the energy.
[0:00:37.3] MN: What better topic to talk about than the thing that we all believe the most, right? The Agile Manifesto.
[0:00:44.6] RL: There’s not much room left for tattoos but there’s room for the Agile Manifesto.
[0:00:51.8] MN: You're going to have all the individuals tatted on yourself as well.
[0:00:55.4] DA: The individuals.
[0:00:57.4] MN: Every single individual name.
[0:00:58.6] DA: It’s like the Last Supper but all of the signings of Agile Manifesto.
[0:01:04.8] MN: Exactly.
[0:01:05.8] DA: Okay. All right, taking notes. What is the Agile Manifesto before I commit to this fully?
[0:01:14.6] MN: Where you get a tattoo on your arm.
[0:01:16.6] SC: Yeah, before you tattoo Agilist on your forehead, you know, you could ask yourself the question, “Do Agilists live their life by some kind of code, right? What are the rules, are there any kinds of “Official Guidelines” for being agile?”
[0:01:32.2] DA: It’s like chivalry.
[0:01:33.5] SC: Right, like chivalry. I guess you open the door for people, et cetera.
[0:01:41.6] MN: Don’t write documentation, that’s probably a big one or something like that, I don’t know.
[0:01:47.0] SC: Yeah.
[0:01:47.1] RL: Likes to read books.
[0:01:51.4] SC: I think this Agile Manifesto, which does in fact exist is a way to answer some of those questions, a way to kind of codify some ideas that folks were thinking about for a while in response to the way that software was working in businesses at the time.
[0:02:10.6] DA: Yeah, we’ve talked about Agile obviously, pretty much continuously on the podcast and we actually, in episode 66, talked about the Agile principles which are the 12 principles that are derived from the manifesto from the four ideals or values but we never talked about the values.
[0:02:33.5] MN: There you go and here we are.
[0:02:35.9] DA: Yeah, so let’s examine these values. First, individuals and interactions over processes and tools.
[0:02:44.8] DA: Yeah, this one is so important because this kind of goes to the root of thinking about people as people instead of resources or things that need to be controlled or managed.
[0:03:01.3] SC: I wonder if anyone has a specific example of when they had to make some kind of choice or decision and this principle helped as a guideline and how to make that decision.
[0:03:16.2] DA: I mean, I’m thinking about the ways in which things often went wrong when not working on Agile environment, where in a prior life, I was working in a place where individuals were definitely resources and they had very specific process-oriented jobs that are basically, it was mechanical Turk, but the workplace. You would insert a sequel script into a ticket, people apply the approvals onto the ticket and then someone else would take the ticket and run the script exactly as it was and if you forgot a semicolon somewhere or something was weird, then they were just like, “Oh back to the drawing board.”
[0:04:03.3] MN: Start all over.
[0:04:04.0] DA: There’s a lot of ways to that and there wasn’t a lot of emphasis on that individual relationship between people. You never had a conversation with somebody on a different team. It was like, the process mediating it. A choice that I made when I was working there was I was going to build human relationships with the people who were the script monkeys.
That way, I’d be like, “Hey, I have a script coming up to you, just wanted to give you a heads up, please reach out to me when you’re running it or if you have any questions” or whatever. That actually helped build a more humane workplace although I still have no idea what any of those people’s faces look like.
[0:04:52.5] SC: It just sounds like you introduced some interactions into a process that was lacking human interactions and in the process, improved that process itself.
[0:05:04.2] DA: Yeah, I would get faster turnaround times, I would get more eager responses and feedback loops when things were going wrong because we knew each other, we were not throwing it over the wall. I feel like another thing we’re like, processes kind of come in in Agile is like, swim lanes. When you have a testing swim lane, where you have a tester and you put it into the test swim lane and they say, “Okay, well, not my problem now.”
[0:05:34.6] SC: You got to build those relationships with your QA folks, whoever is going to be testing it. All right, how about the second ideal, working software over comprehensive documentation.
[0:05:47.4] MN: I love this one, I’ve worked at a place where you would get a 70 page PDF of the thing that you need to build in six months and it was like, “How do you write software in silo by yourself, just referring to this document as you’re building the thing that’s being asked for?” and never again could I ever do that, it was so difficult and not being able to collaborate and make sure that it works is doing the right thing because it just all comes from this very cold documentation.
All these answers are in there for – every formula you need is in there, directions for the documents for those formulas in there, it’s painful.
[0:06:34.4] DA: Even worse, you have that document but then if there’s a mistake, the person who is writing it didn’t know everything that you know today because you’re living at the edge of the last responsible moment where you have the most information. Then what do you do? If you were valuing comprehensive documentation overworking software, you must update that document. That document must be correct and you should also get all the sign-offs from all those stakeholders on your spelling change or refactoring or whatever.
[0:07:09.2] MN: Yeah, it was, I can probably throw some context into it. It was a particular contract, that foreign exchange traders used that was a little different than a payout forward that they want to spice it up so that it’s faster. I have no idea what those terms were, at all. I was just a brand-new programmer thrown into foreign exchange derivatives.
[0:07:34.1] DA: Finance.
[0:07:35.2] MN: Figuring out all of these word salad that was having Bobby from the Bronx with his slacks and buttoned-up shirt on to get on the metro, have to go to Stanford Connecticut and do my banking job. I had no idea what this document — 60 pages of what? I just had to make it happen every day, it was long hours, it was tough, it was no joke.
[0:07:59.4] DA: I’m curious at the end of this project, were you on time, did you have working software?
[0:08:04.1] MN: I mean, it was on the training platform and people said that it worked fine.
[0:08:10.3] DA: Great. Okay, cool because I feel like I have witnessed so many projects that have value in this comprehensive documentation over working software. Then they get to the last month and it’s like, “Oh god, nothing is integrated, we’re not…” Like a correlate of this is like continuous integration and all those practices of making small slices of functionality and building up the small slices of an application over time.
You always have something that’s working, even if you ran away from it today, we would have something. I saw too many projects that ended up in this case where it didn’t fully work at the end because it wasn’t small slices. It was just a big complex thing that just went down in the world and then now we see if this documentation was correct.
[0:09:04.0] MN: Just to let you know, two months before the due date, I was just like screaming in terror and lost. Like, “Yeah, I don’t know what the fuck is going on, you got to send help, send the cavalry. I need help.”
[0:09:13.9] SC: That’s so stressful. I think also, it ties into this previous ideal in a way, right? Because it’s almost as if the comprehensive documentation takes the place of individuals and interactions, right? You might actually have a paring session with someone where you talk about how to solve a particular problem or someone says to you, “I think the answer to that problem is in the documentation.”
[0:09:41.5] DA: Yeah, what is working software but in interaction with an individual that’s a user of that software.
[0:09:46.8] SC: Indeed.
[0:09:49.2] DA: That’s wisdom, just thought that. Great, awesome. I love that. Yeah, maybe we’ll find going through these that the first one is all you need.
[0:10:00.0] SC: Perhaps so, they all build upon each other. With that in mind, let’s talk about the third one.
[0:10:04.9] DA: Yeah, so that’s customer collaboration over contract negotiation. I feel like this is a theme. It’s like, about the interactions, right? Collaboration is an interaction.
[0:10:16.4] SC: Yeah.
[0:10:17.4] MN: The customer as an individual. That is it overall, it’s a person that is using the product and will let you know whether it’s doing the thing the customer expects it to do.
[0:10:29.0] SC: Yeah, the kind of thing about the end user. Now, for those of us who maybe are not so savvy on the sale side of things, does anyone have an example of how contract and negotiation might get in the way of customer collaboration?
[0:10:45.8] DA: Oh boy. Yeah, so I think in the most literal sense like contract negotiation, sometimes there are like fix bid projects where it’s like there is a list of stuff on a contract that you must deliver for this price and the danger there is that you are trying to predict what is going to be useful in the future or like maybe some person in finance is trying to predict what the customer actually needs.
It was like, you should actually be talking to the people who are going to use the software and iteratively work with them over time to arrive at a solution that is meeting the true needs of what they need to do.
[0:11:31.3] SC: Yeah, it makes so much sense when you put it that way.
[0:11:33.9] DA: I think there is other aspects of contract negotiation too that I don’t know if we’re intended but I think about like, you know, interfaces as being contracts too and things like that. If you have an API spec for a public service, I feel again like customer collaboration. You should talk through who are going to use this public facing API rather than hammering out this stone chiseled API doc.
[0:12:05.1] SC: Right, I mean, how would a contract negotiation get so far removed from customer needs after all?
[0:12:12.3] MN: Well, I think it has to do with a contract to me, when something has been negotiated in the contract like it is set in stone and right then and there but it doesn’t allow the customer to actually say something or change something, once they see it in real time like imagine we’ve all had an experience where we were pairing with a designer, goes, “All right, well I got this thing and it looks… what do you think about this?”
He’s like, “Nah, on second thought, let’s try this other thing” but that negotiation takes that away because they have already negotiation where that button is going to go for example on what calculation is going to exist to make this better. I’ve read this in terms of how you take that away from the customer because it is done by people who are not even using the software.
[0:12:59.6] SC: People are very far removed.
[0:13:00.7] MN: To right where this is, yeah.
[0:13:01.4] SC: Yeah.
[0:13:02.2] DA: Yeah and I think there is also if you think about things like, with empathy from the perspective of people who might be writing this contract with a list of stuff, why would they do that, they might do that because they are afraid. They’re afraid that they are going to pay a lot of money for something that is not going to be successful and a lot of these things, these like processes and tools over individual interactions is like, “How do I get control?”
How do I feel comfortable with this process that is inherently very risky? Process and tools, comprehensive documentation and contract negotiation, these are all ways to try to feel like you have control over the inherently risky process of developing software.
[0:13:49.3] SC: Right and I suppose like being agile, being able to respond to change might feel very out of control sometimes. However, that does lead into our last ideal here, which is responding to change over following a plan. No, I don’t think this implies that you should have no plan, right? Just to clarify.
[0:14:12.2] MN: I thought it did.
[0:14:13.5] DA: Right, yeah.
[0:14:14.7] MN: Screw the plan and make it, but I think it does call out the idea that like you can follow a plan and know that there might be changes associated to that plan in which one will have to respond to the change accordingly versus, “Nope, my head is in this document and I am only going to do everything that it is in this document” or “It’s been in the contract and I can’t look away on regardless of the change that is being asked for me to do” because of the stone wall, these very cold processes that exist and the things that Agile is trying to change.
[0:14:55.1] SC: Right, that sounds like inflexible processes. I feel like this implies that the plan that you do have is a plan that allows for change and response to change.
[0:15:10.7] MN: Yeah, with the first three, you can definitely have a much better sense of being able to respond to change, right? Because with response to the change you can collaborate with the customer to figure out what is the best possible solution and work with other individuals via interactions that will end up with some working software that works, right? Because that is the most important thing.
[0:15:34.2] SC: Do you think that this maybe ties into how the Agile process is different from Waterfall for instance? Because Waterfall, in Waterfall you have these stages, right? You go from stage to stage, you complete the stage and then you go to the next but then you never return.
[0:15:53.7] DA: Well, in theory you never return but in practice, you do find yourself learning new things as you’re building and writing software. You then return to question the requirements like the fundamental assumptions that were made there and question the design and other stages that were coming beforehand and so I think it forces you to confront that fact. There is the diagram of Waterfall. It’s like, “Wow, the water never goes back up the fall” but it’s like, “Wait.”
[0:16:26.7] SC: That’s gravity.
[0:16:27.6] DA: Yeah, it’s like we are not on planet earth. We are out in space.
[0:16:36.3] MN: Is there like a fish that swims or jumps against the thing and then goes – that’s what I was thinking. You have like a –
[0:16:42.9] DA: Yeah, there are salmon cannons here. We are shooting salmons straight into space.
[0:16:49.2] MN: You know, sometimes you’ve got a verification in testing and it’s like, “No, we need to do the redesign.” You wiggle your way up the waterfall and start the design again and make it happen. If you pay for the Patreon, that doesn’t exist. Yeah, you will see me actually wiggling on the chair to go up the waterfall. It’s not pleasant but –
[0:17:08.2] DA: Amazing, it’s the Yo Bobby head on a fish.
[0:17:11.4] MN: Exactly, just wiggling my face.
[0:17:13.9] DA: Shooting out of this, holding hand. Yeah, I mean maybe it’s not even planet earth. Maybe it’s a ruckus. It’s dim.
[0:17:22.5] MN: I think the structure of that Waterfall is very, very rigid as you know, in seeing in a diagram where Agile is definitely more fluid and even that last one where you respond to change. If there was a change that has been called out in any part of Waterfall, it’s like, “Well, we’re still going down this ride” like you can’t get off at this point. You got to make it happen and then just go and Agile kind of makes you – it allows you to loop back, take an elevator in this waterfall to go up and then give it a go and then go down again.
[0:17:55.5] SC: Right. To bring in a metaphor, I suppose you were walking down this path and the path gets you from A to B, so the plan is walk down this path from point A to point B but then you start walking down the path and all of a sudden you realize your path is obstructed. Perhaps there is no path, maybe a tree has fallen in the way. Maybe there is a wall, maybe there is a huge cliff or a valley and you cannot pass. If you are following the plan rigidly then I guess you fall into the pit.
[0:18:27.1] DA: Yeah, that’s lemmings right there. That’s a classic 2D game.
[0:18:33.3] MN: Oh man, you just fall right in.
[0:18:36.3] SC: Yeah.
[0:18:37.1] MN: Oh my god, yeah, this sounds about right and what would the Agilist do?
[0:18:40.9] SC: The Agilist would build a bridge or go around.
[0:18:45.3] MN: Or Agilist might even question like, “Wait, why are we trying to get over here?”
[0:18:50.3] SC: Well, that’s true.
[0:18:51.1] RL: Why is the chicken crossing the road?
[0:18:53.2] SC: Why do we need to go to point B?
[0:18:55.2] DA: Yeah, there is corn over here guys like come on.
[0:18:58.4] SC: Exactly, yeah.
[0:19:01.4] MN: If you visit the agilemanifesto.org. First off, great, great website. Definitely made with just HTML because all you needed – you don’t need a JavaScript framework at the time that this was created. You just needed some HTML, write some P tags and BR tags.
[0:19:19.4] DA: Yo, I want to rebuild this using React.
[0:19:23.8] SC: Oh, I do.
[0:19:24.8] DA: Yeah, I’m going to do it. Let’s do it.
[0:19:28.5] MN: At the very top, I will read the Manifesto for Agile Software Development and it goes like this:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.”
There you go, thank you. That’s not mine. That belongs and was created by 17, it says, white males a very, very long time ago.
[0:20:24.8] DA: Oh yeah but it is really like the movement of what came before and after. There is a lot of unsung people and I think there is a lot of other signatories, so I think around William Jeffries is on here somewhere.
[0:20:38.0] MN: Yeah, Ron Jeffries.
[0:20:39.7] DA: Ron Jeffries.
[0:20:41.0] MN: Yeah and I think I definitely want to talk more about what these 17 individuals do, I think it’s important. I mean, we could go over a list and just read some biographies. I remember looking it over and thought, “Wow, that’s pretty amazing and that guy is a part of the creation of this process” which is really cool. Feel free to hear that episode coming soon and with that, keep on Agile-ing if that’s the word. Keep on being Agile.
[END OF INTERVIEW]
[0:21:08.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
