Ich lese gerade das neue Buch von Mary und Tom Poppendieck: Leading Lean Software Development und ich bin hin und weg. Da werden mit leichter Hand strategische Einsichten zusammengetragen und verständlich gemacht. Wenn wir die Scrum-Brille aufhaben, etwa als ScrumMaster, starten wir die Betrachtung beim Team, helfen dem Team effektiv zu arbeiten und eine Umgebung zu sichern, die eine solche effektive Arbeit dauerhaft sichert. Manchmal hört die Betrachtung auch da auf, und man fasst den Rest als „organisatorische Impediments“ zusammen. Die Poppendiecks fangen am anderen Ende an: sie betrachten den Prozess, wie man ihn optimiert, seine Probleme beseitigt. Sie kommen dann auch zum Team und zu optimalen agilen Arbeitstechniken, begründen diese aber oft anders. Für mich ist diese Herangehensweise deshalb so eine wertvolle Ergänzung zu meiner Scrum-Brille, weil ich dadurch oft überraschende neue Argumentationen für die Skalierung von Scrum in großem Maßstab oder überhaupt für die Einbettung in organisatorische Prozesse bekomme. In diesem Fall stellen sie die Forderung, das System als ganzes zu betrachten („systems thinking“) und identifizieren fünf Aspekte der konventionellen Lebenserfahrung, die als Prozesse oder Vorgehensweisen ein Problem geworden sind.
- Komplexität
- Fehlgeleitete Skalierung
- Trenne der Entscheidungen von der Ausführung
- Wunschdenken
- Technische Schulden
Zu viel Komplexität
Viele Softwareysteme enthalten viel zu viele Features und die Komplexität der Software steigt mehr als linear damit an. Und of gibt es Bedingungen, unter denen suggeriert wird, dass der Umfang der Systeme nicht verhandelt werden kann. Irgendwann schlägt dann die Realität zu und man muss sich doch entscheiden: Termin verschieben oder Scope verkleinern. Dann ist aber das Kind schon inden sprichwörtlichen Brunnen gefallen: Zeit und Arbeit sin in Features geflossen, die noch nicht oder nie genutzt werden. Ein weiterer verstärkender Faktor sind Metriken, die ein solchen Verhalten noch unterstützen: Messen der Produktivität in Lines of Code oder Function Points suggerieren einen Erfolg auch bei der Produktion unnützer Features und starten einen verhängnisvollen Feedback-Zyklus.
Fehlgeleitete Skalierung
oder: das Denken in batch-and-queue ist uns schon so fest eingebrannt, dass wir es oft nicht einmal mehr erkennen, wenn wir es in der Suppe finden. Bei komplexen Entwicklungen geht es nicht darum, die Ressourcen (hier: Menschen) optimal auszulasten, sondern den Durchfluß zu optimieren. Das führt zu einem Prozess, der sehr schlecht auf Überraschungen reagiert, bei dem Arbeiten unterbrochen werden müssen und Multitasking und nutzloser Streß endemisch sind. Das gilt auch und gerade für die Praxis von Jahresbudgets für Entwicklungen, die man in keiner Weise seriös abschätzen kann, die aber oft achselzuckend als „so macht man es eben“ akzeptiert werden.
Trennen der Entscheidungen von der Ausführung
Es gibt immer noch den Irrglauben, dass Manager nicht verstehen müssten, was ihre Mitarbeiter tun. Solche Manage können auch keine Hilfen geben und keinen Beitrag zur Lernprozessen leisten. Auf der anderen Seite ist in solchen Kulturen oft die einzige Möglichkeit aufzusteigen, seine technische Expertise brachliegen zu lassen und Personalverantwortung zu übernehmen. Wenn das keine Verschwendung ist…
Wunschdenken
In der Entwicklung gehen wir allzu oft mit einer geadezu naiven, unwissenschaftichen Attitüde an Aufgaben heran. Wir prüfen nicht die Nützlichkeit eines neuen Werkzeugs, produzieren keine Prototypen, haben keine systematische Methode, aus unserer Arbeit Erkenntnisse zu gewinnen. So viel wußte aber sogar schon Frederick Taylor.
Technische Schulden
Wir tolerieren unfertigen Code, zwingen Entwickler zu unrealistischen Zeitplänen, sparen am Refactoring und wundern uns dann über Wartungskosten und unzureichende Qualität.
Scrum und die Verschwendung
Wenn man jetzt wieder die Lean-Sicht mit der Scrum-Brille vertauscht, wird man diese Beschreibungen alle wiedererkennen:
- Zu viel Komplexität wird mit einer rigirisen Priorisierung im Product Backlog bekämpft
- Einer fehlgeleiteten Saklierung setzt Scrum das selbstorganisierte Team entgegen, das am Ende jeden Sprints ein fertiges Inkrement liefert
- Viele Entscheidungen und die Ausführung liegen in der Hand des selbstorgniierten Teams
- Wunschdenken verhindern wir, indem wir es nach jedem Sprint in einer Retrospektive aufdecken und Konsequenzen ergreifen
- Technische Schulden entstehen nur, wenn man nach dem Sprint keinen potentiell auslieferbaren Code produziert hat
Meine Konsequenz? Der Blick über den Tellerrand lohnt sich immer wieder. Manchmal ändert sich nichts an der Arbeit, aber es gibt neue Ideen und Argumentationen. Und in diesem Fall kommt noch dazu, dass es wirklich ein gutes Buch ist.