Agiles Vorgehen

Inzwischen habe ich viele Projekte sowohl nach der einen als auch der anderen Projektvorgehensweise durchgeführt und musste erkennen, dass beide Ansätze nicht nur ihre Berechtigung haben, sondern mittlerweile klar die gleichen Themen behandeln und erfolgreiche Lösungen für die verschiedenen Aufgabenstellungen bieten.

Es gibt noch etwas anderes als die „klassischen“ Projektvorgehensmodelle.

Noch vor wenigen Jahren empfand ich die unterschiedlichen Projektvorgehensmodelle als „konkurrierende“ Vorgehensweisen. Dies hatte unter anderem darin seinen Ursprung, dass die verschiedenen Vorgehensmodelle nicht immer alle Themengebiete des Projektmanagements gleich intensiv behandelten und nicht immer brauchbare Lösungsansätze bereit hielten.

Außerdem existierten in dem Konzern, für den ich damals arbeitete, zwei damals noch sehr unterschiedliche Ansätze gleichzeitig, nämlich nach PMI und nach Prince2. Im deutschen Konzernumfeld wurde das Vorgehen nach PMI favorisiert, während im internationalen Umfeld der Ansatz nach Prince2 vorgeschrieben war.
Die Vertreter beider „Lager“ standen sich lange Zeit scheinbar unversöhnlich gegenüber und jede Seite behauptete mit großer Selbstsicherheit den einen richtigen Ansatz zu verfolgen.

Inzwischen habe ich viele Projekte sowohl nach der einen als auch der anderen Projektvorgehensweise durchgeführt und musste erkennen, dass beide Ansätze nicht nur ihre Berechtigung haben, sondern mittlerweile klar die gleichen Themen behandeln und erfolgreiche Lösungen für die verschiedenen Aufgabenstellungen bieten.

In den letzten Jahren kamen für mich dann noch eigene Erfahrungen mit den Methoden der agilen Vorgehensweise hinzu.
Anfangs empfand ich das agile Vorgehen als seltsamen Sonderweg und wenig methodische Vorgehensweise. Nach vielen Gedankenaustauschen mit in agilem Vorgehen erfahrenen Projektleiterkollegen, einigem Literaturstudium und vielen Selbstversuchen in eigenen Projekten musste ich mich eines Besseren belehren lassen.

Inzwischen wende ich agile Methoden überall da, wo es geht, in meinen Projekten selber an. Bisher ist die Mehrheit meiner Projekte durch die folgenden Umstände geprägt:

  • große und komplexe Projektvorhaben,
  • relativ lange Projektlaufzeiten von ein bis zwei Jahren,
  • große, gemischte Projektteams,
  • feste Terminvorstellungen,
  • feste Projektbudgets,
  • zahlreiche Anforderungen und umfangreiche Konzepte,
  • ausgeprägte und komplexe Prozesse, sowohl in den Geschäftsprozessen als auch in den Systementwicklungs- und Systembetriebsabläufen
  • Umfangreiche und komplexe Vorgaben für Abläufe, Produktdesign oder öffentlichkeitswirksame Ergebnisse.

Dies führte in der Vergangenheit dazu, dass die große Mehrheit meiner Kunden einen der „klassischen“ Ansätze (nach PMI, Prince2 oder V-Modell) als Projektvorgehen vorgegeben hat. Mittlerweile werden die Projektbetreiber, was die Projektvorgehensweise angeht, zunehmend sicherer und auch experimentierfreudiger. Das ist zumindest bei den Kunden, mit denen ich in den letzten Jahren gearbeitet habe, der Fall.
Man versucht in der Projektpraxis immer öfter bewusst das Beste aus allen Vorgehensweisen sinnvoll zu kombinieren, um die alltäglichen Probleme in der Projektarbeit zu lösen. Ich treffe heute zunehmend auf Kunden, die alles „ausprobieren“, was Erfolg verspricht und gute Ergebnisse liefert.

Nach meiner Erfahrung ist agiles Vorgehen in IT-Projekten dann ungeeignet, wenn:

  • Die Projektziele klar formuliert und bis zum Projektende stabil sind.
  • Der Auftraggeber vom Projektteam methodisches Vorgehen mit fest definierten Ergebnisdokumenten verlangt.
  • Das Projekt eine klare Führung braucht.
  • Das Projektteam räumlich verteilt, durch andere Aufgaben gebunden oder eher groß ist.
  • Viele Projektbeteiligte und (externe) Dienstleister koordiniert werden müssen.
  • Termin- und Budgeteinhaltung wichtiger sind als der Produktumfang.
  • Hohe Anforderungen an die Dokumentation gestellt werden.

Vergleich Agile Methoden Klassische Methoden

Fazit:

Die eine allein selig machende Projektmanagementvorgehensweise gibt es nicht. In der klassischen Vorgehensweise verwende ich inzwischen regelmäßig einige Elemente des agilen Vorgehens:

  • tägliche kurze Stand Up-Meetings,
  • regelmäßige Retrospektiven,
  • Selbstorganisation der Entwicklungsteams

Auf einige Elemente der „klassischen“ Vorgehensweise möchte ich nicht verzichten:

  • Ausführliche Anforderungsdokumentation,
  • Liste der kritischen Erfolgsfaktoren,
  • Projektstrukturplan,
  • Meilensteine,
  • regelmäßige Risikodokumentation und bewusste Gegenmaßnahmen,
  • bewusst gesteuerter Betriebsübergang,
  • klar definierte Zuständigkeiten und Eskalationswege.

Die Elemente der „klassischen“ und der agilen Vorgehensweise können sich sehr gut ergänzen – müssen aber sehr sorgfältig ausgewählt und angewendet werden.

Product Backlog und User Stories ersetzen kein sorgfältig erstelltes Anforderungsdokument und kein wirksames Anforderungsmanagement

Die Anwender haben in der Regel eine ganz eigene Art mit Projektdokumenten umzugehen und ganz eigene Vorstellungen darüber was z.B. ein gutes Fachkonzept ausmacht. Ich habe die Erfahrung gemacht, dass das unmittelbare Arbeitsumfeld eines Anwenders und die dort üblichen Dokumente großen Einfluss auf seinen Umgang mit Texten haben.
Wer das nicht glaubt möge einmal ein Fachkonzept zusammen mit Werbefachleuten, Ingenieuren oder Juristen schreiben. Er wird dabei interessante Erfahrungen darüber machen, was man alles mit Sprache so anstellen kann.
Meiner Meinung nach sollte ein sorgfältig erstelltes Anforderungsdokument folgende Kriterien erfüllen:

  • gut verständlich,
  • vollständig,
  • widerspruchsfrei,
  • nachweisbar
  • eindeutig,
  • testbar.

Ein Product Backlog ist dagegen lediglich eine priorisierte Liste von Produkteigenschaften. Auf ein Anforderungsdokument sollte eine Testplanung und die Durchführung der Systemtests bis zur Abnahme aufbauen können.
Über den Weg Anforderung – Testfall – Testdokumentation – Produkteigenschaft sollte nachgewiesen werden können, was aus jeder einzelnen Anforderung im Laufe der Entwicklung wurde und warum ein Entwicklungsergebnis so ist, wie es ist. Wer hat wann was gefordert?

Bei umfangreichen IT-Projekten ist die korrekte Projektplanung eine der wichtigsten Grundlagen

Die Auftraggeber und Entscheider in großen IT-Projekten verlangen nach wie vor eine belastbare Gesamtplanung, klar definierte Termine und realistische Projektbudgets. Außerdem steht nach wie vor ein regelmäßiges Projektberichtswesen, das auf den Ergebnissen der Projektplanung beruht, bei Entscheidern hoch im Kurs.
Das Vorgehen Scrum zum Bespiel bleibt durch die Selbstorganisation der Entwickler eine Blackbox für Entscheider. In der Regel tolerieren Entscheider das Fehlen von konkreten Entwicklungszielen, genauen Aufwandsschätzungen und realistischen Projektterminen wirklich nur, wenn die erforderliche Lösung tatsächlich völlig unbekannt ist. Hier kann die agile Vorgehensweise durch ihre Flexibilität und Spontanität bessere Ergebnisse vorweisen.

Die Schätzmethoden der agilen Vorgehensweise sind eine wertvolle Bereicherung

In den meisten Fällen lasse ich die Projektaufwendungen nach der Methode PERT schätzen. Ich denke der Ansatz mit einem optimistischen, einem pessimistischen und den wahrscheinlichen Aufwandswerten verspricht einen guten Mittelwert. Außerdem können dann Wahrscheinlichkeitswerte für die Projektaufwendungen gemacht werden. Es ist allerdings notwendig, dass im Projektteam schon Erfahrungswerte für die Aufwendungen der Arbeitspakete vorliegen.
Die agilen Schätzmethoden relative Schätzung und Planning Poker können, in den Fällen, in denen keine Erfahrungswerte für Projektaufwendungen vorliegen. Insbesondere die zweite Methode ist inzwischen unter vielen Entwicklern beliebt.

Die Kommunikation im Projekt kann durch agile Elemente spürbar verbessert werden

Tägliche kurze Treffen mit dem Projektteam (Stand Ups) und regelmäßige Termine zur kritischen Würdigung des bisher Erreichen (Retrospektiven) verbessern nach meiner Erfahrung die Kommunikation im Projekt spürbar.
Als Projektleiter bekomme ich täglich den aktuellen Stand der einzelnen Arbeitspakete und die aktuellen Probleme jedes einzelnen Projektmitarbeiters berichtet. Ich kann so schnell reagieren und bin jederzeit in der Lage selber Auskunft über die Details der Projektarbeit zu geben. Ich bekomme außerdem einen aktuellen und ständigen Einblick in die Arbeit des Projektteams und kann Fähigkeiten und Leistungen der Projektmitarbeiter besser einschätzen. Das hilft mir auch bei der individuellen Förderung der Projektmitarbeiter.

Das Qualitätsmanagement sollte sehr gut organisiert sein und auf den Ergebnissen des Anforderungsmanagements aufbauen

In den meist sehr umfangreichen und komplexen IT-Projekten unterstützt ein sehr gut organisiertes Qualitätsmanagement die Systementwicklung am Besten. Dazu gehören nach meiner Erfahrung:

  • korrekt entwickelte und dokumentierte Geschäftsprozesse,
  • eine aufeinander abgestimmte Entwicklung der Anwendungssysteme und der Geschäftsprozesse,
  • einzeln dokumentierte Anforderungen,
  • nachverfolgbare Anforderungen,
  • klar definierte Qualitätskriterien und –ziele für jedes Projektergebnis das dem Qualitätsmanagement unterliegt,
  • klar definierte Testfälle,
  • eine realistische und gründliche Testplanung und –durchführung,
  • eine anschauliche Testdokumentation,
  • eine anschauliche Produktdokumentation für den Betriebsübergang.

Ich greife deshalb immer wieder auf die bewährten Vorgehensweisen und Ergebnisse zurück.

Die Dokumentationen der agilen Vorgehensweise können die üblichen Projektdokumentationen ergänzen

In den für mich heute häufigen IT-Großprojekten würde ich mich nicht nur allein auf User Stories und Product Backlog verlassen. Die Abläufe in der Systementwicklung und dem Systembetrieb vieler Kunden erfordern häufig umfangreiche und klar beschriebene Dokumentationen.
Die meisten IT-Projekte, an denen ich in den letzten Jahren beteiligt war, waren durch

  • komplexe Geschäftsprozesse,
  • zahlreiche Schnittstellen,
  • komplexe Alt- und Umsysteme,
  • komplexe Betriebsabläufe der Systeme

geprägt. Kurze User Stories bilden solche Prozesse nicht immer adäquat ab. Außerdem haben viele Vertreter der Fachabteilungen Probleme damit, ihre komplexen Geschäftsprozesse in kleine Schritte zu unterteilen. Für sie ist nur ein weitgehend kompletter Geschäftsprozess mit konkreten Ergebnissen (be)greifbar und mit ihrem Arbeitsalltag zu vereinbaren.
Hier sind oftmals umfangreiche und ausführliche Dokumentationen notwendig. Diese Dokumente unterstützen, insbesondere, wenn sie mit zahlreichen Diagrammen versehen sind, die Zusammenarbeit zwischen den einzelnen Prozessbeteiligten aus verschiedenen Organisationsteilen und den Übergang von der Systementwicklung in den Systembetrieb.
In rein agilen Projektvorhaben reichen die Dokumente der agilen Projektvorgehensweise sicherlich aus.

Für einen reibungslosen Betriebsübergang und Betrieb eines Anwendungssystems müssen Entwicklungs- und Service-Leistung zusammen entwickelt werden.

Genau betrachtet besteht jedes größere Entwicklungsprojekt aus der Entwicklungsleistung und der Service-Leistung. Das Anwendungssystem muss ja nicht nur entwickelt, sondern später auch so betrieben werden, dass es die Geschäftsprozesse des Unternehmens optimal unterstützt.
Beide Leistungsarten müssen während der gesamten Projektlaufzeit zusammen entwickelt werden. Vom Angebot über die Anforderungsanalyse und Anforderungsdokumentation, über die Systementwicklung und die Tests, bis zur Übergabe an den Betreiber der Anwendung müssen beide Leistungen als gleichwertig und zusammen gehörend behandelt werden.
Da bei vielen Systembetreibern die Anwendungen mit komplexen Prozessen und wechselndem Personal betrieben werden, sind in der Regel umfangreiche und ausführliche Beschreibungen der Anwendungen notwendig. Die in den Programmen selbst enthaltenen Angaben zur Dokumentation und die bei der agilen Vorgehensweise üblichen Dokumente reichen dann in der Regel nicht aus.
Eine weitere Herausforderung besteht darin, dass bei vielen Systembetreibern bestimmte feste Stichtage definiert sind an denen Veränderungen an den Systemen vorgenommen werden (definierte Release-Wechsel).

Wenn Sie zu den genannten Themen Beratung oder Schulungen wünschen, dann schauen Sie sich einmal meine interessanten Angebote an:

alle Dienstleistungen anzeigen