Due to overwhelming demand, I am finally starting my own blog. Or, more accurately, a number of people lately have been complaining about me using the comments section of their blogs to write my own blog.
Jeremy Miller also makes a good point about blogging for Software Developers, so here I am.
Whenever I'm giving a technical interview, I almost always ask candidate the question "What does Agile mean to you?" I also point out that if you ask this question to ten different people, you'll probably get ten different answers. I find that this question often tells me a great deal about a person's experience with and understanding of Agile, which is why I ask it. Anyway, to start off my blog, I'm going to give you my answer (Note to interview candidates: If I ask you this, you will not get bonus points for reciting my answer back to me).
To me, Agile is not a process and it's not even really an SDLC; it's an idea. It's a way of thinking about software development, and from this, several processes have come into existence that are built around the idea of Agile such as Scrum, XP, etc. The idea behind Agile starts from the fact that Waterfall (the traditional approach) tends to fail because it is very poor at handling change throughout the project's lifetime and that implementing changes tends to increase the amount of time and work exponentially as the project ages. Agile was designed to take into account that change is inevitable in software, so doing extra work that would need to be re-done when something changes is pointless.
Another idea behind Agile is that non-working software has no value to the company making it. If you can't sell it, people won't use it and you can't make any money from it. Agile addresses this by focusing on delivering working software as rapidly as possible. Ok, so maybe we didn't implement every last little feature, no, but basically we wrote the software. What we write over each iteration, indeed the reason for short iterations, is that we can deliver something that works and has at least some value right away. If the project ends abruptly, hits a deadline, whatever, we may have something that's functional enough to start delivering value to the company and that people may want to use. We can also get rapid feedback on how well the software works.
In contrast, Waterfall is all-or-nothing. You start designing, then you code, then you test, then you release. You get no value until you release, which isn't until the very end. If you fail to get to the very end for any reason, you have nothing that works and therefore a useless block of writing that is your code base and a big pile of money that is no longer yours.
As an aside, I believe that part of the reason that Waterfall fails and Agile succeeds also revolves around why software is hard to write (i.e "Why can't we build software like we build bridges?"). I have an answer to this, but I'll save it for another blog.
Anyway, in order to realize the benefits of Agile, a few basic principles have been thought up that allows these things to occur. They are mostly outlined in the
Agile Manifesto (which I highly suggest you read). I am going to attempt to give you an overview of my interpretation of these principles.
We always want working software, so the best metric to measure project by is working software. Lines of code or partial requirement satisfaction is meaningless if those things don't provide something that someone can use.
We favor interacting with people because people are the ones who use the software and whose ideas the software is supposed to implement. You can't ask a document questions. A spec can only say so much. A feature like "User can save their data" means something entirely different to a customer and a developer. Dialog helps to clarify what is needed because by asking questions of each other, people can come to a better understanding of what the customer wants, which is all that really matters anyway (more on that in a later post).
We also favor responsiveness to change because software is all about change. We start to understand the business domain more and more as we work on a product for it. As we understand the business domain better, we start to realize that we made mistakes in implementation (communication helps with this also) so we have to make changes. We also understand that when the customer actually sees the software, sometimes they can say "no, I didn't actually want it to work like that" and we have to rebuild it. This is why we only work on a small chunk of the project at a time and show it to the customer frequently. The more time that elapses between the introduction of a bug and the discovery of it, the harder it is to fix and the more code that might be dependent on the buggy code.
We like to have rapid feedback. We do continuous integration in order to get feedback about if the software works as rapidly as possible. If something breaks, we can fix it right away before it has a chance to corrupt anything else. If someone's code fails to integrate, we can fix it right away because we know about it and it's still easy to fix. If we wait, it becomes harder to fix and harder to integrate.
We are mindful of the whole of the application as we build it, so we know when we must make a decision on when to implement something. We don't build things that we don't know about now. If we build something that we're going to use in the future, it's possible that the requirements will change before the future arrives. We do build things so that we can incorporate new functionality into our code later, but we are using those things now; we'll expand on them later. We build things so that we can change them as the need for change arises, because we know that change is inevitable.
We don't focus on process, but we evaluate our own process continuously. We recognize that our process can always improve and we always find better ways to do what we do. Improving our own process is simply another way of responding to change, and we know that change will always happen.
We also don't ignore things like documentation, process, and tools. They have their place. We know their place. However, when given a choice, we tend to prefer talking to each other and writing working code. We write as much documentation and use whatever tools we need but we realize that these tools exist only to make us more productive in what we already do, not to ensure the success of our project. We do not use OR/M as a crutch because we don't know how to persist our data. We do not use IoC containers because we don't know how to resolve our own dependencies. We do not use a Continuous Integration because we don't know how to keep track of our builds and integrate our software. We use these tools because we know that they make it easier for us to focus on building software. We also use them because we have had to do these things manually before and while we understand how to do them, we recognize that tools can save us time by doing for us what we would otherwise do exactly the same way.
Now, a number of people have created a number of tools, ideas, and methods that help facilitate these things. Processes like Scrum and eXtreme Programming are ways to realize the benefits of Agile, but just because you do them, you are not Agile. There are coding principles such as inversion of control, the single responsibility principle, don't repeat yourself, test driven development, etc, but you aren't being Agile by just blindly following them. You can write enough stories to consume three acres of rainforest's worth of note cards every hour, but that won't make you Agile either. You can have iterations and not be Agile. You can write unit tests and not be Agile. You can do anything you can think of and still not be Agile, because Agile isn't about what you do.
In order to truly BE Agile, you must embrace that Agile is just an idea. It is a way of thinking about development that will help you to deliver a successful software project. There are many interpretations of what exactly that means and many processes that can help you in implementing the idea of being Agile. Ultimately, as long as you are realizing the benefits of being responsive to change and delivering working software that has business value, you are Agile, no matter what you're doing.
