I assume that most of the people who might stumble upon this post are of a technical background. It is likely that the term Technical Debt is familiar to you and you will recognise one of its many definitions, such as this one by Ward Cunningham and this one from Martin Fowler. As technical professionals we understand that things could have been better, that we would have approached some problems differently if we had had more time and we are well aware of the impact that not addressing problems in your software has on the quality of the project or product.

However, other stakeholders in your project or organisation can struggle with the concept of Technical Debt. The debt metaphor was chosen to aid understanding – not as a complete model that totally describes the problem we are trying to characterise in software development.

In this post I’m going to describe a few “interesting” approaches to handling technical debt on projects I have worked on.

Your debt, your problem

The relationship that software suppliers have with their customers is usually harmonious, but this is not always the case. Sometimes it can be fraught, tense and in some cases, downright hostile. In these situations, the customer will find any opportunity to give the supplier a hard time.

When the conversation turns to technical debt and its impact on a project, timeline, costs and scope, it becomes a stick with which to beat up the supplier.

In the customer’s eyes, the supplier should be perfect, after all they are charging enough! Technical debt is scope creep that shouldn’t have been introduced in the first place and the customer is absolute in their view that they will not pay for it. The customer will not accept any impact on the original costs, scope and timelines that they originally agreed.

So the supplier has to absorb the impact.  This means longer hours and more effort but often there is the question of how profitable the project will be. The team comes under the inevitable pressure from the top. Reductions in quality become unavoidable.

I have experienced a situation where a customer mandated that a supplier does not address technical debt. The customer explicitly removed authorisation that technical debt could be resolved. This happened because the key decision makers at both the customer and supplier did not recognise the impact of  unresolved technical debt or if they did, they didn’t think that impact would matter much. The result was a demoralised team and a product that was of lower quality than it should have been.

Agile in a Waterfall Wrapper

Often when working on an Agile project, if you look closely enough you’ll find it’s a waterfall project in disguise. Are there worried looks when a team doesn’t meet its sprint goal? Are there release planning boards covered in post-its that are arranged like a Gantt chart if you squint a bit? Is technical debt seen as scope creep and something that is bad and avoided at all costs?

You do have to manage scope creep on an Agile project but it should be dealt with as any other prioritisation question during the project. Technical debt will always occur and is something that should be accounted for in your capacity planning. When the process for accepting technical debt into the project takes longer than resolving the problem itself, questions need to be asked.

Agile Activist 

I wrote about Agile Activists here. The Agile Activist is preoccupied with demonstrating that Agile is the “one true way”. Often, to sway people sitting on the fence, they focus on delivering business value regularly above all other things. When the emphasis is on business value, continuous improvement can get neglected because it becomes hard to justify when compared to all the other lovely business features that could be done instead.

This ends with the project team effectively having to ask permission to resolve technical debt. Usually the people who are granting “permission” don’t really understand what is involved resolving technical debt nor the impact of not doing it.

Again a good indication of this happening is the construction of more and more process to “accept” technical debt resolution stories into the project. Do you have to build a case that demonstrates the business value of making an improvement? Do you have to convince a handful of people who are motivated to deliver new business features over making improvements? Do the people you have to convince have any appreciation of what it takes to build quality software?

Them and Us

Some organisations that are in the early stages of their agile transformation, struggle with the idea of marrying architecture governance with agile delivery. They resist architectural involvement in sprint teams and instead create projects with separate architectural teams.

In my experience this creates friction, as the architecture team assumes technical leadership and decision making but they are not delivering any software. They don’t understand what it really takes to deliver a feature and do not understand the trade-offs that the development teams are making every day.

And when the architecture team start managing a technical debt register…

This is for good intentions. They are doing this to ensure that the project aligns with all the necessary corporate standards. This is absolutely required in many industries and if you are the Agile Activist in these organisation, waving the standard of Emerging Design with no oversight, you are very much running the risk of damaging the organisation you are working in.

But back to the satellite architecture led technical debt register. If this includes items such as

  • Solution must use OpenID Connect 1.0 and OAuth 2.0 for API authentication and authorisation and 256 bit keys must be used
  • Solution must integrate into Microsoft System Center
  • UI must be WCAG 2.0 compliant

These are fine, they read like typical non-functional requirements. At best they should be acceptance criteria on stories. At worst they are technical debt items that must be addressed at some point.

What about these?

  • Solution must use logging framework X
  • System components XYZ must conform to this UML model
  • Code must be written like X

If these sorts of things are mandated by a satellite architecture team, then you are asking for trouble. The development team see them as dictates, ignoring them at best or becoming hostile to the architecture team, if you are not so lucky.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s