Category: bugs

My Agile Team: More Code, More Problems

March 16, 2009 by mattgrommes

Picture courtesy of sa ku ra on flickr

Welcome to the newest installment of My Agile Team, my team's ongoing series of misadventures in trying to get better at Agile development. This time around, we're still playing Whack-A-Mole on the list of bugs we've encountered since Go Live. We stomp one out, another pops up.

What I'm going to discuss this time is our approach to trying to fix these critical bugs while maintaining at least a semblance of our Agile nature. It's hard to do a planning meeting and decide on what to work on when you've got new things popping up and old things dragging on. Read on for more on how we're planning in the midst of firefighting production bugs.

Accounting for bugs the agile way - part II

March 6, 2009 by Jack Milunsky

Last weeks post struck a cord with readers and as a result I got some really good feedback. Based on the responses I decided to use this week's spot to clarify my position on some of the issues as I see them.

I believe that ...

1. Teams should do whatever they can to fix bugs that are found during the sprint in which they're found. The definition of "Done" means the feature is coded to standards, unit tested, functionally tested, documented and all known bugs are resolved during the sprint. If you postpone bugs, what seems trivial at first will mean significant build up of technical debt which you will need to pay for downstream.

How We Actually do it: Accounting for Bugs in an Agile World

February 27, 2009 by Jack Milunsky

Today I'd like to share with you a really important aspect of Agile software development - how to account for bugs in your daily plans.

I am frequently asked by teams I consult with how to deal with bugs if you're Agile and using Scrum. Questions like the following come up time and time again:

"Should I track hours burned fixing bugs?"
"Should the hours burned on fixing bugs count toward my Story Point velocity?"
"When do you schedule bugs and should this be done during Sprint planning?"

You Need to Account For Bugs

My company is often working on many simultaneous projects and having to juggle resources. To get everything done on time and bug free requires careful planning. As a result we have to ensure that we're considering all aspects of software development including bug fixing. Bottom line is Bugs take time to fix and so you have to account for them. If you don't, you will have an inaccurate measure of your teams productivity - something that will definitely lead to poor planning and late deliveries. (....read more)

Stories From The Battlefield: #2 - My God, It's Full Of Bugs!

December 12, 2008 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

The Bet

Let's bet: I will buy you one pint of beer for every minute it takes me to find an embarrassing bug in your code.

Admit it, you have no chance of winning this bet. Ever. Finding bugs in somebody else's code is dead easy. Preventing them is next to impossible. Well, on second thought, scratch the "next to" part.

There is this user story acceptance criteria of "No known bugs should exist" - yeah, right. If you are a Project Manager (agile or otherwise) and your developers tell you they produce bug-less code, and that they do enough testing to be sure their code is healthy, they are either delusional, or are liars - I don't know which is worse. If you have a consultant who claims that they have a cure for bugs and will make your projects clean and shapey, do yourself a favor and fire him. Or better yet, do everybody else a favor and shoot him on the spot. The world will be a better place.

The Rant

Which brings me to the subject of this post - bugs. The most fundamental, yet easily forgotten fact of life is that all software sucks. All software has bugs. If yours does not, then it means only one thing - nobody uses it. Some of the best software I have ever seen has so many bugs that they overflow their bug trackers' bug counters. And you know what? It is actually a good thing! The existence of bug reports means somebody is using the software and actually cares to report back to you that he is having a problem with it, instead of just deleting it from their hard disk.

Oh My God, They Fixed the Bug!

July 1, 2008 by JurgenAppelo

A year ago, when I bought my new car, I noticed that the knob on the gear stick was loose. I was able to rotate it 360 degrees. I assumed that it was not supposed to be delivered that way, but I didn't care. In fact, while driving my car for a year, I got used to this bug and it turned out that I actually liked it. The knob rotated with the movement of my hand while shifting gears, and I kind of thought that was cool. And I liked fumbling with it while waiting for traffic lights to turn green. (Which, in my country, amounts to a lot of fumbling.)

Well, last week I turned in my car for its first scheduled maintenance. And after I got it back, while driving home happily in my serviced car, I suddenly noticed something was wrong... I was feeling resistance to my fumbling. I was unable to rotate the knob on the gear stick. It appeared that the service guy had fastened it! A jolt of anger shot through my system.

Oh my god, they killed the bug. (You bastards!)