Ist eure Entwicklung auf Kurs?
In den letzten Jahren durfte ich in mehr als 15 Entwicklungsprojekten mitgestalten. Ein Thema, das immer wieder zu Reibung zwischen Management und Entwicklungsteams führt, ist die Frage nach „Transparenz“ und „Steuerbarkeit“.
Aus der gefühlten Not jetzt doch mal etwas Handfestes haben zu wollen, entstehen Metriken wie Lines of Code per Developer per Day. Sobald Menschen wissen, dass sie beobachtet werden, verhalten sie sich schon anders. Kennen sie die Metrik, tendieren sie dazu, diese zu beeinflussen. Bewusst wie unbewusst. Wird eine vertraulich angewandte Metrik öffentlich, führt das zu Vertrauenskrisen.
Nur mit Metriken wissen wir, ob wir noch auf Kurs sind
Wir brauchen Metriken, um Entscheidungen zu treffen. Softwareentwicklung ist kurzfristig enorm kostenintensiv, insbesondere wenn das Produkt noch nicht verkaufsfähig ist. Entscheider wollen also verstehen, wann mit einem Verkaufsstart zu rechnen sein kann. Oder wie lange das Budget noch reicht.
Grundsätzlich bin ich (heute) überzeugt, wir brauchen aussagekräftige und akzeptierte Metriken, um sicherzustellen, dass wir auf Kurs sind. Früher sah ich das anders.
Aussagekräftig und akzeptiert?
Eine Metrik ist dann aussagekräftig, wenn sie sich an einem Ergebnis/Ziel orientiert und den Fortschritt dahin bemisst.
Eine Metrik sollte von allen akzeptiert sein. Das bedeutet: Alle verstehen, wozu die Kennzahl nötig ist und tragen die Entscheidung zur Nutzung mit. Das bedingt Dialog. Idealerweise entstehen Metriken in Zusammenarbeit.
There is no easy path!
Die allermeisten Projekte setzen auf Burndown und Velocity Charts. Frage ich nach, höre ich entweder “Das kommt mit unserem Tool” oder “Das nutzen alle, wir daher auch”.
Für mich heißt das zunächst nur, dass man hier einen einfachen Weg eingeschlagen hat. Dafür spricht, dass Metriken zu Lead & Cycle Time, oder das Cumulative Flow Diagram, vergleichsweise selten aktiv genutzt werden.
Dabei können gerade diese beiden Charts auf Missstände frühzeitig hindeuten.
Softwareentwicklung ist mehrdimensional
Softwareentwicklung ist Produktentwicklung (Produkt, Prozess), eine Teamleistung und eine technologische Herausforderung.
Ich verwende in Entwicklungsprojekten gern Metriken, die diese Dimensionen berücksichtigen und mir einen ganzheitlichen Blick ermöglichen. So kann ich Probleme schneller erkennen und lösen, oder das System optimieren.
Praxis: akzeptieren Entwicklungsteams diese Metriken?
Die Metriken werden gemeinsam mit dem Team erarbeitet und leiten sich von konkreten Ergebnisanforderungen ab. So erleben die Metriken hohe Akzeptanz bei allen Stakeholdern. Quartalsweise findet ein Review und ggf. Anpassung statt.
Jetzt gilt frei nach Drucker “you improve what you measure”! Viel Spaß damit!
Sollte Interesse an dem Thema bestehen, freue ich mich über eine kurze Mail mit Feedback an me@erikmatt.de
