Seit mehr als 10 Jahren fordern Führungskräfte von Scrum Mastern,: „Agile Entwickler müssen schneller werden“.
“Schneller werden” ist nicht nur der Wunsch an Scrum Master, sondern eine Erwartungshaltung der Manager an agile Entwickler. Daran wird zusätzlich, unzulässig, die Qualität eines Scrum Master beurteilt.
Nicht selten entstehen Versuche, agile Entwickler anhand von Metriken messen zu wollen. Eine Metrik zur Messung der gesamten Wertschöpfungskette wird kritisch beäugt und abgelehnt. Führungskräfte sehen die Notwendigkeit ein, aber es sei leider ist alles historisch gewachsen – da kann man nichts machen.
Entwicklerteams werden kurzfristig zusammengestellt. Da ist alles Frisch, da geht doch was! Also liegt der Schlüssel zum schneller werden, ganz klar bei den Entwicklern.
Schließlich sind wir Agil. Wir “machen” Scrum. Also müssen Entwickler schneller sein als bei den klassischen Vorgehensweisen.
Agile Entwickler müssen schneller werden ist eine unzulässige, nicht agile Forderung.
Trotzdem muss die Frage erlaubt sein: “Schneller werden, im Vergleich wozu? Wie wird die Geschwindigkeit der Teams denn gemessen?”.
Die meisten Ideen der Manager wie Velocity über Teams vergleichen“ oder dem Einführen einer neuen Metrik zeugt vom „Nicht verstanden“ des Agilen.
Agile Entwickler müssen schneller werden ist, zu kurz gedacht
Abgesehen von diesem fundamentalen Missverständnis, sind die Gründe für diese Denkweise so vielfältig wie, falsch.
Agilität ist Adaption und Selbstreflexion sowie die Fähigkeit, Maßnahmen aus gewonnenen Erkenntnissen abzuleiten und umzusetzen. Dazu bedarf es einem agilen Mindset.
Scrum ist kein Garant für schnellere Ergebnisse oder schnellere Entwickler, sondern ein Framework um dem agilen Wirken Raum zu verschaffen, Agilität leben zu können. Scrum kann, wie alle agilen Methoden, nur dann sein volles Potential entfalten, wenn die gesamte Lieferkette berücksichtigt wird.
Von der Vision bis zur Betriebsübergabe.
Auf der Führungsebene wird diese Lieferkette gerne als Entwicklung verstanden und die Entwickler sind Synonym für jeden einzelnen Bereich der Kette.
Muss also der Entwickler schneller werden? Muss er schneller Code tippen? Schneller denken? Kann ein Entwickler solche Forderungen erfüllen?
Nein.
Agile Entwickler werden durch Reduktion der Tätigkeiten schneller
Professionelle Entwickler arbeiten am in der Regel am Limit. Da helfen weder Kicker noch Druck von Außen oder monetäre Anreize.
Diese Profis können nur noch durch Reduktion schneller mit Aufgaben abschließen. Reduktion des Unwichtigen, des Überflüssigen, von allem was nicht MUSS und keinen Impact auf die Qualität hat.
Das konsequente Befolgen des zehnten agilen Prinzips: Einfachheit – Die Menge nicht getaner Arbeit zu maximieren ist essenziell, bewirkt wahre Wunder. Die Stornierung aller Meetings, die nicht Bestandteil von Scrum sind, können ein guter Anfang sein.
Im Planungsmeeting auf Low-Tech setzen um das Bottleneck “Tastatur” zu vermeiden, kann die Produktivität um den Faktor 7 steigern.
Das sind nur einige Beispiele, wie Entwicklern ermöglicht werden kann, ihre Aufgaben in kürzerer Zeit zu erledigen.
Einfachheit ist essenziell
Eines jedoch ist sicher. Die Wartezeit bis ein Feature von der Vision bis in den Wartungsbetrieb kommt, verringert sich dadurch um keine Minute!
Wie das? Die Entwickler sind doch schneller geworden!
Jetzt sind wir beim Kern des Dilemmas.
Agile Entwickler warten schneller
Der Lieferzeitraum entspricht der Summe der Aufwände aller Bereiche der Lieferkette. Sind einzelne Bereiche nicht im agilen Sinne optimiert und die Übergaben an den Schnittstellen nicht synchronisiert, oder werden Übergaben durch politische Machtspielchen verzögert, erhöht sich unweigerlich die Lieferdauer.
Da können die Entwickler ihre Durchlaufzeit erhöhen wie sie wollen, die Lieferdauer eines Features wird dadurch nicht verkürzt.
Können agile Entwickler schneller werden
Jein. Die Forderung: “Die Entwickler müssen schneller werden” verkürzt keine Lieferzeiten. Dieses Inseldenken ist oft in den Unternehmen verbreitet, die sich mit ihrer “Agilität” brüsten aber maximal einen fahlen Anstrich von Agilität tragen.
Gerade in diesen Unternehmen arbeiten die Entwickler nach agilen Frameworks, das mit Command & Control, Termindruck oder anderen veralteten Methoden aus den 80er- Jahren, wieder ausgehebelt wird.
Ein Zitat das zu Command & Control passt. kommt von Mario Andretti, der Formel 1 Weltmeister von 1978:
„Wenn du glaubst alles unter Kontrolle zu haben, fährst du zu langsam“.
Es wird Zeit für ein gelebtes agiles Mindset der Führungsebene. Klare Ziele vorgeben, Freiraum schaffen und Feedback geben ist das Gebot moderner Führung. Erst wenn eine ganzheitliche Betrachtung und Optimierung von Value Streams erfolgt, Machtspiele und Titelreiterei ein Ende finden, dann werden Produkte schneller geliefert – selbst wenn die Entwickler nicht schneller geworden sind.
