Evaluating Agility

The most agile teams we know of are consistently delivering the highest business value the fastest, and over the longest period. The most agile teams do seem to be the most efficient. But agility is not easy. While built on a set of very simple concepts, agility represents a fundamentally different way of doing business. High levels of agility require a substantial commitment to education and training, new tools and techniques, patient transition, and cultural change. This commitment must flow from management downward, and from the team upward.

Such change is not for everybody. Organizations that don't promote and value open communication, trust, and teamwork may not provide the most fertile ground for agility to succeed. This does not mean that agile cannot work for such organizations. Agility is a spectrum. Some teams are more agile than others, which are in turn more agile than yet others. It may be well worthwhile for your team to start with modest increases in agility, and to gradually seek a most comfortable and workable spot on the agile spectrum.

Ultimately each organization is responsible to itself for its agility. With any process or methodology implementation, practices will need to be adapted and localized. The key is not the specific practices, but the mindset and manner in which they are applied. In Ron Jeffries' words, "The practices are not agility. They are a way to find agility."

Although by no means scientific, as a test of your agility, try rating your team from 1 to 5 on the following 10 agility factors, with 5 being the most agile (note: everyone gets a 1 for each criterion just for showing up to take the test). Virtually no organization will line up straight down the right of the diagram, but the best ones will continue to push themselves further and further as opportunities arise.

Click on test for full sized version

You might not be agile if...

On the other hand, you also might not be agile if…

• The 'Send/Receive' and 'Save As' buttons initiate most team communication
• Your white boards are mostly white
• "Test-driven" still refers to your car
• You don't yet know what PHB stands for (hint)
• You know what CPM stands for, and continue to rely upon it
• You spend more time trying to manage project dependencies than remove them
• Someone still believes the Can't Chart (oops, that's Gantt Chart)
• Developers only develop, testers only test, and managers just manage
• Simplicity is presumed to be simple, and
• A Change Control Board meets...ever