What is Agility?

I’m asking the question specifically in the context of software development although it’s useful to consider the meaning of the word in common usage. The dictionary definition of agile is “characterized by quickness, lightness, and ease of movement; nimble” and doesn’t include an important aspect: quality. A quality result achieves the goal of the action producing the result.

A knee-jerk reaction could be thought of a very quick action that has no goal. Therefore it wouldn’t be especially agile. A very fast reaction that doesn’t achieve it’s goals would likewise not be agile. The word thrashing might be more appropriate for that situation.

Given this expanded definition, it’s easier to understand why some people associate agility with so-called lightweight methodologies. A lightweight software development methodology is often described as one with relatively few required practices or other constraints. I’d expect that, generally speaking, a methodology with fewer constraints would be more agile than one with numerous constraints. This would be especially true if the extra constraints didn’t help or possibly even hindered achieving the goals of the development activities.

Agile practices and methodologies tend to focus on the least amount of constraint while maximizing satisfaction of the development goals, which is usually related to providing business value. A team that quickly responds to problems but does so ineffectively through lack of tests or communication may be fast, but they aren’t agile.

Several days after writing this, Kent Beck shared the following thoughts on the XP mailing list.

I agree that it is not sensible to compare the agility of XP with the agility of Crystal. You can, however, compare the agility of two teams–how quickly and thoroughly can the teams take advantage of surprising opportunities? The teams’ practices, as well as the people involved, will influence their agility. If they can make changes with confidence, if they are practiced at evolving their architecture, if they trust each other, then their chances of realizing opportunities increase. ~ Kent Beck (March 17, 2005)

This perspective is similar to what I wrote earlier. Agility is a function of both practices and the team implementing those practices. Since we don’t currently have any way to analyze a team and determine the best practices for that team, the best approach may be to start with one of the established set of practices, observe the results, and be prepared to adjust the team’s practices accordingly. These adjustments may result in a set of practices for a specific team and situation that don’t clearly match the definition of any of the existing agile methodologies.

Add a Comment

Your email address will not be published. Required fields are marked *