Projekte sollen agiler werden. Doch in vielen Fällen beschränken sich Unternehmen dabei nur auf die Einführung von Scrum als neue Vorgehensweise. Wenige Wochen später stellt man fest: die umliegenden Unternehmensprozesse passen nicht zu der gewählten agilen Vorgehensweise. Da die meisten Projektleiter agiles Projektmanagement und Scrum gleichsetzen, wissen sie nicht, wie man in dieser Situation weiter vorgeht.
Foto: stockfour - shutterstock.com
Folgende drei Vorschläge sollen helfen, agiles Projektmanagement unabhängig von der gewählten Arbeitsmethode in Großunternehmen zu verankern. Wichtig dabei ist, dass es bei den Beteiligten vor allem auf die richtige Denk- und Arbeitsweise beziehungsweise die Haltung ankommt, weniger auf Prozess- und Methodenwissen.
1. Wirksame agile Teams aufsetzen
In agilen Projekten wird viel Wert auf teambasierte Arbeit gelegt. Doch wie setzt man ein gut funktionierendes, wirksames agiles Team auf? Wie kann ein agiles Team das Projekt optimal unterstützen und das Unternehmen nach vorne bringen?
Mit den nachfolgenden fünf Schritten lässt sich ein wirksames agiles Team aufsetzen:
Eine Gemeinsame Mission geben
Menschen arbeiten am besten zusammen, wenn Sie ein gemeinsames Ziel verfolgen. Agile Teams sollen daher mit einer gemeinsamen Mission beziehungsweise Aufgabe ausgestattet werden. Idealerweise soll das Team Verantwortung für das Gesamtergebnis (Projektergebnis oder Ergebnis eines Arbeitspakets) übernehmen und im Rahmen des festgelegten Verantwortungsbereichs eigenständig agieren.
Die Mission beschreibt üblicherweise einen Zielzustand, hält aber den Weg offen, um dorthin zu gelangen. Zur Definition dieser Mission gehört auch eine klare Abgrenzung gegenüber anderen Teams oder Themen (Teamgrenzen).Mit Kompetenz ausstatten
Das Team soll mit genügend Kompetenzen ausgestattet werden, um seine Mission zu erreichen. Idealerweise besteht ein agiles Team aus den Mitarbeitenden, welche die festgelegte Aufgabe ohne weitere Unterstützung fachlich lösen können. Darüber hinaus soll das Team mit genügend Entscheidungskompetenz haben, damit es im Rahmen seines Verantwortungsbereichs schnell vorankommen kann.Ermächtigende Team-Struktur bauen
Wichtig ist die Trennung von Rollen und Menschen. Die Rollen sind üblicherweise über die Arbeitsmethode vorgegeben, zum Beispiel durch Scrum oder Kanban. Die Rollen können fest oder rollierend besetzt werden. Das Team muss passend zusammengestellt sein, um alle Rollen möglichst optimal und zu jeder Zeit besetzen zu können.
Hier empfehlen sich cross-funktionale Teams - besetzt mit Mitarbeitenden aus unterschiedlichen Bereichen: zum Beispiel Informatik, Fachbereich, Produktentwicklung oder Rechtsabteilung. Neben der Teamzusammensetzung muss auch die Teamgröße mit Bedacht gewählt werden. Nicht zuletzt müssen Verhaltensregeln explizit definiert werden, zum Beispiel was in Ordnung ist und was nicht (Eskalationspfad). Viele agile Teams setzen dafür einen „Team-Vertrag“ auf.Unterstützendes Umfeld schaffen
Projektleiter und beteiligte Führungskräfte sollen eine Umgebung schaffen, in der das Team optimal arbeiten kann. Besonders interessant ist hier der Umgang mit Informationsbedürfnissen, zum Beispiel das Reporting nach aussen oder die Interaktion mit den Stakeholdern und dem Lenkungsausschuss. Die Arbeitsweise des Teams muss akzeptiert sein und durch die Linie getragen werden. Anforderungen an das Reporting sollen im Vorfeld vereinbart werden.
Darüber hinaus muss das Belohnungs- beziehungsweise Anreizsystem mit der Arbeitsweise des Teams kompatibel sein. Es muss unbedingt sichergestellt werden, dass individuelle Zielvereinbarungen der Teammitglieder mit dem Teamziel kongruent sind. Für die Erfolgsmessung empfehlen sich agile Metriken statt traditioneller projektbezogener KPIs.Coaching und Erfahrungsaustausch ermöglichen
Die Anwendung der gewählten Arbeitsmethode sollte idealerweise durch Experten überprüft werden. Manchmal bringt die Arbeitsmethode eine dafür geeignete Rolle mit, zum Beispiel Scrum Master oder Service Delivery Manager (bei Kanban). In einem neu aufgesetzten Team können Coaches helfen, dass das Team zusammenwächst und mit der Eigenverantwortung klarkommt.
- Vision, Werte und Sinnstiftung als Leitplanken des Erfolgs
Prägen Vision und Werte meinen Arbeitsalltag? Kenne ich meinen Beitrag zum Unternehmenserfolg? Empfinde ich meine Arbeit als sinnstiftend? - Feedback und Fehlerkultur als Grundlage der Zusammenarbeit
Wie schaffen wir mit konstruktivem Feedback mutiges Verhalten? Wie werden Konflikte als Ressource genutzt? Wie werden wir durch eine Fehlerkultur erfolgreicher? - New Leadership ermöglicht starke Teams
Wie entwickeln Führungskräfte High-Performance-Teams? Wie schaffen es die Führungskräfte, Mitarbeiter zu fördern? Wie gelingt es, erfolgreich in virtuellen Teams zu agieren? - Neues disruptives Denken ermöglicht Innovation
Wie werden experimentelle und disruptive Prozesse gelebt, um Innovationen zu fördern? Ist lebenslanges Lernen bei den Mitarbeitern verankert? Wird lösungsorientiertes Denken gefördert?
2. Agile Retrospektiven einsetzen
Als Projektleiter hatte ich immer Schwierigkeiten mit einer Lessons-Learned-Runde zum Projektende. Was nützt diese Runde, wenn das eigentliche Vorhaben bereits abgeschlossen ist? Darin gewonnene Erkenntnisse können eh nichts mehr ändern und sind kaum auf künftige Projekte anwendbar, denn diese werden unter anderen Rahmenbedingungen und mit anderen Projektteams durchgeführt. Solche Runden waren für mich in neun von zehn Fällen wertlos.
Was wäre, wenn man eine verkürzte Version davon regelmässig im Projektverlauf macht? Sagen wir, alle vierzehn Tage oder in monatlicher Kadenz. Das Projektteam könnte sich in strukturierter Form über die aktuellen Probleme und Herausforderungen austauschen. Es wird ein Stimmungsbild erhoben (neudeutsch: Happiness Index). Daraus resultierende Erkenntnisse würden sofort in die Projektarbeit fließen und wirken als Korrekturmaßnahmen - festgelegt von den Mitarbeitern für die Mitarbeiter.
Solche Runden werden im Allgemeinen als Retrospektiven bezeichnet. Eine Retrospektive ist üblicherweise vergangenheitsorientiert und gibt allen Beteiligten Gelegenheit, den bisherigen Projektverlauf zu reflektieren und auszuwerten. Die Retrospektive ist ein strukturiertes Meeting und kann durch eine neutrale Partei oder durch einen rollierend besetzten Moderator aus dem Projektteam geführt werden. Manche Projektteams treffen sich sowieso in regelmäßigen Abständen und benötigen dafür - im günstigsten Fall - gar keinen separaten Termin.
- Macher-Typen sind nicht mehr gefragt
Der Projektmanager mit rein technischer Expertise ist out, findet Mary Gerush von Forrester Research. Sie beschreibt den Projektmanager der nächsten Generation als kommunikativ, kompetent und stark in Soft-Skills. - 1. Emotionale Intelligenz
Das meint die Fähigkeit, Augen und Ohren offen zu halten, um den Input von Projektmitarbeitern und Kunden in Zusammenhang mit dem Ziel in die Arbeit einfließen zu lassen. - 2. Anpassungsfähige Kommunikation
Die Fähigkeit, seine Ideen - mündlich oder schriftlich - einem weiten Kreis von Interessenten zu vermitteln, egal, aus welcher Abteilung, aus welchem Kulturkreis und mit welcher Vorbildung sie stammen. - 3. Fähigkeit, mit Leuten umzugehen
Die Begabung, schnell positive Beziehungen zu Team-Mitgliedern und Stakeholdern aufzubauen und zu pflegen. - 4. Fähigkeit zu managen
Das Können, in einem Team zu arbeiten, es zu motivieren, auf das Ziel zu fokussieren und die Zusammenarbeit im Team zu fördern. - 5. Flexibilität
Der Wille und die Fähigkeit, seinen Denkansatz zu überarbeiten, wenn es der Projektgegenstand und das Business verlangen - 6. Business-Kenntnisse
Wissen über das Business des Kunden und seine Branche. Die Fertigkeit, seine Strategie zu verstehen und seine Projektarbeit an dieser Strategie auszurichten. - 7. Analyse-Fähigkeit
Die Eignung, Probleme analysieren zu können und seine Entscheidungen aufgrund solcher Analysen zu treffen. - 8. Blick für den Kunden
Das Vermögen, Kunden- und Anwenderbedürfnisse zu verstehen und den Drang, diese Kundenbedürfnisse im Projekt auch befriedigen zu wollen. - 9. Ausrichtung am Ergebnis
Die Fähigkeit, das Projekt effizient und wirksam abzuschließen. - 10. Charakter
Der Projektmanager der Zukunft sollte eine ansprechende Persönlichkeit sowie starke Wertvorstellungen und einen moralisch einwandfreien Charakter besitzen.
Projektteams mit regelmäßigen Retrospektiven haben nicht mehr das Gefühl, im Blindflug unterwegs zu sein. Mitarbeiter schätzen es, dass ihre Meinung zählt und sie selbstbestimmt arbeiten können. Agile Retrospektiven stellen ein wirksames Führungswerkzeug dar, sie fördern Selbstorganisation und können vergleichsweise mit wenig Ressourcen umgesetzt werden.
3. Potenzial agiler Metriken nutzen
Änderungen im Mindset bringen auch Änderungen in der Projektsteuerung. Statt traditioneller projektbezogener KPIs (Zeit, Kosten, Qualität, Ressourcen) werden vermehrt agile Metriken eingesetzt. Warum ist das wichtig? Wir kennen alle den Beobachtungseffekt: wir beeinflussen das, was wir beobachten. Durch die Auswahl und das Tracking von bestimmten Parametern setzen wir die Anreize für diejenige, die daran arbeiten.
- Die 7 schlimmsten KPI-Sünden
Kennzahlensysteme sind beim ITSM erfolgskritisch. Doch KPIs sind nicht aus dem Business abgeleitet und werden zudem falsch definiert und interpretiert. - 1. KPIs werden nicht aus dem konkreten Business-Bezug abgeleitet:
Da die IT-Prozesse sich nach den Business-Anforderungen richten, müssen auch die ITSM-Kennzahlen geschäftsbezogen sein. Eine solche geschäftliche KPI-Orientierung ist in IT-Organisationen selten. Stattdessen sind ITSM-Kennzahlenkonzepte oft selbstbezogen und dienen der eigenen Qualitätslegitimation. - 2. KPI-Systeme ufern aus:
Die Entwicklung und der Einsatz von Kennzahlensystemen gewinnen oft eine Eigendynamik, aus der eine selbstverliebte Beschäftigung mit dem Hang zu immer mehr KPIs entsteht. Die Erfassung, Verarbeitung und Analyse von Messgrößen ist sehr aufwendig, der Nutzen für das Business jedoch gering. CIOs sollten sich daher auf eine begrenzte Anzahl gut beherrschbarer KPIs beschränken. - 3. KPIs werden nicht zielorientiert und praxisbezogen festgelegt:
Manchmal übertreiben Firmen es bei der Analyse von Leistungswerten der IT-Prozesse mit der Transparenz, denn schlechte KPIs sorgen für Kritik und einen hohen Rechtfertigungsdruck. Zwar werden Kennzahlensysteme für das ITSM eingeführt, doch aufgrund der fehlenden Akzeptanz kaum ernsthaft genutzt. Wichtig ist, dass Kennzahlen mit allen Beteiligten fair und zielorientiert festgelegt und vereinbart werden. - 4. KPI-Veränderungen werden nicht geprüft:
Die Leistungswerte in der IT-Organisation verändern sich dynamisch durch den Einsatz neuer Technologien, durch Reorganisation, aufgrund steigender Anforderungen aus dem Fachbereichen oder wegen technischer Probleme. CIOs führen KPI-Analysen in der betrieblichen Praxis häufig nur ungenau und wenig systematisch durch, was zu falschen Schlussfolgerungen führt. - 5. Kennzahlenzusammenhänge werden nicht transparent dargestellt:
CIOs können die Gesamtsituation nicht richtig bewerten, weil einzelne Leistungs- und Qualitätswerte isoliert betrachtet werden statt in Wechselwirkung mit anderen KPIs. Dadurch ist die Aussagekraft im Hinblick auf eine effiziente ITSM-Leistungssteuerung begrenzt. - 6. KPI-Abweichungen werden nicht nachverfolgt:
IT-Abteilungen gehen Inkonsistenzen oder Widersprüchen bei Leistungsdaten zu IT-Prozessen, die aufgrund unzureichender Definitionen entstehen können, oft nur halbherzig nach. Oder sie ignorieren diese gleich ganz.. Das birgt erhebliche Risiken, insbesondere wenn es sich um KPIs zu geschäftskritischen Prozessen handelt. - 7. Bei KPI-Analysen fehlen praktische Maßnahmenkataloge:
Meist werden Mitarbeiter mit den KPI-Analysen zum ITSM allein gelassen. Es fehlen weiterführende Handlungsempfehlungen, die die Auswertungen ergänzen, und Verbesserungsmaßnahmen aufzeigen.
Ein paar Beispiele für gängige agile Metriken:
Velocity misst die Geschwindigkeit, die ein agiles Team im Verlauf eines Sprints oder einer Iteration erreicht. Velocity wird in Story Points pro Sprint/Iteration angegeben. Mit der durchschnittlichen Velocity erhält man einen Zahlenwert, der üblicherweise für Prognosen über die künftige Fertigstellung der Aufgaben verwendet wird (zum Beispiel Release-Planung).
Burndown-Charts messen den Projektfortschritt. Der Sprint-Burndown-Chart zeigt den Fortschritt innerhalb eines Sprints. Es wird die Menge an offenen Aufgaben (y-Achse), die dem Sprint zugeordnet sind, gegen die Zeit (x-Achse) getrackt. Aufgaben können in Arbeitsstunden oder Story Points angegeben werden. Die Kurve fällt üblicherweise im Verlauf der Zeit ab. Der Release-Burndown-Chart überträgt dasselbe Prinzip auf ein Release.
Durch technische Schulden werden „Altlasten“ in einem Programmcode geschätzt, die in der Zukunft beseitigt werden sollen oder perspektivisch Folgekosten verursachen können. Technische Schulden entstehen üblicherweise durch Workarounds oder "Quick & Dirty Fixes“.
Der Happiness Index misst den Einfluss negativer Faktoren (Teamfluktuation, Overruling von Teamentscheiden etc.) auf die Stimmung und Performance des Teams. Das Vorgehen ist denkbar einfach: nach jeder Retrospektive beantworten die Teammitglieder festgelegte Fragen zum Thema Zufriedenheit und Arbeitsklima. Die Zahlen werden in einem Excel-Sheet konsolidiert und mit der Historie verglichen.
Lesetipp: Was macht eigentlich ein Chief Happiness Officer?
Die Verwendung agiler Metriken steht üblicherweise nicht im Konflikt zu traditionellen Unternehmenskennzahlen, wie Umsatz oder Profitabilität. Man geht von einer indirekten Beziehung aus: mehr Agilität manifestiert sich in einer „besseren“ Lösungsentwicklung, was wiederum die Wettbewerbsfähigkeit verbessert und so „bessere“ Unternehmenskennzahlen bewirkt. Agile Metriken sind keine Performance-Kennzahlen, sie messen lediglich den Erfolg im Einsatz agiler Methoden.
Was können nun die Projektleiter tun, um agile Metriken erfolgreich einsetzen zu können?
Das richtige Verständnis über die Metriken bei den Stakeholdern aufbauen
Für die Auswahl und das Tracking geeigneter agiler Metriken sorgen
Sich nicht einmischen, solange die Metriken stimmen
Klassische (von außen vorgegebene) Kennzahlen und agile (aus dem Projekt kommende) Metriken im Einklang halten