A few years ago I was working at a company that was using Bugzilla for bug tracking. When we moved over to Subversion for source control, we decided to move over to Trac for our issue tracking / wiki needs. As we were preparing for the move, one of the team members spent some time investigating the migration of our data from Bugzilla to Trac. Various issues like field mapping, data scrubbing, etc… made us weary of the switch. It may seem like a strange question, but I had a hunch, so I offered up a simple question:
“Guys, do we even need to migrate this stuff?”
I was meet with scoffs of “Of course!”, but most of the justification was based on the simple fact that we had been tracking these things, so they HAD to be valuable, right? By throwing them away, we were wasting the effort it took to track them.
However, once we started to look back at the past 6-12 releases, we noticed that the features / bugs included in each release tended to be things that have recently popped up. Rarely, if ever, did we go back over a legacy bug and include it in a release. Instead, everything we were doing was either a recent customer requests or a new bug that we just discovered. It seemed as though everything that we weren’t hearing about really didn’t matter.
So what’s this got to do with Lean? Well, I quickly started to realize that bug trackers usually represent a repository for waste. We usually toss anything and everything into them. We do this with the idea that we’ll go back and do something with them at a later date, but that’s never the case. Later Never Comes. In reality, these issues / tickets / bugs just gather dust. They create a big lump of data that we need to wade through every time we interact with the tracking system. They become waste. But why is this the case? Don’t these items represent features that need to be added, bugs that need to be fixed or technologies to be investigated? Aren’t those things valuable?
Not necessarily. Once your software is released and customers are using it, you’ll find yourself inundated with feature requests & bugs from your actual customers. If you listen to your customers, they’ll tell you what’s important and what needs fixing. If they’re not asking for a particular feature, chances are it’s not really important. That kind of direction and feedback is a lot more valuable than some feature you added to your tracker 6 months ago.
Besides, even if you wanted to go back and tackle them, you face several roadblocks. For example, the issue my be incomplete or ambiguous or the original reporter could be gone. It could take you time just to figure out what the bug meant. In that case, you can find yourself chasing something that might not even be useful to anyone. It could have been addressed already without anyone knowing it. It could also have been for an older direction of the product that’s not being pursued anymore.
In my experience, things that are created with the sole intention of circling back and revisiting something are the worst kind of waste a system can product. Not only are you leaving something potentially broken / incomplete, but you now have this millstone that you need to carry with you wherever you go, limiting your agility. Don’t fall into the trap. Later Never Comes!