July 25, 2015

Bottleneck, Where Art Thou?

  —Tools can create process bottlenecks in unexpected ways.

I've been reviewing the tools we use to help us develop software. Tools affect process and shape workflow. They colour how we view the work we do.  Some examples: Review Board provides support for identifying the reviewers of a patch. Bugzilla provides support for prioritizing tasks.

I identified our use of Bugzilla as an problem almost immediately. We use the priority field of a task to create a workflow. The highest priority tasks are tackled first. Unfortunately, Bugzilla doesn't manage priority as a list. It forces you to group tasks into a small number of priorities. As a result, multiple tasks can have the same priority.

The problem with multiple tasks having the same priority is that the software team, not the business ends up determining what to work on first. This is fine if the team is capable of arriving at the same decision as the business. If the team makes a mistake they produce less business value than they could have.

It took longer to identify Review Board as a tool that undermined our work flow. Peer review is a new process. To the team's credit, they embraced it and created a working agreement to ensure its use. Our agreement calls for a review of all code prior to committing it to production and for at least two people to participate in the review.

About six months after we deployed Review Board reviews began to bottleneck. The authors said they couldn't commit to production because the patches hadn't been reviewed. The reviewers said they were too busy to complete the reviews. The drop in commits to production occurred because code reviews stopped. The team was committed to reviews but a bottleneck developed.

In effect, the reviewers had been asked to review the patch, had agreed to do so, but didn't have the time to follow through. The authors identified the reviewers in Review Board and accepted that they would eventually get the promised review. I ultimately concluded that the team's commitment to performing reviews coupled with the working agreement created the problem.

We treated the decision to review a patch as final and never went back to revisit it. This was eye opening. Two positive behaviours: commitment and peer review conspired against us because we accepted that identifying reviewers ahead of the review as sufficient.

What I learned about Bugzilla is that it's a poor task management system. Using Bugzilla the way we use it encourages a form of lazy prioritization--no one in the decision process was forced to decide what task to do first and so the grouping of tasks is what became important. Bugzilla appears designed to encourage this. This loss of advantage manifests itself whenever there are multiple high priority tasks.

With Review Board I discovered that the act of identifying the reviewers before the review created a form of paralysis within the team. Our focus on commitment and delivery made us blind to the fact that we needed to be more agile in our decision making.

Bugzilla made me want a product and sprint backlog. [1] It's great for tracking issues but not in the manner we use it. Review Board reminded me that agility can come in many different forms and a lack of agility can create bottlenecks whose root causes can be surprising.

[1] I am aware of ScrumBugz and the Mozilla hosted version at ScrumBu.gs. I haven't investigated it.

2018-06-06:

The scrumbu.gs website is offline. The link to this site has been removed.