The CHAOS reports from the Standish Group has become infamous, so much so that Sean Hanly made us promise to never quote the figures as evidence against the traditional models. However I recently found an interview that Deborah Hartmann at InfoQ did with the Standish Groups founder and chairman Jim Johnson. In the interview Deborah asks some really interesting questions and Jim’s answers seems straightforward and honest. The relatively fresh statistics presented is interesting, but most interesting of all is the list of success factors, where it is obvious that the Agile values and methods addresses most of the top 10 with concrete techniques.
PLM and ALM
On the behalf of my current customer I went to PLM Europe in Frankfurt on October 9-11, a UGS User conference. UGS is one of the major suppliers of software supporting product life-cycle management (actually meaning parts, articles, hardware). After visiting three days of presentations and workshops, some more marketing than workshops, some mediocre and some really inspiring, I found that many things being said was also applicable to software. But there are genuinely different properties in software and software based products which this branch of the engineering business has yet not understood. I also realized that replacing the first letter in the PLM acronym with an A gets you ALM, Application Life-cycle Management, which has created some whoa lately. I guess I’ll have to dive into that area also.
Development is Investment
One irritating circumstance in the world around development is the fact that customers and company managment tend to view the voyage of development as something that has to be calculated like any other investment. Or at least I thought it was irritating until last week.
This investment calculus that has to take place upfront drives big design upfront, detailed planning and everything bad that goes with a model with “upfront” in it.
But last week I had a discussion with my two collegues about how to draw a curve illustrating the fact that we need to get early payback from any development project or activities. I suppose you have all experienced the fact that given multiple checkpoints a long the way, as opposed to only a single at the end you are much more likely to hit the target (after all that is what being agile is all about).
We started talking about how to visualize the fact that worked hours (the most common tracking parameter for development projects in the world, it seems) is not a good way to measure, and consequently show in a follow-up diagram, project progress. Instead it is the value of the current development result that should be put on the y-axis. This is actually nothing new (what is?), already function points and earned value are classical methods to do something this.
But the real insight here is that if we just could turn this earned value (which in agile terms of course is working functions delivered) into money we would be in a position to argue all the benefits of agile thinking to management and into the contract problem area.
Why? Because to a company executive it is easy to understand that the value returned did not come from exactly what we planned but we could still cash in the same value. Dollars for dollars, as it where. This opens up a possibility to work agile in rigidly contracted environments also, if only we can formulate the contract in terms of investment and return on investment.
So how would we estimate progress in terms of ROI? Well, I guess that anyone that can guess the ROI on a completed product, given some essential functions and properties, could also do a fairly good job of estimating partial value of same. So, do an earned value estimate on each function (or story or UseCase according to your preferences), follow up on that, and handle any change in features also as a change in the earned values. Then trade one earned value for another and, if they are comfortable with the estimated values, they will have no objections to whatever changes your agile project uncovers or requires.
A Vaccum Cleaner and an Aircraft
What is the similarity between an aircraft and a vaccum cleaner? Often product developing companies get stuck in old thinking. No surprise there, but what I mean this time is their thinking about what is their primary competence and as a consequence of this, how they need to think about their product development.
Apart from the pure software products there is a large number of products being developed out there, which, some decades ago where hardware only, but now also includes software, often increasingly so.
Since the company has successfully developed products according to rules and conditions which are valid for a hardware only product, it is often difficult to make managers on all levels to understand that once you introduce software in a product, you are in a completely different ballpark.
Software has completely different characteristics, different minimal lead times, different complexity properties which must be taken into account when organising product development. This is is not only a difference, it is also a set of opportunities to exploit. One of the more obvious opportunities is the the short lead times possible, which, if done correctly, could mean shorter time to delivery, shipment and return on investment. This means, of course, becoming more agile, but it doesn’t stop with the development -Â project, product and company management must embrace the agile principles and change their thinking.
If you cross a vaccum cleaner with a computer you get a computer, and if you cross an aircraft with a computer you also get a computer!
One you introduce software in your product you are stuck with new values, characteristics and opportunities. Too many developing companies fail to exploit these opportunities for rapid return on investment and improved quality.