Der Erfolg eines Projektes hängt von vielen Faktoren ab, auch von der Auswahl der für das Projekt angemessenen Management Methodik, agil, klassisch oder Hybrid.
20 Jahre Agiles Projektmanagement: 1999 veröffentlichte Kent Beck das Buch „Extreme Programming“ dem 2001 das Agile Manifest folgte, dazu Agile Prinzipien.
Seitdem hat sich die Welt der Software Projekte massiv gewandelt – und ist agil erfolgreich!
Es gibt jedoch Erfolgsfaktoren für Projekte, die in der Diskussion weniger prominent behandelt werden. Einige dieser Faktoren sollen hier anhand von Praxis-Beispielen betrachtet werden:
- Pragmatisches Anforderungsmanagement
- Nicht-funktionale Anforderungen
- Dokumentation
- Qualitätssicherung (QA)
Klassische (Wasserfall-)Projekte haben einen Anfang und ein Ende und einen linearen Projektplan aus vordefinierten Schritten. Dies ist für einmalige Vorhaben auf Basis bekannter Technologien und Verfahren durchaus angemessen. Bekannte Technologien implizieren angemessene Erwartungshaltung und daraus folgend sinnvolle funktionale und nicht-funktionale Anforderungen.
Agile Projekte etablieren einen iterativen Entwicklungsprozess. In der Softwareentwicklung sind Technologien jung und wechseln schnell. Regelmäßig ändern sich funktionale Anforderungen noch während der Projektlaufzeit. Eine Projektorganisation ist gefragt, die es den Developern erlaubt systematisch zu arbeiten – und dabei der Dynamik der technologischen Entwicklung gerecht zu werden.
In agilen Projekten können Development-Abteilungen kontinuierlich arbeiten – ein Projekt wird für das Developer Team als Prozess abgebildet.
Prozesse sind auf Dauer angelegt und werden dabei begleitend verbessert, modifiziert, angepasst.
Schlüssel für den Erfolg agiler Methoden ist eine solche iterative Vorgehensweise, inklusive des immer wieder neu angestoßenen kurzfristigen Austauschs mit dem Auftraggeber.
Agil versus Pflichtenheft: Eine weitere wichtige Innovation der agilen Vorgehensweise ist, von vorne herein zuzugeben, dass man vorab nicht alles weiß und wissen kann.
In der klassischen Projektplanung werden Unsicherheiten als Zeit- oder Kosten-Puffer ausgedrückt – eine nach aller Erfahrung unzureichende Methodik.
Im agilen Verfahren werden offene Fragen im iterativen Vorgehen behandelt und gelöst.
Anders als im klassischen Verfahren umfasst diese iterative Vorgehensweise auch Themen, die klassisch als vorgegeben (statisch) verstanden werden: z.B. die Definition der Anforderungen, das Pflichtenheft. An die Stelle eines Pflichtenhefts tritt eine Sammlung von User-Stories mit dem erklärten Ziel, Nutz-Anforderungen frei von technologischen Vorgaben zu formulieren. Developer sollen frei und nach ihrem besten Verständnis über Werkzeuge und Technologie entscheiden können.
Projekterfolg mit vorgegebenen Methoden
Oft ist die Projekt-Methode nicht frei wählbar.
Vorgaben des Kunden (z.B. V-Modell bei Behörden) oder die Präferenz eines erfolgreichen Developer Teams für eine bestimmte Vorgehensweise sind zu berücksichtigen.
Dies allein kann den Erfolg eines Projektes in der Regel nicht verhindern. Projektmanagementmethoden sind nur Werkzeuge. Und nicht das Werkzeug sondern die geschickte Anwendung desselben führt zum Projekterfolg.
Viele Probleme in Projekten haben gar nichts mit der Management Methode zu tun – zumindest nicht mit der Frage ob agil oder klassisch.
Es finden sich in vielen erfolgreichen klassischen Projekten Elemente aus dem Agilen Manifest: zum Beispiel kontinuierliche Kommunikation mit dem Auftraggeber zur Anpassung der Anforderungen war auch im Projektmanagement der alten Schule immer schon eine „geheime Zutat“ zum Erfolg.
Auch iterative Vorgehensweisen wurden auch lange vor dem Agilen Manifest genutzt, jedoch in der Regel nicht prominent präsentiert, da sie als teuer galten.
Selbst als umfangreich bekannte klassische Projektmanagement-Rahmenwerke unterstützen inzwischen Agile Methoden V-Modell XT (PDF) für Projekte öffentlicher Auftraggeber in Deutschland. (Englisch: V-Model-XT-english)
Priorisierung von Zielen und Anforderungen
Wie einfach oder schwierig ein Projekt wird, hängt oft nicht von der gewählten Management Methode ab, Agil oder Wasserfall.
Es entscheidet sich schon in der Vorbereitungsphase: werden Ziele und Anforderungen klar priorisiert oder einfach nur als statische „Muss-Liste“ festgeschrieben? Priorisiert bedeutet hier, dass die wichtigsten Ziele erreicht werden müssen, um das Projekt erfolgreich abzuschließen.
Viele Anforderungen lassen sich erst im Laufe des Projekts präzise formulieren. Vorab definierte statische „Muss-Listen“ neigen deshalb zum unnötigen Aufblasen des Projektaufwandes, auch BRUF (Big Requirements Up Front) genannt. Referenz 6 fokussiert auf Agile Methodik - die Problematik tritt aber in allen Projektmanagement-Methoden auf.
Zusätzlich besteht die Gefahr, dass später gewonnene Erkenntnisse (=neue Anforderungen) stillgeschwiegen werden, da nicht in der Anforderungsliste und diese Diskussion beendet ist.
Der klare Vorteil am Etablieren einer Diskussionskultur zwischen Auftragnehmer und Auftraggeber ist die Möglichkeit zum Einbringen neuer Erkenntnisse in das Projekt und die daraus folgende Sicherstellung der Projektzufriedenheit.
Pragmatischer Ansatz: Unabhängig von der Management-Methode hat sich die Trennung von „Zielen“ und „Anforderungen“ praktisch bewährt: es wird eine priorisierte Liste der Ziele erstellt, die im Weiteren Erfolgskriterien des Projekts darstellen.
Werden die ersten L Ziele erreicht und zusätzlich N der nächsten M Ziele wird das Projekt erfolgreich abgeschlossen. Die Auswahl N aus M wird während des Projekts in enger Abstimmung mit dem Auftraggeber getroffen und immer wieder überprüft (Stichwort: Diskussionskultur). Die aus den Zielen abgeleiteten Anforderungen sind dann keine Vorgaben sondern Ergebnisse der im Projekt stattfindenden System-Architektur, des System-Designs und der Diskussion mit dem Kunden.
Praxisbeispiel für suboptimales Anforderungsmanagement
Ein leider gar nicht seltener Fehler ist, wenn Elemente eines noch zu entwickelnden System Design vorab festgelegt und als Anforderung gelistet werden.
Beispiel: Es muss Server-SW von Lieferant X in der Version Y verwendet werden.
Hintergrund: Auf Nachfragen wurde argumentiert, man habe eine Firmenlizenz dafür schon erworben. Außerdem habe IT-Beratung Z dies empfohlen. (Z ist Vertriebspartner von X)
Lösungsweg: Diskussion mit dem Auftraggeber. Es stellte sich dann heraus, dass Lizenzkosten sehr wohl auf das Projekt gebucht werden sollten. Zudem waren verschiedene Feature-Lizenzen nicht im Lizenzumfang abgedeckt. System-Architektur präferierte eine andere Lösung. Nachdem auch Security und Datenschutz des Auftraggebers Bedenken angemeldet hatten, konnte letztlich eine technisch und wirtschaftlich angemessene alternative Lösung ausgewählt werden.
Praxisbeispiele für agilen Erfolg und Versagen:
Wir hatten festgestellt, auch Projektmanagementmethoden sind nur Werkzeuge. Es kommt darauf an, was man damit macht. Hier zwei Beispiele aus der Praxis:
- Ein Beispiel für suboptimales agiles Development
- Ein Beispiel für erfolgreiches agiles Development
Das erste Beispiel zeigt die Folgen fehlverstandenen Anforderungsmanagements und der mangelhaften Interaktion zwischen Development und Produktmanagement.
Das zweite Beispiel betrachtet Gründe für den Erfolg eines agilen Development, unter anderem QA und Dokumentation.
Ein Beispiel für suboptimales agiles Development
Ein Unternehmen mit wichtigen Kunden aus Government-Sektor entwickelt eine Middleware zur HPC Lastverteilung. Die Entwicklung ist agil (Scrum) organisiert, die Produktstrategie reduziert die Anzahl der eigenentwickelten Funktionen zugunsten von externen (Open Source) Komponenten. Somit beinhaltet der Installationsprozess viele Downloads, OS-Updates und Dependencies.
Die Installation auf einer „Secure Site“ scheitert, da kein Internetzugang besteht.
Im zweiten Anlauf ersetzt eine Custom-Installation-DVD den Internetzugang.
Nach erfolgter Installation bemerkt der Kunde, dass vorher demonstrierte grafische Darstellungen nicht funktionieren. Jene verwenden Google APIs, welche nur online zur Verfügung stehen. Auch Kunden aus Oil&Gas (u.a. HPC Cluster auf Schiffen) bemängeln dies.
Was ist falsch gelaufen?
Die nicht-funktionale Anforderung „Installation und Betrieb müssen offline möglich sein“ war verloren gegangen – stand nicht mehr in der DoD.
Die DoD (Definition of Done) steht in der Verantwortung des Development Teams – der Product-Owner liefert nur seine Anforderungen dazu.
Was für kurze Projekte praktikabel erscheint, versagt bei der langfristigen Produktpflege komplexer Anwendungen und Middleware. Der Product Owner (oder Produktmanager) muss „sein“ Produkt begleiten und das Verständnis der Rahmenbedingungen und Kundenanforderungen in den Development Teams immer wieder neu einpflegen. „Immer wieder“ da die tägliche Arbeit der Developer sich auf das gerade bearbeitete Modul fokussieren – das Gesamt-System ist in diesem Moment „Out of Scope“. „Neu“ deshalb, weil gerade im Development auch Spezialisten hinzugezogen werden für spezifische Anforderungen – aber gerade diese Developer kennen die Systemzusammenhänge nicht und sind so in der Gefahr in die Irre zu laufen.
Ein Beispiel für erfolgreiches agiles Development
Ein erfolgreicher ISV für komplexe System-Middleware hatte erkannt, dass seine Kunden ihre Existenz riskieren falls diese Middleware versagen sollte. Um dieser Verantwortung zu entsprechen wurden Produkt- und Development-Strategien definiert:
Produktstrategie: SOA, Komponenten (Services) sind entweder selbst entwickelt oder detailliert kontrolliert und mit dem Produkt gepackt.
Autonome Installation – DVD Installation möglich, fast keine OS-Patch-Level Abhängigkeiten.
Rückwärts-Kompatibilität – CMD Syntax und API bleiben unverändert für existierende Funktionen obwohl neue Features im Laufe der Zeit dazukommen.
Development Strategie: Agil mit Betonung der Gesamt-System-Qualität
Information Development (ID): anders als für Web/UI Projekte ist korrekte hochqualitative Dokumentation für System-Middleware ein absolutes Muss. Developer sind in der Verantwortung technische Dokumentation zusammen mit ihrem Code zu liefern. ID testet neuen Code basierend auf den Informationen der vom Developer produzierten Dokumentation. Wird die Dokumentation als zureichend befunden, gibt ID das Release frei.
QA (Systemische Tests und Qualitätssicherung): Die Developer-eigenen Unit Tests verifizieren, dass ein spezifisches Stück Code funktional ist. Erst die Gesamt-System-Tests zeigen ob das gesamte System mit dem neuen Code arbeitet, auch unter verschiedenen Randbedingungen, ausgewählten Kunden-Konfigurationen und unter hoher Last. Nur falls die System-Tests erfolgreich sind, wird QA das anstehende Release freigeben.
Ergebnis: Stabilität, Zuverlässigkeit und Performance dieser System-Middleware sind legendär. Über viele Jahre hinweg wurden weltweit im Markt die höchsten Preise erzielt – trotz Low Cost- und Free Ware-Konkurrenz.
Anmerkung zu Dokumentation
Nein, dies ist kein Widerspruch zum Agilen Manifest.
Das Agile Manifest wertschätzt (Zitat) „funktionierende Software mehr als umfassende Dokumentation“. Hiermit ist die Projektdokumentation gemeint (z.B. Pflichtenheft, Projektbericht) – interne Dokumente.
Wenn zu einem Produkt eine kundenorientierte Produktdokumentation notwendig ist, ohne die der Anwender das Produkt nicht nutzen könnte (wie im beschriebenen Beispiel System-Middleware), dann ist diese Dokumentation „funktional relevant“ (eine User Story) und wird als essentielles Ergebnis des Developments genauso wertgeschätzt wie „funktionierende Software“.
Weitere Lektüre:
Der Artikel von Willem-Jan Ageling’s Artikel 12 brilliant ways to fail with Agile stellt sehr schön mögliche agile Irrwege dar - unsere Praxisbeispiele finden sich darin wieder.
Links
[1]: Manifest für Agile Softwareentwicklung
https://agilemanifesto.org/iso/de/manifesto.html
[2]: Prinzipien hinter dem Agilen Manifest
https://agilemanifesto.org/iso/de/principles.html
[3]: User Stories: An Agile Introduction
http://www.agilemodeling.com/artifacts/userStory.htm#Figure2UserStoryCard
[4]: V-Modell XT
https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html
[5]: PDF: V-Modell XT Version: 2.3
http://ftp.tu-clausthal.de/pub/institute/informatik/v-modell-xt/Releases/2.3/V-Modell-XT-Gesamt.pdf
[6]: Big Requirements Up Front (BRUF) Approach
http://agilemodeling.com/essays/examiningBRUF.htm
[7]: Definition of DoD by leadingagile.com
https://www.leadingagile.com/2017/02/definition-of-done/
Zitat: ”(DoD =>) Non-Functional requirements met”
[8]: Willem-Jan Ageling “12 brilliant ways to fail with Agile”
https://medium.com/serious-scrum/12-brilliant-ways-to-fail-with-agile-3bfda458f656
[9]: V-Model-XT English
ftp://ftp.heise.de/pub/ix/ix_listings/projektmanagement/vmodell/V-Modell-XT-Gesamt-Englisch-V1.3.pdf