I’ve mentioned probably about a hundred times that I have recently joined ThoughtWorks. What I haven’t done is discuss what ThoughtWorks, as a company, actually does.
So, the company is one of the driving forces for agile software development in the industry. We* provide consulting and training to organizations that want to adopt agile practices, and we also develop (“deliver”) software to organizations using an agile approach. (There is also ThoughtWorks Studios, a division of the company which develops products for agile development.)
What the heck is agile development?
I’m glad you asked!
The “traditional” way of developing software involves a lot of planning: establishing clearly defined requirements, drafting feature and technical specifications, designing test cases, prioritizing features, etc.—in this way, a traditional software development methodology such as RUP is highly focused on predicting the challenges and needs of a software project.
The “agile” way of developing software is in many ways a response to the faults of traditional processes that leaders within the software industry have observed over the past several decades. Agile development represents a fundamentally different approach to handling change within a software project: whereas a traditional approach attempts to prevent costly changes by anticipating requirements, an agile approach strives to minimize the negative impacts of changes by adapting quickly.
The fact that agile software development typically involves less up-front planning than traditional development has resulted in a lot of misinformation out there about what it means to be agile. Some detractors think of the term “agile” as meaning “unstructured”, “disorganized”, or even “risky”:
A better way of understanding what it means to be agile is this: agile is all about adapting to change. As I said, traditional practices tend to try and plan an entire software project from beginning to end. In this scenario, change is very expensive because, with so much effort invested in planning, every little change requires additional effort towards adjusting schedules, budgets, requirements, etc. The agile philosophy is that change is inevitable, and so rather than fight against it, it makes more sense to actually expect it (and adapt to it).
So you might think of “traditional” as representing a more predictive approach to software, and “agile” as representing a more adaptive approach.
Now here’s the crucial part about what I just said: when you expect something to happen, it doesn’t make much sense to plan for it not to happen.
That might sound a little too… obvious (or even tautological). Let me put it differently, using an analogy.
Let’s say I go to the horse races. I’ve done a lot of research, and according to what I’ve learned, I strongly suspect that Seabiscuit is going to win. This actually isn’t much of a leap of faith on my part; Seabiscuit nearly always wins. So it just makes sense for me to assume, or anyway, to guess, that Seabiscuit will win again. And yet, when it comes time to place my money on a horse, suppose I put it on War Admiral instead.
This doesn’t make sense, right? I expect one thing to happen, and yet I act as if something else is going to happen.
It doesn’t make sense, and yet this is what traditional development is. Honestly, these days nobody honestly expects that changes won’t happen. They will happen, and they are generally anticipated with fear, because developers know just how much additional work they can cause. Agile development is about saying, “Hey, wait a minute, why are we building up these huge specifications and making these great big plans when we know it’s going to hurt like crazy when (not if, when) they change?”
To put it another way: agile development is about not spending $1,000,000 on a house where you know (or are relatively sure) an earthquake is going to hit and obliterate it sometime in the next few months.
I was just thinking about all this today during a team meeting with some of my classmates from school. We were working on an assignment consisting of roughly four parts, and repeatedly the conversation kept coming back to the “big picture”: how we were going to structure the assignment overall. There would be a lot of back-and-forth on areas that were subjective, unclear, or complex. There was much speculation and discussion of the unknowable (e.g., what would have happened if the plan had been X).
That is, there was a lot of mental gear-turning that was premature because the ideas being explored were not yet fully in focus.
This is exactly what the agile approach is meant to avoid: wasting effort. After all, this is why change is so expensive in the first place: it undoes much of the work that has been done. If that work hadn’t been done in the first place, change wouldn’t seem so scary.
And so at this meeting, as we were going on and on in our conversation about this or that future aspect of our project, we eventually arrived at a simple realization: Why don’t we take an agile approach to this? Rather than plan the entire thing from start to finish, we can just get started on the parts we know about now, and as we move forward a clearer picture of those parts we don’t know as much about should start to form, making it easier for us to work out decisions in those areas when we come to them.
After this realization, I think the bigger realization came to me (well, came to me again—I have actually thought about this before, but it seems every now and then I’m reminded of it): an “agile methodology” is not just a software development methodology. It is really just a way of approaching any problem: by expecting change, and planning to adapt to it, rather than planning for one fixed set of circumstances and praying those circumstances don’t change.
*It feels a bit weird to say “we” to refer to a company I’ve just joined, but… gotta start some time, right?