Recently, as I sat on the Northeast corridor train, the ticket-taker informed us that we would be delayed 15 minutes. As I thought about the impact on my day, a flutter of activity rippled through the cabin. Passengers called bosses, colleagues, wives and customers spreading the news. What was interesting was that the relayed news was different: some people doubled the time, others bumped it up to solid hour and, shockingly, no one made it shorter.
As a software project manager, I have had this reaction often. Whenever I received an estimate, I instinctively doubled it. However, as the product manager, I was in a position to drill down and get more insight into the origin of the estimate. Was it a WAG (Wild A** Guess) or was it thought out? What assumptions were used? What could I do to make it shorter? The estimate grew as I dug in, but so did the work. The conversation surfaced issues that needed to be discussed and brought clarity to the task at hand.
Now, as a regular passenger spending my money with NJ Transit, I felt compelled to “dig in” and see if I could help or understand the situation better. Was that estimate from the conductor or Penn Station? Why were we delayed? Is it a signal, power line or derailment? Any insight would help me determine the accuracy or credibility of the estimate, but that sort of interaction goes against social roles — and these days may even be a Federal offense!
In truth, I don’t want to be a railway project manager — but I do want transparency. And I believe that transparency is the primary source of stress in software development. How many times have you been under the gun trying to explain why certain features take longer than others? Or why a performance is so slow? Or why you are still looking for the cause of that bug — armed with nothing more than soundbites from your development team, when what you really needed was facts.
Getting On Track
Customer (internal and external) expectations are dragging development into greater and greater maturity. The great thing is that tools and processes are finally mature enough to support this industrialization of software engineering. Today’s processes are standardized, consistent and self-correcting, and tools are available that provide fact-based measurement and insight into these processes and the systems they develop.
The largest opportunity for improving quality and productivity during application development is in eliminating its largest sources of waste: defects and the rework they cause. In many organizations, 30% to 50% of the development effort is devoted to rework. These staggering numbers are driven by the fact that defects become 10 times more expensive to fix for each major phase of the software life cycle they slip past. Under these circumstances, quality largely determines productivity. However, by applying lean principles of static analysis to application development, companies can realize significant overall cost and risk reduction – 10% or more – most of which is based solely on waste elimination and driving desired behavior among AD teams.
Keeping application development on track comes down to finding the best visibility over your software, because, in the end, productivity without quality is a waste, quality without productivity is costly and optimal performance is achieved only when both quality and productivity are on the same track.