Agiles und phasenorientiertes Vorgehen im Team

Water-Scrum-Fall

In meinem Blog „Agile Projekte vs. phasenorientierte Projekte“ bin ich darauf eingegangen, dass beide Vorgehensmodelle ihre Berechtigung haben. In diesem Blog geht es darum, ob beide Modelle auch im Team zu zusammenarbeiten.

Leben im Team

Ist das agile Vorgehen zum phasenorientierten Vorgehen wirklich wie Hund und Katze oder wie Schwarz und Weiß? Kann nur das Eine oder das Andere genutzt werden?

Nein, es können Teile aus beiden Welten gemeinsam genutzt werden und dies ist auch in vielen Projekten die best mögliche Vorgehensweise. Ebenso ist es in vielen Firmen üblich, dass nicht das rein agile Vorgehen, wie IT-Kanban oder Scrum genutzt wird. Eine Kombination der phasenorientierten Vorgehensweise mit agilen Elementen ist oft anzutreffen.

Wie eine solche Vorgehensweise genannt wird ist eine Sache, wenn diese gemixte Vorgehensweise aber die Change eines erfolgreichen Projektes erhöht, dann sollte sie auf jeden Fall genauer betrachtet werden.

Aber darf man dies überhaupt? Was sagt hierzu das agile Manifest?

Manifest für Agile Softwareentwicklung

Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

Das agile Manifest stellt die Individuen und deren Interaktionen über Prozesse und Werkzeuge. Wünschenswert ist ausdrücklich, dass „rein“ agil vorgegangen wird, doch wenn die Organisation, die Menschen, etc. dies nicht können bzw. wollen, so ist ein kontinuierlicher Verbesserungsprozess, welcher bei den aktuell gelebten Prozessen und den genutzten Werkzeugen beginnt, auf jeden Fall im Sinne der agilen Methoden.

Studie zur Nutzung agiler Methoden

Wie aktuell die Methoden in den Firmen gelebt werden, dazu gibt es eine sehr gute deutschsprachige Studie von den „BPM-Labors der Hochschule Koblenz, Prof. Dr. Ayelt Komus, über die Verwendung agiler Methoden„. Die 2014er Studie kann dort kostenfrei heruntergeladen werden. Die 2016er Studie sollte in den nächsten Wochen ebenso verfügbar sein.

Die nachfolgenden Daten stammen aus dieser Studie.

  • Die Mehrheit der Anwender agiler Methoden nutzt dies selektiv oder in einer Mischform. Die durchgängige Nutzung agiler Methoden ist nur bei ca. einem Viertel der agilen Anwender der Fall.
  • Fast zwei Drittel der Studienteilnehmer nutzen agile Methoden erst seit 4 Jahren
  • Mit 86% ist Scrum die meistgenutzte agile Methode. Danach folgen Kanban, XP und Feature Driven Development.
  • Agile Methoden werden nach Teilkriterien wie „Ergebnisqualität“, „Termintreue“, „Mitarbeitermotivation“, etc. durchgängig besser bewertet als klassische Projektmanagementmethoden.
  • Bei Teams dominiert die Größe von 5-9 Personen. Auch bei Anwendern klassischen Projektmanagements ist dies die meistgenannte Teamgröße.
  • 74% der Anwender agiler Methoden sehen in ihrem Unternehmen bzw. in einzelnen Fachabteilungen Wandel als integralen Bestandteil der Unternehmenskultur. Dies ist bei Anwender klassischen Projektmanagements nur bei 55% der Befragten der Fall.

Die Teilnehmer dieser Studie haben angegeben, dass

  • 21% durchgängig agil arbeiten,
  • 64% eine Mischform oder unterschiedliche Methoden (je nach Projekt) nutzen und
  • 15% durchgängig klassisch arbeiten (obwohl dies eine Studie zu agilen Methoden ist).
Quelle: Studie Status Quo Agile 2014, BPM-Labor HS Koblenz, Prof. Dr. Komus: Zufriedenheit
Quelle: Studie Status Quo Agile 2014, BPM-Labor HS Koblenz, Prof. Dr. Komus: Zufriedenheit

Wie aus der Abbildung ersichtlich wird, ist die Zufriedenheit mit agilen Methoden durchgängig höher, als mit dem klassischen Projektmanagement.

Welche agilen Techniken werden, nach dieser Studie, am häufigsten genutzt?

Top 5

  • 89% nutzen Daily Scrum
  • 81% nutzen User Stories
  • 80% nutzen Produkt Backlog
  • 79% nutzen Sprint Review
  • 78% nutzen Sprint Backlog

Wie wird gemischt?

Water-Scrum-Fall

Water-Scrum-Fall findet sich schon seit 2011 in einigen Artikeln im Internet.

Die Nutzung kommt in Bereichen vor, bei denen die ersten „Projektphasen“ detailliert vorhanden sein müssen, damit überhaupt eine Freigabe für die Umsetzung erfolgt. Ebenso ist es hier auch oft der Fall, dass die Produktivsetzung ausführlich geplant und mit anderen Projekten abgestimmt werden muss. Als Beispiel sind hier geschäftskritische Bereiche wie SAP Projekte zu nennen.

Water-Scrum-Fall hat ein klassisches Phasengerüst, welches in der Umsetzungsphase (Pflichtenheft und Realisierung) in den agilen Modus (beispielsweise Scrum) wechselt.

Dabei wird das Fachkonzept (Lastenheft) klassisch von der Fachabteilung erstellt. Danach erfolgt klassisch die Projektplanung auf agregierter Ebene.

In der Umsetzungsphase wird in den Scrum-Modus gewechselt. Hier wird parallel das technische Konzept (Pflichtenheft) und die Realisierung vorangetrieben. Dabei werden das Fachkonzept und das technische Konzept in User Stories und technische Tasks umgewandelt und daraus das Product Backlog erstellt. Über Sprints werden die Funktionalitäten entwickelt.

Nach der Entwicklung wird wieder in den klassischen Modus gewechselt und der Prozesstest bzw. Abnahmetest durch den Kunden (Fachabteilung) durchgeführt. Ebenso erfolgt die Produktivsetzung klassisch anhand der Releaseplanung und im Zusammenspiel mit den abhängigen Projekten.

Water-Scrum-Fall
Water-Scrum-Fall

Weitere Möglichkeiten

Einfach ausgedrückt: Erlaubt ist, was hilft und die Prozesse verbessert. Denn es geht nie um einzelne Personen, sondern immer um den Gesamtprozess.

Wer im klassischen Projektumfeld arbeitet und dies auch beibehalten möchte, sollte sich überlegen, ob nicht einzelne „kleine“ agile Teile das klassische Projektgeschäft bereichern und verbessern.

  • Daily:
    Jeden Tag um die gleiche Zeit treffen sich alle Entwickler und sagen was die seit dem letzten Daily gemacht haben, was sie bis zum nächsten Daily geplant haben und was sie an ihrer Arbeit behindert. Diese Kommunikation ist in fast allen Projekten hilfreich. Um einen Anfang zu machen können Dailys auch 2 bis 3 mal die Woche durchgeführt werden.
  • User Stories, sowie das Product und Sprint Backlog:
    Wird das Fachkonzept in kleine überschaubare Anforderungen (Funktionalitäten) aufgeteilt, so können Abhängigkeiten leichter ermittelt werden und auch fertige Teile schon früher dem Kunden (der Fachabteilung) gezeigt werden. Das Einholen von frühem Feedback durch den Kunden erhöht auf jeden Fall den Projekterfolg.
  • Product Owner (oder auch der Prozessverantwortliche):
    Wird dieser regelmäßig (mehrmals wöchentlich) eingebunden, um Verständnisfragen zum Fachkonzept zu klären oder ihm vorab erste Ergebnisse zu präsentieren, so erhöht sich die Zufriedenheit über das Endprodukt erheblich.
  • Retrospektive:
    Die Retrospektive dient der kontinuierlichen Verbesserung und erhöht, wenn sie richtig angewand wird, sukzessive die Qualität des Prozesses im Entwicklerteam.
 
Vielen Dank, dass Sie diesen Beitrag gelesen haben. Wenn er Ihnen gefallen hat, empfehlen Sie mich gerne weiter.
Wenn Sie keinen Beitrag verpassen wollen, dann folgen Sie mir doch einfach auf Twitter. Klicken Sie hierzu im rechten Bereich auf das Twitter-Symbol.
Ebenso können wir uns gerne bei LinkedIn und Xing verlinken. Die entsprechenden Symbole sind an der selben Stelle, wie das Twitter-Symbol. Geben Sie bei Ihrer Anfrage bitte den Blog-Namen "PM2blog4you" an, da ich Anfragen, welche ich nicht zuordnen kann, nicht bestätige.

2641total visits,4visits today

Schreibe einen Kommentar