As a small software company, we’re constantly evolving. Especially in a sector like ours, where change is very often driven by external factors. But that doesn’t mean that we don’t have to cope with problems that other (more “traditional”) companies also face.
A few years ago, we were going through a turbulent period. This was some years after we did a lot of new hires, and it was beginning to show. We didn’t have the time to educate the people we hired to work on the level we expected, and as a result, the quality of the code was not as it should have been. This in turn resulted in lots of bugs that needed to be fixed and we couldn’t bill the customer for them.
We (the management) were of course not happy with the course of events, so we wanted to stay on top of it and avoid further escalation. More specifically, we tried to keep the amount of time spent fixing those bugs as minimal as possible. We have developed our own tool for internal use to track effort time spent on the various issues, and in those days we divided those issues into stories (aka “new stuff”) and tickets (aka “bugs”).But effort spent on tickets and stories kept escalating, and that meant that the deadlines were being missed.
Our already grumpy customers were becoming more and more agitated, so a solution had to be found. One of the proposals was that next to the estimates that development gave for each issue, we should also add another metric, the effort that was still expected to be spent on the issue. So let’s say that there was a story that a validation check on the e-mail field of the input screen for a new user needed to be added and that development estimated they needed 16 hours (or “points”) to implement it. After a few days, maybe it still wasn’t finished (for whatever reason), but now the original estimate was exceeded and so the extra metric kicked in and development would need to do an additional estimate to indicate how much time there was still needed to actually finish the story. And they would have to update it daily, until the story was done.
At first it seemed like a good idea, it would give us the information we needed to tell the customer whether we would be able to ship in time or how much overtime there would be (or which features we would need to cancel or postpone). But very soon it appeared to me that we weren’t actually solving anything. We were just adding a new layer of bureaucracy to the “failing” system. The original estimate was wrong, and overtime was being spent. We didn’t need any additional (possibly wrong) estimates to tell us how wrong we were. We just needed to fix the original problem: improve our estimates and improve the code quality to avoid bugs!
Another example (maybe more familiar to some) could be that management requires a late team to issue a daily “status report” until the situation improves. They’re not really adressing the problem, instead they are just giving the overburdened team just more work and more stress!
So once that dawned on us, we canceled that feature and ever since then we call something that just registers the problem instead of fixing it “institutionalizing your problems”. In another article I’ll elaborate on how we managed to fix the original problems we had.
Author Wout Neirynck is owner of Debreuck Neirynck and an experienced agile developer with strong focus on TDD