Value Over Productivity
The first listed principle at agilemanifesto.org lists customer satisfaction via delivery of valuable software as the highest priority.
Some people interpret this to mean the more software that gets delivered the better. They even point to short iterations which include deliverable’s as a manifestation of that. More rapid delivery can even be a selling point to launch an Agile transition. Thing is, the goal isn’t more software, it’s valuable software.
Everybody that has worked in software development for any length of time has heard of “Feature Creep.” You don’t even need to be in software to understand the concept as it’s been around projects for a long time. While I can’t prove it, I wouldn’t be surprised to learn it has been around since before the pyramids were an active construction project. The basic notion is that as the project progresses more and more functionality is crammed into the product being delivered. This is something that generally pushes release back, drives up costs, and threatens quality. It can even result in lots of (potentially unpaid) overtime as people involved try to prevent it from affecting the schedule. This is “affectionately” known as a “Death March.”
The classic project management practice to deal with this is Change Management. The Project Manager intercepts incoming changes and routes them through some kind of acceptance criteria. This minimizes the shift from what was originally planned and helps to maintain the schedule and budget.
Approaching the same problem with an Agile mindset results in a very different environment. The final deliverable will have the minimum responsible amount of definition to being with. Changes to the final product will be welcome as the project progresses. The schedule will not have to be affected as any changes will be agreed upon by the people doing the work and the people wanting the product through regular communication. Ideally there will be some useful form of the final product available starting early on which improves over the life of the project.
Where we really see a difference here is that the classic approach provides all of the original product vision as well as the approved changes over time. It provides more functionality. This isn’t necessarily a good thing. Many people are familiar with the 2002 Standish Group Study stating that 45% of all developer features are not used. (Some info on it if you aren’t.) The Agile approach trims things that are discovered to be less important than new things as the project goes on. The end result has less functionality due to avoiding the death march, but the functionality included should have a higher utilization.
This is something we should be taking to our management. Increasing productivity is a neat idea but it is likely a red herring in most knowledge work. A better idea is to increase the value produced. In some cases this might be a volume question. If your target market wants a lot of trashy novels, then more value is found by increasing volume. If your target market wants a single definitive guide to writing unit tests then more volume isn’t the way to go, better information in a single volume is.
It’s the same for software. Giving the accounting department tons of bells and whistles in their new account management software is nice, but if they are only going to use the core set of account payable/receivable functions and not touch the rest you have failed in value delivery. You could have given them the core functionality when it was done instead of making them wait for all the bells and whistles. Instead of building those bells and whistles you could have refined the core functionality.
Next time you’re looking at what the end result of a project will be and how to get there take a moment to step back. Consider what the true value is and put some methods in place to deliver better value over time instead of spending all of your time trying to increase productivity.
