Bikeshedding is when development teams spend too much time on small items that don't really matter, like the color of the bikeshed in your offices.

Imagine if your development team has a huge project upcoming, and you need to make huge decision about: major architectural direction of the code, the new code principles for this upcoming codebase, how you will test it and release it etc - but in this meeting you can't seem to get off minor discussions like whether you will draw up all the technical planning in a PDF or a Markdown file on GitHub. This is a good example of bikeshedding.

Normally bikeshedding happens when people feel overwhelmed by big decisions that seem too difficult, but the "easier" decisions are much simpler to reason around so everyone feels like they can "chip in". This can lead to lots of voices all speaking about small issues they are comfortable enough to talk about, but don't really matter too much.

A healthy solution to bikeshedding is to try and solve the biggest issues first, and the "smaller" issues normally start to sort themselves. You finally planned out that huge project and how you can solve some of the issues? Then you've easily solved the PDF vs Markdown discussion, as PDF didn't work due to needing multiple people contributing so it ended up being a file in GitHub so the developers can push and pull to update it for example.