Gruppe: Projekte oder das Management von Vorhaben

Sehr geehrter Forumsmitglieder,

wer hat schon einmal schlechte Erfahrungen mit agilen Methoden gemacht und wenn ja welche?

Für mich stellen agile Methoden (Scrum, V-Modell XT, etc.) eigentlich immer die bessere Alternative dar, jedoch gibt es in der betrieblichen Praxis immer noch sehr viele Teams die nach dem Wasserfall-Modell oder dem V-Modell arbeiten. Häufig stößt man als Projektmanager auf größere Widerstände, wenn man hier eine Veränderung zum besseren hin, also zu mehr Agilität, anstrebt. Auch von anderen Projektmanagers weis ich, dass grundsätzliche Veränderungen in der Vorgehensweise schwierig sein können.

Mich würde interessieren, ob jemand schon einmal ein agiles Vorgehen in einem Projekt eingeführt hat, dann aber wieder zur alten Vorgehensweise zurückging. Was waren die Gründe für das Scheitern (menschliche oder sachliche Gründe? Was sprach für die alte Vorgehensweise? Soll es einen neuen Anlauf mit agilen Methoden geben?

Über Feedback würde ich mich sehr freuen.

Mit freundlichen Grüßen

Jürgen Reimold

Persönlich möchte ich nicht von agilen "Methoden" sprechen sondern von Agilität als einen Satz von "Werten und Prinzipien" i.S. von http://agilemanifesto.org/
Und es gibt eine Reihe von "Konkretisierungen" im Sinn von Vorgehensweisen, funktionalen Rollen, Kommunikations- und Kooperationstechniken, .... welche diese Werte und Prinzipien unterstützen - aber nicht nur in diesen sondern auch in ganz anderen Kontexten sinnvoll sein können.
So etwa kann ich "Pair Programming" oder "Backlogs" auf Basis von "User Stories" auch komplett unabhängig von agilen Werten und Prinzipien sinnvoll nutzen.

Die Frage möchte ich also so umformulieren:
"Welche schlechten Erfahrungen mit agilen Werten und Prinzipien gibt es?"

Und als eine der Antworten aus meiner Sicht das hier:

Die agilen Werte und Prinzipien ergeben sich aus der Erkenntnis, dass in komplexen Situationen weit in die Zukunft reichende und detaillierte Aktionspläne auf Basis der Analyse der Vergangenheit unangemessen sind. Statt dessen sind Herangehensweisen auf Basis kurzer "inspect - adapt - Zyklen" mit enger und nahezu synchroner Kommunikation zwischen den Akteuren geeigneter. Mehr dazu siehe Diverses zu "Complex Adaptive Systems".

Und daraus ergibt sich umgekehrt auch, dass in simplen und komplizierten Situationen eine Herangehensweise auf Basis kurzer "inspect - adapt - Zyklen" mit enger und nahezu synchroner Kommunikation zwischen den Akteuren eine unangemessene Dynamisierung und Komplexitätserhöhung mit sich bringt. Dort also sind weit in die Zukunft reichende und detaillierte Aktionspläne auf Basis der Analyse der Vergangenheit angemessener, also das, was gerne als "Wasserfall" bezeichnet wird .. wobei es sich dabei um die einfachste Variante der 1970 von Winston Royce veröffentlichten Iterativen Projektmanagementverfahren handelt. Royce jedoch war sich bewusst, dass diese seine einfachste Variante nur für die unkompliziertesten Projekte funktioniert und sicher nicht für komplexe. Leider ist diese Einsicht in den letzten 40 Jahren irgendwie vergessengegangen ...

Also: Agile Werte und Prinzipien sind nicht in jedem Fall angemessen - sondern dann, wenn wir es mit (aus unserer Sicht) komplexen Systemen zu tun haben.
Ein fertig konstruiertes Auto "agil" produzieren zu wollen wäre ziemlich ineffizient..... Es "agil" zu konstruieren ist jedoch durchaus angemessen.

Ich würde nicht ausschließlich schlechte Erfahrungen reflektieren wollen, sondern Erfahrungen allgemein in Verbindung mit den von Ihnen angesprochenen "klassischen" Vorgehensweisen.

Beide haben für mich ihre Berechtigung - jeweils dort wo's passt - und das zeigt auch meine Anwendungserfahrung. ich bin seit 20+ Jahren als Projektmanager unterwegs, habe PM klassisch gelernt, mich als PMP und PgMP zertifiziert, und wende beide Methoden in Projekten oft "gemischt" an:

Für die längerfristigen Pläne und Roadmaps gibt's sorgfältige Planungen, die Entwicklungsarbeiten können aber durchaus "agil" durchgeführt werden. Gerade wenn das Ergebnis noch nicht komplett definiert werden kann, oder wenn der Zeit- oder Budgetrahmen absehbar nicht alle Features abdecken kann, ist das iterativ priorisierende Vorgehen à la Scrum dem Durchprügeln von Plänen überlegen. Der Kunde erhält nach der geplanten Zeit- und Budgetspanne ein (Zwischen-)Produkt, mit dem das Projekt sinnvoll weitermachen oder abgeschlossen werden kann. Werden noch weitere Verbesserungen gewünscht, kann dies ohne Beeinträchtigung des Gesamtprojekts in einem separaten Stream parallel erfolgen und am Ende integriert werden. Hier genügt dann ein relativ einfach kalkulierbarer Change Request anstelle von vielen Nachträgen und entsprechenden Verzögerungen.

Ich bin mir bewusst, dass diese Kurzdarstellung nicht alle Facetten beleuchtet, aber wie gesagt kann eine sinnvolle Kombination von klassischem und agilem PM durchaus zielführend, zeit- und kostensparend sein. es ist wie mit einer Arznei: Die richtige Dosierung machts's ...

Beste Grüße
Henning Zeumer

Hallo zusammen,

ich würde prinzipiell die Fragestellung zum "Positiven" umdrehen -
und fragen "Gute Erfahrungen mit agilen Methoden?"

Meine persönliche Antwort ein klares JA,
aber der Mix machts und es muss vorallem von ALLEN Beteiligten gelebt und unterstützt werden.

Ein Statement hierzu:
Verfahren zur agilen Softwareentwicklung wie z.B. Extreme Programming oder Scrum helfen,
Projekte in Zeiten knapper Budgets, kurzer Realisierungszeiten und schnell wechselnder
Anforderungen zum Erfolg zu führen.

Das Problem
Die im Rahmen eines Angebotes erforderliche Aufwandsschätzung benötigt oft mehr Zeit, als zur
Verfügung steht. Pauschale Angebote mit Stundensätzen und der Verweis auf ein zunächst zu
erstellendes Pflichtenheft finden jedoch zu Recht wenig Gefallen beim Kunden. Mit dem bestätigten
Angebot stehen Leistungsumfang, Lieferdatum und Kostenrahmen oft im wesentlichen fest.
Doch ebenso oft entwickeln und verändern sich die Anforderungen erst im Laufe des Projektes,
erfahrene Projektleiter sprechen von 30 bis 50%.

Agiles Projektmanagement in der Softwareentwicklung
...
weiterlesen auf meiner HomePage.

Dieter Langjahr

cert. SCRUM Master

Sehr geehrter Herr Langjahr,

vielen Dank für Ihren Beitrag.

Die Vorteile die agile Methoden im Rahmen der Software-Entwicklung mit sich bringen sind mir bekannt, natürlich auch die üblichen Argumente, sowie zahlreiche Berichte von agilen Projekten die sehr gut gelaufen sind und nicht zuletzt die eigenen Erfahrungen die ich damit gemacht habe.

Bekanntlich haben jedoch alle Dinge zwei Seiten. Jedes System, jedes Konzept hat Grenzen, Vor- und Nachteile und es bedarf immer bestimmter Rahmenbedingungen, damit es überhaupt sinnvoll eingesetzt werden kann.

Mich würde es deshalb sehr interessieren, ob jemand bei einem agil durchgeführten Projekt schon schlechte Erfahrungen gemacht hat, die insbesondere bei einer nicht-agilen Vorgehensweise nicht aufgetreten wären.

Viele Grüße aus Hamburg

Jürgen Reimold

www.kualitas.de

Hallo Herr Reimold,

die gibt es sicherlich, und ganz sicher auch viele - auch in meiner Praxis, wenn ich Projekte aus Schieflagen herausholen soll, sind mir davon schon welche untergekommen. Aber da lag es meist nicht an der agilen Vorgehensweise, sondern am für die Aufgabenstellung oder Projektsituation inadäquaten Einsatz der Methode!

Leider werden viele Projekte und Projektpartner immer noch nach dem Least-Price-Prinzip ausgewählt. Und viele Anbieter treiben auch ein sehr agressives Marketing mit ihren Preisen und den zugehörigen Leistungen. Scrum, XP und andere agile Entwicklungsmethoden bieten sich geradezu an, mit Verkaufsargumenten wie "Sie haben nach dem ersten Sprint schon verwertbare Ergebnisse" und "Sie selbst bestimmen, wie lange das Projekt dauert und was es kostet" zu punkten. Das ist natürlich bei einem "klassisch" geplanten und kalkulierten Festpreis-Projekt ganz anders...

Man muss sich schon mit beiden Ansätzen auseinandersetzen, sie verstehen und auseinander halten können, und dann sie sinnvoll und zum Nutzen des Auftraggebers kombinieren. Dann wird (fast) immer ein erfolgreiches Projekt daraus. Und da müssen gute Anbieter noch dazulernen, auch in der Art, für solide Angebote zu werben und überzeugend zu argumentieren. Und die Auftraggeber müssen endlich akzeptieren, dass es für'n Appel und'n Ei kein seriöses Projektmanagement und kalkulierbare Projekte gibt...

Es wäre also der falsche Ansatz, hier nur die schlechten Erfahrungen zu diskutieren, denn das wirft ein falsches Bild auf das Diskutierte - und auf die Diskutanten...

Beste Grüße
Henning Zeumer

Henning Zeumer schrieb:
... viele Anbieter treiben auch ein sehr agressives Marketing mit ihren Preisen und den zugehörigen Leistungen. Scrum, XP und andere agile Entwicklungsmethoden bieten sich geradezu an, mit Verkaufsargumenten wie "Sie haben nach dem ersten Sprint schon verwertbare Ergebnisse" und "Sie selbst bestimmen, wie lange das Projekt dauert und was es kostet" zu punkten.
Was ist bei diesen Argumenten "sehr agressives Marketing"? Diese Argumente sind ja essentielle Eigenschaften von Scrum, XP und anderen agile Entwicklungsmethoden ... und sind offenbar zusätzlich auch noch gute "Verkaufsargumente".

Ist es denn "agressiv" auf offensichtliche positive Unterschiede gegenüber "klassisch" geplante und durchgeführte Projekte hinzuweisn?

lg HPK

Hallo Herr Korn,

nein, im Gegenteil, wenn es denn wirkliche Vorteile sind. Der Fairness und Seriosität des Angebots halber müsste man aber dann auch dazu sagen, dass es nach angebotenen X Sprints = Y Zeit = Z Kosten nicht zugesagt ist, dass der Kunde dann ein fertiges Produkt gemäß Anforderungen bzw. Spezifikation erhält, sondern eben nur das, was in diesem Rahmen fertig und abgenommen wurde.

Das ist ein für ein "klassisches" Festpreisangebot einzukalkulierendes Risiko, dass man für das Geld und im gegebenen Zeitrahmen halt auch mal mehr als ursprünglich geplant leisten muss, um dem Kunden voll umfänglich zu liefern, was er bestellt hat, und das muss sich eben auch im Preis niederschlagen. Ich verkenne nicht, dass dem Kunden durchaus auch damit ausreichend gedient sein kann, was er nach agiler Kalkulation erhält, und dass es damit auch billiger sein kann. Nur man muss es ihm halt sagen, wo der Unterschied ist, sonst ist es für mein Empfinden unredlich.

Nur vorsorglich zur Klarstellung: ich unterstelle niemandem Unseriosität. Es fehlt aber bei vielen Ausschreibungen die Transparenz, was manchmal ja durchaus gewollt sein mag. Daher kombiniere ich gerne - wo es passt - die Ansätze und schenke dem Auftraggeber reinen Wein ein. Mag ein wenig altmodisch sein und nicht immer zum Auftrag führen, aber ich bin ja auch schon ein paar Jahre im Projektgeschäft...

Viele Grüße
Henning Zeumer

Henning Zeumer schrieb:
nein, im Gegenteil, wenn es denn wirkliche Vorteile sind. Der Fairness und Seriosität des Angebots halber müsste man aber dann auch dazu sagen, dass es nach angebotenen X Sprints = Y Zeit = Z Kosten nicht zugesagt ist, dass der Kunde dann ein fertiges Produkt gemäß Anforderungen bzw. Spezifikation erhält, sondern eben nur das, was in diesem Rahmen fertig und abgenommen wurde.
Das verstehe ich nun wirklich nicht:
Beim agilen Vorgehen (z.B. gemäss Scrum) erhält der Kunde GENAU DAS (und nicht weniger oder mehr oder etwas anderes), was er - via den "Product Owner" - jeweils PRO SPRINT AKTUALISIERT tatsächlich spezifiziert hat und nach jedem Sprint auch effektiv abnimmt.

Er erhält also insbesondere keine Lösungen, welche auf zu Beginn des Projektes bereits in aller Breite und Tiefe definierten Anforderungsspezifikationen beruhen und dann "eingefroren" wurden - und sich dann dennoch im Verlauf des Projekte als unpassend herausstellten.

lg HPK