Zero Bug-Policy

Bild: Wikimedia Commons/JohnSka - CC BY-SA 3.0

Auf einem Projekt das ich letztes Jahr auditieren durfte konnte es die Delivery Managerin (so hieß dort die Scrum Masterin) nicht lassen über ihren ehemaligen Agile Coach herzuziehen. Der habe zwar ein paar gute Ideen gehabt, aber auch ein paar unsinnige. Beispielsweise hätte er eine "Zero Bug-Policy" gefordert. Als ob das umsetzbar wäre. Erwartungsvoll schaute sie mich an, in der Hoffnung, dass ich in ihr Gelächter einstimmen würde, doch den Gefallen konnte ich ihr nicht tun. Der Mann hatte nämlich völlig recht, bugfreie Software ist möglich. Und nicht nur das - sie ist sogar die Voraussetzung für agile Softwareentwicklung.

"Kann gar nicht sein", erwiederte die Delivery Managerin, Scrum Guide und Agiles Manifest habe sie beides gelesen, da würde nichts von Bugs stehen. Nun ja, nicht wörtlich, aber indirekt durchaus. Werfen wir einen Blick darauf. Zunächst der Scrum Guide: im Abschnitt Increment sagt er über das Sprintergebnis It must be in useable condition [...] und ergänzt im Abschnitt Definition of Done Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. Weiter mit dem agilen Manifest: in seinen Prinzipien legt es fest: We follow these principles: [...] Deliver working software frequently [...] Working software is the primary measure of progress. Software soll also "Usable" und "Working" sein, und um das sicherzustellen darf sie keine bekannten Fehler mehr enthalten. Denn selbst wenn die Fehlfunktion scheinbar gering ist - niemand kann sagen ob nicht weitere Funktionen auf dieser einen fehlerhaften aufbauen. Wenn das so ist können selbst kleine Bugfixes wirken wie das Entfernen des untersten Steins in einem Jenga-Turm - alles bricht zusamen. Also: Agilität erfordert eine Zero Bug-Policy.

Erneut musste die Delivery Managerin widersprechen. Für das Fixen aller Bugs wäre gar keine Zeit da, es müssten doch Deadlines eingehalten werden. Auch den Hinweis, dass die aktuell laufende Bugfixing-Phase den Release um drei Monate nach hinten geschoben hätte wollte sie nicht gelten lassen. Einen besseren Weg gebe es nun mal nicht, oder könnte ich einen nennen? Zu ihrem Pech - ja, ich konnte. Er nennt sich Andon und ist eines ältesten agilen Vorgehensmuster überhaupt. Übernommen aus dem Maschinenbau bedeutet er (vereinfacht gesagt), dass beim Auftreten eines Fehlers die Produktion neuer Features sofort angehalten und erst dann fortgesetzt wird wenn der Fehler behoben ist. Dadurch befindet sich alles immer in einem auslieferungsfähigen Zustand (Zero Bugs) und monatelange Test-, Bugfixing- und Retest-Phasen entfallen. Selbst wenn die Fehlerbehebung die Feature-Produktion kurzfristig verzögert ist der Gesamtzeitraum bis zur Fertigstellung kürzer, man spart also Zeit und Geld.

Sichtbar verärgert legte die Delivery Managerin ihr letztes Argument auf den Tisch. Das wäre ja alles schön und gut, und irgendwo würde das sicher funktionieren, ganz sicher aber nicht in ihrer Firma. Da wäre die Situation eine besondere, weite Teile der Anwendung könnte man nämlich gar nicht testen. Nun ja, ein klarer Fall von Truthiness. Um es mit einem Sprichwort zu sagen: ich kann den Menschen nur die Tür aufhalten, durchgehen müssen sie selber. Manchmal tun sie es nicht. Für alle Anderen (zum Glück die Mehrheit) gilt: eine Zero Bug-Policy ist machbar, sie beschleunigt die Entwicklung, spart Kosten und sie macht agile Softwareentwicklung überhaupt erst möglich.