Agile Entwickler müssen schneller werden

Entwickler in der Maschinerie des Unternehmens

Seit mehr als 10 Jahren fordern Führungskräfte von Scrum Mastern, das die Entwickler schneller werden müssen.

“Schneller werden” ist nicht der Wunsch, sondern eine Erwartungshaltung, welche die Qualitätsbeurteilung eines Scrum Masters in einem messbaren KPI festzurren.

Die Einsicht, es müsse sich auch etwas in Führungskreisen ändern, ist gegeben. Leider ist alles historisch gewachsen – da kann man nix machen. Entwicklerteams werden kurzfristig zusammengestellt. Da ist alles Frisch, da geht doch was! Also liegt der Schlüssel zum schneller werden, exakt hier.

Schließlich sind wir Agil. Wir “machen” Scrum. Also müssen Entwickler schneller sein

Von aussen betrachtet wirkt diese Haltung wenig agil.

Trotzdem muss die Frage erlaubt sein: “Schneller, im Vergleich wozu? Wie wird die Geschwindigkeit der Teams denn gemessen?”. 

Meist folgt darauf eine Bestätigung des coming outs, durch den Vergleich mit anderen Teams, schlimmstenfalls unter Zuhilfenahme der Velocity. 

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, sondern ein Framework um dem agilen Wirken Raum zu verschaffen, Agilität leben zu können. Scrum kann 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.

Von der Vision bis zur Betriebsübergabe

Muss also der Entwickler schneller werden? Muss er schneller Code tippen? Schneller denken? Kann ein Entwickler solche Forderungen erfüllen?

Nein. 

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. 

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.

Fazit

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.

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.

Das "Agile CatchUp" Briefing

E-Mail eintragen und "Abonnieren" klicken. Fertig!

Mit dem Briefing erhältst du Tipps & Tricks zu Agile und Informationen rund um die Angebote von Frank Schatz. Mit Klick auf „Abonnieren“ akzeptierst du die Datenschutzbestimmungen und weisst, das du den Empfang von E-Mails jederzeit und in jeder E-Mail widerrufen kannst.