- Eine rund 45-köpfige Engineering-Organisation setzt pro Quartal eine Woche lang Roadmap, Design und Meetings aus und veranstaltet eine „Fixit-Woche“, um sich auf kleine Bugs und Produktivitätsprobleme zu konzentrieren
- Bei diesem Fixit wurden 189 Bugs behoben, 40 Personen nahmen teil; der Median lag bei 4 geschlossenen Bugs pro Person, das Maximum bei 12
- Mit einer Regel zur Lösung innerhalb von 2 Tagen, einem Punkte- und Leaderboard-System sowie T-Shirt-Belohnungen werden Motivation und Team-Moral gestärkt
- Durch den Einsatz von AI-Tools wurden Code-Erkundung und Änderungsvorschläge beschleunigt und die Last von Kontextwechseln reduziert
- Fixit trägt zur höheren Produktreife und stärkerem Teamzusammenhalt bei und wird als Kultur bewertet, die die Freude am Lösen kleiner Probleme wiederbelebt
Konzept und Ablauf von Fixit
- Fixit ist eine fokussierte Bugfix-Woche, die jedes Quartal stattfindet und in der reguläre Roadmap-Arbeit, Design und Meetings vollständig ausgesetzt werden
- Engineers beheben kleine Fehler oder Produktivitätsbremsen, die Nutzer und Entwickler bisher gestört haben
- Beispiele: eine seit 2 Jahren unklare Fehlermeldung, ein Glitch bei gleichzeitiger Nutzung von Scrollen und Zoom, CI-Verzögerungen durch langsame Tests
- Es gibt zwei Regeln
- Kein Bug darf mehr als 2 Tage in Anspruch nehmen
- Die Arbeit konzentriert sich auf Verbesserungen für Endnutzer oder höhere Produktivität für Entwickler
- Ein Punktesystem und Leaderboard machen die Beteiligung sichtbar; für Kategorien wie „erster Bugfix“ oder „nervigster behobener Bug“ gibt es T-Shirt-Belohnungen
Ergebnisse von Fixit
- Resultate dieses Fixit
- 189 behobene Bugs, 40 Teilnehmende, Median von 4 pro Person, Maximum von 12
- Wichtige Beispiele
- Eine 2021 eingereichte Feature-Anfrage für Perfetto wurde innerhalb eines Tages umgesetzt und verbesserte die User Experience
- Durch eine Korrektur der GitHub Action wurde die Zahl der Klicks reduziert, die UI-Entwickler für Build-Zugriff benötigen
- Die Bereitstellung einer integrierten SDK-Version erleichterte die Projektintegration und wurde in etwa einer Stunde umgesetzt
Wirkung von Fixit
-
Produktsicht: Detailgenauigkeit und Reife
- Ein gutes Produkt zeichnet sich durch Aufmerksamkeit für Details und Konsistenz aus
- Fixit bietet die Chance, die Produktqualität auf die nächste Stufe zu heben, indem kleine Reibungspunkte entfernt werden, die Nutzer womöglich nicht einmal bewusst wahrnehmen
-
Individuelle Sicht: Zufriedenheit durch Umsetzen
- Es ist eine Rückkehr zu dem unmittelbaren Erfolgserlebnis aus frühen Karrierejahren: „Problem finden → beheben → ausrollen“
- Während Fixit liegt der Fokus weniger auf „Was bauen wir?“ als auf „Wie verbessern wir es?“, wodurch sich Erfolgserlebnisse in kurzen Zyklen ansammeln
-
Teamsicht: Mehr Moral und Zusammenarbeit
- Wenn 40 Personen über zwei Zeitzonen hinweg gleichzeitig Bugs beheben, steigt die Energie im gesamten Unternehmen
- Im Chat werden Fixes in Echtzeit geteilt, Screenshots gepostet und Demos gezeigt
- Jeden Morgen werden Anzahl der Fixes, Zahl der Teilnehmenden und Leaderboard-Platzierungen geteilt, was die Motivation weiter erhöht
Voraussetzungen für ein erfolgreiches Fixit
-
Vorbereitung
- Über das Jahr hinweg werden Bugs als „good fixit candidate“ markiert und in der Woche vor Fixit in klein, mittel und groß (0,5/1/2 Tage) eingeteilt
- Je nach Größe werden 1, 2 oder 4 Punkte vergeben und eine priorisierte Bugliste erstellt
- Dieser Vorbereitungsprozess ist der Schlüsselfaktor, um Chaos am ersten Tag zu vermeiden
-
Die 2-Tage-Regel
- In der Vergangenheit gab es einen Bug, der komplizierter als erwartet war und die gesamte Fixit-Woche aufbrauchte
- Danach wurde die Regel eingeführt, bei mehr als 2 Tagen Aufwand abzubrechen und den Bug zurück ins Backlog zu verschieben, um ein kontinuierliches Gefühl von Fortschritt zu erhalten
-
Umfang der Teilnahme
- In der Anfangsphase mit 7 Personen gab es zwar Ergebnisse, aber zu wenig Resonanz in der gesamten Organisation
- Erst bei rund 40 Personen entstand eine kritische Masse, die kollektive Energie und Immersion maximierte
-
Gamification
- Bei den Punkten geht es mehr um Spaß als um Präzision (1/2/4 Punkte)
- Leistungen werden breit anerkannt: erster Fix, nervigster Bug und weitere Kategorien
- Das System ist von Performance-Bewertungen getrennt, damit die Beteiligung intrinsisch bleibt
- Dank sozialer Normen und Teamgröße gibt es praktisch keinen Missbrauch des Systems
Die Rolle von AI-Tools
- AI reduziert die Belastung durch Kontextwechsel, eine Kernherausforderung bei Fixit
- Relevante Dateien lassen sich schneller finden und zusammenfassen, was die kognitive Last senkt
- Beispiele
- Das Ergebnis ist eine schnellere Annäherung an den Startpunkt; in manchen Fällen sind sofortige Korrekturen möglich
Kritik an Fixit und Antworten darauf
-
„Heißt das nicht, dass Bugs sonst ignoriert werden?“
- Zum Teil stimmt das, ergänzt aber die Realität, dass kleine Ärgernisse (papercut bugs) in der Priorisierung oft nach hinten fallen
- Fixit ist ein Mittel, explizit Zeit für kleine, aber wichtige Probleme zu reservieren
-
„Ist es nicht Verschwendung, die Roadmap-Arbeit anzuhalten?“
- Der Einsatz von 40 Personen für 1 Woche ist groß, wird aber durch höhere Produktreife und größere Nutzerzufriedenheit ausgeglichen
- Produktivitätsgewinne wie schnellere Tests, klarere Fehlermeldungen und kürzere Workflows wirken langfristig nach
-
„Funktioniert das nicht nur in Großunternehmen?“
- Auch kleine Teams können das Format als „Fixit Friday“ oder zweitägiges Mini-Fixit anpassen
- Entscheidend sind fokussierte, geschützte Zeitfenster und gemeinsame Verbesserungsarbeit
Der eigentliche Wert von Fixit
- Das offizielle Ziel ist die Verbesserung von Produktqualität und Entwicklerproduktivität
- Der inoffizielle Grund ist die „Freude daran, etwas zu reparieren“
- Es wird als essenzieller Bestandteil gesehen, um die Zufriedenheit einfacherer Zeiten zurückzuholen und eine Kultur sorgfältiger Produktentwicklung zu bewahren
2 Kommentare
Das erinnert mich an die Pitstop-Kultur von Baemin. Soweit ich gehört habe, gibt es sie inzwischen nicht mehr.
Hacker-News-Kommentare
Die Idee gefällt mir, aber der Satz „Ein Bug sollte nicht länger als 2 Tage dauern“ wirkt seltsam.
In der Praxis ist es fast unmöglich vorherzusagen, wie lange ein Bugfix dauern wird, bevor man den Bug tatsächlich behebt.
Allerdings denke ich, dass es, sofern kein großes Refactoring nötig ist, kaum etwas gibt, das länger als einen Tag dauern sollte.
Ich behandle Bugs normalerweise nach Schweregrad oder Priorität. Je schwerwiegender ein Bug ist, desto überraschend häufiger lässt er sich leicht finden.
Wenn die Ursache einmal gefunden ist, geht die Lösung schnell.
Wir haben jahrelang die Logs analysiert, ohne die Ursache zu finden, bis wir entdeckten, dass er sich mit einer bestimmten Kombination aus DB-Zustand und Commit zu 100 % reproduzieren ließ.
Wir haben eine NDA unterschrieben, ein minimales reproduzierbares Binary gebaut und das Ganze mit einem PowerShell-Skript automatisiert; einen Monat später hatte MS den Fehler behoben.
Intern fühlte es sich wie ein Buffer Overflow an, sicher war ich mir aber nicht.
Wenn ich eine ganze Woche lang nur Bugs behoben und in Jira keine Story Points gesammelt hatte, kamen mehrere Manager auf mich zu und fragten, warum meine Geschwindigkeit so niedrig sei.
Die Lektion daraus war also: schwierige Bugs meiden und Arbeiten ohne Punkte möglichst früh aufgeben.
Man weiß nicht, ob der Fehler im Code, Compiler oder in der Hardware liegt, und zusammengesetzte Bugs, die durch mehrere gleichzeitig verkettete Faktoren entstehen, lassen sich oft nicht einmal isoliert reproduzieren.
Wenn sich in solchen Fällen schnelle Workarounds ansammeln, führt ein späterer sauberer Bugfix oft zu einem groß angelegten Rework.
Außerdem gibt es in Low-Trust-Umgebungen Fälle, in denen man wegen Jira-Prozessen nicht einmal kleine Bugs sofort beheben kann.
Als ich bei Meta gearbeitet habe, gab es jedes Quartal eine Fix-it Week.
Anfangs dachte ich, dass sich die Führung wirklich um Qualität kümmert, aber in Wirklichkeit war es eher eine Lizenz, technische Schulden anzuhäufen.
Während einer Woche wollten wir Bugs beheben, aber wegen der bereits aufgelaufenen Schulden konnten wir fast nichts lösen.
Andernfalls stapelt sich neuer Code auf dem Bug und es entsteht ein instabiles Fundament.
Auch in John Romeros Vortrag wird dieselbe Philosophie betont.
Entwickler erledigten alte TODOs und erhöhten so die LOC; manche schrieben absichtlich schlechten Code, um ihn später zu „korrigieren“ und so mit Tricks die Anzahl der Diffs zu erhöhen.
Also Zeit für Probleme, die nicht dringend sind, aber stören.
Wichtiger ist, dass die Führung die Business-Prioritäten ehrlich erklärt und die Auswirkungen von Bugs auf Nutzer klar sichtbar macht.
Ich habe schon einen Teufelskreis erlebt, in dem sich während der Feature-Entwicklung Notfalleinsätze und Prioritätswechsel ständig wiederholten.
Am Ende ist das System voller Workarounds und weder Kunden noch Entwickler sind zufrieden.
In so einer Situation denke ich oft, man hätte lieber gleich stoppen und grundlegende Bugs beheben sollen.
Die Kommunikation bricht zusammen, und Führungskräfte rennen wie kopflose Hühner herum und geben nur noch Anweisungen.
Entwickler werden zu Feuerwehrleuten für alle Probleme degradiert, und am Ende ist Weggehen die einzige Lösung.
Je langsamer es wird, desto mehr gerät die Führung in Panik, wirft das Projekt wild um und verstärkt so Chaos und toxische Kultur.
Ich habe immer nach der Philosophie gearbeitet: „Bugfixes zuerst“.
Wenn bestehende Funktionen nicht korrekt arbeiten, baue ich keine neuen Funktionen.
So lässt sich eine fehlerfreie Codebasis erhalten und die Produktivität des Teams steigern.
Vor allem im Frontend ist ein vollständig bugfreier Zustand wegen verschiedenster Umgebungsprobleme fast unmöglich.
Außerdem ist die Definition von „Bug“ unscharf, sodass Manager manchmal gewünschte Features als Bugs klassifizieren.
Zum Beispiel kann ein Fehler auf einer kaum genutzten API-Seite weniger wichtig sein als ein neues Feature.
Die meisten sind geringfügig, deshalb bevorzugt die Führung eher neue Features.
Ich betreibe ein kleines SaaS-Produkt und halte mich an das Prinzip „Bugs zuerst beheben“.
Ich löse zuerst Bugs, die von Kunden gemeldet wurden, bevor ich neue Features angehe.
So werden neu entdeckte Bugs allmählich seltener und lassen sich auch leichter beheben.
Geschäftlich mag das ineffizient sein, aber in Bezug auf Qualität und Kundenvertrauen ist es die beste Strategie.
Kunden freuen sich wirklich, wenn ein von ihnen gemeldeter Bug innerhalb weniger Stunden behoben wird.
Regelungen wie eine Fix-it Week fördern eher die Verzögerung von Bugfixes.
Es entsteht die Ausrede: „Machen wir später in der Fix-it Week.“
Stattdessen sollte man in Quartals- oder Sprint-Planungen Wartungszeit ausdrücklich einplanen.
So haben Entwickler eine legitime Grundlage, Bugs sofort zu beheben, und eine Kultur kontinuierlicher Verbesserung kann sich etablieren.
Eine Fix-it Week wäre eher sinnvoll, wenn sie wie ein Mini-Hackathon mit kleinen Verbesserungen oder POCs betrieben würde.
In meinem früheren Unternehmen wiederholte sich immer derselbe Zyklus.
Dieses Muster war ein Signal für eine kaputte Organisationskultur. Wenn man sich im Alltag keine Zeit für Bugfixes schafft, ändert sich das nie.
Ich musste an den Joel Test denken, den Joel Spolsky früher vorgestellt hat.
Die fünfte Frage darin lautete: „Beheben Sie Bugs, bevor Sie neuen Code schreiben?“
Auch nach 25 Jahren ist das noch immer ein gültiger Maßstab.
Link zum Original
Ich bin der Meinung, dass man Bugs keine Punkte oder Größenschätzungen geben sollte.
Wenn man unbedingt Punkte braucht, kann man einfach überall 2 vergeben, dann passt es im Durchschnitt.
Bugfixes sollte man nach Kanban-Art nach Wichtigkeit abarbeiten und innerhalb der verfügbaren Zeit abschließen.
Ich bin der Autor. Es freut mich, dass so eine lebhafte Diskussion entstanden ist.
Sie war kein Ersatz für technische Hygiene oder die Lösung großer Probleme.