Klassisches Projektmanagement beginnt mit der Planung. Diese umfasst die Grobplanung, die Bereitstellung von Kapazitäten, die Priorisierung des Projekts und der damit einhergehenden Aufgaben sowie die Detailplanung (z. B. mit einem Gantt-Diagramm). Mit der Unterzeichnung des Pflichtenhefts, in dem die Anforderungen fixiert werden, endet in der Regel die Mitwirkung interner und externer Auftraggeber. Probleme ergeben sich dann, wenn Kosten unvorhergesehen steigen oder der ursprünglich geplante Aufwand wächst, weil sich die Anforderungen im Nachgang geändert haben. Hier wird der Nachteil von rein klassischen Managementmethoden deutlich. Der Vorteil hingegen liegt in der guten Nachvollziehbarkeit aller Schritte (Termine, Weiterentwicklungen) aufgrund der umfangreichen Dokumentation.

Ein lineares Vorgehensmodell zur Projektorganisation im klassischen Sinne ist das Wasserfallmodell, bei dem der Ablauf in einzelne Projektphasen unterteilt wird (vgl. Abbildung 1).^[1]

Hierbei gehen die Phasenergebnisse immer als bindende Vorgabe in die nächste Phase ein, wobei jede Phase definierte Start- und Endpunkte mit definierten Ergebnissen hat. Phasenbezogene Rücksprünge sind in der Regel nicht vorgesehen und verursachen häufig unüberblickbare Kosten- und Zeitaufwände. Das Wasserfallmodell wird meist dort angewendet, wo Anforderungen, Leistungen und Abläufe während der Planung präzise beschrieben werden können. Der Kunde wird ausschließlich während der Analyse der Anforderungen eingebunden.

In der heutigen Zeit werden ständig neue Technologien in immer kürzeren Abständen auf den Markt gebracht. Dieser Herausforderung müssen Unternehmen und deren Mitarbeiter begegnen, indem sie schnell und flexibel reagieren und sich den ständig verändernden Marktbedingungen anpassen, um wettbewerbsfähig bleiben. Folglich entstehen innovative und komplexe Aufgaben im Unternehmen, an deren Bewältigung Experten aus unterschiedlichen Bereichen beteiligt sein müssen. Dies erfordert im Sinne einer agilen Vorgehensweise und Führung die selbstständige Organisation innerhalb des Projektteams, welche den Erfolg des Projektes wesentlich beeinflusst.

Der Begriff »Agilität« ist ursprünglich auf die Softwareentwicklung zurückzuführen, einhergehend mit dem Ziel, flexibler und schneller auf veränderte Markt- und Kundenanforderungen reagieren zu können und Anforderungen nicht von Beginn an final festzulegen, sondern nur ein Grobkonzept zu entwerfen. Das heißt jedoch nicht, dass Agilität mit Planlosigkeit einhergeht. Agile Projekte bedürfen ebenfalls einer Führung und Organisation.

Mit Blick auf das magische Dreieck des Projektmanagements wird der Unterschied zwischen klassischem und agilen Projektmanagement deutlich (vgl. Abbildung 2).^[2]

Beim klassischen Projektmanagement gibt es fixe Anforderungen, die innerhalb eines Zeit- und Kostenplans umgesetzt werden müssen. Können die Anforderungen unter den gegebenen Bedingungen nicht erfüllt werden, müssen der Zeitplan und/oder die Kosten angepasst werden. Beim agilen Projektmanagement hingegen sind der Zeit- und Kostenplan fix, die Anforderungen hingegen variabel, sodass alles, was in der vorgegebenen Zeit nicht umgesetzt werden kann, vernachlässigt wird.

Gründe für eine zunehmend agile Denkweise außerhalb der Softwarebranche liegen in den stark veränderten Anforderungen bezüglich der Umsetzung von Projekten. Lineare Planungs- und Durchführungsprozesse stoßen an ihre Grenzen, zudem haben sich beispielsweise im Bereich Maschinenbau die Entwicklungszyklen in den letzten zehn Jahren um ein Drittel verkürzt. Aufgrund der sich schnell verändernden Umwelt und der weniger statisch bleibenden Kundenanforderungen können diese nicht zu Beginn einer Innovation exakt konkretisiert werden. Die Qualität und Quantität von Planungsdaten nehmen im Laufe des Entwicklungsprozesses zu. Bezüglich der Planung gibt es zu Projektbeginn hohe Unsicherheiten. Gerade beim klassischen Projektmanagement werden Daten, die sich während der Umsetzung konkretisieren, nicht berücksichtigt und die Kunden nur geringfügig einbezogen. Zusammenfassend lässt sich folglich festhalten, dass klassische Projektmanagementmethoden aufgrund des steigenden Preisdrucks und der fehlenden Fähigkeit, auf Anforderungen flexibel zu reagieren, Projekte lähmen und teuer machen können. Agile Methoden setzen genau dort an und versuchen, mit Kommunikation, Interaktion, Dynamik und Flexibilität den bestehenden Herausforderungen zu begegnen.

Agile Projekte bedürfen wie die klassischen ebenfalls einer strukturierten Organisation und Führung. Die agile Herangehensweise kommt aus dem Bereich der Softwareentwicklung, einer Branche mit sehr geringem Materialaufwand, dafür aber hohem Personaleinsatz. Sie geht von der Erwartungshaltung aus, dass es einen definierten Zeit- und Kostenrahmen gibt, die Anforderungen aber flexibel bleiben (vgl. Abbildung 2). Ein gutes Beispiel, um diese Herangehensweise besser nachvollziehen zu können, ist der Bau eines Hauses. Der Kunde legt fest, wie viel Geld er ausgeben möchte und in welcher Zeit das Haus fertiggestellt werden soll. Änderungen (z. B. ein zusätzlicher Garagenanbau) können realisiert werden, wenn der Zusatzwunsch innerhalb von Zeit und Budget umgesetzt werden kann. Agilität geht davon aus, dass Mindestanforderungen (z. B. der Rohbau des Hauses) zuerst umgesetzt werden. Weitere geringer priorisierte Anforderungen können in regelmäßiger Absprache mit dem Kunden ergänzt und/oder ausgetauscht werden (z. B. ob ein Treppenaufgang in Marmor notwendig ist oder ob eine Holztreppe ausreicht). Agilität bindet somit den Kunden von Beginn an stärker in den Entwicklungsprozess ein. Es wird grundsätzlich davon ausgegangen, dass alle Anforderungen zu Beginn eines Projekts nicht vollständig definiert werden oder Prioritäten sich im Laufe der Zeit nicht ändern können. Regelmäßige Absprachen mit dem Kunden sind erfolgskritisch.

Die Grundpfeiler für die agile Entwicklung sind im »Agilen Manifest« festgelegt (vgl. Abbildung 3). Diese lauten:^[3]

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Der Mensch steht im Mittelpunkt, Werkzeuge können ausgetauscht und Prozesse überarbeitet werden. Eine sinnvolle Standardisierung muss noch genügend Freiraum für individuelles Handeln und die interaktive Kommunikation lassen.
• Funktionierende Endprodukte sind wichtiger als eine umfassende Dokumentation. Hierbei ist das entstandene Projektergebnis wichtiger, als die Frage, wer die Schuld an einem potenziellen Scheitern trägt.
• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.Agiles Projektmanagement vertritt die Meinung, dass es nicht sinnvoll ist, zu Beginn eines Projektes vertragliche Regelungen darüber zu treffen, welche Funktionalitäten für den Kunden zu leisten sind. Stattdessen sollten Dokumente erstellt werden, die bei Änderungsbedarf einfach angepasst werden können.
• Reagieren auf Änderungen ist wichtiger als das Befolgen eines Plans.Veränderungen werden positiv betrachtet und die Planung einbezogen, um daraus einen Nutzen zu generieren.

Aufgrund bestehender Restriktionen ist eine agile Herangehensweise in stark regulierten Branchen, wie zum Beispiel dem Maschinenbau, der Pharmaindustrie oder der Chemie, schwer umzusetzen. Zudem geht gerade zu Beginn ein hoher Schulungsaufwand damit einher sowie eine aufwändige Planung und Steuerung.

Es gibt verschiedenen Methoden, welche im agilen Projektmanagement Anwendung finden. Im Folgenden werden Scrum und Kanban näher erläutert.

Eines der bekanntesten Vorgehensmodelle im agilen Projektmanagement ist Scrum. Hierbei handelt es sich um ein anpassbares Vorgehen, basierend auf den Prinzipien »erfassen – umsetzen – überprüfen – ändern«, welches sich besonders für Anfänger eignet. Im Fokus steht die Einbindung des Kunden sowie die Kommunikation mit diesem. Scrum umfasst die folgenden Schritte.^[4]

1. Schritt: Erarbeitung einer Anforderungsliste mit dem Kunden zusammen.
2. Schritt: Priorisierung der Anforderungen aus Kundensicht.
3. Schritt: Aufwandsschätzung des Umsetzungsteams für alle Anforderungen.
4. Schritt: Auswahl geeigneter Anforderungen für eine in einem Zeitraum X (maximal drei Wochen) umsetzbare Liste.
5. Schritt: Umsetzung der ausgewählten Anforderungen durch Team ohne Beeinflussung von außerhalb.
6. Schritt: Vorführung der Ergebnisse an Kunden.
7. Schritt: Überarbeitung der Anforderungen (Art und Priorisierung) mit Kunden.
8. Schritt: Wiederholung der Schritte 3-7, bis der Zeit- oder Kostenplan erreicht sind.
9. Schritt: Auslieferung an den Kunden.
10. Schritt: Lessons Learned.

Die im Scrum vergeben Rollen sowie verwendeten Fachbegriffe werden im Folgenden erläutert:^[5]

Product Owner: Der Product Owner agiert in der Rolle des Kunden als Schnittstelle zwischen dem Scrum Team und internen und externen Stakeholdern des Projekts. Er managt das Product Backlog, definiert die Anforderungen und Akzeptanzkriterien, schreibt und priorisiert die Product Backlog Items/ User Stories. Er verantwortet den wirtschaftlichen Erfolg.

Product Backlog: Sammlung von Inhalten, die (insgesamt) umgesetzt werden könnten. Das Product Backlog wird häufig durch eine (fortlaufende) Liste realisiert. Die einzelnen Einträge werden als Product Backlog Items oder einfach als Product-Backlog-Einträge bezeichnet. Verantwortlich für die Pflege des Product Backlogs ist der Product Owner, der auch die Priorisierung übernimmt. Aus den am höchsten priorisierten Product Backlog Items wird zu Beginn eines Sprints (im Sprint Planning) das Sprint Backlog erstellt.

Sprint Planning: Ein Meeting in Scrum, bei dem zu Beginn eines Sprints die Planungen für den Sprint durchgeführt werden. Kann unterteilt werden in Sprint Planning 1 (strategisch, grob) und Sprint Planning 2 (taktisch, detailliert). Im Sprint Planning wird auch das Sprint-Ziel festgelegt.

Scrum Team: Das Scrum Team besteht aus dem Product Owner, dem Entwicklungsteam sowie dem Scrum Master. Da das Entwicklungsteam nach Scrum Guide idealerweise aus 3 bis 9 Personen bestehen soll, ergibt sich eine Größe von 4 (wenn der Scrum Master auch Mitglied des Entwicklungsteams ist) bis 11 Personen.

Sprint Backlog: Im Sprint Backlog werden diejenigen Aufgaben (Items oder Tasks) festgehalten, die im aktuellen Sprint umgesetzt werden (sollen).

Sprint: Zeitdauer (Timebox) in der ein Zyklus in Scrum abgearbeitet wird. Typischerweise 2 bis 4 Wochen. Die Sprintlänge wird vor Beginn des Projekts festgelegt und sollte dann nicht mehr verändert werden.

Sprint Retrospective: Ein Ereignis/Meeting (bei Scrum am Ende eines Sprints), bei dem das Team den eigenen Entwicklungsprozess betrachtet und Verbesserungen erarbeitet.

Daily Scrum: Beim Daily Scrum oder kurz Daily (ein Scrum Ereignis/Scrum Meeting) trifft sich das Entwicklungsteam, um vorzustellen, woran der Einzelne gerade arbeitet. Wie der Name schon andeutet, findet dieses Meeting täglich statt. Die Dauer sollte beschränkt sein – typischerweise 15 Minuten. Häufig stehen die Teilnehmer beim Daily Scrum: daher ist auch der Name Daily Stand-Up gebräuchlich.

Scrum Master: Der Scrum Master ist dafür verantwortlich, dass das Entwicklungsteam gemäß des Scrum-Prozesses arbeiten kann. Er sorgt für die Beseitigung von Hindernissen (Impediments) für das Entwicklungsteam und fördert dessen Zusammenarbeit.

PSI – Potentially Shippable Product Increment: Das PSI ist eine Ergänzung zum bestehenden Produkt, die in einem Sprint umgesetzt werden sollte und die einen Mehrwert für den Kunden/für das Produkt bringt. Das PSI muss auslieferbar sein (aber nicht zwangsläufig ausgeliefert werden).

Scrum setzt bei der Umsetzung auf Transparenz durch die Zugänglichkeit aller Informationen, Prozesse, Dokumente und Entscheidungen. Aufgrund der Bereitstellung der Ergebnisse sowie der kontinuierlichen Einbeziehung des Kunden ist eine gute Nachvollziehbarkeit gewährleistet. Grundlage hierfür ist eine kontinuierliche interne und externe Kommunikation sowie häufige Absprachen mit dem Kunden, ein selbstorganisiertes Team und tägliche »Stand-Up«-Besprechungen. Bei Scrum handelt es sich um ein klar strukturiertes Vorgehensmodell zur praktischen Umsetzung von Agilität, wodurch es auch für Einsteiger gut anzuwenden ist. Es gibt wenige Regeln und Rollen sowie Schlüssel-Dokumente (Vision, Backlogs, Inkremente), die pflegeleicht sind und dabei größtmögliche Transparenz bieten. Es handelt sich um ein iteratives Vorgehen mit definierten Zeitintervallen (Sprints). Scrum eignet sich besonders für hochkomplexe Projekte mit wechselnden Anforderungen in einem unbeständigen Umfeld.

Ein weiteres bekanntes Vorgehensmodell im agilen Projektmanagement ist Kanban.^[2] Diese ursprünglich aus dem Qualitäts- und Produktionsmanagement kommende Methode ist die einfachste im agilen Projektmanagement, da keine Schulungen oder aufwändige Software benötigt werden. Grundsätzlich wird im ersten Schritt eine Tafel – das Kanban-Board – mit drei oder mehr Spalten (je nach Bedarf) erstellt. In den Spalten ist der Status einer Aufgabe (offen, in Bearbeitung, abgeschlossen) unterschieden. Im nächsten Schritt erfolgt die Ermittlung der Anforderungen mit dem Kunden bzw. im Team, eine Priorisierung ist nicht zwingend erforderlich. Im Folgeschritt werden die zeitlich ähnlich gelagerten Anforderungen auf das Kanban-Board übertragen sodass sich dann jedes Teammitglied eine Aufgabe suchen und diese selbstständig erledigen kann (vgl. Abbildung 5).

Die Kanban-Methode setzt durch die Nachvollziehbarkeit jedes Arbeitsschritts auf maximale Transparenz und ist einfach umzusetzen, da keine aufwändige Dokumentation erforderlich ist. Durch die Vielzahl von Ausgestaltungsmöglichkeiten und das Fehlen von klaren Regeln lässt sich Kanban auf individuelle Unternehmensbedürfnisse anpassen. Weil Engpässe schnell erkannt und behoben werden können, ist eine Projektbeschleunigung die Folge. Durch die Limitierung der Anzahl gleichzeitig auszuführender Aufgaben werden der Workflow verbessert und Durchlaufzeiten verkürzt, weil die Mitarbeiter sich auf eine Aufgabe konzentrieren und nicht mehrere Aufgaben gleichzeitig ausführen müssen. Die Kanban-Methode lässt sich sehr gut mit klassischen Methoden verknüpfen, jedoch kann die Umsetzung dieser agilen Methoden aufgrund fehlender Regeln für Anfänger schwierig sein. Für komplexe Projekte mit vielen Abhängigkeiten ist Kanban eher ungeeignet.