Agile Entwickler mĂŒssen schneller werden

Entwickler in der Maschinerie des Unternehmens

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.

Ich wĂŒnsche dir eine stressfreie Zeit.
Frank

Frank Schatz

Frank Schatz

Als Trainer, Mentor und Coach ist Frank Schatz vielleicht einer der gefragtesten T-Shaped Agilisten im deutschsprachigen Raum. Er ist geprĂŒfter SachverstĂ€ndiger fĂŒr agiles Projektmanagement und seit ĂŒber 25 Jahren IT-Unternehmer, Agile Work Experte und Certified Instructor. Frank Schatz, damit es agil wird.

Agile Work

Die Agile Transformation

Agiles Mentoring