Tag Archives: Stop The Bleeding

Escaping the Oubliette (Part 1) – Topping

Posted on by
Reply
Reading time ~ 2 minutes

As promised, how to Escape The Oubliette…

So here you are, part of a team at the bottom of the defect & debt pit. What now?

The simple fact is, there’s no one answer but there are a selection of tools and there is a key.

The key comes courtesy of a comment from Jim Highsmith during one of his sessions at Agile 2010 – my paraphrasing below…

“Teams facing technical debt need both debt reduction and debt prevention strategies.”

When teams face technical debt they pick away, removing it piecemeal. After all, you have to eat an elephant one bite at a time right?

Trouble is, that only works if the elephant isn’t growing as fast as you’re chewing.

You need a two-pronged attack – what I like to call “topping and tailing”. The “top” is all the incoming issues and build-up of new debt. This is where you need to stop the bleeding. The “tail” is the backlog of existing debt. It’s already there – gently rotting in the corner of your product.

Topping

If you’ve read my post on stopping the bleeding, this is the crux of “topping”. You may have a variety of strategies for this but here’s the fundamentals.

Incoming Customer Defects

Ringfence enough capacity to address defects as soon as they come in. Make sure your burn rate matches your incoming rate. If you’re strapped, it’s your call whether you only cover high severity issues but for my money, I’d hit them all. A multi-year build-up of low severity issues makes products ugly, no pleasure for the users and a series of minor problems rapidly becomes a major burden and a big debt buildup.

Addressing every incoming defect doesn’t mean fixing every one. Whilst I generally recommend you do, when trying to dig yourself out of an oubliette the bigger issue is how to keep your goal achievable.

Be critical. The big, nasty bugs are usually pretty obvious but what about the rest?

    • Is it low severity and not important?
      • Is it quick & cheap to fix? – Just fix it.
      • If it’s not – Can you put a safety rail around it? Document it as a limitation or even ignore it?

Negotiate with your customers and make an explicit decision to fix now or never. Once decisions are made, communicated and agreed, close the defects in your backlog.

Getting these conversations happening immediately makes customers far happier than pretending they’ll just go away and never making a decision. (but not quite as happy as fixing their issues).

Incoming Internal Defects

The story here is the same. I’ve called it out independently as many companies and teams do.

Those incoming internal defects speak volumes about your approach to quality.

Get the discipline in place to fix them when you find them or be brutal and admit which ones will never be fixed but don’t pussyfoot around!

  • If you provide a service to other internal teams, treat them as customer defects.
  • If they’re raised by your own team, are they on new code or exposing existing issues?
    • On new code, fix them! – No excuses .
    • On existing code, the problems are already there. You need to decide if what you’ve done has made it more visible or harder to work with than before and make a judgement call. Fix now or never, resolve or close.

In the next article in this series I’ll cover debt prevention…

Stop The Bleeding

Posted on by
1
Reading time ~ 2 minutes

One of my favourite verbal patterns is “Stop The Bleeding”. I heard the term come back to me in a management meeting last week in the right context and with the right response – Success!

I’m not exactly sure where I heard this first but it was sometime in the last 4 years. Mike Cohn references it in the context of agile testing but until I searched for the term just now I’d never read that particular article so I’m sure it’s also used elsewhere…

Name: “Stop The Bleeding” or “Plug The Hole”.

Concept: Consider the “flow” of work and issues. Many software activities generate or receive some sort of flow. Whilst you can use a Kanban approach to manage the flow, you need to address the site of the problem first to prevent it getting any worse and look upstream to consider prevention activites.

Analogies: You have a patient on a stretcher with a series of broken bones and a torn major artery, where do you focus your attention first? – or- You’re in a boat with a leak in the hull. You either stop rowing and start bailing or start rowing and start sinking. Maybe it’s time to fix the leak?  Once you’ve fixed the leak, how about staying away from the rocks?

Usage: The most common times I’ve used this term are in test automation and defect management.

I’ve seen major investments in writing automated regression test suites for existing functionality or old manual tests. Skilled testers are usually in limited supply. Why are we using their valuable capacity on a static problem?

We need to take that capacity and apply it to the issues we continue to create every day – the ones where we’re still bleeding. Write automated tests for our new functionality and changes that we’re introducing right now. These become your regression tests as soon as they start passing!

In defect management a common challenge is customer escalations. These usually happen because we failed to act on a problem in a timely manner. Stopping the bleeding here means addressing new incoming defects promptly and properly. For example; try replicating issues immediately and then negotiating when your customers want a solution rather than just focusing on traditional severity / impact numbers.

Once your flow is under control and you’re working to when customers want a fix, escalations for delinquent issues will trail off fast. Now you can start addressing your other priorities.  Note: The “bleeding” in this second example is customer escalations, not incoming defects – Stopping incoming defects is a subject in itself!