The growing use of Agile development practices is shining a bright light on the concept of Technical Debt. We’ve got people helping us understand what debt is, how it can be categorized, and how development teams can go about fixing it. There are some semi-automated tools that can help teams identify debt. Perhaps, though, the most certain sign that technical debt is something that we need to deal with is that some consulting firms are now offering professional service offerings to help CIOs and other leaders of large organizations identify, understand, and manage their technical debt. When big firms offer these kinds of services, you know that something important is happening.
Steve Rabin, CTO of Insight Venture Partners, recently asked me to give a talk on how development organizations can use our CollaboratizeSM process to identify and prioritize technical debt at one of the Forums he organizes for his portfolio companies. The public version of the slides for that talk are below. If you want to skip the slides and get an overview the process, keep reading.
I’m a strong advocate of using the games to identify and prioritize technical debt because my experience is that development teams:
- Are often quite knowledgeable as to where technical debt – in all its myriad manifestations – exists.
- Would love the chance to work, as a team, to identify technical debt and prioritize the most important improvements.
- Realize that they must balance reduction of technical debt with time spent on new features, enhancements, and bug fixes.
Identifying and Prioritizing Technical Debt is a natural use of our Collaboratize process and two key games:
- Speed Boat to identify the “anchors” that are holding the team back; and,
- Buy a Feature to collaboratively prioritize the improvements to the system.
In the case of the Speed Boat game, the “boat” is a metaphor for the system under development. I’ve previously discussed using Speed Boat for process improvement in this post. In this case, you’re adapting the game so that the anchors are technical debt anchors. Note that these anchors are not just “code” anchors. They can cover your data model, your user interface, your build process, your test automation processes, and even “anchors” related to source code management.
The results of your Speed Boat game are then shaped into potential Buy a Feature projects. Specifically, you’ll create a project with a name, a description, an overview of the benefits of this improvement, and a cost. This cost should be reflective of the overall development effort required to remove the debt. It can derived easily from a “Shirt Size” estimate from your architect.
Potential projects are then fed into a Buy a Feature game. This is also a straightforward use of this game: Developers are given a limited amount of money to purchase the projects that they believe will most benefit the team. It is always insightful to learn how the developers want to attack their technical debt. Do they want to focus all of their energies on one or two costly improvements? Would they instead prefer to address a variety of smaller projects that could collectively create a big improvement? As they negotiate, the entire organization gains the benefit of seeing how developers negotiate over which items are most important, further shaping, clarifying, and structuring these potential projects.
To put these results into action, you should add the big items that likely involve architectural change to your roadmap and the smaller items to your backlog. To ensure that items in the backlog are “authorized” for work by the team, the Product Manager must prioritize them into a release. And they should do this, as I describe in my three-part blog series Prioritizing for Profit: 1, 2, 3.
Sometimes it is best to allocate an entire sprint to removing technical debt – something that I refer to as entropy reduction. You can download the section of my book Beyond Software Architecture on entropy reduction here.
For more ideas on how you can use the games in managing technical debt, see:
- A nice presentation by Chris Sterling and Brent Barton.
- Cutter Consortium’s Technical Debt Assessment and Valuation service.
- A powerful discussion of Technical Debt including Ward Cunningham’s definition at c2. Video here.
- Martin Fowler’s discussion of Technical debt.
Thanks to the attendees of the Insight Venture Partners Forum for playing games during my talk.
Great post!
One thing here is that once we identify the anchors, how to “estimate” the cost of cutting each in $? Cost estimate depends on the “method” to be used to cut the anchor.
I think the Benefit could be decided from playing Buy-a-Feature. Benefits depends on various stakeholders (Customer, Technical, Sales, Business Analyst ….). I think when we play But-a-Feature, the chosen features would be the one with highest Benefit/Cost ratio. From my view Cost can be estimated before playing Buy-a-Feature, however, Benefit is the result of playing the game.
Thanks for this interesting post.
Sameh
One more point. It is also possible to estimate the Cost-of-Poor-Quality (CoPQ) which is how much the this anchor currently costs the organization. So we have three figures:
1. CoPQ
2. Cost of Cutting the anchor
3. Benefit from cutting the anchor. This exceeds the $ value to more intangible benefits that should be based on collective views of the players.
Thanks,
Sameh