Instead of trying to reflect at the end of the week when you’re tired, leave it until Monday morning. You’ll be fresh, you’ll have had a chance to privately reflect on the last week over your weekend. Crucially, when you leave the meeting with new ideas about how to work, you’ll have a whole week ahead of you to try them out.

Instead of leaving work at the end of the week with no clear idea what you’ll be doing the next, get ahead of the game and make a plan before you leave on Friday. You’ll have prepared the ground for getting down to business almost straight away when you walk in on Monday morning, and I suspect this means you’ll enjoy a more relaxing weekend too.

I’ve never looked at things this way before, but now I do it makes perfect sense. Why not try it and let me know how it works for you?

On my way home I reflected on the root cause of the defect, and how we could have avoided it. The faulty code was pretty good: it read nicely and was obviously written test-first but there was a tiny leak in the logic, obvious enough with hindsight but easy to see how it had been overlooked. I pondered whether the with the investment of a little bit more attention at the time of writing, we might have saved my pair and I an afternoon of relatively tedious data-clean up. My reckoning was that we probably could have.

At the time the original defective code was written, the team were under a fair amount of pressure. As a start-up, we’re living on borrowed time, and we had a great product that was almost finished hidden away in private beta while our public offering languished behind the competition. There was real urgency to get the new product released. I’m extremely proud of the team that under that pressure we stuck to practices we knew were making us most effective: writing code test-first, working in pairs and keeping the code clean and defect-free as we went. Or so we thought.

On reflection, I’m surprised to find I’m perfectly comfortable with the fact that we allowed that bug to creep through. Given the option of going more slowly and avoiding these kind of fairly subtle mistakes, and going at the pace we did and getting launched when we did with the product we did, it seems to me that going more quickly was the right choice to make at the time. Despite the fact that the net amount of programmer time was eventually greater, we exchanged that cost for the benefit of being able to launch the product at an earlier date.

This is an extremely dangerous lever to fiddle with. A programming team that allows itself to make too many mistakes will certainly not be able to ship to a predictable schedule, and may never even manage to ship at all. We were lucky that the damage this bug made to the data could be completely repaired: a more serious error might have left us having to contact users and apologise for losing their data, for example.

In this case I think we got the balance just about right, but that took skill, experience, and probably a bit of luck too.

Yes, yes, smarty-pants: the ones you already know about.

Ten? Fifty? Two hundred? More?!

I find it frighteningly common to see teams let a huge backlog of bugs build up. They set up a trusted system like Jira or Bugzilla and then use it as a dumping bucket for a whole variety of irritations, glitches, missing features, and genuine defects.

Pretty soon the list becomes un-managably large. Nobody dares go in there, because it’s full of bad news. This drains the team’s energy and morale.

Getting on top of, and staying on top of your bug list is hugely important, and I outline my thoughts and experiences on achieving that below.

Draw Some Axes

There’s nothing like getting your bugs out of the tracker system and up onto the wall on a big, colourful, chart to really ram it into people’s faces that something needs to be done.

It’s also a terrific motivator as you start to get on top of the bug list and are rewarded with real visible progress on the wall.

A great simple tool for this is the bug-down ‘finger chart’. Grap your flip-chart or whiteboard pens, and let’s get stuck in.

• Draw an x-axis scale plotting days from today.
• Draw a y-axis scale going up to, say, 1.5 x the total number of bugs your tracker system knows about – open or closed.
• Mark a point for today at the total number of bugs, open or closed.
• Now beneath that, mark a point at the total number of closed bugs.

That gap between the two points is what you need to work on.

The beauty of this simple chart is that it shows you:

• How quickly you’re finding new bugs
• Whether you’re winning the war (is the top line going up steeper than the bottom line?)

Plot these points every day, and rotate the task so that everyone is in touch with the situation.

Turn Bugs into Features To Do

As James Shore says, many items in your bug tracker are probably features in disguise. If an application is in production, it’s hopefully usable in it’s current state, even if it’s doesn’t do everything you wanted it to do in every single scenario.

See how many of your bugs you can re-write like this:

BUG: Users without javascript can’t sign-up. The sign-up form uses AJAX and won’t work for users with javascript disabled.

STORY: As a user with javascript disabled, I want to be able to sign up for the site, so that I can use it like everyone else.

or, perhaps more cheaply:

STORY: As a user with javascript disabled, I expect to see a helpful message telling me that I need to enable javascript to use the site, so that I don’t feel excluded and confused.

Bingo! one less bug to fix. This feature or user story can now be prioritised and planned alongside all the other changes you’d like to make to the software.

Alternatively, take a buggy part of the product and write a story that says something like: As a user in the upload photo page, I expect the site to be bug-free. Now carry all the bugs relating to the photo upload with that story card, prioritise it, and when it comes out of development it should be shiny, gleaming and bug-free.

Bug Monday

Fixing bugs is demoralising. It’s no coincidence that they can usually be found in the grottiest bits of the code, where misunderstandings and mistaken assumptions abound. It’s no fun hanging out there. It’s hard work and requires a lot of energy. Some people find it easier than others.

We found that fixing bugs as a team effort really made a difference for us. The old adage ‘many hands make light work’ really comes into its own here, and by all mucking in together, the team can generate a bug-quashing momentum that no one or two individuals could compete with.

Much better to put the whole team of five onto bugs for a single, horrible day, than to force one poor bastard to do it for the whole week.

Talking of which…

Take, Don’t Give

Assigning bugs to particular people is very close to assigning blame. Anyone and everyone in the team should feel a collective responsibility to defeating and controlling the bug count, and hopefully most members of the team will feel confident enough to dive in to any area of the code to make a fix.

Having said that…

Specialize

Although I’m big on the XP principle of ‘no code ownership’, I’m also a pragmatist. If you wrote the WidgetFragulator last week while I was on holiday, and there’s a bug in the WidgetFragulator, it’s probably going to be quicker for you to fix it. It might, on the other hand, offer a great opportunity for me to get my head around the new code you wrote. Make a quick judgement within the team about what will give the most value, balancing long-term knowledge-sharing within the team against the short-term business benefit of getting the fix done ASAP.

Write a Test

If you’ve got a defect in your code, it’s usually for one of two reasons:

1. The guy who wrote it didn’t know what the software was supposed to do. What he implemented was correct to his understanding of what it was supposed to do, but his understanding was wrong.
2. The guy who wrote it knew what the software was supposed to do, but he made a mistake.

In the first instance, you may well be lucky enough to have an existing unit test that you can modify to specify the correct behaviour. In the second instance you certainly won’t.

By writing a unit test to reproduce the bug, you get to do something mildly creative, you save time tesing out different options for the fix, and you make sure that this particular bug will never go undetected again.

Aim for Zero Defects

David Allen’s excellent GTD methodology promotes a two minute rule: if it will only take two minutes, do it now!

Encouraging your team to take a similar attitude to defects saves everyone a huge amount of time. Rather than wasting effort finding defects, logging them in a tracker, reviewing the lists, prioritising them, re-reading them weeks later to figure out what the hell they mean… just fix it! Now!

This also promotes a culture within the team where everybody cares. They care about the quality of the product, and if they see a typo, they’ll take the time to stop and fix it before moving on.

Keep Shorter Lists

While David Allen’s excellent GTD methodology teaches us that having a trusted system where you can dump everything out of your head will elevate your mind and allow you to concentrate on the tasks at hand, lean thinking teaches us that maintaining long lists of anything is inventory, and inventory is waste.

These two guiding principles apparently contradict.

It’s easy to see how wasteful it is to keep a large system full of bugs: many of the entires may be out of date, for issues that have already been fixed, and each time you open one up you’ll have to waste 30 seconds figuring out if the bug is still relevant. Whatever you do, don’t let your bug-tracker become one great big ‘hmph’ pile for all the things your team can’t make a decision about.

For every bug in there, ask yourselves these quesions:

• Is this really a defect, or can we call it a new feature and prioritise it?
• If it’s a defect, why don’t we fix it this week?
• If we don’t need to fix it this week, when should we fix it by? Does it even matter if we never fix it?

Create Less Bugs

Finally, a really obvious point but one worth ramming home nonetheless. Using quality-focussed software engineering techniques like Test-Driven Deveopment, pair programming and refactoring will help you to quash bugs at source: when the code is written.

With our second major live release looming large on the horizon, I focussed the session on the theme of ‘Success’. My aim was to give the team a blueprint for a successful iteration to keep in mind when things were tough, and to help ensure that we were all pulling in the same direction by agreeing as a team what constitutes success for us.

I started by asking the team to score how successful, in their own mind, the last iteration had been, drawing a histogram on the flipchart of the results. Interestingly, there was quite a variance in the scores, with most people either grading the iteration 2/5 or 4/5, perhaps suggesting that different members of the team have different criteria for success, or that they just experienced the iteration differently.

I then asked them to reflect on the criteria they’d used to make that judgement, again in their own mind, capturing each of the criteria on a separate index card. We then spread the cards out on the floor, and mapped them into headings: teamwork, stability, delivery, happiness & joy… and a couple of others I can’t remember right now.

We then decided that our output would be some kind of vision statement under each heading, of the form “An iteration is a success when…” and worked through the various headings, discussing what it was that made us successful, and distilling that discussion into a bullet point on the chart.

Reflecting on what we’d covered, it seems to me that while the session was fun, motivating and affirming for the team, and thus valuable in it’s own way, it didn’t really enable us to focus on the major issues that are affecting us right now, such as the disruption of the recent office move. It also didn’t leave us with any concrete actions to take away and do in order to make things better. In terms of inspect and adapt, it really didn’t deliver.

When planning your retrospectives always remember your key goals (in priority order):

1. Try to smoke out the most significant areas of waste in the team’s production of quality software
2. Invent concrete actions you can take in order to reduce this waste
3. Build and motivate the team

Whilst building and motivating the team is an important goal for a session like this, it’s often a side-effect of successfully satisfying the first two. Concentrate on facilitating a session that helps reduce waste while having fun, and you’ve hit the nail on the head.