Process Bikeshedding

Hopefully we’re all familiar with Parkinson’s law of triviality:

Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively.

One anti-pattern to watch out for in retrospectives is what I would call process bikeshedding.

Topics like these tend to get a disproportionate amount of coverage in retrospectives:

• The length of sprints (2 weeks or 3 weeks?)
• On which day to start the sprints (Monday or Wednesday?)
• On which day to have the sprint planning meeting (first day of this sprint or last day of previous sprint?)

They come up over and over because they’re simple, easy to have an opinion on, and no one’s feelings will be hurt by discussing them. Unfortunately, this also means they’re trivial—i.e., not impactful to the delivery of working software to production (the purpose of a sprint).

So how does a team get beyond the trivial to discuss the real stuff? That’s the tough part. But I believe it comes down to trust and scope.

People need to trust each other in order to discuss deep concerns. There’s no magic to building trust. It just takes time.

In Parkinson’s example of the nuclear power plant, why are people so focused on the bikeshed while ignoring the design of the plant itself? I’d say it's an issue of scope. Luckily on a Scrum team we’re not approving designs for a nuclear power plant (hopefully); we’re just trying to improve the next two weeks on our software project.

In this video on Scrum retrospectives, Jeff Sutherland cuts the scope:

You only want to fix one thing at a time.

What is the one thing, that if we fixed it, would have the biggest impact on making this team go fast? And then commit to fix it.

Certainly the color of the bikeshed is not that one thing.