In 2002, Jim Johnson of the Standish Group (made famous by their Chaos Report of software project “success”) presented findings of features and functions used in a typical system. The number of features that were never or rarely used totaled a whopping 64% while sometimes, often and always weighed in with 16%, 13% and 7% respectively. For those acquainted with the Pareto principle (80/20 rule), notice how the often and always used features – those things we should concentrate on building for our customers and those things things that bring us the most value – is exactly 80%.

In other words, a great deal of our effort is generally spent creating things that customers do not use or want.

Metrics. Metrics. Metrics. We love numbers. We measure and put numbers to all kinds of things. We use these numbers to mark our projects as red, yellow and red (of course, the project is always green until there are a few weeks left when someone finally blinks and acknowledges reality and begins to use yellow or, god forbid, red).

Unfortunately, in our headlong rush to create metrics we tend to forget the why of what we are doing. Numbers and statuses become an end unto themselves.

While there are many people who believe that the key reason to adopt agile frameworks and methods is for increased productivity, I tend to find this to be more a healthy byproduct of a team working together over time (and thus could be found in other methodologies).

The real benefits of agile lies in greater transparency, predictability and faster time to market.

The third agile principle speaks directly to these, especially quicker time to market.

The world changes fast. The software development world changes faster.

Locking into a long term plan and remaining steadfast to that plan might bring comfort when the world around us is awash in change, but it doesn’t give the flexibility necessary to remain competitive.