Agil mit Scrum oder Wasserfall als klassische Methode – Eine Geschichte

  • Start
  • /
  • Artikel
  • /
  • Agil mit Scrum oder Wasserfall als klassische Methode – Eine Geschichte

Entwickler wollen Lösungen produzieren. Dazu benötigen sie klare Anforderungen, damit sie die Lösung erstellen können. Ohne detaillierte Anforderungen kann kein Entwickler auf diesem Planeten eine passende Lösung entwickeln.

Keine Anforderung = keine Umsetzung.

Auf der anderen Seite steht der Auftraggeber, Kunde oder Anwender – im folgenden Kunde genannt. Dieser Kunde will keine Anforderung formulieren, oft weiß er nicht, wie eine Anforderung beschaffen sein muss.

Was der Kunde weiß ist, dass er eine Lösung für sein Problem benötigt. Das Problem kann der Kunde gut beschreiben. Er hat eine Vision …

Anwender wollen Lösungen, Projektleiter wollen Fakten, Product Owner in Scrum wollen ein Ziel.

In dem folgenden Beispiel wird deutlich, dass die jeweilige Perspektive die Sicht auf eine gemeinsame Lösungsfindung versperrt.

Ein Kunde ist Schäfer und möchte eine Lösung für sein Problem. Er trifft sich für die Lösungsfindung mit einem Projektleiter aus einem klassischen Projekt und einem Product Owner für agile Projekte nach Scrum.

Das Problem und schnelle Lösungen

Der Kunde erzählt: “Ich wohne am Ufer eines kleinen Flusses und muss jeden Morgen auf die andere Uferseite zu meine Schafe zu füttern. Im Fluss liegen Steine, auf die ich hüpfe, um auf die andere Seite zu gelangen. Manchmal sind die mit Moos bedeckt. Dann passiert es manchmal das ich abrutsche und in den Fluss falle und nass werde. Alles, was ich will ist, trocken zu meinen Schafen und zurückzukommen.”

Für den Projektleiter ist alles klar und notiert: “Neopren Trockenanzug 4 mm Wandstärke auf Maß mit Atemgerät und Tauchermaske.”. Er notiert alles und verabschiedet sich mit dem Lastenheft in der Tasche und verspricht mit einem Pflichtenheft und einem Angebot wiederzukommen.

Auch der Product Owner verabschiedet sich und nimmt die Problembeschreibung und seinen persönlichen Eindruck vom Kunden mit. Er verspricht, sich in Kürze mit dem Kunden zu treffen.

Von Plänen, Zielen und Teams

Zurück am Arbeitsplatz startet der Product Owner einen Rundruf, wer in einem Scrum-Team an der Lösung für eine Flussüberquerung mitarbeiten möchte und an dem Thema interessiert ist.

Der Projektleiter hat indes den Kunden in die Firma eingeladen und erwartet ihn in mit 2 Assistenten und einem Protokollführer sowie einem groben Pflichtenheft sowie einem ersten Projektplan. Wenn man in Kürze startet, könne das Produkt in einem Jahr fertiggestellt sein.

Alles was nicht definiert ist, muss als Änderungswunsch extra bezahlt werden.

Der Kunde findet die Lösung etwas teuer und muss prüfen, ob die Lösung für ihn passen könnte. Die Vorstellung ein weiteres Jahr nass zu werden, gefällt ihm gar nicht.

Der Projektleiter stimmt Zähneknirschend zu und vereinbart einen Termin, wann man zusammen kommen wird und bis wann der Kunde seine Antwort geben muss – wegen dem prozessualen Vorlauf. Alles wird peinlich genau im Protokoll festgehalten.

Der Product Owner hat mittlerweile ein Scrum-Team beisammen und hat einen Termin beim Kunden vor Ort ausgemacht. Er erscheint dort mit dem gesamten Scrum-Team. Nach einer Ortsbesichtigung, dort wo der Kunde über den Fluss möchte und dem Begutachten der Schafherde setzt man sich bei Croissants und einem Tässchen Kaffee zusammen.

Wichtig ist, was noch nicht gesagt wurde

Die Entwickler und der Product Owner fangen an Fragen zu stellen. Der Kunde erzählt seinen Arbeitstag und was alles passieren kann.

Manchmal, wenn es regnet, dann ist der Fluss ja nicht mehr einen Meter tief, sondern fast 3 Meter und die Strömung ist schon gewaltig. Besonders dann, wenn mal ein Schaf zum Tierarzt muss, ist das dann unmöglich. Im Winter muss er noch Stroh ans andere Ufer schaffen, weil die Wiesen dann karg sind. Erzählt der Kunde.

Der Product Owner teilt dem Kunden mit, das das Scrum-Team jetzt eine erste Lösung erarbeitet und in zwei Wochen könne diese vom Kunden ausprobiert werden. Danach würde er alle zwei Wochen eine Erweiterung und/oder Verbesserung der Lösung erhalten.

Kurze Time-to-Market

Außerdem könne der Product Owner dem Kunden dann einen vorläufigen Release Plan präsentieren. Er teilt dem Kunden mit was die Entwicklungsdauer von zwei Wochen kostet und dass das Material noch zusätzlich bezahlt werden muss.

Dafür können der Kunde jederzeit die Entwicklung beenden, wenn ihm das Produkt genügt oder er über kein Budget mehr verfügt.

Der Kunde überlegt und vereinbart mit dem Projektleiter sich in zwei Wochen zu treffen und bittet ihn, den Betrag x (so viel wie die 2 Wochen kosten die der Product Owner veranschlagt hat kosten) in das Projekt zu investieren und das Ergebnis zu präsentieren.

Agile Frameworks wie Scrum sind besser als klassische Vorgehensmodelle oder andersherum

Der Projektleiter beauftragt sofort Analysten mit einer detaillierten Ausarbeitung und Planung des Projekts “maßgeschneiderter Tauchanzug”.

Der Product Owner und das Team beginnt die Arbeit am Projekt ”Trocken über den Fluss zu den Schafen kommen”.

Das agile Team diskutiert erste Lösungen und wie komplex deren Umsetzung ist und ob eine Realisierung in 2 Wochen zu schaffen sei. Der Product Owner übersetzt die Wünsche des Kunden in Akzeptanzkriterien und das Dev-Team entwickelt einen Plan und definiert die Anforderungen selber. Dafür müssen sie mit dem Product Owner und ein paar mal mit dem Kunden Rücksprache halten.

Die Business-Analysten des Projektleiters erstellen eine Machbarkeitsstudie über den maßgeschneiderten Taucheranzug und holen sich Input von Schneidern, Gummi- und Reißverschluss-Herstellern.

Rund 2 Wochen später

Der Product Owner und das Team sowie der Projektleiter seine Assistenz und Protokollführer treffen sich beim Kunden vor Ort.

Der Projektleiter hat 2 Aktenordner voll Papier und eine Excel-Tabelle und eine PowerPoint Präsentation mitgebracht.

Der Product Owner hat einen ersten Release Plan und das Team hat ein Stahlseil, ein Paar Lederhandschuhe und zwei Karabinerhaken mitgebracht.

(K)ein guter Plan

Der Kunde fragt, zuerst den Projektleiter, was er für sein Geld von ihm bekomme. Der Projektleiter knipst den Beamer an und hält eine einstündige Präsentation zur Lösung mit Kosten, Nutzen und Risiken sowie einem geplanten Fertigstellungsdatum. Die Details wären in den Ordnern zu finden und der Projektplan in der Excel-Tabelle. Während der Präsentation des Projektleiters hat sich das agile Team zur Vorbereitung ihrer Präsentation zurückgezogen.

Zufrieden setzt sich der Projektleiter an den Tisch.

Früher Return on Invest

Jetzt präsentiert der Product Owner. Dieser bittet alle an den Ort des Geschehens, weil dort die Präsentation durch das Team stattfindet. Dort angekommen sieht der Kunde, das ein Stahlseil zwischen zwei vorhandenen Masten gespannt wurde. Das Team demonstriert dem Kunden, wie er durch Hangeln am Seil, ohne nass zu werden, über den Fluss kommt. Die Handschuhe schützen vor Verletzungen.

Der Kunde fragt aus welchem Material die Handschuhe sind, denn er sei gegen Materialien aus Kunststoff allergisch. Die Lederhandschuhe sind für den Kunden akzeptabel.

Der Kunde ist verwundert und begeistert zugleich. Jetzt schon eine Lösung zu haben, Trocken zu bleiben, fasziniert ihn. Die Lösung passt dem Kunden nicht zu 100 % und er fragt den Product Owner, wo das hinführ

Der Product Owner stellt dem Kunden seinen Release-Plan, seine Roadmap vor:

  1. Sprint: Stahlseil zum Hangeln
  2. Sprint: offene Gondel an das Stahlseil gehängt, ziehen weiterhin per Hand
  3. Sprint: Eine Winde in der Gondel zur einfacheren Fortbewegung
  4. Sprint: ein Dach für die Gondel
  5. usw.

Er erklärt dem Kunden, er habe einen sofortigen Return on Invest und mit jedem weiteren Sprint eine Verbesserung zu erwarten. Änderungen sind jederzeit möglich und Feedback ist mindestens alle zwei Wochen gewünscht. Deshalb werde man sich mit dem Kunden regelmäßig treffen. “Prinzipiell”, sagt der Product Owner zum Kunden, “sind wir alle zwei Wochen mit dem Projekt fertig und sie bekommen ein verwendbares Produkt.“

Der Product Owner und der Projektleiter erwarten nun eine Entscheidung darüber, wer den endgültigen Zuschlag bekommt.

Fazit

In dieser Geschichte hat der Projektleiter – der nebenbei bemerkt ein passionierter Sporttaucher ist, eine Entscheidung über die Lösung getroffen. Diese Entscheidung hat der Projektleiter basierend auf seiner Erfahrung, seinem Wertemodell und seiner Wahrnehmung des Lebens, seiner eigenen Realität, nach bestem Wissen und Gewissen getroffen. Wie er es gelernt hat.

Der Product Owner hat eine Lösungsidee, will aber dem Team nicht vorgreifen und das Problem von den Teammitgliedern individuell beleuchten lassen. Er weiß, das eine gemeinsame Lösung die tragfähigere ist. So hat er es gelernt.

Projektleiter und Product Owner haben dasselbe Problem zu lösen. Jeder hat eine völlig unterschiedliche Sicht- und Vorgehensweise.

Dadurch, dass der Kunde seine perfekte Lösung nicht ansatzweise kennt, kommt die klassische Produktentwicklung in Schwierigkeiten.

Es existiert keinerlei Anforderung. Alles, was zur Verfügung steht, ist die Vision des Kunden.

Hat der Kunde klare Anforderungen an seine Lösung und eine exakte Vorstellung was er will: “eine Zugbrücke aus Holz” ist der Product Owner mit dem Team in Schwierigkeiten, weil die Anforderungen klar sind. Diese Vorhersagbarkeit sind agile Teams nicht gewohnt.

Wer bekommt deiner Meinung nach den Zuschlag? Wem würdest du den Zuschlag für die Problemlösung erteilen? In dieser Geschichte spiegeln sich einige der 12 Prinzipien aus dem agilen Manifest wider. Hast du welche gefunden? Ich bin gespannt auf dein Feedback.

Bleib agil Erfolgreich!

Frank

Über den Autor

Frank Schatz

Wertschätzend. Motivierend. Polarisierend. Einer der führenden T-Shaped Agilisten im deutschsprachigen Raum. Seit über 25 Jahren IT-Unternehmer und Agile Work Experte dem, auf seinem Fachgebiet, kaum jemand etwas vormacht.

Interessante Artikel




{"email":"Bitte E-Mail Adresse eingeben","url":"Website ungültig","required":"Bitte alle Pflichtfelder ausfüllen"}
>