Escaping the Oubliette (Part 2) – Tailing

Share
Reading time ~ 4 minutes

Following my previous articles on topping and debt prevention, we’ll now focus on the easier parts. How to clear old defects and debt. we’ll cover 4 simple strategies; 2 for defects and 2 for debt. (there are paired similarities across these).

For defects, we’ll focus on:

For debt we’ll focus on:

Unlike prevention and stop the bleeding activities which often require significant effort and commitment to accomplish, defect and debt removal have some simple and relatively low effort options. There are some high-effort/impact alternatives that we’ll cover later.

Today we’ll look at…

Tailing & Ratcheting

When you have a build up of defects over time you tend to have a “tail” of really old defects and issues. These are usually low or medium severity/priority items (with the occasional blip) and are often in functionally gray areas requiring difficult decisions or significant rework.

They age because we don’t want to touch them and would rather forget about them (the oubliette again). A typical defect age distribution looks something like this:

right-skewed beta distribution

right-skewed beta distribution

It’s one of the most common statistical patterns I see in software development (and I’ll return to it in future) but for the purposes of this article, I want to look at the “tail” of this curve- that last 5-10% of your defect population – all your oldest items.

Addressing the tail is pretty straightforward. You can either set yourself a target “maximum defect age by a given date” or simply focus on continuous improvement. Whilst the target approach gives you a clear goal, you risk setting yourself up for failure or under-commitment. Defects are considered notoriously hard to size (I’ll cover this myth in future) but chances are if they’re old they’re probably a bit tricky too so being predictable about dates is something you might prefer to avoid for starters.

Whether you aim for a specific target or improving every day/week/month you’ll need the same stepped approach.

Identify your oldest defect, pick it off the end of the queue and commit to closing it quickly and fairly.

Here’s the first thing to accept… Closing doesn’t mean fix it in every case. Because you’ve not touched it for a while, chances are someone is expecting a solution so you’ll be looking at a difficult conversation if you don’t fix it but that might be far easier than “fixing” something that shouldn’t be changed or will derail your team and product. Make open, fair, honest decisions in each case.

  • If it is something you think you should be fixing, get on with it.
  • If it’s not – close it

Sound familiar?

Aim to close at least one of your oldest defects every week or every sprint.

If you have a lot of items that are considered old, consider increasing your capacity on these in the short term to get the ball rolling. (at the cost of other delivery activities)

If we look back to your distribution of defects over time, when you do close out your oldest defects, put a ratchet mechanism in place that sets a continuously reducing maximum age.  In very bad weeks the ratchet may not improve but don’t let the numbers get worse again or the effort and good faith from your teams and management will have been wasted.

With a ratchet, remember each “notch” is a step change from the last point. For example if your last point was 1000 days(!), clearing everything older than that should leave some defects nearly 1,000 days old. Set the next ratchet point to 950 days (rather than 997), determine what falls in that next block (950-999) and fix those. Ensure each ratchet point is a larger time window than your execution period otherwise you’ll end up stationary. (I usually go for a ratchet up of 50 days improvement per week or sprint).

Here’s what I mean…

Defects Tail

Ratcheting out the oldest defects each week

3 months of this tailing practice every week will dramatically reduce the average and maximum age of issues in your queue. It’ll make you all feel better and it usually helps to draw the heat off on escalations for a while. (Bear in mind you should be doing this in addition to your “topping” approaches).

Occasionally you’ll reopen some old wounds this way but paying these some attention now stops them coming back up when the timing isn’t under your control.

Keep this up for six months or a year and you’ll reach a stable point where nothing gets too old and your team becomes adept at having difficult conversations with your customers early and backs them up with some successes as well.

Eventually in order to keep the ratcheting improving you’ll have to commit more people. This probably means you’re approaching your natural level of control or entitlement where you have aging defects levelling off and others being addressed in a reasonably consistent manner. It’s up to you whether you aggressively pursue the numbers down further or sustain them at this level.

In case this sounds too obvious or simple to work, I’m working with a team right now that introduced this ratcheting approach less than a month ago. We’ve reduced our oldest defect age by over 25% and customer escalations are consistently lower already. Perhaps most important to the team; we’re no longer at the top of the charts when our leaders review the defect stats. Although harsh-sounding. Sometimes, having someone else drawing the heat for a while lets us get back to focusing on value and priorities.

In part 3 we’ll look at an old favourite – the “bug blitz” or feel free to skip to part 4 – “the litter patrol“.

Your Baby Might Be Ugly

Share
Reading time ~ 4 minutes

Everyone thinks their own babies are beautiful. Some probably are but there are plenty that really aren’t. In fact I remember one particularly interesting comment -“ugly people produce ugly babies”

This happens in code too.

Collective code ownership has many challenges. Here I focus on the person pitfalls.

Imagine you’ve just spent the last 3, 5, or even 10 years nurturing and grooming an insanely complex (and dare I say “clever”) functional area of a product. This has been your working heart and soul for years – apart from the occasional customer to distract you. It follows your own unique,  “perfect” coding style and conventions. You’re so damn good you don’t need unit tests, you instinctively know and understand every intricate tracery and element of logic in there.

Why then if it’s so perfect are you not willing to share?

This is where “Bad Captain” starts to kick in with me…

  • Do you believe that every other developer in the building is less capable than you?

(OK, sometimes it might be true but that’s very rare.)

– That’s fine, you can peer review and provide feedback if they don’t meet your standards right? It might be an emotional lurch to start with but seeing someone else succeed and recognize your greatness must surely be rewarding right? I’ll help you if you need.

  • It’ll always be quicker if you work on it. It’s just a waste of time and effort to train someone else up.

– Sure. Except if we had 3 or 4 people capable of working on it in parallel we might get everything that’s on the wish list for it done this year and you might be able to do that other interesting stuff that the rest of the team have been playing with. In fact, I’m willing to invest if it’s that important…

Bad Captain starts to twitch…

…and if it’s not, why do I have someone who believes they’re “one of the best” working on it – I want my “best” people on my priority tactical and strategic items.

  • You’ve been doing this as your own pet-project on the side and it’s not ready to share.

– If it’s important I want a team on it. I’ll happily lobby for some strategic investment. If it’s not as important as anything else we have committed right now I want you helping the rest of the team out…

Bad Captain…

– even if you’re good, you’re not “special”, don’t expect to be treated any differently than the rest of the team.

These first reasons are almost valid. But not good enough for me. The more of these I hear the more I start to twitch, the more terse I get and the more I start to frown and tense up.

Suddenly it’s too late! Captain Hyde takes the helm!

Here’s why Captain Hyde thinks you’re not sharing…

  1. You’re lazy, you’re only any good at this one area and don’t want to have the responsibility of teaching it or learning something new that you’re not so good at. – Time for you to learn a bit about intellectual humility.
  2. If you relinquish control of this code, you relinquish your seat of power, you’ll make yourself dispensable and that can’t possibly happen, you think you’re far too important for that. – I believe in good people, if you’re one of them I’ll fight to keep you. If there’s a squeeze, even the indispensable will get the push. In fact in my experience, the all-rounders are more likely to find new homes.
  3. Secretly in your heart you know it’s loaded with technical debt, years of warts strapped onto the sides, a catalogue of compromises and mud that doesn’t mirror the patterns of the outside world in the 21st century. – In fact I could probably find something open source that does the same thing. Quite frankly it’s an ugly baby that should have been put up for adoption or surgery years ago but your professional pride won’t admit it.

Captain Hyde can’t think of any good reason other than personal self-preservation or embarrassment that someone who is a single code owner would be unwilling for other people to work on and learn their code.

Maybe I’ve just been in management too long but I distinctly remember in my early coding years a call with a colleague in San Francisco where he said:

“Damn, you’re the only guy in the world that knows this stuff man”.

– at which point I felt that little clench inside that said. “I need to find and train my replacements up as soon as I can!”

A similar counterpart of mine in the US at the same time got thrown another pile of stock options every time he threatened to leave – that wasn’t my style as a developer and it’s not my style as a manager either.

Now despite all this ranting, there is another very real problem.

Developing collective code ownership from single points of failure on complex products is time-consuming, expensive and probably not what my business stakeholders want my team “wasting” their time on when we already have experts who are “perfectly capable of maintaining this themselves”.

It’s a fair point.

With a team who are willing to share but have no slack, if I want collective code ownership to succeed I’ve got to be able to market it properly.

Escaping the Oubliette (Part 1) – Topping

Share
Reading time ~ 3 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

Share
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!

Breaking The Seal (Part 2)

Share
Reading time ~ 2 minutes

In my first article on “breaking the seal” I described how this pattern applies to managing WIP on teams. There’s also a work/social concept that fits the same name with a different pattern…

Name: “Breaking the Seal”, “The Lid is Off” etc.

Analogy: When you open a new pack of good coffee there’s that great smell that comes out – suddenly everyone wants a brew.

Concept: Socially, many people are unwilling to speak up in a crowd or be the exception either in positive or negative situations. Fortunately for experienced agile teams, the social norm of staying silent has often become disrupted but you’ll need to break it back open once in a while and as a coach you’ll need to find ways to introduce it.

Being the first to speak up triggers team inertia; suddenly others’ voices will also be found.

How many times have you sat in a meeting where someone uses a term or concept you have no idea what they mean but you don’t speak up? How many other people in the room also have no clue but stay silent? This might be inertia, it might be fear or just an unwillingness to appear stupid. Particularly with technical teams where your career goal may be “technical guru” – being seen as wrong or not clued up may be a sign of weakness. Having a “wise fool” on the team breaks the seal on this but needs some caution applied.

In some organizational cultures it may not be socially acceptable to question more senior staff. This really gets to me. In fact, I’ll write another post dedicated to this.

Occasionally speaking up might be risky, particularly if there’s obvious management issues. (Nobody likes to speak about the elephant in the room when the elephant is in the room) In these cases arrange with a few like-thinking peers to take it in turns to be the one to raise issues so it’s not always you. This will also ensure that you’re not speaking alone with others relying on you to take the risks up every time.

On the more positive side, the “red cards” tool relies on this same concept for group self-facilitation. Where once it becomes socially acceptable to halt a problem or challenge others the team’s self-organizing capability steps up another notch.

Practice this in your own teams – challenge yourself and your peers to ask a dumb question or plug a rat-hole at least once a week.