I always wondered what authors meant when they said they sat down to write one thing and ended up writing something else completely different; or that they sat down with one motivation for their protagonist, and halfway through had to change the entire premise because they realized their protagonist’s motivation was different than they thought it was.
‘Wondered’ here is in past tense because as of yesterday, I no longer wonder. It happened to me. I sat down to write an email titled ‘what I mean when I use the term agile’, and got halfway through it and realized I was writing a completely different email entirely. So here’s the email you were originally supposed to get when I wrote the “agile is not a process” email. (Authors note: For the folks viewing this on my blog, this paragraph may seem out of place; Every so often I post things from my email list here, and this just happened to make it. To be sure you get these sorts of things when they’re published and not potentially weeks after, if at all, subscribe to my email list in the box below).
I want to start out by saying that despite my experience and belief showing that we’re entering a post-agile world, that unlike some folks, I do have a concrete set of things I mean when I use the term ‘agile’. This may not agree with your definition (if that’s the case hit the reply button and let me know what your definition is), but it’s a definition, and if we’re going to have any sort of coherent conversation on the merits of agile for software development, we’ve got to start somewhere. This is that somewhere.
Agile is a contrast to waterfall-based development; in that waterfall treated software development like construction or other hard engineering applications with the following discrete and sequential phases: Requirements, Planning, Design, Development, Testing, Maintenance. Once you went to a new phase, you didn’t go back to the previous phase. Waterfall projects are typically defined with lots of ‘gates’ and documentation, and do not handle any change in requirements well at all. They’re expensive when they work, and even more expensive when they go off the rails, and since Software Development is still in its infancy as a discipline, they go off the rails quite a bit.
Agile instead defines software development as an iterative process, where those phases may happen dozens of times during a project’s planning and launch; and even more so, jettisons the idea of extensive documentation with embedding the customer into the team, and working with the business people in a collaborative fashion, instead of through these well-specified hierarchical channels. If you can produce working software quickly, you have less need of extensive documentation — since the documentation was there to describe how it worked.
Another principle of agility is the idea that since requirements change quite unpredictably, the software team should expect that and operate with flexibility towards that outcome. To that end requirements (according to some agile processes) can change every planning cycle.
So to distill the meaning of agile down to something that can fit on a postcard:
Agile is a philosophy of software development where software is released frequently and iteratively, based on the requirements needed in that moment, with the business and development team collaborating and involving input from the customer during the development process.