Skip to main content

Agile Australia 2011 Series - Tackling Technical Debt

I love the topic of technical debt on agile projects and how it’s the cause of much debate and discussion. It seems destined to trip project managers up and cause massive amounts of project manager stress . I think the angst is around the seemingly unpredictable nature of technical debt, and how it has the potential to result in project blow outs, and how unsettling that can feel when we have faith that agile projects will bring us efficiency and yes, predictability. Maybe if technical debt didn’t exist Agile would really be the silver bullet that everyone seems to be looking for, or insisting that Agile isn’t!

When I was a project manager on agile projects it used to drive me crazy whenever my team doubled their story points in an iteration by finding tech debt here there and everywhere that they stated MUST be attended to. It’s really hard to contradict developers on this topic, they make a compelling case for tackling debt that will slow you down the more you want to extend your software platform in the future. The trouble is most software projects focus on the here and now and consequently decisions that are focussed on the project delivery date, right in front of our noses, get made.

Martin Fowler has penned a great hypothesis on ‘design stamina’ and represents graphically the time at which short term decisions might pay off against where they cost you more due to the increased effort to build more features in a world where you made only short term design decisions.

My team wouldn’t have forgiven me if I had not talked about tech debt at Agile Australia as it’s a hot topic there at the moment. So without dwelling I’ll tell you what we do, and what I think you could do for getting debt relief in this area:

  • Tame the debt! Respect the cost – by this I mean yes include debt cards, include refactoring but respect the business value you are delivering at the time and don’t go crazy with it.
  • Tackle debt outside the project with a quadrant – Create a Tech Debt wall with a quadrant, include effort and payoff axis and post tech debt cards on the quadrant. Empower people to foster some debt cards on their project. Even creating the tech debt wall provides an outlet for frustration. Perhaps do some blitzing on rainy days or quite periods (intersprint breaks) or devote some budget to it. Perhaps some money you saved by chucking something out can be spent towards paying down debt?
  • Don’t keep it a secret from the customer or bury your head in the sand. Make it visible to them, staple your relevant tech debt story cards to the businesses story cards if needs be. If you can articulate the benefits to addressing tech debt you might be surprised how they are willing to prioritise it along with functional scope. If you can articulate it well enough, it may seem ludicrous not to include it as scope.
  • Don’t make the mistake of thinking it’s an IT problem and IT need to deal with it. Describe it in business value terms. If the business cannot understand it they will never prioritise it as important to do.

These are my high level approaches to recognising and addressing technical debt.

There’s a whole other science around the prevention of the contribution to the tech debt. Factors like very skilled developers and all of the great XP development practices we know about come in to play here. That’s a great big topic and also a reason why I mapped this topic in my 'hard and expensive' quadrant during my Agile Australia presentation. I personally wouldn’t recommend on day 1 you start your agile transformation with the identification and eradication of technical debt but you certainly shouldn’t kid yourself into thinking you will never have to deal with it. The truth is you are already dealing with it in the cost you are paying for your software today.


Alexander Abner said…
Having a basic factor at as a knowledge chart scrum meeting help us a lot with knowing a lot and at the same time have the basics which are fine enough in their own ways.

Popular posts from this blog

Business Requirement Documents are just no good and should be abolished from the world of creating software

I had hoped the world could have wholeheartedly rejected Business Requirement documents by now. For too long I’ve seen the repeated scenario of only commencing the creation of a new initiative with a requirements document.Unfortunately most organisations that have teams developing software still use these flawed anathemas to creativity as the status quo. Despite agile approaches maturing and customer-centric modes of design emerging, requirements documents still persist. 
If you work in an organisation that doesn’t use business requirement documents any more, read no further. You are lucky; sense has prevailed at your place however in my experience, you are still the minority.
Let's face it; addressing this issue is not always the point you want to start your improvement work when there's much that could be dysfunctional with how a team is delivering software. But now, I find myself as mad as hell, and I'm not going to take business requirement documents anymore. I want to …

Gamify your children

Inspired by James Ross’s LAST conference talk on The Shamification of Lamification and the Reclaimification of Gamification I was motivated to try and “Gamify” the school holidays for my three children, Leo aged 8, Chloe 9 and Max 10.
Buy-in is everything, so the first thing we did was a quick workshop to extract the kids ideas. I asked them to write their ideas for good rewards on sticky notes, with a few examples for context, such as ‘trip to the movies or ‘play date with a friend’ . They had 5 minutes to come up with their ideas – one idea per sticky note (as always).
They then read out their ideas for all of us to hear, there were a few duplicates and also a few comedy suggestions. Even though we had ruled out crazy stuff, such as rewards of a million dollars, Leo had written down ‘A unicorn for the back yard’ reading it out with gleeful giggles.
Then they spent 5 minutes writing down tasks that they could do to earn rewards. By now they had the hang of it and quickly came up with t…

Agile Australia 2011 Series - Agile Governance

If you are in an industry that is heavily into governance you need some structure and process around your projects or you could find your Agile projects getting usurped by the culture of command and control. So it’s important not to shy away from the topic but to work with the entities that enforce and monitor governance. In this way you can create something that is fast and easy and not laborious to work with.I work for an Apra regulated organisation and we made keenly aware of our obligation under Apra to evidence documented change when audited. However in all organisations I’ve ever worked in, there are boundaries that bend quite a bit, ways to change things and ways to get by that satisfy governance process without crippling your agile process.There’s almost two alternating schools of thought here which are ‘work within process’ and ‘decide to change the process’. It’s actually pretty easy for my team to work within process. Project approvals, mandates and PIDs that are important …