The Agile Executive

Making Agile Work

Posts Tagged ‘Dave West

Forrester on Managing Technical Debt

leave a comment »

Forrester Research analysts Dave West and Tom Grant just published their report on Agile 2010. Here is the section in their report on managing technical debt:

Managing technical debt

Dave: The Agile community has faced a lot of hard questions about how a methodology that breaks development into short iterations can maintain a long-term view on issues like maintainability. Does Agile unintentionally increase the risk of technical debt? Israel Gat is leading some breakthrough thinking in the financial measures and ramifications of technical debt. This topic deserves the attention it’s beginning to receive, in part because of its ramifications for backlog management and architecture planning. Application development professionals should :-

  • Starting captured debt. Even if it is just by encouraging developers to note issues as they are writing code in the comments of that code, or putting in place more formal peer review processes where debt is captured it is important to document debt as it accumulates.
  • Start measuring debt. Once captured, placing a value / cost to the debt created enables objective discussions to be made. It also enables reporting to provide the organization with transparency of their growing debt. I believe that this approach would enable application and product end of life discussions to be made earlier and with more accuracy.
  • Adopt standard architectures and opensource models. The more people that look at a piece of code the more likely debt will be reduced. The simple truth of many people using the same software makes it simpler and less prone to debt.

Tom: Since the role I serve, the product manager in technology companies, sites on the fault line between business and technology, I’m really interested in where Israel Gat and others take this discussion. The era of piling up functionality in the hopes that customers will be impressed with the size of the pile are clearly ending. What will replace it is still undetermined.

I will be responding to Tom’s good question in various posts along the way. For now I would just like to mention the tremendous importance of automated technical debt assessment. Typical velocity of formal code inspection is 100-200 lines of code per hour. Useful and important that formal code inspection is, there is only so much that can be inspected through our eyes, expertise and brains. The tools we use nowadays to do code analysis apply to code bases of any size. Consequently, the assessment of quality (or lack thereof) shifts from the local to the global. It is no more no a matter of an arcane code metric in an esoteric Java class that precious few folks ever hear of. Rather, it is a matter of overall quality in the portfolios of projects/products a company possesses. As mentioned in an earlier post, companies who capitalize software will sooner or later need to report technical debt as line item on their balance sheet. It will simply be listed as a liability.

From a governance perspective, technical debt techniques give us the opportunity to carry out consistent governance of the software process based on a single source of truth. The single source of truth is, of course, the code itself. The very same truth is reflected at every level in the organization. For the developer in the trenches the truth manifests itself as a blocking violation in a specific line of code. For the CFO it is the need to “pay back” $500K in the very same project. Different that the two views are, they are absolutely consistent. They merely differ in the level of aggregation.


Recommendations from Santa Clara

with 4 comments

So much was going on simultaneously in Rally’s Agile Success Tour event in Santa Clara! More than 140 participants, an eclectic panel, 6 breakout sessions, numerous 1-1’s and, of course, a ton of spontaneous interactions. This posts in many ways represents my own “thread” within this very gratifying event. My Rally colleagues will no doubt supplement this post by commenting on the various activities and interactions in which I was not able to engage.

The number one question I was asked in the course of the event was about the difficulties quite a few software development champions encounter in the course of attempting to coalesce successful Agile projects into comprehensive initiatives at the corporate level. Team successes with Agile sometimes remain isolated islands of excellence within corporate “oceans.” The proven  ability of a capable Agile champion to carry the day in specific project does not necessarily lead to adoption of Agile as part of an all-encompassing corporate doctrine. Just like the Geoffrey Moore entrepreneur who demonstrates success in the early days of his/her start-up but does not quite make it big time, the Agile champion often struggles to cross an adoption chasm and make his/her way to “main street.”

Colleagues Ryan Martens, Dave West and Tom Grant discussed how to apply Agile in combination with Lean to elevate Agile from the project level to the corporate level. There is no need to repeat their good work (click here for example) in this post. Instead, here are the tactical suggestions I gave in Santa Clara to various Agile champions who looked for recommendations how to elevate Agile:

  1. A statement of Agile benefits is not sufficient. It must go hand-in-hand with an assessment of the risks (plural!) associated with the Agile expansion. See A View from the Executive Suite for details of the recommended approach.
  2. Statements of Agile benefits and corresponding risk mitigation approaches are not sufficient. As Peter Drucker quipped, Companies make shoes! To be relevant at the strategic level, the Agile program must be tied into the top initiatives a corporation carries out.
  3. Statement of Agile benefits, risk mitigation and strategic relevance are not sufficient. These statements must be accompanied by a clearly articulated approach to managing the cultural aspects of extending and expanding Agile. If at all possible, opt for for building on the strength of the current culture. It is much more difficult to try to change a culture. Moreover, it take a long time to transform a culture. See my forthcoming presentation Four Principles, Four Cultures, One Mirror in Agile Roots for details.

I will allow myself to repeat my recent assessment from the NYC event as it applies so well to the Santa Clara event:

I came out of the Santa Clara event convinced that we as a movement have a great opportunity on our hands. What we -Agilists – do works quite well. The need clearly exists to elevate Agile to the enterprise level. We will be solving a real problem in so doing.

Written by israelgat

June 6, 2009 at 10:17 am