Autor Dipl-Ing. Bonka Roustcheva
Standard und Agile Projektkennzahlen
Die traditionellen Projektkennzahlen dienen dazu, Projektfortschritt, Projektbudget und Projektqualität zu beobachten, rechtzeitig Risiken und Probleme zu identifizieren und diese zu beseitigen/lösen.
In den agilen Projekten ist es nicht viel anders! Als die am meisten verbreitete agile Methode ist Scrum prädestiniert, allen Stakeholdern maximale Transparenz zu bieten, und mit Professionalität (d.h. hoher Qualität, definiert in der DoD) stetig Mehrwert zu liefern (continuous delivery of business value). Also haben wir die Transparenz in dem Projektfortschritt unter Einhaltung der hohen Qualitätsanforderungen, die zu hoher Kundenzufriedenheit führen sollen.
Bei beiden Arten von Projektabwicklung, traditionell und agil, sollte man aber zwischen „internen“, entwicklungsrelevanten (delivery) und „externen“, management- und stakeholderrelevanten (owner) Kennzahlen unterscheiden.
Was man auch nicht aus den Augen verlieren sollte, ist das Hauptziel / die Hauptmotivation des Unternehmens. Dieses Ziel gehört unbedingt und ganz oben auf das Projekt-Dashboard!
WIR MÖCHTEN ERREICHEN/VERÄNDERN "WAS"
um "Zahl / %" bis "WANN"
Meistens ist der Übergang (Transition) zur Agilität aus einem bestimmten Grund beschlossen worden, und zwar um:
Dieser Grund kann bei der Formulierung des Hauptziels widergespiegelt werden.
Prinzipien für Kennzahlenauswahl
Bevor man zu den Vorschlägen zu entwicklungs-relevanten und management-relevanten Kennzahlen übergeht, einige Worten über die sinnvollen Kriterien zur Kennzahlenauswahl, die man anwenden sollte:
Es sind einfache Prinzipien, die keiner Erklärung bedürfen. Für manche Unternehmen, die sich in der Übergangsphase / Transition Phase befinden, ist es aber sehr schwierig, diese konsequent umzusetzen!
Entwicklungsrelevante bzw. Delivery-Kennzahlen:
Diese Kennzahlen dienen der Überwachung und Steuerung des Entwicklungs- und Auslieferungsprozesses. Sie sollten dem Team helfen, den Überblick über Terminplan / Schedule, Qualität und Effektivität der Arbeit zu behalten, und eine kontinuierliche Verbesserung zu erreichen.
Auch wenn wir allgemein über Owner-Kennzahlen sprechen, gibt es Unterschiede zwischen den management- und stakeholder-relevanten Kennzahlen. Z.B. interessiert es den Kunden nicht, wie hoch die Investitionskosten des Lieferanten sind, oder ob die Mitarbeiter zufrieden sind und effizient- den definierten Unternehmensprozess folgend-arbeiten! (Man kann hier auch zwischen externen und internen Kunden = Produktmanagement unterscheiden, was wir hier jedoch unterlassen, um den Rahmen nicht zu sprengen). Der Kunden interessiert es nur indirekt, wie innovativ das Lieferunternehmen ist, und ob es wächst.
Aber in beiden Fällen ist es wichtig, kostenneutral mehr Gewinn zu machen!
Management- und stakeholder-relevante bzw. Owner-Kennzahlen:
Diese Kennzahlen dienen der Überwachung und Steuerung von Kosten, Umsatz und Gewinn des Unternehmens.
Sie sollten dem Management-Team helfen, den Überblick über Terminplan / Schedule, Qualität und Effektivität der Arbeit zu behalten und rechtzeitig eine Risikominimierung oder Strategieanpassung zu unternehmen.
Es spricht nichts dagegen, dem Entwicklungsteam bzw. der Abteilung auch regelmäßig die Management-Kennzahlen zu kommunizieren und Bericht zu erstatten. Umgekehrtist ein Überblick über den Fortschritt der Entwicklung und der technischen Probleme für das Senior Management nicht uninteressant.
Aus den dargestellten Überlegungen und Fakten ist auch im Scrum-Umfeld ein Dashboard für die interne Unternehmens- und externe Kundenkommunikation notwendig, das die Überwachung / das Monitoring und die Transparenz im Projekt gewährleistet. Sinnvoll für die Überwachung des Projektfortschritts ist der Releaseplan Burn Up Chart. Man sollte die Kosten pro Sprint / pro Release und die Einnahmen pro Sprint / pro Release gut im Auge behalten. Die Software wird VON Menschen FÜR Menschen entwickelt! Also ist es sinnvoll, auch Trends in der Kunden- und Mitarbeiterzufriedenheit zu überwachen!
Schematisches Dashboard:
Das schematisch dargestellte Dashboard beinhaltet die üblicherweise sinnvollen Kennzahlen. Je nach Wichtigkeit für das definierte Unternehmensziel, kann die entsprechende Metrik höher in dem Dashboard ihren Platz finden.
Das Wesentliche im Überblick:
Die Projektmetriken sollten im Zusammenhang mit den Zielen und dem Fokus des Unternehmens gewählt werden!
Man sollte nicht in die Falle tappen, Metriken einzuführen, nur weil man etwas sehr leicht messen kann. Nicht alles, was man messen kann, macht auch Sinn gemessen zu werden! Typisches Beispiel hierfür: Lines of Code! Eine sehr große Gefahr besteht darin, verschiedene agile Metriken auch für Benchmarking zu benutzen, was man in dem traditionellen Projektmanagement üblicherweise macht! Ein typisches Beispiel hierfür wäre die Team Velocity!
Besonders gefährlich sind die Ego-Metriken. Diese Bezeichnung benutze ich für Kennzahlen, die eigentlich nicht unbedingt zur wirklichen Verbesserung der Qualität des Produktes, oder des Prozesses beitragen und durchaus auch Fehlverhalten stimulieren können. Ein gutes Beispiel dafür ist z.B Number of Daily Commits.
An dieser Stelle sei ein Zitat von Eli Goldratt erwähnt
„Tell me how you will measure me and I’ll tell you how I will behave“ – „ Sag mir, wie du mich beurteilen/ messen wirst, und ich sag dir, wie ich mich verhalten werde!“
Der Einsatz vom Scrum als Methodologie im Projekt bietet folgende Vorteile für die Metriken in dem vorgeschlagenen Dashboard:
1. Für die Überwachung des Projektfortschritts ist es sinnvoll, einen Release Burn Up Chart zu benutzen. Hier sei erwähnt, dass ein Burn Up Chart mehr Sinn für ein Agiles Projekt ergibt, als ein Burn Down Chart, da sich auch der Umfang des Projektes ändern kann, man aber eine gute Übersicht der erledigten Aufgaben / erzielten Ergebnissen hat.
Für die Überwachung des Sprint-Fortschritts ist ein Sprint Burn Down Chart sinnvoller!
2. Die Kennzahl Time to Market kann in einer agilen Projektumgebung um einiges verkürzt und zuverlässiger ermittelt werden. Durch die kurzen und häufigen Iterationen findet eine größere Anzahl von Releases statt, bei denen der Kunde neue Funktionalität(en) bekommt und benutzen kann. An dieser Stelle ist es interessant und nützlich zu wissen, wie lange die Stabilisierung eines Releases dauert und wie die Cycle Time ist (siehe Cycle Time Definition).
3. Die Innovation wird nicht nur durch die Lieferung neuer Funktionalität in jeder Iteration demonstriert, sondern kann auch durch das Grundprinzip der ständigen Verbesserung und die Anwendung von Scrum Patterns /Refactoring (d.h. die Wartbarkeit des Codes wird verbessert) gefördert werden.
4. Die Optimierung von Features und die Reduktion von unterstützten Versionen (Maintenance von unterschiedlichen Versionen sollte vermieden werden, um die Kosteneffizienz zu verbessern!) führt auch zur Steigerung der Innovationsfähigkeit.
5. Die Kundenzufriedenheit (siehe NPS Definition) steigert die Motivation der Mitarbeiter. Jeder ist stolz darauf und freut sich, für die Entwicklung eines großartigen Produktes beigetragen zu haben! Die Happiness Metrik hilft aber auch, die Zufriedenheit der Mitarbeiter zu überwachen und bei Bedarf Prozesse zu optimieren, oder Probleme rechtzeitig zu erkennen.
6. Produktkosten und Einnahmen erlauben es nicht nur der Entwicklungsabteilung, Management oder Stakeholdern sondern dem gesamten Unternehmen als ein Team das Erreichen des Hauptzieles zu veranschaulichen.
Über die Autorin:
Dieser Artikel ist im Zuge des Kooperations- Projektes von SPQR und Think-PI entstanden.
Die THINK π GROUP unterstützt Unternehmen bei der Gestaltung ihrer Prozesse und bei der Implementierung von Lean Management.
Dipl.-Ing. B.Roustcheva verfügt über mehrjährige Erfahrung auf dem Gebiet der kontinuierlichen Verbesserung und bietet durchgängige Prozessberatung an – vom Konzept bis zur Implementierung. Durch Workshops, Coaching und Interims Management lernen die Kunden Verschwendung zu erkennen, möglichst schlanke und flexible Prozesse zur Steigerung der Wettbewerbsfähigkeit zu gestalten und ihre Wertschöpfungskette zu verbessern.
PEOPLE - PROCESS – PERFORMANCE
Kontakt | Think-PI Group | www.think-pi.de | Impressum
IT-Beratung, Data-Management, App-Entwicklung, Konzeption und Enterprise Development