Agile Manifesto

So right around 2006, I had this opportunity to work for the Secretary of State's office in Denver, Colorado, and I was working on the statewide voter registration system, a very large waterfall, traditional approach project. And we were months into the analysis phase, gathering user requirements. And I remember being in this large conference room. We take a break and I walked down the hallway and there was a smaller conference room off to the side. Group of developers were in there and posted on the door to that conference room was the Agile Manifesto. And I remember reading it and thinking to myself, this is better. Look, I want to do stuff this way. It resonated with me in such a big way that it literally changed my career path. I haven't worked on a waterfall project since then, and I'm just convinced that that is not the way to build software solutions that we need to use agile practices. So what is this thing, this Agile manifesto? Well, in 2001, a group of software developers got together who were. They were tired of traditional waterfall project software projects. Again, traditional being. We're going to have a very large analysis phase. We're going to gather all the requirements and write them down. We're going to ask people to think about things they've never thought of. How you might use a system that may or may not exist. Maybe you're unhappy with your current system. We do a fit gap analysis, write it all down, and then we would design it. So that's analysis, design it. So then architects show up and sort of design the system. Nobody's built any software. We've just built documents, we've designed it. We get really good drawings and diagrams of things that don't exist. They're just drawings. And then it gets to the software development team. That could be like six months. Software developers get all these requirements and they just start coding. They just start coding to requirement783, just write it up. And that would take months, months and months and months before we hand it to testing. And so you could be like a year into a project and no one's tested anything, which just seems like madness. And then, so then the testers test the software and they're late because you've got a committed date, you know, two years in advance, and testing gets squished out and squished out. They're running out of time. And so you shortcut all your testing. Now when you go to deploy, because you've never deployed before into production, which again seems crazy to not deploy to production for extended periods of time, you're deployed to production and nothing Works, you can't get it deployed, you've got race conditions, the database is locked up, problems, Right? And those of you that have been on these projects are nodding your head with me right now, going, yes, I've been there. There's got to be a better way. Well, these software developers were convinced there is a better way and so they wrote these, the Agile Manifesto. Now, before we dive into that, just some things to keep in mind is the very beginning says we're uncovering better ways of building software by doing it and helping others do it. And man, that's true today. Like, we're getting better at this by doing it and helping others do it. And so we're going to be better at this tomorrow. And that's why this document is so, you know, critical to us understanding and thinking about today. So what are they? Well, the first one starts off with, with individuals and interactions over processes and tools. Are there processes and tools? Sure. In fact, we're going to teach you some processes, but they're not as important as individuals and interactions. And the second one, working software over comprehensive documentation. Now, is there documentation? Absolutely, yeah, sorry, developers, you're going to have some documentation, but wouldn't you rather have the software than a requirements document? Of course, we prefer working software over comprehensive documentation. And the next one is customer collaboration over contract negotiation. Are contracts important? Absolutely. Contracts are very important. But wouldn't you rather collaborate with a customer than ask them to refer to page 17 of the contract? We just prefer customer collaboration. We can get faster at that. And then finally, we value responding to change over following a plan. In Agile, there's plenty of planning, but we don't just follow a plan because it was written and that's exactly what it says to do. You know, the old sort of, you know, plan the work, work the plan. That only makes sense if you can predict the future. And since we can't, that sort of approach doesn't work to software development. The most dynamic, complex thing we're working on, that whole construct doesn't work. Instead, you have to have adaptive planning and plan all the time and be ready to pivot and change and respond to change. And then it concludes with by saying that is we value the first part of the statement more than we value the second part. It's not that there's no value in the second part, there's value. It's just that we value the things on the left or the first part of the statement more. Look, we're not choosing between good and evil. If we were to be easy. We're choosing between good and like Gooderer.