Die projektbezogene Arbeit nimmt in allen Ländern und Branchen stetig zu - ein Trend, der seit Längerem zu beobachten ist. Ziel ist es, die Effizienz und das zielgerichtete Handeln der Mitarbeiter zu fördern. Dieser Wandel hat zur Folge, dass den unterschiedlichen Ansätzen im Projektmanagement eine größere Bedeutung zukommt. Heute sind nicht nur klassische Methoden weit verbreitet, sondern gibt es auch neue Ansätze, einschließlich des agilen Projektmanagements. Letzteres ist übrigens nicht nur in Projekten zur Softwareentwicklung anwendbar, auch wenn es ursprünglich aus diesem Bereich stammt. Agiles Projektmanagement ist auf jedes Projekt übertragbar, das einen gewissen Grad an Komplexität aufweist.
Foto: Trismegist san - shutterstock.com
Digitalisierung treibt agiles Projektmanagement
Die Geschwindigkeit des Wandels und die Vielfalt des digitalen Geschäftsverkehrs führen zu einer zunehmenden Kluft zwischen Business und IT. Nicht nur das Geschäft mit der Softwareentwicklung ist einem sich immer schneller verändernden Marktumfeld ausgesetzt, auch das Business wird mit folgenden Anforderungen konfrontiert:
• Schnellere Veränderungen im Unternehmen und daraus resultierende verkürzte Produktzyklen und Time-to-Market-Dauer.
• Personalisierung von Produkten und Dienstleistungen wie Lot Size One und neue Konsumgewohnheiten.
• Unvermeidliche Technologieeinbindung, das heißt disruptive und dynamische Veränderung der technologischen Fähigkeiten (Skill Shift).
• Vielfältige digitale Geschäftsmöglichkeiten, die auf Technologien wie KI und IoT basieren, sowie verbesserte Produkte und Dienstleistungen durch Analytics-Verfahren.
Je unsicherer der Sektor ist, in dem ein Projekt durchgeführt wird, desto schwieriger ist es, ein solches Projekt zu planen oder sich an einen solchen Plan zu halten. Darin liegt jedoch eine der Hauptstärken des agilen Projektmanagements. Um Projekte in dieser komplexen Welt, die mehr denn je von Unsicherheiten und Risiken geprägt ist, erfolgreich zu managen, sind Kenntnisse in agilem Projektmanagement und Lean Management erforderlich. Zunehmende Komplexität ist hierbei die Herausforderung.
Planung wird nicht überflüssig - im Gegenteil: sie ist wichtig. Bei komplexen Projekten ist es jedoch nicht möglich, mit einem großen Plan zu agieren. Um das Projektziel zu erreichen, ist eine häufigere und segmentierte Planung erforderlich, wie zum Beispiel ein dreiwöchiger Sprint-Plan. Es reicht für Projektmanager nicht aus, das Vorhaben mit einer umfangreichen Planungsphase zu Projektbeginn zu starten und sich an einen Plan zu halten, der nicht erfüllt werden kann. Es ist nicht erforderlich, umfangreiche Anforderungsdokumente, Spezifikationen sowie Lasten- und Pflichtenhefte zu formulieren.
Agiles Projektmanagement ist die Antwort auf Komplexität. Agil sein, heißt auf Veränderungen reagieren zu können. Agiles Projektmanagement steigert die Leistung der Projekte und ermöglicht eine schnelle und effiziente Umsetzung (schnellere Auslieferung eines Produkts), Innovationsübernahme und Verbesserung der Skalierbarkeit (Reaktion auf veränderte Anforderungen und Projektausrichtung).
Scrum und Kanban - agile Methoden im Überblick
Zwei der gängigsten agilen Projektmanagement-Methoden sind Scrum und Kanban. Beide unterstützen die Prinzipien und Werte des agilen Manifests. Und beide Verfahren zielen darauf ab, komplexe Herausforderungen mit einem klaren Blick auf den Umfang, die Qualität und den Zeitpunkt eines Projekts zu erfassen und diese effektiv und menschlich anzugehen, indem sie flexibel auf Veränderungen reagieren und eine größere Kontrolle haben als andere Methoden.
Diese Prinzipien und die nicht reflektierte Anwendung der Methoden allein garantieren jedoch nicht den Erfolg eines agilen Ansatzes. Hier liegt das größte Missverständnis beim Einsatz von Tools für die agile Produktentwicklung. Nur Disziplin, Kommunikation und hohe Motivation können Hindernisse beseitigen, Verschwendung vermeiden und ein Projekt zum Erfolg führen. Es sind die einzelnen Projektmitglieder, die Framework füllen und die Prozesse gestalten. Agile Methoden sind leicht zu verstehen, aber schwer zu beherrschen, da sie auf einem System von zusammenarbeitenden Komponenten beruhen, insbesondere auf den Personen, die in einem Projekt zusammenarbeiten.
Scrum und Kanban - Gemeinsamkeiten:
beide Methoden arbeiten nach dem Pull-Prinzip: im Scrum Framework wird es für die Sprint-Planung verwendet, in Kanban für das gesamte Board.
Scrum und Kanban sind sowohl lean als auch agil.
Die Teams organisieren sich selbst.
In Scrum und Kanban wird der Release Plan optimiert: Scrum verwendet hierfür Team-Velocity, Kanban bedient sich der Lead-Time.
"Limit your WIP" heißt es im Kanban bei Statusübergängen. WIP steht für Work In Progress und die Aufforderung sagt im Wesentlichen: Nicht zu viel auf einmal. In Scrum limitiert der Sprint die Anzahl der zu erledigenden Aufgaben.
Beide Vorgehensmodelle setzen darauf auslieferbare Softwareinkremente schnell und oft zu releasen.
Durch Transparenz sollen Optimierungspotentiale aufgezeigt und dadurch Effizienzsteigerungen herbeigeführt werden. In Scrum forciert dieses Thema im Wesentlichen der Scrum Master, in Kanban wird es durch die Stakeholder und das Management getrieben, sofern durch WIP-Limits die Bottlenecks aufgezeigt werden.
Scrum und Kanban - der maßgebliche Unterschied:
In Kanban ist keine fest zugeordnete Rolle definiert, aber die Erfahrung zeigt, dass die Implementierung einer agilen Methode ohne den Einsatz eines agilen Trainers häufig zu einer Verdünnung führt und nicht zum gewünschten Erfolg führt.
Die Produktverantwortung trägt in Scrum der Product Owner. In Kanban wird nicht vorgeschrieben, wer die Definition und Priorisierung der Anforderungen übernimmt.
Scrum vs. Kanban - agile Methoden im Vergleich
Der Hauptunterschied zwischen den beiden Methoden besteht darin, dass sich Scrum auf die iterative Produktentwicklung und Kanban auf die kontinuierliche Prozessverbesserung konzentriert. Mit Scrum ist es daher möglich, das vom Kunden gewünschte Produkt zu entwickeln. Bei Kanban liegt das Augenmerk im Projekt auf kurzen Vorlaufzeiten und der Vermeidung von Makulatur. Kanban konzentriert sich darauf, die Schwachstellen und Engpässe des Prozesses aufzudecken. Während Scrum pro Sprint auf ein in sich geschlossenes Produktinkrement hinarbeitet und das Produkt Iteration für Iteration erweitert und verbessert wird, ist Kanban bestrebt, den Prozessfluss zu optimieren.
Framework-Vorgabe | Scrum | Kanban |
Servant Leadership | Scrum Master | Benötigte Rollen, initial keine Rollen vorgeschrieben |
Produkt-Verantwortung | Product Owner | Existierende Rollen werden übernommen |
Teams | 3-9 Personen ("2-Pizza-Regel"), cross-functional, kollaborativ | keine Vorgaben bei Teamgröße, cross-functional oder spezialisiert, Pull-Mechanismus |
Framework-Vorgabe | Scrum | Kanban |
Timebox | Täglich im "daily standup meeting" | Keine Vorgaben |
Austausch | Team-retroperspektive nach jedem Sprint | Keine Vorgaben (nicht zu lange Abstände) |
Steering (Kunde & Stakeholder) | Review-Meeting nach jedem Sprint | Keine Vorgaben |
Team-Forecast | Vor jedem Sprint im Sprint Planning des Teams | Keine Vorgaben (Nachschub-Meetings müssen regelmäßig stattfinden) |
Framework-Vorgabe | Scrum | Kanban |
Anforderungsliste | Product Backlog | Backlog (auf Board geführt) |
Lieferzyklus | Sprint | Bestimmt von der Durchlaufzeit des Tickets |
Board | Sprint Backlog; ein Scrumboard ist optional und wird zu jedem Sprint neu mit Arbeitspaketen bestückt | Kanban-Board (dauerhaft: wird erst mit Beendigung des Produkts/Projekts gelöscht) |
Lieferung | Potentially Shippable Product Increment | Abgearbeitete Tickets (Arbeitspakete) |
Metriken | Velocity | Lead Time, Cycle Time, WIP |
Kanban oder Scrum?
Kanban eignet sich durch das Kernprinzip der kontinuierlichen Verbesserung als Methode in einem steuerbaren Softwareprozess. Kanban wird häufig in Support- oder Wartungsteams eingesetzt, wo die lösenden Aufgaben kompliziert, aber in der Regel nicht komplex sind (wie zum Beispiel Software-Rollouts oder Wartungsarbeiten). Kanban konzentriert sich auf Prozesseffizienz und Produktivitätssteigerungen.
Scrum hingegen konzentriert sich auf komplexe Softwareentwicklung. Scrum kann seine Stärken voll entfalten, wenn es in einem Umfeld eingesetzt wird, in dem ein neues komplexes Softwareprodukt oder eine Serviceleistung entwickelt werden soll. Scrum wird häufig in der Forschung und Entwicklung eingesetzt, wo empirisches Vorgehen auf der Agenda steht. Durch den Einsatz von Scrum in interdisziplinären Teams mit kurzen Feedback-Zyklen lässt sich das richtige Produkt mit überschaubarem Aufwand entwickeln. (pg/fm)
- 1. Unklare Arbeitslast
Bryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen. - 2. Undefinierte Erwartungen
Alle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia. - 3. Fehlende Management-Unterstützung
Die Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv. - 4. Methodik nach Schema F
Im Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt. - 5. Überlastete Mitarbeiter
„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet. - 6. Ungeteiltes Herrschaftswissen
Projekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann. - 7. Unklare Entscheidungsfindung
Im Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht. - 8. Fehlende Software
Exel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software. - 9. Gefahr des Ausuferns
Change Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist. - 10. Nicht "Nein" sagen können
Im Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man "nein" sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat. - 11. Mangelnder Zusammenhalt
Projektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3. - 12. Vergessener Arbeitsalltag
Hilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen. - 13. Zu häufige Meetings
Meetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren. - 14. Gut genug ist nicht immer gut
Sergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes. - 15. Nicht aus Fehlern lernen
Liz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden. - 15 Fehler beim Projektmanagement
Es gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.