Jan Kus hat gestern in der Online-Ausgabe des Technologie-Magazins t3n mit einer markanten These aufhorchen lassen. Da heißt es gleich am Beginn der Einleitung:
„Projektmanagement ist so etwas wie das Stiefkind moderner Softwareentwicklung.“
Ich fand den Artikel so spannend und mutig, dass ich gerne noch meinen „Senf“ dazu geben möchte. Zuerst aber zu den Kernbotschaften des Artikels:
- In Fixpreisprojekten wird häufig viel Zeit mit Vertragsvereinbarungen verschwendet. Diese Zeit wäre besser in produktive Arbeit investiert.
- Teams sollten möglichst dezentral gesteuert werden (nämlich indem sie sich soweit möglich selbst steuern).
- Agile Softwareentwicklung und Projektmanagement sollten Hand in Hand gehen. Man sollte sich die agilen Werte und Prinzipien immer wieder vergegenwärtigen.
- Agiles PM birgt aber auch Risiken: (Klassische) Kundenanforderungen (wie z.B. eine saubere Dokumentation) müssen von Teams auch erfüllt werden.
- Fixpreisverträge sind zeitaufwändig, ihre Ausarbeitung teuer. Vor allem kleine Agenturen / Dienstleister sollten wenn möglich zeitbasiert abrechnen. Dies kann aber nur funktionieren, wenn gegenseitiges Vertrauen zwischen Auftraggeber und -nehmer herrscht (Stichwort: Handschlagqualität).
- Die Definition und Umsetzung starrer, komplizierter Prozesse ist in der Softwareentwicklung häufig wenig sinnvoll. Es ist ratsam, die Energie stattdessen auf die Schaffung guter Rahmenbedingungen für das Team, eine gute Kommunikation untereinander, das Ergebnis selbst oder das Lernen aus Erfahrungen zu lenken.
- Aussagekräftige und dokumentierte Tests können teilweise eine aufwändige Dokumentation ersetzen.
- In jedem Fall gilt: Eine konsequente Fokussierung auf das Ergebnis ist das A und O moderner Softwareentwicklung nach agilen Prinzipien.
In den meisten Punkten stimme ich dem Autor zu. Nicht allerdings in folgenden:
- Ich vertrete (nicht erst seit heute) die Ansicht, dass in den meisten Projekten (IT oder auch anderswo) eine Integration klassischer und agiler Ansätze sinnvoll ist. Denn ich sehe weder in klassisch-deduktiven noch in agil-iterativen Vorgehensmodellen ein Allheilmittel zur Bewältigung komplexer Vorhaben.
- Konkret heißt das für beispielsweise für die Softwareentwicklung, dass bei der Initiierung und Planung von Projekten sehr wohl eine bestmögliche Abgrenzung und Spezifikation des „project scope“ notwendig und sinnvoll ist. Allerdings sollte das Projektmanagement-Dreieck (triple constraint) nicht starr, sondern vielmehr in zumindest einem Parameter flexibel interpretiert werden. Beispiel:
- Leistungsziele = Muss- und Soll-/Kann-Anforderungen (deren Notwendigkeit im laufenden Entwicklungsprozess verifiziert wird)
- Kostenziele / Budget = fixiert (+ ggf. definiertes Nachtragsbudget)
- Terminziele = harte Deadline für Muss-Anforderungen, weiche Deadlines für Soll-/Kann-Anforderungen
Hier ein Beispiel eines möglichen Ansatzes (in Anlehnung an „APM – Agiles Projektmanagement“ von Bernd Oestereich und Christian Weiss, S. 4):
Fazit: Klassisches Projektmanagement ist gut, agiles Projektmanagement ist (im Zweifelsfall) besser. Aber die wahre Kunst liegt in der Überbrückung vermeintlicher Gegensätze. Dies kann gelingen, wenn man den guten alten Hausverstand einschaltet und sich auf das Wesentliche konzentriert.
PS: Die Kernkonzepte des Buches „Agiles Projektmanagement“ können hier als Poster herunter geladen werden.
So sehe ich es auch 🙂 Der neue Typus der hier gefragt ist, ist weder ein Agilo noch ein Tradierter.
Die Aufgabe des neues, hybrid PM liegt in der darin die Vereinbarkeit der Vorgehensweisen zu schaffen und auf die Aufgabe (Scope und Umfeld) anzupassen.
Sollte dann auch noch die Umsetzung gelingen, ist viel erreicht.
Wie immer ist es nie zielführend ein Methodenfetischist zu sein, wenn die Aufgabe andere Anforderungen stellt!
Allerdings als „Nicht Agilo“ stimme ich dem Punkt „Die Definition und Umsetzung starrer, komplizierter Prozesse ist in der Softwareentwicklung häufig wenig sinnvoll. Es ist ratsam, die Energie stattdessen auf die Schaffung guter Rahmenbedingungen für das Team, eine gute Kommunikation untereinander, das Ergebnis selbst oder das Lernen aus Erfahrungen zu lenken.“ zu.
Es steckt einfach viel Erfahrung im Team, und diese zu mehren ist eine Aufgabe, die dem Projekt zum Erfolg verhilft. Zu komplzierte Prozesse werden alleine schon wegen der Infragestellung ihrer Sinnhaftigkeit nicht befolgt!
Jens
Ein bißchen agil ist wie ein bißchen schwanger zu sein. Agile Konzepte mag man übernehmen können, aber solange die Grundsätze des agilen Manifests nicht umgesetzt werden, verstehe ich nicht, wieso man überhaupt „agil“ als erstrebenswert betrachtet.
Mir scheint, dass es vielerorts immer noch ein fundamentales Fehlverständnis von agiler Arbeitsweise gibt. Sobald ich diese mit klassischen „Wasserfallprozessen“ kreuze, verabschiede ich mich meiner Meinung nach komplett von allen Vorteilen der Agilität (aber handle mir eventuell andere Vorteile ein, die insgesamt die Bilanz verbessen. Nur eben nicht agil).
Ein Buchtipp dazu: „Balancing Agility and Discipline“ von Boehm/Turner. Hier werden klassische und agile Vorgehensmodelle unter allen erdenklichen Gesichtspunkten verglichen.
Grundsätzlich arbeiten wir alle irgendwie an der Kombination von klassischen und agilen Ansätzen. Allerdings tue ich mich immer noch schwer mit jenen, die den Focus auf klassischen Ansätzen hatten und dann versuchen, diese mit der (meinst nicht wirklich verstandenen) agilen Welt zu vereinen. Das APM-Poster ist für mich wieder ein solcher Beleg. Die Grafiken strahlen eine Komplexität aus, die für mich wenig mit Agilität zu tun haben ;-).
Ich finde die kombination beider Vorgehen auch sinnvoll auch wenn mein Artikel das „eine“ Extremum darstellt. An dieser Stelle war das jedoch Absicht um jungen Unternehmen, gerade in der Phase der Gründung die Augen zu eröffnen und zu zeigen, dass es auch anders geht als es zukünftige Gründer und Unternehmer vielleicht in der Betriebwirtschaftslehre beigebracht bekommen haben.
Nach einer gewissen Zeit im Agenturgeschäft wird aber klar: ein Mix ist notwendig. Und hier stimme ich leider nicht Stephan’s Gedanken zu: „Sobald ich diese mit klassischen “Wasserfallprozessen” kreuze, verabschiede ich mich meiner Meinung nach komplett von allen Vorteilen der Agilität“. Denn gerade dann bin ich agil, denn ich reagiere flexibel auf meine Projekt-Umwelt, indem ich Methodiken und Techniken variiere und einfach einen auf das Projekt und Kunden abgestimmten Mix an diesen Methoden und Techniken benutze um einen reibungslosen Projektablauf zu ermöglichen.