Bikeshedding: Warum dein Team stundenlang über Button-Farben diskutiert, aber das Hauptproblem ignoriert
Die Law of Triviality erklärt, warum Teams ihre Energie an den falschen Stellen verbrennen, und was du als Scrum Master dagegen tun kannst.
Stell dir folgende Szene vor. Dein Team sitzt im Sprint Review. Auf dem Tisch liegt ein Architekturentscheid, der die nächsten zwei Jahre eurer Produktentwicklung prägen wird. Drei Minuten Stille. Niemand stellt eine Frage. Der Product Owner nickt, der Stakeholder scrollt durch sein Handy. Dann kommt der nächste Punkt: die Farbe des neuen Call-to-Action-Buttons. Plötzlich hat jeder eine Meinung. Der Designer plädiert für Korallrot. Die Entwicklerin findet Blau vertrauenswürdiger. Der Product Owner erinnert sich an einen A/B-Test von 2019. Zwanzig Minuten später diskutiert das Team immer noch. Über einen Button.
Dieses Phänomen hat einen Namen: Bikeshedding. Oder formaler: die Law of Triviality. Der britische Historiker und Publizist C. Northcote Parkinson beschrieb sie 1957 in seinem Buch Parkinson’s Law mit einem Beispiel, das bis heute zitiert wird: Ein Gremium soll über den Bau eines Atomkraftwerks entscheiden. Der Milliarden-Antrag geht in wenigen Minuten durch. Dann kommt der Antrag für einen Fahrradschuppen (bike shed) neben dem Verwaltungsgebäude. Die Debatte dauert über eine Stunde. Der Grund: Jedes Gremiumsmitglied kann sich unter einem Fahrradschuppen etwas vorstellen. Beim Atomreaktor fehlt den meisten die Kompetenz, um überhaupt eine Meinung zu formulieren.
Fast siebzig Jahre später ist das Muster identisch. Nur die Schauplätze haben sich verändert: aus Gremien wurden agile Teams, aus Fahrradschuppen wurden Button-Farben, Icon-Grössen und Slack-Channel-Namen. Die Dynamik bleibt.
In diesem Artikel schauen wir uns an, warum Bikeshedding so hartnäckig ist, welche psychologischen Mechanismen dahinterstecken, wie es sich in agilen Teams manifestiert und was du konkret dagegen tun kannst.
Das Parkinson’sche Gesetz der Trivialität
Parkinson formulierte sein Gesetz nicht als Psychologe, sondern als scharfer Beobachter bürokratischer Organisationen. Er arbeitete Jahre im britischen Staatsdienst und dokumentierte, wie Institutionen Entscheidungen treffen. Seine zentrale Beobachtung: Die Zeit, die eine Organisation für die Diskussion eines Tagesordnungspunktes aufwendet, steht in umgekehrtem Verhältnis zu dessen tatsächlicher Bedeutung.
Das klingt absurd. Ist es auch. Aber die Erklärung ist nachvollziehbar.
Bei einem Atomreaktor versteht kaum jemand im Gremium die technischen Details. Die Reaktorkosten, die Sicherheitsanforderungen, die regulatorischen Auflagen: all das übersteigt das Wissen der meisten Beteiligten. Also vertrauen sie den Experten und winken den Antrag durch. Nicht weil der Antrag unwichtig ist, sondern weil die Hürde, eine kompetente Meinung zu äussern, zu hoch liegt.
Beim Fahrradschuppen ist das anders. Jeder hat schon einen gesehen. Jeder hat eine Meinung zu Dachform, Material und Standort. Die Einstiegshürde liegt bei null. Also diskutiert jeder mit. Und weil alle mitreden können, fühlen sich alle berechtigt, es auch zu tun. Die Diskussion expandiert, bis die Zeit abgelaufen ist oder jemand mit Autorität ein Machtwort spricht.
Parkinson beobachtete ein weiteres Detail: Die Teilnehmenden fühlen sich nach der Fahrradschuppen-Diskussion produktiver als nach der Atomreaktor-Entscheidung. Sie haben aktiv beigetragen, Argumente ausgetauscht und eine Lösung gefunden. Dass der eigentliche Wertbeitrag bei der Reaktor-Entscheidung lag, geht im Gefühl der Beteiligung unter.
Warum das Gehirn triviale Probleme bevorzugt
Bikeshedding ist kein Zeichen von Dummheit oder mangelndem Engagement. Es ist ein psychologisches Muster, das tief in der Art verwurzelt ist, wie unser Gehirn Entscheidungen trifft. Mehrere kognitive Mechanismen spielen zusammen.
Cognitive Ease: Der Weg des geringsten Widerstands
Daniel Kahneman beschreibt in Thinking, Fast and Slow (2011) zwei Denksysteme: System 1 (schnell, intuitiv, automatisch) und System 2 (langsam, analytisch, anstrengend). System 2 kostet Energie. Das Gehirn aktiviert es nur, wenn es muss. Bei einer Button-Farbe reicht System 1 vollkommen aus. Bei einer Architekturentscheidung müsste System 2 ran, aber das Gehirn vermeidet diese Anstrengung, wo immer es kann.
Das Ergebnis: Teams wenden sich instinktiv den Themen zu, die kognitiv leicht zugänglich sind. Nicht weil sie wichtiger sind, sondern weil sie weniger Denkarbeit erfordern.
Die Illusion der Erklärungstiefe
Die Psychologen Leonid Rozenblit und Frank Keil publizierten 2002 eine Studie mit dem Titel The Misunderstood Limits of Folk Science, in der sie die “Illusion of Explanatory Depth” beschrieben. Menschen glauben, alltägliche Dinge besser zu verstehen, als sie es tatsächlich tun. Frag jemanden, wie ein Reissverschluss funktioniert, und die Person wird sagen: “Klar, weiss ich.” Bitte sie dann, es Schritt für Schritt zu erklären, und die Sicherheit bröckelt.
In Meetings wirkt dieser Effekt verstärkend. Teammitglieder schätzen ihre Kompetenz bei vermeintlich einfachen Themen höher ein, als sie ist. Bei der Button-Farbe glaubt jeder, genug über UX, Farbpsychologie und Conversion-Optimierung zu wissen, um mitzureden. Bei einer Datenbankmigraton gibt niemand vor, Experte zu sein. Also schweigt das Team beim komplexen Thema und redet beim einfachen.
Soziale Dynamiken: Wer schweigt, verliert Sichtbarkeit
In jedem Team gibt es einen impliziten Druck, sich einzubringen. Wer in Meetings schweigt, wirkt desinteressiert oder inkompetent. Bei komplexen Themen riskiert man, etwas Falsches zu sagen. Bei trivialen Themen ist dieses Risiko minimal. Die Button-Farbe ist ein sicheres Terrain: Es gibt keine falsche Meinung, keine Blamage, keinen Gesichtsverlust.
Dieser Effekt verstärkt sich in Organisationen, die Beteiligung als Leistungsindikator werten. Wenn dein Chef erwartet, dass du in jedem Meeting einen “Beitrag” leistest, wirst du dir Themen suchen, bei denen das gefahrlos möglich ist. Das sind fast immer die trivialen.
Bikeshedding in der Software-Entwicklung
Der Begriff “Bikeshedding” wurde in der Software-Branche durch Poul-Henning Kamp populär. Kamp, ein dänischer Entwickler und langjähriger Contributor des FreeBSD-Betriebssystems, schrieb 1999 eine E-Mail an die FreeBSD-Mailingliste, in der er die endlosen Diskussionen über triviale Code-Details mit Parkinsons Fahrradschuppen verglich. Die E-Mail wurde legendär und der Begriff setzte sich in der gesamten Open-Source-Community durch.
Kamp beschrieb ein Muster, das jeder Entwickler kennt: Jemand reicht einen Pull Request ein, der eine komplexe Architekturänderung enthält. In den Code-Reviews kommentiert niemand die Architektur. Stattdessen gibt es zwanzig Kommentare zu Variablennamen, Einrückungen und der Platzierung von geschweiften Klammern.
Wo Bikeshedding in agilen Teams auftaucht
In meiner Arbeit als Scrum Master beobachte ich Bikeshedding regelmässig in verschiedenen Kontexten:
Sprint Planning: Das Team schätzt eine komplexe Story mit Abhängigkeiten zu drei anderen Teams in fünf Minuten. Dann verbringt es fünfzehn Minuten damit, die Akzeptanzkriterien einer trivialen Bug-Fix-Story zu perfektionieren.
Retrospektiven: Das Team identifiziert ein systemisches Problem (fehlende Testautomatisierung, unklare Produktvision, technische Schulden). Die Diskussion bleibt an der Oberfläche. Dann kommt jemand mit “Können wir den Stand-up von 9:15 auf 9:00 verschieben?” und die nächsten zwanzig Minuten sind verbraucht.
Refinements: Der Product Owner stellt ein Epic vor, das den Kern des Produkts betrifft. Stille. Dann fragt jemand nach dem Wording einer Fehlermeldung in einem Edge Case, und das Team stürzt sich darauf.
Code Reviews: Die Architekturentscheidung im Pull Request bleibt unkommentiert. Dafür gibt es eine Diskussion über die Reihenfolge von Import-Statements.
Slack und Teams: Ein Thread über die strategische Ausrichtung des nächsten Quartals bekommt drei Reaktionen. Ein Thread über den Namen des neuen Slack-Channels bekommt dreissig.
Die Kosten, die niemand misst
Bikeshedding wirkt harmlos. Eine zwanzigminütige Diskussion über Button-Farben bringt kein Projekt zum Scheitern. Oder doch?
Rechne es hoch. Ein Team mit sieben Personen verliert pro Sprint zwei Stunden an Bikeshedding-Diskussionen (eine konservative Schätzung). Das sind vierzehn Personenstunden pro Sprint. Bei zweiwöchigen Sprints und einem durchschnittlichen Stundensatz von 150 Franken ergibt das 2’100 Franken pro Sprint. Über ein Jahr: rund 54’000 Franken. Für ein einziges Team. Für Diskussionen, die keinen messbaren Wert erzeugen.
Aber die direkten Kosten sind nur ein Teil. Die indirekten Kosten wiegen schwerer:
Erstens: Entscheidungsmüdigkeit. Jede Diskussion, ob trivial oder bedeutsam, verbraucht kognitive Ressourcen. Ein Team, das seine Energie an Button-Farben verbrennt, hat weniger Kapazität für die schwierigen Entscheidungen.
Zweitens: Vermeidung komplexer Themen. Bikeshedding ist oft ein unbewusstes Ausweichverhalten. Solange das Team über Triviales diskutiert, muss es sich nicht mit den unbequemen Fragen auseinandersetzen: Stimmt unsere Architektur noch? Liefern wir das richtige Produkt? Sind wir als Team ehrlich zueinander?
Drittens: Frustration der Experten. Die Personen im Team, die bei den komplexen Themen beitragen könnten, erleben Bikeshedding als Zeitverschwendung. Über Zeit führt das zu Disengagement. Die besten Leute werden leise, ziehen sich zurück oder verlassen das Team.
Der Bikeshedding-Selbsttest für dein Team
Bevor du Gegenmassnahmen einleitest, lohnt sich eine ehrliche Diagnose. Die folgenden fünf Fragen helfen dir, das Ausmass von Bikeshedding in deinem Team einzuschätzen:
Zeitverteilung: Wie viel Prozent eurer Meeting-Zeit verbringt ihr mit Themen, die weniger als 10% des Projektwertes ausmachen?
Beteiligungsmuster: Gibt es Themen, bei denen alle reden, und Themen, bei denen nur eine Person spricht? Korreliert das mit der Komplexität oder mit der Wichtigkeit?
Entscheidungsgeschwindigkeit: Wie lange braucht euer Team für reversible Entscheidungen (Button-Farbe, Variablenname, Meeting-Zeit) im Vergleich zu irreversiblen (Architektur, Tooling, Prozess)?
Nachbesprechungen: Wie oft sagt jemand nach einem Meeting: “Das war produktiv”? Und wie oft stimmt das objektiv, gemessen am Output?
Eskalationsmuster: Werden komplexe Entscheidungen häufig vertagt, delegiert oder “nächste Woche nochmal besprochen”, während triviale Entscheidungen sofort getroffen werden?
Wenn du bei drei oder mehr Fragen ins Grübeln kommst, hat dein Team ein Bikeshedding-Problem.
Sieben Techniken gegen Bikeshedding
Bikeshedding lässt sich nicht eliminieren. Es ist ein menschliches Verhaltensmuster, kein Bug, den du fixen kannst. Aber du kannst Strukturen schaffen, die es eindämmen.
1. Timeboxing für triviale Entscheidungen
Die einfachste und wirksamste Technik. Setze ein explizites Zeitlimit für Entscheidungen, die reversibel und von geringer Tragweite sind. “Wir haben drei Minuten für die Button-Farbe. Danach entscheidet der Designer.” Klingt brachial. Funktioniert.
Timeboxing wirkt auf zwei Ebenen: Es begrenzt die Zeit direkt und es signalisiert dem Team, dass das Thema trivial ist. Oft reicht das Signal allein, um die Diskussion zu verkürzen.
2. Two-Way Door vs. One-Way Door
Jeff Bezos unterscheidet in seinen Shareholder Letters zwischen zwei Arten von Entscheidungen: “Two-Way Doors” (reversibel, korrigierbar) und “One-Way Doors” (irreversibel, schwer rückgängig zu machen). Two-Way Doors verdienen schnelle Entscheidungen. One-Way Doors verdienen gründliche Analyse.
Mach diese Unterscheidung in deinem Team explizit. Wenn eine Entscheidung auf dem Tisch liegt, frage zuerst: “Ist das eine One-Way Door oder eine Two-Way Door?” Button-Farben sind immer Two-Way Doors. Architekturentscheidungen sind oft One-Way Doors. Sobald das Team die Kategorie kennt, passt es sein Verhalten an.
3. Silent Writing vor der Diskussion
Bevor eine Diskussion beginnt, schreibt jedes Teammitglied seine Position in zwei bis drei Sätzen auf. Ohne Absprache, ohne Beeinflussung. Erst danach wird diskutiert.
Diese Technik, inspiriert von Amazons “Six-Pager”-Kultur und dem “Brainwriting”-Ansatz aus der Kreativitätsforschung, reduziert Gruppendenken und Ankering. Sie verhindert, dass die lauteste Stimme die Diskussion dominiert, und sie macht Bikeshedding sichtbar: Wenn sechs von sieben Personen “mir egal, Hauptsache konsistent” schreiben, braucht es keine Diskussion mehr.
4. Delegation Boards
Ein Delegation Board aus dem Management-3.0-Framework von Jurgen Appelo definiert für verschiedene Entscheidungskategorien, wer entscheidet. Die sieben Stufen reichen von “Manager entscheidet” bis “Team entscheidet vollständig”. Für triviale Entscheidungen delegierst du die Entscheidungskompetenz an eine Einzelperson (den Designer für visuelle Fragen, den Tech Lead für Code-Style-Fragen). Damit gibt es bei diesen Themen schlicht keine Gruppendiskussion mehr.
5. Die Fünf-Prozent-Regel
Führe folgende Faustregel ein: Wenn eine Entscheidung weniger als fünf Prozent des Sprint-Wertes betrifft, bekommt sie maximal fünf Prozent der Diskussionszeit. Ein Sprint mit 400 Story Points und zweistündigem Planning ergibt: Für eine Story mit 8 Punkten (2%) stehen maximal 2.4 Minuten zur Verfügung. Das zwingt zur Priorisierung.
6. Parking Lot mit Verfallsdatum
Richte ein “Parking Lot” ein: eine Liste von Themen, die während eines Meetings aufkommen, aber nicht sofort besprochen werden. Der Unterschied zu einem normalen Parking Lot: Jedes Thema bekommt ein Verfallsdatum. Wenn es innerhalb von zwei Wochen nicht besprochen wurde, verfällt es. Du wirst feststellen, dass 80% der Themen verfallen. Weil sie trivial waren.
7. Die Facilitator-Frage
Als Scrum Master oder Facilitator hast du ein mächtiges Werkzeug: die richtige Frage zur richtigen Zeit. Wenn eine Diskussion in Bikeshedding abdriftet, stelle eine dieser Fragen:
“Was passiert im schlimmsten Fall, wenn wir diese Entscheidung falsch treffen?”
“Wer im Team hat die meiste Expertise zu diesem Thema?”
“Können wir das in unter zwei Minuten entscheiden?”
“Ist das eine Entscheidung, die wir als ganzes Team treffen müssen?”
Jede dieser Fragen lenkt die Aufmerksamkeit zurück auf das Wesentliche: die Tragweite der Entscheidung und die Frage, ob eine Gruppendiskussion überhaupt nötig ist.
Bikeshedding als Symptom: Was dein Team dir eigentlich sagt
Bikeshedding ist selten ein isoliertes Problem. Meistens ist es ein Symptom für tieferliegende Dysfunktionen. Wenn dein Team chronisch über Triviales diskutiert, lohnt sich ein Blick auf die Ursachen.
Fehlende psychologische Sicherheit
In Teams mit geringer psychologischer Sicherheit (ein Konzept, das Amy Edmondson in The Fearless Organization beschreibt) vermeiden Teammitglieder Risiken. Bei trivialen Themen ist das Risiko gering. Bei komplexen Themen riskiert man, als inkompetent wahrgenommen zu werden. Bikeshedding ist dann ein Schutzmechanismus: Das Team diskutiert dort, wo es sicher ist.
Wenn du dieses Muster erkennst, ist die Lösung nicht “weniger Bikeshedding”, sondern “mehr Sicherheit”. Ermutige Fragen, normalisiere Nichtwissen, und reagiere konstruktiv, wenn jemand sich bei einem komplexen Thema exponiert.
Unklare Produktvision
Wenn das Team nicht weiss, wohin das Produkt sich entwickelt, fehlt der Massstab für Entscheidungen. Ohne klare Vision sind alle Entscheidungen gleich gewichtig: die Architektur ebenso wie die Button-Farbe. Eine starke Produktvision gibt dem Team einen Filter: “Bringt uns diese Diskussion näher an unser Ziel?” Wenn die Antwort “Nein” lautet, kann das Team sie abkürzen.
Fehlende technische Kompetenz
In manchen Teams fehlt schlicht die Expertise, um bei komplexen Themen mitzureden. Das ist kein Vorwurf. Wenn dein Team hauptsächlich aus Junior-Entwicklern besteht, wird eine Architekturentscheidung halt nicht breit diskutiert. Die Lösung: Baue Wissen auf. Pair Programming, Tech Talks, Architektur-Reviews mit externen Experten.
Zu viele Meetings, zu wenig Fokuszeit
Teams, die den ganzen Tag in Meetings sitzen, bringen nicht die kognitive Energie auf, um komplexe Probleme zu durchdenken. Bikeshedding wird dann zum Default-Modus: Das Team diskutiert, was es mit der verbleibenden mentalen Kapazität noch bewältigen kann. Reduziere die Meeting-Last. Gib dem Team Fokuszeit. Die Qualität der verbleibenden Diskussionen wird sich verbessern.
Ein Blick in die Forschung
Bikeshedding ist nicht nur eine Anekdote. Die Forschung bestätigt das Muster in verschiedenen Kontexten.
Eine Studie von Kühberger et al. (1995) zeigte, dass Entscheidungsträger bei Problemen mit grossen Zahlen (hohe Budgets, grosse Reichweite) weniger kritisch urteilen als bei Problemen mit kleinen Zahlen. Die Erklärung: Grosse Zahlen überfordern das System-2-Denken, und System 1 übernimmt mit einer schnellen, oberflächlichen Bewertung.
Forschung zu “Shared Information Bias” (Stasser & Titus, 1985, publiziert im Journal of Personality and Social Psychology) zeigt, dass Gruppen dazu neigen, Informationen zu diskutieren, die allen bekannt sind, statt einzigartige Informationen einzelner Mitglieder einzubringen. Triviale Themen sind per Definition “shared information”: Jeder kann zur Button-Farbe etwas sagen. Komplexe Themen bringen einzigartiges Wissen ins Spiel, das aber im Gruppendiskurs untergeht.
Auch die Forschung zu “Groupthink” von Irving Janis (1972) liefert Erklärungen. In kohäsiven Gruppen entsteht Druck zur Konformität. Bei komplexen Themen führt dieser Druck dazu, dass abweichende Meinungen unterdrückt werden. Bei trivialen Themen ist Dissens ungefährlich, also wird er ausgelebt. Das Ergebnis: hitzige Diskussionen über Kleinigkeiten, Stillschweigen bei den grossen Fragen.
Abschliessende Gedanken
Ich beobachte Bikeshedding in jedem Team, mit dem ich arbeite. Ausnahmslos. Und ich beobachte es auch bei mir selbst. Letzte Woche habe ich zwanzig Minuten damit verbracht, das perfekte Icon für einen Confluence-Seitentitel auszuwählen. Den eigentlichen Inhalt der Seite habe ich in der Hälfte der Zeit geschrieben. Das Icon hat kein Mensch bemerkt.
Diese Ehrlichkeit ist wichtig, denn Bikeshedding ist kein Problem “der anderen”. Es ist ein menschliches Muster, dem wir alle unterliegen. Die Frage ist nicht, ob dein Team bikesheddet. Die Frage ist, ob du es erkennst und steuerst.
Ich halte nichts davon, Bikeshedding komplett ausmerzen zu wollen. Ein Team, das nie über Kleinigkeiten diskutiert, ist kein effizientes Team. Es ist ein Team, in dem sich niemand traut, den Mund aufzumachen. Gesunde Teams streiten auch über Triviales. Der Unterschied liegt im Verhältnis: Wenn die Button-Farben-Diskussion mehr Raum einnimmt als die Architekturentscheidung, stimmt etwas nicht.
Als Scrum Master sehe ich meine Rolle darin, dieses Verhältnis zu steuern. Nicht mit Verboten (”Wir diskutieren jetzt nicht über Farben”), sondern mit Struktur. Timeboxing, Delegation, die richtige Frage im richtigen Moment. Und vor allem: mit der Bereitschaft, die unbequemen Themen auf den Tisch zu bringen, die das Team lieber vermeidet.
Denn das ist der Kern von Bikeshedding. Es geht nicht um Button-Farben. Es geht um die Architekturentscheidung, die keiner ansprechen will. Um die technische Schuld, die alle kennen, aber niemand benennt. Um das Feedback, das überfällig ist, aber zu riskant scheint.
Die Button-Farbe ist der Fahrradschuppen. Die Frage ist: Wann sprecht ihr über den Reaktor?