Archive for September 2009
Sign of the Times
As I learned the hard way, the post Technical Debt on Your Balance Sheet missed an important risk associated with technical debt.
I got an email today advising me as follows:
Debt Con Expert is now following you on Twitter!
The good services provided by Debt Con Expert are debt consolidation loans, help with bad credit situations, how to tips on filing bankruptcy, etc. As I do not owe a penny to anyone in this solar system, I am inclined to conclude I am being followed as a result of yesterday’s post on technical debt.
Please be prudent with technical debt. In addition to elevating the error feedback ratio of your software to an unacceptable level, it might also lead to your mail box being flooded with debt consolidation offers.
Sigh.
Technical Debt on Your Balance Sheet
Colleague Jonathon Golden introduced me to a new plug in to Sonar. The plug in calculates the cost to fix the technical debt accrued in a product. For example, you might find an accrued technical debt amounting to $1M in a 500KLOC application. Obviously, you will need to spend $2 per each line of code to “pay back” your debt.
The expression of technical debt in monetary terms is intriguing. Unlike financial debt, there is no credit limit on technical debt. Hence, unless a team is proficient at refactoring on an ongoing basis, technical debt tends to grow over time as the underlying software decays. Beyond a certain level of debt, no good option is available. The code decayed to the point in which fixing anything in a hazardous proposition – every fix is likely to break something else. Under such circumstances, most/all of the development team gets sucked into maintaining the software instead of developing new features and functions.
Monetizing technical debt can have two far reaching implications, as follows:
- A credit limit on technical debt can be established. For example, when the technical debt reaches a certain level (say 25 cents per line of code), new functionality is put on hold. The team applies itself to aggressive refactoring to reduce the debt to an acceptable level.
- For companies who capitalize software, technical debt could become a line item on the balance sheet. It will simply be listed as a liability.
From a customer perspective, the monetized technical debt on the balance sheet of a software vendor is a proxy for the technical risk involved in licensing software from this vendor. Such monetization could be easily extended to report technical debt per product family. With such reporting in place, the technical risk associated with licensing a specific product can be assessed.
Software vendors might frown at the requirement to monetize technical debt. I would contend that such a reporting requirement is absolutely consistent with the spirit of the Agile Manifesto:
Customer collaboration over contract negotiations
In other words, if you are reluctant to list your monetized technical debt you can’t really claim you practice Agile.
Don’t Take Your Boss to Lunch
During my Agile 2006 presentation I made the following recommendation to the audience:
Don’t take your boss to lunch; take him/her to the daily stand-up meeting.
The point I was trying to get across is straightforward: there is no substitute to “touching” Agile and being touched by Agile. Instead of preaching the benefits of Agile, get your executive engaged in the Agile process.
Last week, colleagues Ken Collier, Jonathon Golden and I were on a Cutter Consortium consulting engagement. The CEO of the company we were consulting to immersed himseld in the workshop. I would say he spent about 50% of his time in the three day workshop in which we worked with his team on Agile and refactoring.
This CEO certainly got it [Agile]. And, he took his CTO and us to lunch.
It might have been a breach of my own counsel don’t take your boss to lunch…
I Believe I Set a New World Record
Coming back yesterday from the Rally Agile Success Tour (AST) event in Boston, I picked my car at the Austin-Bergstrom airport from the spot in which I parked it a few days earlier.
Today, flying to a Cutter Consortium consulting gig in Salt Lake City, I found the very same spot at the airport available to me. I am actually fairly certain the spot sort of smiled with familiarity at me. I, of course, returned the smile.
Quite a record, even if I have to say so… is there a message here somewhere?!
Richness and Vibrancy in Boston
A blog post can’t do justice to the richness and vibrancy of the dialogs that were produced by 80 participants in the September 17 Rally Agile Success Tour event in Boston. You had to be there in order to fully savor the experience. If you are a Boston Agilist who missed this gathering, the event in Chicago gives you an opportunity to catch up without needing to fly all the way to the forthcoming events in Seattle or London.
Agile metrics reported during the event were very impressive. AOL’s Jochen Krebs indicated acceptance of user stories improved from 20% to 90% in one year! Sermo’s Rob Sherman provided the following three year data:
-
2007: 10 releases; 26 patches
-
2008: 29 releases; 32 patches
-
2009: 67 releases; 0 patches
(“0 patches” is not a typo – year-to-date “patches” at Sermo have primarily been about laying the required infrastructure for forthcoming releases to be deployed, not about bug fixing).
The quantitative data was nicely complemented by qualitative insights. ITG’s Heather Kanser’s work on the Virtuous Cycle of Agile and Constant Contact’s Rick Simmons contrasting Informational Metrics v. Motivational Metrics demonstrated ahead-of-the-power-curve thinking.
One other thread that came to the fore during the event was Agile Business Service Management (Agile BSM). Think of it as the fusion of Agile methods for software development with state of the art practices for managing IT from a business perspective. Embryonic that this trend is, the potential impact is huge. We will discuss this emerging trend in forthcoming posts.
It is a pleasure writing this post!
How Hard Should the Agile Champion Push?
A question which often comes up in the course of the Rally Agile Success Tour is about the balance to strike between conviction, passion and politics. By virtue of his/her interest in the topic, the Agile champion is often more knowledgeable than his/her superiors on what Agile really is and which strategies are best suited to roll it out. A thoughtful push toward Agile values, principles and practices may lead to major improvements in the way an organization practices Agile. In contrast, an overly hard push might lead to regression in the state of Agile affairs. Moreover, it could easily lead to a breach of the psychoilogical contract between the Agile champion and employer.
Reading The Bureaucratic Phenomenon – a book recommended to me by Forrester’s Tom Grant – I found the following nugget:
The power of decision making within a bureaucratic system of organization is located exactly at the points where the stability of the internal “political” system is preferred to the achievement of the functional goals of the organization.
The specific nature of the bureaucracy with which one has to cope changes, of course, from one company to another. No matter what kind of bureaucracy the Agile champion has to cope with, the observation cited above applies. The Agile champion can successfully push hard as long as he/she does not cross the fine line between achievement of functional goals and “political” stability.
Hand Crafted Sausages – a Metaphor from Josh Kerievsky
Reflecting on the Rally Agile Success Tour in Los Angeles, I discussed the “sausage syndrome” as one of the more painful issues between the Agile champion and his/her executive(s):
The “sausage syndrome”: “Don’t bother me with details how you do the software – just get it done” seems to be the attitude of numerous “business executives.” I must admit I still don’t get it. Software is becoming pervasive on an unprecedented scale. And, software is becoming bigger and bigger component of just about any product in which it is embedded. Ditto for software as part of the business process. What is your recipe for success if you (as an executive) don’t get down and dirty on such a major component of your business?!
Joshua Kerievsky and I discussed the metaphor during an elevator ride in Agile 2009. Josh’s pointed out how delicious hand crafted sausages are. Moreover, he emphasized how intentional and thoughtful a good chef is about the ingredients going into such sausages.
I used this metaphor in a teleconference I had earlier today with a CEO contemplating a large scale rollout of Agile. He chuckled and enquired about the right kind of beer to go with the sausages. Caught empty handed (was “Pilsner” the right answer?!), I promised an answer no later than my next elevator ride with Josh..
The Agile Executive 