You may remember my previous post about pair problems and my pointing out how we've stopped much of our pairing and our bug rate hasn't gone up.
Let's just pretend I never said any of that. Regrettably, our bugs have evolved and have learned to crawl deeper underground and are more difficult to root out. Superficially it looked like we were getting more work done and, initially, I think we were. Somewhere along the way, though, things started breaking down and in the space of only two weeks the programmers have requested that we slow down and go back to pairing and management has agreed. Despite the agreement, we're not pairing and the workload doesn't seem much slower, but we're still struggling to find the best way to get work done which satisfies everyone. It's clear that we're still turning out a lot of work, but failure to spread business knowledge has been what's really biting us -- hence the bugs.
I suspect that management is either going to have to babysit us through this period (which I doubt they will) or we programmers will have to find a way to work it out amongst ourselves.
Let's just pretend I never said any of that
I have to admit that I snickered slightly when I read that. Sorry
Despite the agreement, we're not pairing and the workload doesn't seem much slower
I've found that moving to shorter iterations for a bit can sometimes help with this. It forces you to make the stories smaller, which means that people get to work on more stories in the same period of time. The more different stories you get to work on, the more domain knowledge you need to cover, so you have to pair more to keep up. You also get the end-of-iteration reality check a bit more often which will stop you wandering off-course.
Might be worth a go.
Re:Shorter iterations may help
Ovid on 2004-07-25T17:48:15
We have one-week iterations. We've wanted longer ones, but I think that shorter iterations have been a benefit when we get a bit sloppy.
Re:Shorter iterations may help
Adrian on 2004-07-27T16:00:25
We have one-week iterations.Scratch that advice to try shorter iterations then
:-) We've wanted longer ones, but I think that shorter iterations have been a benefit when we get a bit sloppy.That's been pretty much my experience. Longer iterations work well if things are going okay, and moving to shorter ones helps when there are problems.
If there's any sort of quantitative incentive for knocking off bugs--even if it's indirect incentive such as bragging rights--the easy bugs will go first, and the harder ones will tend to get avoided until they're unavoidable.
Have you tried treating bugs like any other story? Let your customer (or customer proxy) prioritize them and decide which go into the mix for an iteration. This has the benefit of keeping a single set of priorities, and helps avoid cherry picking on small problems, or playing hot potatoe with big ones.
Re:Evolving bugs
chromatic on 2004-07-25T16:26:50
It also lets you put the time spent fixing bugs into the "how's our estimating?" feedback loop./p.
Re:Evolving bugs
Ovid on 2004-07-25T17:46:17
We do treat bugs like other tasks. The only major exception is bugs that affect the availability of our site or our data inputs/feeds. Those are almost always "drop everything and fix them now." Our data is what we get paid for (the Web site is a free bonus to many of our customers) so we can't afford to drop the ball there.
