June 14, 2017

Bottleneck, Where Art Thou (New Tools, Same Problems)

  —Changing tools doesn't mean the bottlenecks change.

In Bottleneck, Where Art Thou, I discuss how our use of Review Board and Bugzilla conspired to produce bottlenecks. Blindly accepting the workflow imposed by tools can create poor outcomes. To improve our workflow the team moved to JIRA and Confluence with goal of abandoning Bugzilla. We evaluated Crucible but remained with Review Board.

Two months following the introduction of JIRA code reviews remain a bottleneck. Team members often position code reviews as something to do in addition to everything else they need to complete. Reviews piled up on individual to do lists just as before.

Well, almost like before. JIRA provides tools to manage workflow. We use the JIRA Agile simplified workflow: "To Do" progresses to "In Progress" then "Done". We use stories and tasks, so a bottleneck means that tasks stay "In Progress" longer.

A student suggested changing our workflow to address the code reviews. They suggested placing "In Review" between "In Progress" and "Done" much like in Every team needs kick-ass code reviews. Seems simple enough. [1]

Except workflows seldom get simpler as they age. They get bigger and complex.

Adding a state tells the team and I what we already know. It identifies tasks in the bottleneck. A state doesn't bring us closer to the solution. It may even deflect from a solution.  A better solution improves the timeliness of code reviews. A state doesn't improve timeliness. It draws attention to deficient time management.

A better solution enables better time management for tasks requiring code reviews. Our code reviews require that at least two people review a change. This means tasks involve three people: the author and two reviewers.

The default implementation of a JIRA task and the JIRA Agile simplified workflow has the potential to shape our workflow in a disadvantageous manner. A task in JIRA has a single owner. JIRA makes is very easy to add new states. There is a conflict between our workflow and the defaults provided by JIRA.

If you assume the team is committed to code reviews but struggles with execution ask why. Does a single task owner mean they are solely responsible for it? Does this place team members in competition for completing tasks? If competition exists, does this imply that team members are likely to complete their tasks before they help their peers?

If there is any truth to competition then a better solution is to change a JIRA task to include reviewers. Or introduce tasks for code review.

We went with multiple owners for tasks in the hope that this provided a greater sense commitment to tasks and allows team members to better coordinate their work. If not, we can always add a new state and watch the reviews pile up there.

[1] Another student had a similar idea. Their rationale for "In Review" was management might be interested in task status. Management isn't asking and we didn't have a compelling reason for adding "In Review" that helped the team.