Agiles Projektmanagement: Projekte mit Scrum flexibel zum Erfolg führen
Viele Projekte scheitern. Die zu Beginn gefassten Ziele werden nicht erreicht. Für manchen Geschäftsführer ist das eine Katastrophe, für den erfahrenen Projektmanager Alltag. Denn er weiß, wie schwierig es ist, komplexe Projekte zum vorgegebenen Ziel zu führen. Dieses ändert sich nämlich sehr oft, genauso wie die Erwartungen der Auftraggeber und der Betroffenen (Kollegen oder Kunden). Zu den alltäglichen Problemen gehört auch, dass Ressourcen nicht ausreichen, Mitarbeiter nicht die notwendigen Kompetenzen mitbringen oder das Top-Management die Unterstützung versagt.
Diese Liste der Ursachen lässt sich beliebig fortführen. Genauso wie die Liste der Lösungen und Werkzeuge, die den Unternehmen und ihren Mitarbeitern an die Hand gegeben werden, um diese Widrigkeiten zu bewältigen. Und vieles davon ist inzwischen standardisiert und normiert, was den Unternehmen und den Projektverantwortlichen ein enges Korsett anlegt.
Ein ganz anderer Ansatz verspricht Abhilfe. Sein Kerngedanke: Wenn alle ausgefeilten Methoden, Werkzeuge und Vorgehensweisen im klassischen Projektmanagement nicht zu den erwünschten Erfolgen führen, dann lasst das doch einfach sein. Vertraut darauf, dass ein erfahrenes Projektteam es schon irgendwie schaukeln wird, wenn es die Freiheiten dazu hat. Vor allem muss es sich regelmäßig treffen und sich besprechen. Die Protagonisten dieses revolutionären Ansatzes bezeichnen diese Art der Abstimmung als Scrum – zu Deutsch „Gedränge“; ein Begriff aus dem Rugby, wo Scrum einen dichten Haufen von Spielern meint, die um das Spielgerät rangeln.
Scrum und agiles Projektmanagement für die Produktentwicklung
Schon vor rund dreißig Jahren wurden erste Erfahrungen mit dieser Form des Projektmanagements gemacht. Es ging zunächst darum, Produkte schneller und kundenorientierter zu entwickeln. Weniger Bürokratie und Planung und stattdessen engere Zusammenarbeit und häufigere Abstimmungen zwischen den Mitarbeitern im Produktentwicklungsteam waren die Ziele. Die sollten vor allem direkt mit den Kunden sprechen.
Hirotaka Takeuchi und Ikujiro Nonaka zeigen in ihrem Beitrag „The new new product development game: stopp running the relay race and take up rugby“ (1986), dass kleine, vernetzte und interdisziplinäre Teams die besten Resultate erzielen, wenn es darum geht, schnell neue Produkte zu entwickeln, die den besten Kundennutzen bringen. Sie bezeichnen dieses Vorgehen als Scrum. Unternehmen, die damals Erfahrungen damit gesammelt haben, sind Honda, Xerox, Canon, HP und IBM.
Dass der Wunsch nach weniger Bürokratie und Normen einher ging mit der „Lean-Welle“ Ende der 1980er Jahr ist nicht zufällig. Mehr Autonomie für den Einzelnen, Teamarbeit, einfache und klare Regeln und mehr Kundenorientierung kamen in Mode. Methoden des Total Quality Managements und der bedarfsorientierten Produktionslogistik (Kanban) waren die Vorbilder. Daraus sind schließlich die Konzepte und Methoden für die Produktentwicklung hervorgegangen, die seither unter dem Begriff „agiles Projektmanagement“ zusammengefasst werden.
Stichwort
Agiles Projektmanagement umfasst unterschiedliche Methoden eines Projektmanagements, das vor allem auf Flexibilität und Anpassung setzt. Statt ausführlicher und umfangreicher Planung zu Beginn eines Projekts unterstützen diese Methoden das adaptive Planen und die schnelle Abstimmung im Team. Agiles Projektmanagement hat insbesondere bei der Softwareentwicklung an Bedeutung gewonnen.
Methoden und Vorgehensweise sind dabei unter anderem: Scrum, agile Modelling, Feature-Driven Development, extreme Programming.
Ken Schwaber und Jeff Sutherland waren Anfang der 1990er Jahre die Treiber dieser Entwicklung in der Softwareindustrie und in vielen IT-Abteilungen. Sie haben auch das sogenannte Manifest der agilen Softwareentwicklung formuliert. „We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.“ [Quelle: http://www.agilemanifesto.org/]
Wer kennt agiles Projektmanagement und Scrum?
Auch wenn diese Vorgehensweise bei der Softwareentwicklung nicht mehr neu ist, die meisten IT-Verantwortlichen in den Unternehmen kennen sie nicht. Nach einer Umfrage der Zeitschrift CIO haben fast die Hälfte der befragten Leser den Begriff „Scrum“ noch nie gehört und ein weiteres Viertel hat noch keinerlei Erfahrungen damit sammeln können. Andere Befragungen kommen zu anderen Ergebnissen. So stellt die IT-Beratung it-agile fest, dass fast alle der von ihr gemeinsam mit der Zeitschrift ObjektSpektrum befragten Unternehmen agile Methoden der Softwareentwicklung kennen. Das dürfte dem Umstand zu verdanken sein, dass die Macher der Studien vor allem ihre eigene Community befragt haben. Wie dem auch sei: Wer Erfahrungen mit Scrum gesammelt hat, ist damit meistens sehr zufrieden.
Auch die Analysten von Forrester sagen, dass die Zahl der Unternehmen, die agile Entwicklungsmethoden einsetzen, ständig zunimmt.
„In den letzten Jahren haben agile Prozesse nicht nur steigende Anwenderzahlen erreicht; sie passten sich auch sehr schnell den allgemeinen Trends der Entwicklungsmethoden an. Und je mehr Unternehmen agile Prozesse etablieren, desto mehr passen sich diese Prozesse auch am einzelnen Arbeitsplatz ein. Vielleicht ist es ein untrügliches Zeichen, dass agile Prozesse im Trend sind, dass die klassischen Methoden an Zuspruch verlieren.“ [Quelle: Forrester, Agile Development: Mainstream Adoption Has Changed Agility, 2010]
Ohne Regeln geht es auch bei Scrum nicht
Ganz ohne Regeln kommen auch Scrum und andere Methoden des agilen Projektmanagements nicht aus. Doch es sollen sehr wenige und sehr einfache Regeln sein, die maßgeblich dafür sind, dass das Projektteam die gemeinsamen Ziele erreicht. Entscheidend ist, dass ein Team beim agilen Projektmanagement sich selbst organisieren kann und auch darf und dass es interdisziplinär zusammengesetzt ist, sodass unterschiedliche Kompetenzen zusammenkommen.
Wichtig sind die Rollen, die Akteure einnehmen müssen. Es gibt bei Scrum drei davon:
- der Produkteigner (Product Owner)
- der Scrum-Master
- das Mitglied im Projektteam
Der Produkteigner vertritt die Anwender des Produkts oder die Stakeholder des Projekts. Das sind alle, die betroffen sind und ein Interesse am Erfolg des Projekts haben. Wenn eine neue Software oder IT-Lösung im Unternehmen eingeführt wird, sind das die Nutzer, denn sie wollen reibungslos mit ihren Programmen arbeiten. Bei Produkten sind es die Produktmanager, die als Stimme der Kunden auftreten. Er sollte wissen, was die Kunden schätzen. Aber auch das Marketing, der Vertrieb und der Kundendienst können spezifische Anforderungen artikulieren.
Der Scrum-Master (Project-Master) ist vor allem Moderator und Dienstleister für das Projektteam. Er sorgt dafür, dass Hindernisse im Umfeld des Teams beseitigt werden. Er beschafft die notwendigen Ressourcen und ist Ansprechpartner für Außenstehende. Er hilft dem Team bei methodischen Problemen und stellt sicher, dass die Regeln des agilen Projektmanagements eingehalten werden.
Das Projektteam sollte zwischen fünf und zehn Mitarbeiten umfassen. Sie organisieren alle Aufgaben selbst. Es gibt im Team keine Hierarchie. Jeder hat dieselben Rechte und Pflichten, aber durchaus unterschiedliche Kompetenzen. Alle Fachbereiche, die zur Lösung beitragen, sollten vertreten sein. Wichtig ist, dass alle Teammitglieder freiwillig dabei sind. Sie sollten sich ihre Projekte selbst aussuchen können. Das setzt Vertrauen der Manager und Verantwortungsbewusstsein der Mitarbeiter voraus.
Neben den Rollen ist es vor allem der Prozess, der kennzeichnend ist für Scrum. Am Anfang steht dabei eine Produkt-Vision; eine Idee des Produkts, die die Geschäftsleitung als Auftraggeber des Projekts vorantreiben will und die auch den Anwendern einen Nutzengewinn bringt. Mit diesem Auslöser startet ein Projekt nach Scrum mit den folgenden Schritten:
1. Aus dieser ersten, aber anschaulichen und verständlichen Vision lassen sich die einzelnen Elemente und Merkmale des Produkts ableiten, die zu entwickeln sind. Das sind die konkreten Anforderungen und einzelne Funktionalitäten, die in sogenannten Story Cards in den Worten der Anwender formuliert werden – nicht im Jargon der Techniker. Damit wird auch sichtbar, welche Ressourcen das Projekt braucht (Qualifikationen im Projektteam und grober Aufwand für die Umsetzung).
2. Aus diesen Anforderungen des Produkteigners wird ein sogenanntes Produkt-Backlog zusammengestellt. Das ist eine Sammlung sämtlicher Funktionen und Merkmale, die das Produkt haben soll. Am Anfang ist diese Zusammenstellung noch grob, doch im Projektverlauf wird sie immer genauer.
3. Im nächsten Schritt werden Prioritäten vergeben. Welche Elemente und Funktionen sind am wichtigsten im Sinne von: Das sichert die Zufriedenheit der Anwender essenziell. Andere Anforderungen sind nicht so wichtig, können aussortiert werden, werden mit anderen zusammengelegt, sind technisch nicht realisierbar oder werden verschoben. Sie werden dann bei der Überarbeitung oder bei der Erweiterung des Produkts behandelt (schnelle Release-Wechsel).
4. In einer ersten Besprechung zur Sprint-Planung werden die Rahmenbedingungen abgesteckt: Wo und wann kann sich das Team regelmäßig (täglich!) treffen? Was sind die Teilziele für die entsprechende Funktion und Aufgabe? Wie soll der allgemeine Aufbau aussehen? Was sind die Meilensteine? In welche Teilaufgaben, sogenannte Sprints, lässt sich das Projekt untergliedern? Auf welche Details oder Besonderheiten ist zu achten? Welche Konventionen und Schnittstellen sind einzuhalten?
5. Die Aufgaben oder Tickets werden im sogenannten Sprint-Backlog aufgeführt. Das ist gewissermaßen der Maßnahmenplan und der Arbeitsvorrat für das Entwickler-Team für den nächsten Arbeitszyklus (Sprint). Jedes Teammitglied übernimmt eigenverantwortlich einzelne Aufgaben oder ein Ticket (Verpflichtungserklärung).
6. Im Sprint arbeiten die Teammitglieder an ihren Aufgaben.
7. Während eines täglichen, 15-minütigen Treffens, dem sogenannten Scrum, berichtet jeder der Reihe nach: Was er seit dem letzten Scrum gemacht hat, was er bis zum nächsten Scrum tun wird und was ihn bei seiner Arbeit behindert. Der Scrum-Master muss diese Hindernisse aufgreifen und helfen, dass sie beseitigt werden. In einem Sprint-Burndown-Chart wird sichtbar gemacht, wie das Projekt voranschreitet.
8. Jeder Sprint wird durch ein Sprint Review Meeting abgeschlossen. Das Team stelle die Ergebnisse dem Produkteigner vor. Er muss sie akzeptieren und abnehmen. In gesonderten Treffen können auch die Teammitglieder ihre Zusammenarbeit überprüfen und festhalten, was intern verbessert werden sollte (Lernprozess!).
9. Sind alle Sprints durchlaufen, wird das fertige Produkt an den Produkteigner geliefert. Das Projekt kann abgeschlossen werden.
Bei Scrum werden alle Aufgaben auf einer Tafel festgehalten (Task-Board). Dort wird sichtbar, was noch ansteht, was gerade in Bearbeitung ist und was schon fertig ist. Für manche Zwecke ist das zu knapp.
Deshalb raten die Experten von it-agile, das sogenannte Kanban-Board einzusetzen. Es macht sehr anschaulich, in welcher Phase sich ein Ticket gerade befindet. Es bildet die Wertschöpfungskette des Projekts ab. Dabei werden nur so viele Tickets für die Bearbeitung freigegeben, wie vom Projektteam bearbeitet werden können. Geht es an einer Stelle nicht voran, stauen sich dort die Tickets. Es wird schnell sichtbar, wo der Engpass liegt und was getan werden kann. Eilige Tickets können vorgezogen werden. So steuert das Team die Aufgabenverteilung und den Arbeitsfluss völlig selbstständig.
Das Burndown-Chart ist eine einfache Abbildung, die sichtbar macht, ob das Projekt im ursprünglich vereinbarten Zeit- und Kostenrahmen bleibt. Oder ob Budget oder Zeitplan angepasst werden müssen. Durch die täglichen Treffen können diese sehr aktuell geführt und Korrekturmaßnahmen sehr schnell eingeleitet werden.
Nicht jeder will völlig selbstbestimmt arbeiten (lassen)
Manche Mitarbeiter kommen mit dieser Philosophie für Projektmanagement und Produkt- oder Softwareentwicklung nicht zurecht. Denn hier kann sich niemand mehr verstecken. Die Leistung jedes einzelnen Teammitglieds wird sehr schnell sichtbar und bewertbar. Die vorgebrachten und die tatsächlichen Gründe für Verzögerungen im Arbeitsablauf werden in täglichen Besprechungen offensichtlich. Wenn der Kollege seine Aufgabe nicht erledigt, kommen die anderen nicht voran. Darüber wird offen und direkt gesprochen.
Dabei bleibt es nicht immer auf der sachlichen Ebene. Manche kommen mit der direkten Kritik nicht zurecht. Es kommt zu Konflikten. Das Team fällt auseinander. Einzelne Mitarbeiter verlassen das Team und manchmal sogar das Unternehmen. Zumindest wird die Kommunikation erschwert. Die Mitglieder im Team sprechen nicht genug miteinander. Sie sind nicht mehr bereit, Probleme und Aufgaben anzugehen, damit alle vorankommen. Teilaufgaben werden hin und her geschoben.
Andere Konflikt- und Reibungspotenziale ergeben sich dann, wenn einzelne Mitarbeiter das Projektteam dominieren. Sie setzen ihre Interessen und Meinungen durch, ohne dass diese im Sinne des Projekterfolgs richtig sein müssen. Hier gibt es zu wenig Korrekturmöglichkeiten, da das Team ja selbstbestimmt arbeiten soll und auch der Scrum-Master nicht eingreifen darf.
Auch Projektleiter tun sich oft schwer. Haben sie beim klassischen Projektmanagement eine zentrale Rolle und Führungsfunktion und laufen bei ihnen alle Fäden zusammen, so weist ihnen das agile Projektmanagement nur eine Moderatorenfunktion zu. So fühlen sie sich in ihrer Bedeutung zurückgesetzt. Projektmanagement ist kein Feld, auf dem man sich für den nächsten Karriereschritt empfehlen kann.
Besonders kritisch ist, wenn das Top-Management im Unternehmen nicht hinter diesem radikalen Paradigmenwechsel steht. Es muss darauf vertrauen, dass die Projektteams selbstverantwortlich arbeiten und dass am Ende das rauskommt, was sie erwarten. Ein solcher Vertrauensvorschuss für die Mitarbeiter und ein so hohes Maß an Autonomie, das passt nicht zu jeder Unternehmenskultur und auch nicht zu jeder Führungspersönlichkeit.
Wer die Barrieren überwindet, erntet den Profit
Agiles Projektmanagement setzt demnach eine ganz andere Sichtweise auf die Projektorganisation eines Unternehmens voraus. Ohne eine entsprechende Organisationskultur, die auf Vertrauen, Eigeninitiative und Verantwortungsbewusstsein setzt, und ohne die Mitarbeiter, die neben der Fachkompetenz auch soziale und methodische Qualifikationen brauchen, wird sich ein Unternehmen mit diesen Konzepten schwer tun.
Zudem sind agile Methoden auf solche Projekte ausgerichtet, in denen es um die Entwicklung von Produkten oder Dienstleistungen geht oder um die Einführung einer Technologie, zum Beispiel durch die IT-Abteilung im Unternehmen. Projekte zur Organisationsentwicklung, zum Change Management oder für die Personalentwicklung haben meist kein genau spezifiziertes Ergebnis, das ein Produkteigner abnehmen könnte. Hier lassen sich allenfalls Teilaufgaben mit den agilen Methoden bearbeiten.
Manchmal sind es auch nur die organisatorischen Rahmenbedingungen, die agiles Projektmanagement erschweren. Das kann beispielsweise sein:
- Das Projektteam ist räumlich getrennt und kann sich nicht täglich treffen.
- Spezialisten stehen nur für eine begrenzte Zeit oder in eingeschränktem Umfang zur Verfügung.
- Die Kundenanforderungen bleiben unklar; der Produkteigner kann die Anforderungen nicht genau artikulieren.
Wer diese Barrieren überwindet, eine förderliche Organisationskultur schafft und die Mitarbeiter dafür gewinnen kann, der erntet mit dem agilen Projektmanagement besondere Früchte. Wie beim schlanken Management wird bei der agilen Vorgehensweise zumeist die Qualität der Ergebnisse verbessert und weniger Ressourcen werden verschwendet. Alle fokussieren sich auf das Wesentliche. Die Produktivität steigt, aber auch die Zufriedenheit der Kunden und der Stakeholder.
Die ständige und regelmäßige Kommunikation fördert die Transparenz. Engpässe werden schnell erkannt und können beseitigt werden. So kommt das Projekt insgesamt schneller voran.
Auch die Mitarbeiter selbst können von dieser Vorgehensweise profitieren. In ihrer Befragung zur agilen Softwareentwicklung hat it-agile von den Teilnehmern erfahren:
- Diese schätzen vor allem, dass sie jetzt mehr Spaß bei der Arbeit hätten.
- Sie können außerdem sehr viel mehr lernen und ihr Wissen erweitern.
Am meisten schätzten sie, dass sie im Projekt flexibler sind. Auch wenn sich die Ziele und die Anforderungen der Auftraggeber ändern, so kann das Projektteam vergleichsweise schnell und einfach seine Arbeiten und den Fortschritt anpassen. Sie sind agil.
Mehr zum Thema auf:
http://www.business-wissen.de/schlagwoerter/projektmanagement/
Diese Liste der Ursachen lässt sich beliebig fortführen. Genauso wie die Liste der Lösungen und Werkzeuge, die den Unternehmen und ihren Mitarbeitern an die Hand gegeben werden, um diese Widrigkeiten zu bewältigen. Und vieles davon ist inzwischen standardisiert und normiert, was den Unternehmen und den Projektverantwortlichen ein enges Korsett anlegt.
Ein ganz anderer Ansatz verspricht Abhilfe. Sein Kerngedanke: Wenn alle ausgefeilten Methoden, Werkzeuge und Vorgehensweisen im klassischen Projektmanagement nicht zu den erwünschten Erfolgen führen, dann lasst das doch einfach sein. Vertraut darauf, dass ein erfahrenes Projektteam es schon irgendwie schaukeln wird, wenn es die Freiheiten dazu hat. Vor allem muss es sich regelmäßig treffen und sich besprechen. Die Protagonisten dieses revolutionären Ansatzes bezeichnen diese Art der Abstimmung als Scrum – zu Deutsch „Gedränge“; ein Begriff aus dem Rugby, wo Scrum einen dichten Haufen von Spielern meint, die um das Spielgerät rangeln.
Scrum und agiles Projektmanagement für die Produktentwicklung
Schon vor rund dreißig Jahren wurden erste Erfahrungen mit dieser Form des Projektmanagements gemacht. Es ging zunächst darum, Produkte schneller und kundenorientierter zu entwickeln. Weniger Bürokratie und Planung und stattdessen engere Zusammenarbeit und häufigere Abstimmungen zwischen den Mitarbeitern im Produktentwicklungsteam waren die Ziele. Die sollten vor allem direkt mit den Kunden sprechen.
Hirotaka Takeuchi und Ikujiro Nonaka zeigen in ihrem Beitrag „The new new product development game: stopp running the relay race and take up rugby“ (1986), dass kleine, vernetzte und interdisziplinäre Teams die besten Resultate erzielen, wenn es darum geht, schnell neue Produkte zu entwickeln, die den besten Kundennutzen bringen. Sie bezeichnen dieses Vorgehen als Scrum. Unternehmen, die damals Erfahrungen damit gesammelt haben, sind Honda, Xerox, Canon, HP und IBM.
Dass der Wunsch nach weniger Bürokratie und Normen einher ging mit der „Lean-Welle“ Ende der 1980er Jahr ist nicht zufällig. Mehr Autonomie für den Einzelnen, Teamarbeit, einfache und klare Regeln und mehr Kundenorientierung kamen in Mode. Methoden des Total Quality Managements und der bedarfsorientierten Produktionslogistik (Kanban) waren die Vorbilder. Daraus sind schließlich die Konzepte und Methoden für die Produktentwicklung hervorgegangen, die seither unter dem Begriff „agiles Projektmanagement“ zusammengefasst werden.
Stichwort
Agiles Projektmanagement umfasst unterschiedliche Methoden eines Projektmanagements, das vor allem auf Flexibilität und Anpassung setzt. Statt ausführlicher und umfangreicher Planung zu Beginn eines Projekts unterstützen diese Methoden das adaptive Planen und die schnelle Abstimmung im Team. Agiles Projektmanagement hat insbesondere bei der Softwareentwicklung an Bedeutung gewonnen.
Methoden und Vorgehensweise sind dabei unter anderem: Scrum, agile Modelling, Feature-Driven Development, extreme Programming.
Ken Schwaber und Jeff Sutherland waren Anfang der 1990er Jahre die Treiber dieser Entwicklung in der Softwareindustrie und in vielen IT-Abteilungen. Sie haben auch das sogenannte Manifest der agilen Softwareentwicklung formuliert. „We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.“ [Quelle: http://www.agilemanifesto.org/]
Wer kennt agiles Projektmanagement und Scrum?
Auch wenn diese Vorgehensweise bei der Softwareentwicklung nicht mehr neu ist, die meisten IT-Verantwortlichen in den Unternehmen kennen sie nicht. Nach einer Umfrage der Zeitschrift CIO haben fast die Hälfte der befragten Leser den Begriff „Scrum“ noch nie gehört und ein weiteres Viertel hat noch keinerlei Erfahrungen damit sammeln können. Andere Befragungen kommen zu anderen Ergebnissen. So stellt die IT-Beratung it-agile fest, dass fast alle der von ihr gemeinsam mit der Zeitschrift ObjektSpektrum befragten Unternehmen agile Methoden der Softwareentwicklung kennen. Das dürfte dem Umstand zu verdanken sein, dass die Macher der Studien vor allem ihre eigene Community befragt haben. Wie dem auch sei: Wer Erfahrungen mit Scrum gesammelt hat, ist damit meistens sehr zufrieden.
Auch die Analysten von Forrester sagen, dass die Zahl der Unternehmen, die agile Entwicklungsmethoden einsetzen, ständig zunimmt.
„In den letzten Jahren haben agile Prozesse nicht nur steigende Anwenderzahlen erreicht; sie passten sich auch sehr schnell den allgemeinen Trends der Entwicklungsmethoden an. Und je mehr Unternehmen agile Prozesse etablieren, desto mehr passen sich diese Prozesse auch am einzelnen Arbeitsplatz ein. Vielleicht ist es ein untrügliches Zeichen, dass agile Prozesse im Trend sind, dass die klassischen Methoden an Zuspruch verlieren.“ [Quelle: Forrester, Agile Development: Mainstream Adoption Has Changed Agility, 2010]
Ohne Regeln geht es auch bei Scrum nicht
Ganz ohne Regeln kommen auch Scrum und andere Methoden des agilen Projektmanagements nicht aus. Doch es sollen sehr wenige und sehr einfache Regeln sein, die maßgeblich dafür sind, dass das Projektteam die gemeinsamen Ziele erreicht. Entscheidend ist, dass ein Team beim agilen Projektmanagement sich selbst organisieren kann und auch darf und dass es interdisziplinär zusammengesetzt ist, sodass unterschiedliche Kompetenzen zusammenkommen.
Wichtig sind die Rollen, die Akteure einnehmen müssen. Es gibt bei Scrum drei davon:
- der Produkteigner (Product Owner)
- der Scrum-Master
- das Mitglied im Projektteam
Der Produkteigner vertritt die Anwender des Produkts oder die Stakeholder des Projekts. Das sind alle, die betroffen sind und ein Interesse am Erfolg des Projekts haben. Wenn eine neue Software oder IT-Lösung im Unternehmen eingeführt wird, sind das die Nutzer, denn sie wollen reibungslos mit ihren Programmen arbeiten. Bei Produkten sind es die Produktmanager, die als Stimme der Kunden auftreten. Er sollte wissen, was die Kunden schätzen. Aber auch das Marketing, der Vertrieb und der Kundendienst können spezifische Anforderungen artikulieren.
Der Scrum-Master (Project-Master) ist vor allem Moderator und Dienstleister für das Projektteam. Er sorgt dafür, dass Hindernisse im Umfeld des Teams beseitigt werden. Er beschafft die notwendigen Ressourcen und ist Ansprechpartner für Außenstehende. Er hilft dem Team bei methodischen Problemen und stellt sicher, dass die Regeln des agilen Projektmanagements eingehalten werden.
Das Projektteam sollte zwischen fünf und zehn Mitarbeiten umfassen. Sie organisieren alle Aufgaben selbst. Es gibt im Team keine Hierarchie. Jeder hat dieselben Rechte und Pflichten, aber durchaus unterschiedliche Kompetenzen. Alle Fachbereiche, die zur Lösung beitragen, sollten vertreten sein. Wichtig ist, dass alle Teammitglieder freiwillig dabei sind. Sie sollten sich ihre Projekte selbst aussuchen können. Das setzt Vertrauen der Manager und Verantwortungsbewusstsein der Mitarbeiter voraus.
Neben den Rollen ist es vor allem der Prozess, der kennzeichnend ist für Scrum. Am Anfang steht dabei eine Produkt-Vision; eine Idee des Produkts, die die Geschäftsleitung als Auftraggeber des Projekts vorantreiben will und die auch den Anwendern einen Nutzengewinn bringt. Mit diesem Auslöser startet ein Projekt nach Scrum mit den folgenden Schritten:
1. Aus dieser ersten, aber anschaulichen und verständlichen Vision lassen sich die einzelnen Elemente und Merkmale des Produkts ableiten, die zu entwickeln sind. Das sind die konkreten Anforderungen und einzelne Funktionalitäten, die in sogenannten Story Cards in den Worten der Anwender formuliert werden – nicht im Jargon der Techniker. Damit wird auch sichtbar, welche Ressourcen das Projekt braucht (Qualifikationen im Projektteam und grober Aufwand für die Umsetzung).
2. Aus diesen Anforderungen des Produkteigners wird ein sogenanntes Produkt-Backlog zusammengestellt. Das ist eine Sammlung sämtlicher Funktionen und Merkmale, die das Produkt haben soll. Am Anfang ist diese Zusammenstellung noch grob, doch im Projektverlauf wird sie immer genauer.
3. Im nächsten Schritt werden Prioritäten vergeben. Welche Elemente und Funktionen sind am wichtigsten im Sinne von: Das sichert die Zufriedenheit der Anwender essenziell. Andere Anforderungen sind nicht so wichtig, können aussortiert werden, werden mit anderen zusammengelegt, sind technisch nicht realisierbar oder werden verschoben. Sie werden dann bei der Überarbeitung oder bei der Erweiterung des Produkts behandelt (schnelle Release-Wechsel).
4. In einer ersten Besprechung zur Sprint-Planung werden die Rahmenbedingungen abgesteckt: Wo und wann kann sich das Team regelmäßig (täglich!) treffen? Was sind die Teilziele für die entsprechende Funktion und Aufgabe? Wie soll der allgemeine Aufbau aussehen? Was sind die Meilensteine? In welche Teilaufgaben, sogenannte Sprints, lässt sich das Projekt untergliedern? Auf welche Details oder Besonderheiten ist zu achten? Welche Konventionen und Schnittstellen sind einzuhalten?
5. Die Aufgaben oder Tickets werden im sogenannten Sprint-Backlog aufgeführt. Das ist gewissermaßen der Maßnahmenplan und der Arbeitsvorrat für das Entwickler-Team für den nächsten Arbeitszyklus (Sprint). Jedes Teammitglied übernimmt eigenverantwortlich einzelne Aufgaben oder ein Ticket (Verpflichtungserklärung).
6. Im Sprint arbeiten die Teammitglieder an ihren Aufgaben.
7. Während eines täglichen, 15-minütigen Treffens, dem sogenannten Scrum, berichtet jeder der Reihe nach: Was er seit dem letzten Scrum gemacht hat, was er bis zum nächsten Scrum tun wird und was ihn bei seiner Arbeit behindert. Der Scrum-Master muss diese Hindernisse aufgreifen und helfen, dass sie beseitigt werden. In einem Sprint-Burndown-Chart wird sichtbar gemacht, wie das Projekt voranschreitet.
8. Jeder Sprint wird durch ein Sprint Review Meeting abgeschlossen. Das Team stelle die Ergebnisse dem Produkteigner vor. Er muss sie akzeptieren und abnehmen. In gesonderten Treffen können auch die Teammitglieder ihre Zusammenarbeit überprüfen und festhalten, was intern verbessert werden sollte (Lernprozess!).
9. Sind alle Sprints durchlaufen, wird das fertige Produkt an den Produkteigner geliefert. Das Projekt kann abgeschlossen werden.
Bei Scrum werden alle Aufgaben auf einer Tafel festgehalten (Task-Board). Dort wird sichtbar, was noch ansteht, was gerade in Bearbeitung ist und was schon fertig ist. Für manche Zwecke ist das zu knapp.
Deshalb raten die Experten von it-agile, das sogenannte Kanban-Board einzusetzen. Es macht sehr anschaulich, in welcher Phase sich ein Ticket gerade befindet. Es bildet die Wertschöpfungskette des Projekts ab. Dabei werden nur so viele Tickets für die Bearbeitung freigegeben, wie vom Projektteam bearbeitet werden können. Geht es an einer Stelle nicht voran, stauen sich dort die Tickets. Es wird schnell sichtbar, wo der Engpass liegt und was getan werden kann. Eilige Tickets können vorgezogen werden. So steuert das Team die Aufgabenverteilung und den Arbeitsfluss völlig selbstständig.
Das Burndown-Chart ist eine einfache Abbildung, die sichtbar macht, ob das Projekt im ursprünglich vereinbarten Zeit- und Kostenrahmen bleibt. Oder ob Budget oder Zeitplan angepasst werden müssen. Durch die täglichen Treffen können diese sehr aktuell geführt und Korrekturmaßnahmen sehr schnell eingeleitet werden.
Nicht jeder will völlig selbstbestimmt arbeiten (lassen)
Manche Mitarbeiter kommen mit dieser Philosophie für Projektmanagement und Produkt- oder Softwareentwicklung nicht zurecht. Denn hier kann sich niemand mehr verstecken. Die Leistung jedes einzelnen Teammitglieds wird sehr schnell sichtbar und bewertbar. Die vorgebrachten und die tatsächlichen Gründe für Verzögerungen im Arbeitsablauf werden in täglichen Besprechungen offensichtlich. Wenn der Kollege seine Aufgabe nicht erledigt, kommen die anderen nicht voran. Darüber wird offen und direkt gesprochen.
Dabei bleibt es nicht immer auf der sachlichen Ebene. Manche kommen mit der direkten Kritik nicht zurecht. Es kommt zu Konflikten. Das Team fällt auseinander. Einzelne Mitarbeiter verlassen das Team und manchmal sogar das Unternehmen. Zumindest wird die Kommunikation erschwert. Die Mitglieder im Team sprechen nicht genug miteinander. Sie sind nicht mehr bereit, Probleme und Aufgaben anzugehen, damit alle vorankommen. Teilaufgaben werden hin und her geschoben.
Andere Konflikt- und Reibungspotenziale ergeben sich dann, wenn einzelne Mitarbeiter das Projektteam dominieren. Sie setzen ihre Interessen und Meinungen durch, ohne dass diese im Sinne des Projekterfolgs richtig sein müssen. Hier gibt es zu wenig Korrekturmöglichkeiten, da das Team ja selbstbestimmt arbeiten soll und auch der Scrum-Master nicht eingreifen darf.
Auch Projektleiter tun sich oft schwer. Haben sie beim klassischen Projektmanagement eine zentrale Rolle und Führungsfunktion und laufen bei ihnen alle Fäden zusammen, so weist ihnen das agile Projektmanagement nur eine Moderatorenfunktion zu. So fühlen sie sich in ihrer Bedeutung zurückgesetzt. Projektmanagement ist kein Feld, auf dem man sich für den nächsten Karriereschritt empfehlen kann.
Besonders kritisch ist, wenn das Top-Management im Unternehmen nicht hinter diesem radikalen Paradigmenwechsel steht. Es muss darauf vertrauen, dass die Projektteams selbstverantwortlich arbeiten und dass am Ende das rauskommt, was sie erwarten. Ein solcher Vertrauensvorschuss für die Mitarbeiter und ein so hohes Maß an Autonomie, das passt nicht zu jeder Unternehmenskultur und auch nicht zu jeder Führungspersönlichkeit.
Wer die Barrieren überwindet, erntet den Profit
Agiles Projektmanagement setzt demnach eine ganz andere Sichtweise auf die Projektorganisation eines Unternehmens voraus. Ohne eine entsprechende Organisationskultur, die auf Vertrauen, Eigeninitiative und Verantwortungsbewusstsein setzt, und ohne die Mitarbeiter, die neben der Fachkompetenz auch soziale und methodische Qualifikationen brauchen, wird sich ein Unternehmen mit diesen Konzepten schwer tun.
Zudem sind agile Methoden auf solche Projekte ausgerichtet, in denen es um die Entwicklung von Produkten oder Dienstleistungen geht oder um die Einführung einer Technologie, zum Beispiel durch die IT-Abteilung im Unternehmen. Projekte zur Organisationsentwicklung, zum Change Management oder für die Personalentwicklung haben meist kein genau spezifiziertes Ergebnis, das ein Produkteigner abnehmen könnte. Hier lassen sich allenfalls Teilaufgaben mit den agilen Methoden bearbeiten.
Manchmal sind es auch nur die organisatorischen Rahmenbedingungen, die agiles Projektmanagement erschweren. Das kann beispielsweise sein:
- Das Projektteam ist räumlich getrennt und kann sich nicht täglich treffen.
- Spezialisten stehen nur für eine begrenzte Zeit oder in eingeschränktem Umfang zur Verfügung.
- Die Kundenanforderungen bleiben unklar; der Produkteigner kann die Anforderungen nicht genau artikulieren.
Wer diese Barrieren überwindet, eine förderliche Organisationskultur schafft und die Mitarbeiter dafür gewinnen kann, der erntet mit dem agilen Projektmanagement besondere Früchte. Wie beim schlanken Management wird bei der agilen Vorgehensweise zumeist die Qualität der Ergebnisse verbessert und weniger Ressourcen werden verschwendet. Alle fokussieren sich auf das Wesentliche. Die Produktivität steigt, aber auch die Zufriedenheit der Kunden und der Stakeholder.
Die ständige und regelmäßige Kommunikation fördert die Transparenz. Engpässe werden schnell erkannt und können beseitigt werden. So kommt das Projekt insgesamt schneller voran.
Auch die Mitarbeiter selbst können von dieser Vorgehensweise profitieren. In ihrer Befragung zur agilen Softwareentwicklung hat it-agile von den Teilnehmern erfahren:
- Diese schätzen vor allem, dass sie jetzt mehr Spaß bei der Arbeit hätten.
- Sie können außerdem sehr viel mehr lernen und ihr Wissen erweitern.
Am meisten schätzten sie, dass sie im Projekt flexibler sind. Auch wenn sich die Ziele und die Anforderungen der Auftraggeber ändern, so kann das Projektteam vergleichsweise schnell und einfach seine Arbeiten und den Fortschritt anpassen. Sie sind agil.
Mehr zum Thema auf:
http://www.business-wissen.de/schlagwoerter/projektmanagement/