Kommentierte Links (VII)
Ein interessantes und wichtiges Thema. Teamübergreifende Reviews sind mittlerweile in vielen Projekten üblich, teamübergreifende Retrospektiven nicht. Was ich bisher kannte sind Retros of Retros, in denen analog zum Scrum of Scrums Delegierte aus den einzelnen Teams zusammenkommen. Andy Park und Henrik Kniberg gehen einen anderen Weg: Übergreifende Retrospektiven finden nicht als einzelne, zentrale Veranstaltungen statt. Stattdessen gibt es zuerst parallele "Themen-Retrospektiven", z.B. zu Architektur, Programm-Management, etc. Erst danach kommt eine zentrale Veranstaltung, in der versucht wird aus den einzelnen Ergebnissen übergreifende Trends abzuleiten. Zuletzt werden die Erkenntnisse in größeren oder kleineren Runden in die Entwicklungsteams kommuniziert. Müsste man mal ausprobieren.
Die Geschichte in Kürze: am Pariser Flughafen ist eine Software namens DECOR im Einsatz, die nur auf dem Windows 3.1-Betriebssystem von 1992 (!) läuft. Probleme dieser Anwendung sind immer schwerer zu beheben, da sowohl kompatible Hardware als auch Entwickler mit derartig "historischen" Kenntnissen kaum noch zu bekommen sind. Was sich dahinter verbirgt ist ein grundlegendes Problem - viel zu häufig werden (Groß)Programme unnötig tief mit dem Betriebssystem verzahnt, so dass sie mit neueren Versionen nicht mehr funktionieren. Weil auch nachtragliche Anpassungen nicht vorgenommen werden (sagen wir es wie es ist - meistens aus Geiz) ist man plötzlich gezwungen sich vom technischen Fortschritt abzukoppeln, und damit auch von den aktuellen Standards in Sicherheit, Usability, etc. Dieses Beispiel aus Paris ist zwar extrem,
es ist aber kein Einzelfall. Und wie so häufig gilt: durch Sparen an der falschen Stelle macht man alles nur teurer.
Code Coverage ist erstaunlich häufig ein kontroverses Thema. Von "das bringt alles nichts" über "das geht nur mit bestimmten Leuten" bis zu "das führt nur dazu, dass alle Entwickler Getter-Setter-Tests schreiben" habe ich schon alles an Einwänden gehört. Ron Jeffries anscheinend auch, aber überzeugt hat ihn das alles nicht. Er bricht seine Argumente auf ein Gedankenspiel herunter:
Wenn es zwei Projekte gibt, die in fast allem identisch sind, von denen aber eines eine Codeabdeckung von 95% hat und das andere eine von 45% - in welchem werden Fehler in der Software wohl besser gefunden? Man kann eigentlich nur eine einzige ehrliche Antwort auf diese Frage finden, es sei denn man führt das Thema durch die Aufzählung unwahrscheinlicher Ausnahme-Szenarien ad Absurdum. Genau das scheint ihm passiert zu sein. Da ich derartige Diskussionen auch schon einmal miterleben musste hat er mein volles Mitleid.
Ein witziger Grundansatz. Statt zum x-ten Mal darüber zu berichten, wie Design Thinking, Lean Startup oder andere Vorgehensweisen zu innovativen Produkten führen (können) geht Rainer Gibbert den anderen Weg und zeigt auf was man tun muss um Innovationen zu verhindern. Der Hintergedanke: wer sich selbst in diesen Mustern wiedererkennt weiss, dass er etwas falsch macht. Und jedes dieser Antipattern ließe sich auch auf die Einführung von Agile/Scrum in Unternehmen anwenden:
-
Warten auf den großen Visionär
-
Gallische Dörfer (Auslagerung von Innovation in isolierte Abteilungen)
-
Mangelnde Offenheit und Fehlerkultur
-
Das falsche Mindset im Team
-
Fehlende Methoden und Prozesse
-
Innovation unter Druck
-
Innovation im Hamsterrad (kein Innehalten, kein Inspect and Adapt)
-
Innovation am Nutzer vorbei
Mir sind auch sofort einige Manager und Unternehmen eingefallen, die in genau in solchen Fehlverhalten unterwegs sind. Das Tragische daran: viele davon bemerken es nicht, selbst dann nicht wenn man es ihnen sagt.
Die Ergebnisse des
Barcamp Arbeiten 4.0, zusammengefasst auf 40 Seiten. Gar nicht so uninteressant, aber mal ehrlich - ein besserer Titel liess sich nicht finden?
