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.
As an Agile coach I am in the Agile transformation business. Coaches are rarely employed when an organization “gets” the philosophy and properly implements an Agile framework or methodology. In my experience those that are most challenged are those who seem to concentrate on the ceremonies while failing to focus on the bigger picture concerns – those more interested in “doing” rather than “being.”
The interesting thing about big upfront design is the gall it takes to even begin to believe that all can be known at the beginning of a complex endeavor. This harkens back to some of my earlier posts, including Software Development is Communication, where I argue that those in charge of software development decisions (like team size, composition, physical location, etc.) have no clue about software development. Software development is most often a complex undertaking.
We all have customers. If we didn’t there would be no reason to do what we do. If we didn’t their would be no one to pay our invoices. And when someone agrees to pay you for work, they generally want to have some kind of agreement on the nature of the work for the money that is being paid. This agreement is usually put in writing and voila, we have a contract. This is an important part of the process and as everyone knows, contracts are valuable documents for both the customer and yourself. But as the Manifesto states, it’s important to not get caught up in negotiation fever.
Of the four agile values, this is probably the least understood and most often misinterpreted. It certainly does not say that there should be no documentation as some (the less ambitious developers and teams) propose. It says that there is more value to actual software than comprehensive documentation.
The Agile Manifesto is best seen as a reaction to the environment at the time. Many authors are saying that software development values have gotten out of whack because the majority of companies now value processes and tools more than individuals and interactions. Obviously in order to create better software this needs to be corrected!
I am pleased to announce that my first book, Understanding the Agile Manifesto: A Brief & Bold Guide to Agile is now available as a podcast. Over the next few days / weeks I will be releasing the book, chapter by chapter, on this website and through the iTunes store under my “Agile Doctor” podcast.