Tag: prioritising

Delivery, Delivery, Delivery

When I started this job it was towards the end of a big release. I witnessed a long and painful bug-fixing period, and got to thinking about what improvements could be put in place to make the next release smoother. It soon became apparent though, that the releases all year had been late, and as such a backlog of work had built up. What also became apparent was that all of this work was contractually required to be delivered by the end of 2010. My first full release was certainly going to be interesting, if not smooth…

According to the PMs all of the required work would fit into the time we had, but unfortunately the estimates that this assertion was based on had all been provided by individuals who would not actually deliver the work, or by developers who had been forced to ‘estimate’ to a specific figure. In my mind these so-called estimates are pretty worthless, as the whole point of estimating is to be able to plan well (in many environments it’s also to cost things up, but in our case the costs are already fixed by the overall contract), but more on estimation in a future post…

So we ended up in a situation with the resource, time and scope were effectively fixed – not ideal.

We mitigated this to a degree by ensuring we worked on the right things first. Although the overall scope was fixed, there are usually ‘nice-to-have’ features that the business can truly live without. The business owners weren’t used to having to prioritise in this way – we had to gain their trust, and explain that we weren’t planning to drop their features, rather we needed to avoid a situation where if the sh*t really did hit the fan, we wouldn’t be left with critical features not implemented, based on their advice. This seemed to work okay, and we had more confidence that we were working on the right things in the right order. We also tightened the testing feedback loop by getting the testers to test everything in an earlier environment. This reduced the total cycle time to deliver bug-fixed requirements.

Even after those minor improvements, it was a tough release. The team worked a lot of overtime, something I hope to avoid in future. We worked late nights and we worked from home some weekends. When we worked in the office at the weekend we had to get portable heaters in as it was so cold that our fingers were seizing up, and when it really started snowing we booked people into hotels so they could carry on working instead of leaving early.

And we delivered. We got the release out on time, and we partied when it was all over. Would I want to do another release like that again – no way… However there was something positive about the team pulling together to beat the odds. It was a time when we worked hard and played hard together, and it’s still one of the releases that some of those involved talk about with a wry smile.

Input Queues => More Output

One of the first ‘quick wins’ that we’ve implemented is to let the development team manage their own workflow. A bug tracking tool was in place when I arrived (a good thing as there were a LOT of bugs, but more on that later) but the process in place was for Project Managers to ‘manage’ these bugs by assigning up to three bugs at a time to any given developer.

Maybe it gave the PMs some sense of security that ‘all bugs are assigned, therefore we will fix them and deliver on time’ but I’d argue that this is a false sense of security.

There are a few other things wrong with this approach:

  • How can a developer be working on three things at once?
  • How does the PM know the best person to work on a particular bug?
  • Not all bugs are equal – one might a be a tiny copy change, another could mean a fundamental problem in an important component.

We resolved this by introducing the concept of a prioritised input queue. Between us, we (Dev Team Leads) and the PMs would triage new bugs into the queue, constantly re-prioritising it so that we have collective control of which bugs get looked at next.

The developers then just have to pick the next bug off the list that makes sense for them to work on. We’d usually set some rule like ‘you have to pick from the top three bugs’, so that Developers have some control and ownership of what they work on, and still ensuring they’re working on the one of the most important things for the business.

In our case the input queue was a physical one – a new column on the Kanban board that’s in place on our giant whiteboards. We’d add a new post-it to the input queue for each bug triaged into there.

This worked well as it reduced the amount of time wasted in context-switching every time a developer was ‘assigned’ a new bug, and each bug got to the relevant person more quickly and with less fuss. The hardest part was persuading the PMs to relinquish the perceived control that they had over the process.

By introducing the input queue, we were able to demonstrate that we’d be able to waste less time, and therefore fix more bugs, by managing our own workflow.