Doing Business in Real Time
The global economy has a life of its own, it lives in real-time, and we are all part of it. Hello brave new world.
How does your company measure value in the systems it produces? Most companies measure value by the degree to which a system meets the traditional “iron triangle” of Scope, Schedule and Cost. System scope is defined by the functionality needed in a system which then determines the development schedule and the cost of the system. In a presentation at the Agile 2010 Conference, Jim Highsmith (a director at the Cutter Consortium) proposed a new way to look at system value. He suggested that value should instead be determined by system quality (meaning a reliable and adaptable system that can meet changing company needs over time).
This sounds fine but there is a radical notion inherent in this idea. It starts with the fact that value depends on quality and quality is degraded when people are pressured to deliver lots of functionality called for in the system scope while still adhering to the planned schedule and cost for the system. So what can be done? Here’s the radical notion. A study from a few years ago found that 64% of functions built into systems are rarely used (Standish Group study presented in 2002 by their CEO Jim Johnson). So maybe the best way to increase value is to decrease scope. Maybe we should change the old saying of “do more with less” to simply “do less”.
[ I do lively presentations on this and related topics - mhugos@yahoo.com ]
Technical Debt is the Enemy of Value
People are often under pressure to deliver a lot of system functionality in a short period of time so we turn out code that is not of good quality. It has bugs, it isn't well written and it isn’t well tested, but it is done to meet tight development schedules. Systems coded in a hurry may be delivered on time, but they incur a cost in the form of “technical debt”. In other words, the code is low quality and over time it becomes more and more unstable and this makes it less and less valuable.
If you don’t go back and pay down that technical debt by cleaning up the code (agilists call this “refactoring”) the system becomes progressively more unreliable. In application systems with high technical debt estimating time and cost for new enhancements becomes nearly impossible because there is so much instability in the code it’s hard to know what will happen when you add new features. So over time the value of the system degrades. It can no longer evolve to meet new business needs.
If companies build less functionality into their systems they can spend more time making sure that the quality of what they do is high. This way they can prevent the build up of technical debt that lowers the quality of software and reduces the value of systems. If companies focus on quality by building less functionality and taking time to do what they do with higher quality they will get more value in the form of sustainable systems that can continue to be enhanced over time as their needs evolve. (You could say agility means simple things done well, not complex things done fast.)
A Real World Example from The Gap
Pat Reed, (an IT director at The Gap) told how she implemented Jim’s ideas in her company. She made the point that system functions that do not get used or are only rarely used are not just of marginal value; they are of NO value; they are outright waste. Unused system functions are like excess inventory.