The Agile Executive

Making Agile Work

Archive for the ‘Technical Debt’ Category

A Special Technical Debt Offer from the Cutter Consortium

leave a comment »

The good folks at Cutter are making the October Issue of the Cutter IT Journal (CITJ) available to anyone who is interested in getting deeper into the intricacies of technical debt. Here is the table of contents for this issue:

  • Opening Statement by Israel Gat
  • Modernizing the DeLorean System: Comparing Actual and Predicted Results of a Technical Debt Reduction Project by John Heintz
  • The Economics of Technical Debt by Stephen Chin, Erik Huddleston, Walter Bodwell, and Israel Gat
  • Technical Debt: Challenging the Metaphor by David Rooney
  • Manage Project Portfolios More Effectively by Including Software Debt in the Decision Process by Brent Barton and Chris Sterling
  • The Risks of Acceptance Test Debt by Ken Pugh
  • Transformation Patterns for Curing the Human Causes of Technical Debt by Jonathon Michael Golden
  • Infrastructure Debt: Revisiting the Foundation by Andrew Clay Shafer

Being the guest editor for this issue, I can attest better than anyone else how much I learned from the various authors, from Karen Pasley (the October issue editor) and Chris Generali (CITJ Editor-in-Chief).

Click here for details of this special offer including downloading instruction.

Advertisements

Agile Enterprise Forum 2011

with 4 comments

Charles Handy, Chris Potts, Don Reinertsen, John Seddon and I are the featured speakers in the Agile Enterprise Forum 2011. The Forum will be held on March 10, 2011 in the Chandos House at the Royal Society of Medicine,  London. Attendance is limited to 30 CIOs.

The theme for the forum is Agility for Complex Organizations. The overarching message is nicely captured in the following summary by James Yoxall:

There are two strands of interest for a CIO: strategy and delivery.  The Agile/Lean message can be summarised as “merging” the two, so that delivery can start before strategy is complete, and delivery informs strategy through feedback loops. This leads to a faster/earlier delivery and a better end result.

My own workshop – Agile Governance: Tying Delivery to Value – builds on this message by describing a specific strategic initiative which is not achievable without the use of advanced delivery techniques. Here is the abstract for my workshop:

This workshop will explore mechanisms for unlocking the full potential of existing software through the combination of Agile/Lean methods with technical debt techniques. These mechanisms apply to complex organisations that rely on in-house development teams as well as to third party delivery partners. Israel’s approach emphasizes the need to continuously monitor and mitigate the decay of software that more often than not had been developed over many years. Most importantly, it shows how well-governed software can become the enabler for unleashing the synergistic power of cloud, mobile and social.

You can think of the workshop as linking past, present and future. The “sins” of the past require technical debt reduction initiatives today. These initiatives utilize the classical Agile/Lean techniques of continuous measurement and tight feedback loops. Without such initiative, the value of existing software cannot be unlocked in the future. In particular, competing in the hyper-segmented markets that cloud, mobile and social generate will be next to impossible for legacy software that has not been modernized.

Jim Highsmith on the Financial Implications of Technical Debt

leave a comment »

Jim Highsmith launched his new blog/website last week. I have no doubt whatsoever it will be a thought leadership blog. Moreover, knowing Jim I would expect the blog will address and integrate concepts and ideas from numerous disciplines, not “just” from software methods.

Jim’s first publicly available post  – The Financial Implications of Technical Debt – explores the impact of technical debt on capitalization. To quote Jim:

So the bottom line for technical debt. It’s expensive to fix, but much more expensive to ignore. Technical debt reduces future earnings, but even more critically, it destroys predictability which in turn impacts market capitalization in the near term, not in the future.

http://www.flickr.com/photos/johnwardell/80125882/

Figure 1: Loss of Predictability

Jim’s post nicely closes the {financial –> technical –> financial} loop. Ward Cunningham’s original debt metaphor borrowed the financial term to apply it to software development. Jim is now bridging from the technical arena back to the financial world.

If you are into any form of agility – technical, managerial or business – you owe it to yourself to follow Jim’s blog.

Written by israelgat

November 1, 2010 at 6:44 am

The Nine Transformative Aspects of the Technical Debt Metric

with 3 comments

No, the technical debt metric will not improve your tennis game. However, using it could help you generate time for practicing the game due to its nine transformative aspects:
  1. The technical debt metric enables Continuous Inspection of the code through ultra-rapid feedback to the software process (see Figure 1 below).
  2. It shifts the emphasis in software development from proficiency in the software process to the output of the process.
  3. It changes the playing fields from qualitative assessment to quantitative measurement of the quality of the software.
  4. It is an effective antidote to the relentless function/feature pressure.
  5. It can be used with any software method, not “just” Agile.
  6. It is applicable to any amount of code.
  7. It can be applied at anypoint in time in the software life-cycle.
  8. These seven characteristics of the technical debt metric enable effective governance of the software process.
  9. The above  characteristics of the technical debt metric enable effective governance of the software product portfolio.

Figure 1: Continuous Inspection

Written by israelgat

October 28, 2010 at 8:40 am

How to Use Technical Debt Data in the M&A Process

leave a comment »

http://www.flickr.com/photos/brajeshwar/266749872/

As a starting point, please read Implication of Technical Debt Uncertainty for Software Licensing Negotiations. Everything stated there holds for negotiating M&A deals. In particular:

  • You (as the buyer) should insist on conducting a Technical Debt Assessment as part of the due diligence process.
  • You should be able to deduct the monetized technical debt figure from the price of the acquisition.
  • You should be able to quantify the execution risk (as far as software quality is concerned).

An important corollary holds with respect to acquiring a company who is in the business of doing maintenance on an open source project, helping customers deploy it and training them in its use. You can totally eliminate uncertainty about the quality of the open source project without needing to negotiate permission to conduct technical debt assessment. Actually, you will be advised to conduct the assessment of the software prior to approaching the target company. By so doing, you start negotiations from a position of strength, quite possibly having at your disposal (technical debt) data that the company you consider acquiring does not possess.

Action item: Supplement the traditional due diligence process with a technical debt assessment. Use the monetized technical debt figure to assess execution risk and drive the acquisition price down.

http://www.flickr.com/photos/tantek/254940135/

____________________________________________________________________________________________________

Negotiating a major M&A deal? Let me know if you would like assistance in conducting a technical debt assessment and bringing up technical debt issues with the target company. I will help you with negotiating the acquisition price down. Click Services for details and contact information.

____________________________________________________________________________________________________

Written by israelgat

October 20, 2010 at 5:37 am

Implications of Technical Debt Uncertainty for Software Licensing Negotiations

with 2 comments

A few years ago, my friend Sebastian Hassinger characterized the state of affairs in enterprise software by the following chart a la Christensen:

The key point this charts gets across is that Open Source Software is becoming “good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By so doing, open source software will steadily gain ground from traditional enterprise software vendors.

Consider this chart from a buyer’s perspective. Functionality (the vertical axis in the chart) can be thought of as value. Whatever the value might be, it is diminished by technical debt in the software as the debt manifests itself as application crashes, degradation of  performance and possible corruption of customer data. Everything else being equal, an application with lower technical debt per line of code is preferable to an application with a higher technical debt per line of code.

Traditional enterprise software vendors do not typically provide the technical debt data for the applications they sell/license. In contrast, a customer can carry out his/her assessment of technical debt straight off the open source code. For example, colleague and friend John Heintz carried out the following technical debt analysis on the Cassandra open source project:



As demonstrated in this chart, any customer can measure the level of technical debt in an open source software he/she considers. For better or worse, there is no uncertainty about the amount of technical debt the customer will need to live with in an open source software. In contrast, a customer will usually need to live with  uncertainty about the level of technical debt in proprietary software.

Uncertainty has economical consequences. For example, testing a product increases its value because it decreases operational uncertainty. The economical value of uncertainty about technical debt is conceptually depicted in the figure below in which value is adjusted in accord with the knowledge or lack thereof of the amount of technical debt. Please note that the following equation holds for the various intersection points on the Enterprise Customer Requirements line: {T3-T2} < {T1-T0}. What this equation means is that under conditions of uncertain technical debt open source software is becoming more attractive than proprietary software faster than it would without taking technical debt uncertainty into account.

Action Item: Before licensing an enterprise application or renewing an existing license, ask the vendor for technical debt data for the application and the plans to reduce the debt. If the vendor refuses to disclose this data or can’t generate it within a reasonable amount of time, ask for the number of open bugs against this application in the vendor’s bug data base. Use either kind of data to drive down the price. Consider  an open source solution (even if it provides less functionality than the proprietary software product) if the vendor you are dealing with refuses to disclose either the technical debt data or the number of open bugs in the enterprise application.

____________________________________________________________________________________________________

Negotiating a major enterprise software deal? Let me know if you would like assistance in bringing up technical debt issues with the vendor to help with negotiating the price down. Click Services for details and contact information.

____________________________________________________________________________________________________

Y2K vis-a-vis IT Debt

leave a comment »

http://www.flickr.com/photos/plural/4279707276/

Andrew Dailey of MGI Research and Andy Kyte of Gartner Group kindly did some digging for me on the total amount of money that was spent on Y2K. Here is the bottom line from Andy concluding our email thread on the subject of Y2K expenditures:

I have remained comfortable with our estimate of $300B to $600B.

In other words, it will take an effort comparable to the Y2K effort at the turn of the century to ‘pay back’ the current IT Debt.

____________________________________________________________________________________________________

Considering modernization of your legacy code? Let me know if you would like assistance in monetizing your technical debt, devising plans to reduce it and governing the debt reduction process. Click Services for details.

____________________________________________________________________________________________________

Written by israelgat

October 18, 2010 at 6:13 am