Agile Without a Name

Getting work done

There’s been much discussion and debate in various forums about the evolving use of the word “agile” to describe software development. Some people involved in the discussion have suggested creating a new term to replace “agile”. In most cases, I don’t support replacing terminology. However, the term “agile” seems to have suffered so much semantic diffusion that it’s practically meaningless.

Speaking for myself, I am interested in the effectiveness of my software development activities, where “effective” must be evaluated in a specific context. In Effective Software Development (ESD), I want to have a wide range of resources (practices, tools, resources) available to me and I want to understand the tradeoffs associated with using these resources in various contexts. I’m not interested in labeling myself or my team as an “XP Team” or a “Scrum Team”. Who cares about the label if the team or organization is not effective.

I’ve seen several ESD teams who have used practices similar to the established named agile methodologies. However, they typically used a hybrid of those sets of practices. They couldn’t be labeled as Scrum or XP or Crystal or whatever. Their process was agile — but without a name. And they were effective.

I recommend not worrying about whether your team or organization deserves the fashionable “agile” label. The important question is “are you effective?”. Ask yourself what “effectiveness” means in your organization and then evaluate if your team meets that criteria. This isn’t an optimization problem. If you are effective enough, then focus on delivering value. If not, study the development options available to you and decide which ones will help you and your team be more effective. You might decide on a “ready-to-go” combination of practices like XP or you could experiment with a combination of techniques that are a custom fit for your team. Evaluate the results and adjust as necessary until you become an ESD team.