The Spirit of Agility

So what is agility, exactly, and where did this whole agile software development movement come from?

In February 2001, seventeen interested persons (including Andy) got together in Snowbird, Utah, to discuss an emerging trend of what was loosely being called lightweight processes.

We had all seen projects fail because of ponderous, artifact-heavy, and results-light processes. It seemed like there should be a better way to look at methodology—a way to focus on the important stuff and de-emphasize the less important stuff that seemed to take up a lot of valuable time with little benefit.

These seventeen folks coined the term agile and published the Agile Manifesto to describe a refocused approach to software development: an approach that emphasizes people, collaboration, responsiveness, and working software (see the sidebar here for the introduction to the manifesto).

The agile approach combines responsive, collaborative people with a focus on demonstrable, concrete goals (software that actually works). That’s the spirit of agility. The practical emphasis of development shifts from a plan-based approach, where key events happen in individual, separate episodes, to a more natural, continuous style.

It’s assumed that everyone on the team (and working with the team) are professionals who want a positive outcome from the project. They may not necessarily be experienced professionals yet, but they possess a professional attitude—everyone wants to do the best job they can.

If you have problems with absenteeism, slackers, or outright saboteurs, this is probably not the approach for you. You’ll need something more heavy-handed, slower, and less productive. Otherwise, you can begin developing in the agile style.

That means you don’t leave testing to the end of the project. You don’t leave integration to the end of the month or stop gathering requirements and feedback as you begin to code.

Instead, you continue to perform all these activities throughout the life cycle of the project. In fact, since software is never really “done” as long as people continue to use it, it’s arguable that these aren’t even projects anymore. Development is continuous. Feedback is continuous. You don’t have to wait for months to find out that something is wrong: you find out quickly, while it’s still relatively easy to fix. And you fix it, right then and there.

That’s what it’s all about.

This idea of continuous, ongoing development is pervasive in agile methods. It includes the development life cycle itself but also technology skills learning, requirements gathering, product deployment, user training, and everything else. It encompasses all activities, at all levels.

Why? Because developing software is such a complex activity, anything substantive that you leave until later won’t happen, won’t happen well, or will grow worse and fester until it becomes unmanageable. A certain kind of friction increases, and things get harder to fix and harder to change. As with any friction, the only way to fight it effectively is to continually inject a little energy into the system (see “Software Entropy” in The Pragmatic Programmer: From Journeyman to Master [HT00]).

Some people raise the concern that agile development is just crisis management in disguise. It’s not. Crisis management occurs when problems are left to fester until they become so large that you have to drop everything else you’re doing to respond to the crisis immediately. This causes secondary crises, so now you have a vicious cycle of never-ending crisis and panic. That’s precisely what you want to avoid.

Instead, you want to tackle small problems while they are still small, explore the unknown before you invest too much in it, and be prepared to admit you got it all wrong as soon as you discover the truth. You need to retool your thinking, your coding practices, and your teamwork. It’s not hard to do, but it might feel different at first.