The Agile Executive

Making Agile Work

Posts Tagged ‘Governance

Technical Debt: Assessment and Reduction

with one comment

Below is the detailed outline for my August 8, 1:30-5:00PM Technical Debt Workshop in Agile 2011. I look forward to meeting you and interacting with you in the conference before, during and after this workshop!

Best,

Israel

Technical Debt: Assessment and Reduction

Part I: Technical Debt in the Overall Context of the Software Process

  • A Holistic Model of the Software Process
  • Two Aspects of Output
  • Three Aspects of Technical Debt
  • Six Aspects of Software

Part II: What Really is Technical Debt?

  • What’s in a Metaphor?
  • Code Analysis
  • Time is Money
  • Monetizing Technical Debt
  • Typical Stakeholder Dialog Around Technical Debt
  • Analysis of the Cassandra Code
  • Project Dashboard

Part III : Case Study – NotMyCompany, Inc.

  • NotMyCompany Highlights
  • Modernizing Legacy Code
  • Error Proneness

Part IV: The Tricky Nature of Technical Debt

  • The Explicit Form of Technical Debt
  • The Implicit Form of Technical Debt
  • The Strategic Impact of Technical Debt
  • No Good Strategy Following Prolonged Neglect

Part V: Unified Governance

  • How We View Success
  • Three Core Metrics
  • Productivity, Affordability, Risk
  • What is the Real ROI?

Part VI: Process Control Models

  • A Typical Technical Debt Pattern
  • Process Control View of Scrum
  • Integration of Technical Debt in the Agile Process
  • Using Statistical Process Control Methods

Part VII: Reducing Technical Debt

  • A Framework for Thinking about and Acting on Technical Debt Issues
  • Portfolio Governance

Part VIII: Takeaways

  • Nine Simple Takeaway
  • Connecting the dots
Advertisements

SPaMCAST 112 – Israel Gat, Technical Debt

leave a comment »

http://www.flickr.com/photos/pumpkinjuice/229764922/

Click here for my just published interview on Technical Debt. Major themes discussed in the interview are as follows:

  • The nature of technical debt
  • Tactical and strategic effects of technical debt
  • How the technical debt metric enables you to communicate across levels and functions
  • What Toxic Code is and how it is related to Net Present Value
  • The atrocious nature of code with a high Error Feedback Ratio
  • Cyclomatic complexity as a predictor of error-proneness
  • Use of heat maps in reducing technical debt
  • Use of density of technical debt as a risk indicator
  • How and when to use technical debt to ‘stop-the-line’
  • Use of technical debt in governing software

To illuminate various subtle aspects of technical debt, I use the following metaphors in the interview:

  • The rusty automobiles metaphor
  • The universal source of truth metaphor
  • The Russian dolls metaphor
  • The mine field metaphor
  • The weight reduction metaphor
  • The teeth flossing metaphor

Between the themes and the metaphors, the interview combines theory with pragmatic advice for both the technical and the non-technical listener.

Fresh Perspectives on Technical Debt

leave a comment »

Update, October 15: The issue has been posted on the Cutter website (Cutter IT Journal subscription privileges required).

Cutter is just about ready to post the October issue of the IT Journal for which I am the guest editor. Print subscribers should receive it by the last week of the month. Jim Highsmith and I will be reflecting on it in our forthcoming seminar on technical debt in the Cutter Summit.

This issue sheds light on three noteworthy aspects of technical debt techniques:

  1. Their pragmatic use as an integral part of Governance, Risk and Compliance (GRC).
  2. Extending the techniques to shed light on various nuances of technical debt that have alluded us so far.
  3. Applying the techniques in new domains such as devops.

Here is the Table of Contents for this exciting issue:

Opening Statement

by Israel Gat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3

Modernizing the DeLorean System: Comparing Actual and Predicted Results of a Technical Debt Reduction Project

by John Heintz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

The Economics of Technical Debt

by Stephen Chin, Erik Huddleston, Walter Bodwell, and Israel Gat . . . . . . . . . . . . . . . . . 11

Technical Debt: Challenging the Metaphor

by David Rooney . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Manage Project Portfolios More Effectively by Including Software Debt in the Decision Process

by Brent Barton and Chris Sterling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

The Risks of Acceptance Test Debt

by Ken Pugh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Transformation Patterns for Curing the Human Causes of Technical Debt

by Jonathon Michael Golden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  30

Infrastructure Debt: Revisiting the Foundation

by Andrew Shafer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

 

Action Item: Apply the techniques recommended in this issue to govern your software assets in an effective manner.

____________________________________________________________________________________________________

Overwhelmed by a “mountain” of technical debt? Let me know if you would like assistance in devising and carrying out plans to reduce the debt in a biggest-bang-for-the-buck manner. Click Services for details.

____________________________________________________________________________________________________

Apropos is Going Places

with one comment

Pictured above is a screen shot from the forthcoming Rally implementation of Apropos – the end-to-end Kanban system unveiled by Erik Huddleston, Stephen Chin, Walter Bodwell and me in the Lean Software and Systems conference last April.

Pictured below is Stephen Chin presenting the forthcoming product in the recent JavaOne conference:

The commercial version by Rally builds on the four pillars of the original implementation of Apropos at Inovis and the subsequent open source version:

  • Stakeholder Based Investment Themes
  • Business Case Management
  • Upstream and Downstream WIP Limits
  • Dynamic Allocations

These four pillars enable Apropos users to dynamically adjust their plans as needed in accord with the realities of end-to-end execution. Agile portfolio planning and actual execution truly run alongside each other as depicted in the following figure:

Adjustments to allocations can take place in either in the plan or in execution. Here are two typical examples of stakeholders’ dialogs:

  • In planning: “In response to the quick growth of the sales funnel, we decide to increase the % of time allotted to tactical sales opportunities from 35% of the total R&D budget to 40%.”
  • In execution: “The introduction of product Pj will be delayed by three months due to lack of qualified professional services resources. During this period, the affected R&D resources will be reassigned to help with multi-tenant aspects of a SaaS version of product Pk.”

Recommendations: Consider using the open source version of Apropos for a small-scale pilot as part of your 2011 planning/budget cycle. If the pilot proves a good fit with your needs,  switch over to the commercial version in the 2012 planning/budget cycle.

____________________________________________________________________________________________________

Considering end-to-end Agile/Kanban roll-out? Let me know if you would like assistance in planning and implementing a roll-out which focuses on continuous value delivery. Click Services for details.

____________________________________________________________________________________________________

The Gat/Highsmith Joint Seminar on Technical Debt and Software Governance

leave a comment »

Jim and I have finalized the content and the format for our forthcoming Cutter Summit seminar. The seminar is structured around a case study which includes four exercise. We expect the case study/exercises will take close to two-thirds of the allotted time (the morning of October 27). In the other third we will provide the theory and practices to be used in the seminar exercises and (hopefully) in many future technical debt engagements participants in the workshop will oversee.

The seminar does not require deep technical knowledge. It targets participants who possess conceptual grasp of software development, software governance and IT operations/ITIL. If you feel like reading a little about technical debt prior to the Summit, the various posts on technical debt in this blog will be more than sufficient.

We plan to go with the following agenda (still subject to some minor tweaking):

Agenda for the October 27, 9:30AM to 1:00PM Technical Debt Seminar

  • Setting the Stage: Why Technical Debt is a Strategic Issue
  • Part I: What is Technical Debt?
  • Part II : Case Study – NotMyCompany, Inc.
    • Exercise #1 – Modernizing NotMyCompany’s Legacy Code
  • Part III: The Nature of Technical Debt
  • Part IV: Unified Governance
    • Exercise #2 – The acquisition of SocialAreUs by NotMyCompany
  • Part V: Process Control Models
    • Exercise #3 – How Often Should NotMyCompany Stop the Line?
  • (Time Permitting – Part VI: Using Technical Debt in Devops
    • Exercise #4 – The Agile Versus ITIL Debate at NotMyCompany)

By the end of the seminar you will know how to effectively apply technical debt techniques as an integral part of software governance that is anchored in business realities and imperatives.

Written by israelgat

September 30, 2010 at 3:20 pm

Why Spend a Whole Morning on Technical Debt?

with one comment

In a little over a month Jim Highsmith and I will deliver our joint seminar on technical debt in the Cutter Summit. Here are eight characteristics of the technical debt metric that make it clear why you should spend 3.5 precious hours on the topic:

  1. The technical debt metric shifts the emphasis in software development from proficiency in the software process to the output of the process.
  2. It changes the playing fields from qualitative assessment to quantitative measurement of the quality of the software.
  3. It is an effective antidote to the relentless function/feature pressure.
  4. It can be used with any software method, not “just” Agile.
  5. It is applicable to any amount of code.
  6. It can be applied at any point in time in the software life-cycle.
  7. These six characteristics of the technical debt metric enable effective governance of the software process.
  8. The above  characteristics of the technical debt metric enable effective governance of the software product portfolio.

The eight characteristics in the aggregate amount to technical debt metric as a ‘universal source of truth.’ It is a meaningful metric at any level of your organization and for any department in it. Moreover, it is applicable to any business process that is not yet taking software quality into account.

Jim and I look forward to meeting you at the summit and interacting with you in the technical debt seminar!

Written by israelgat

September 22, 2010 at 7:32 am

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.