ZA061 - Scrummerfall - Wenn Scrum scheitert
27.08.2013
00:00:00.000 Stunden
00:00:00.000 Minuten
Zusammenfassung
Mich erreichte eine Hörerfrage zu Scrummerfall und ob Scrum und klassische Vorgehensweisen zusammen funktionieren können.
Scrummerfall ist eine Verwässerung von Scrum durch klassische Methoden. Eine absolute Katastrophe! Im Gegensatz dazu sind WaterScrum und Water-Scrum-Fall zwei Ansätze um klassische Vorgehensweise im Positiven durch Methoden aus der agilen Welt zu ergänzen. In dieser Episode bespreche ich die verschiedenen Ausprägungen, warum sie entstehen und wie damit umgegangen werden kann.
Die Themen der Episode:
- Scrummerfall, WaterScrum und Water-Scrum-Fall
- Warum entstehen die verschiedenen Varianten?
- Wie kann mit den verschiedenen Varianten umgegangen werden?
Hinweise in der Episode:
- Episode #19: Sprints & Weekly Builds im Systems Engineering
Mich live als Speaker treffen
- Am 14.09. auf dem PM Camp in Berlin mit meinem Vortrag „Agile Leadership – Wie muss sich Führung in agilen Projekten verändern?“
- Am 26.09. auf der Agilen Bodensee-Konferenz 2013 mit meiner Keynote “Agile conversion – Agile vs. Leadership”
- Am 04.12. auf der Embedded Software Engineering 2013 mit meinem Vortrag “Lean Systems Engineering”
Subscription link
Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:
Euer Feedback
Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de
Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.
Frage: Wie ist Eure Erfahrung mit Scrummerfall? Habt Ihr mit einen der anderen Varianten in Euren Projekten zu tun?
Hallo Maik,
danke für den interessanten Podcast. Ich kann nicht auf alle Aspekte und Inhalte eingehen, möchte aber ein paar Anmerkungen loswerden.
Natürlich ist es richtig, das Scrum nicht überall eingesetzt werden kann. Auch wenn im Scrum-Guide von Jeff Sutherland und Ken Schwaber nirgendwo der Begriff Software vorkommt (Einfach mal herunterladen und nach dem Suchbegriff "Software" abklopfen; man hat 0 Treffer), sondern immer von einem "Produkt" geredet wird (Zitat: "Scrum is a framework for developing and sustaining complex products."), kann dieses Framework seine Herkunft natürlich nicht ganz verbergen.
Ich finde es auch immer wichtig zu betonen, das Scrum einerseits nur EINE Möglichkeit ist, Agilität in der Produktentwicklung zu implementieren, und andererseits dass es sich um ein FRAMEWORK handelt – sprich: es ist bewusst unvollständig gehalten.
Das Scrum unvollständig ist wird u.a. daran deutlich, dass das im agilen Manifest erwähnte Prinzip der technischen Exzellenz von Scrum quasi gar nicht adressiert wird. An dieser Stelle dockt ja die Software Craftsmanship Bewegung an und konstatiert, dass das Produkt (in diesem Fall ist es Software) eine bestimmte innere Qualität haben muss, damit Scrum überhaupt funktionieren kann. Was nützt es zu sagen, das man Anforderungsänderungen auch spät im Projekt noch Willkommen heißt, wenn der Konstruktionsgegenstand ein zäher Monolith ist, der solche Änderungen gar nicht zulässt?
Darüber hinaus steht es natürlich jedem frei, ein anderes Vorgehen als nach Scrum zu wählen, und trotzdem agil zu sein. Essenziell ist dabei natürlich die Beachtung der agilen Werte ("Individuals and interactions over processes and tools.", usw.) und der 12 agilen Prinzipien. Und das funktioniert sehr wohl auch in einem interdisziplinären Umfeld, also: im Systems Engineering, mit Mechanik, Optik, Elektronik, Software, etc.
Meine Beobachtung ist, und auch meine Kollegen erzählen darüber, das Scrum zumeist deswegen scheitert, weil es schon vom Start weg adaptiert wird und eben nicht 100% dogmatisch nach Lehrbuch eingeführt wird. So wird z.B. "Scrum" eingeführt, aber die wichtige Retrospektive wird weggelassen, und neben dem Product Owner mischt auch noch ein klassischer Projektleiter mit, oder es wird sogar ein Projektleiter als Scrum Master eingesetzt, weil man das ja für dasselbe hält (sog. "Scrum, But…"). Daher finde ich es wichtig, die ersten Sprints mit Scrum aus dem Lehrbuch durchzuführen und dann zu schauen (Inspect & Adapt) was gut funktioniert, und was man noch ändern oder verbessern kann, natürlich ohne die essenziellen Bestandteile von Scrum über Bord zu werfen.
Ansonsten wird kurz- bis mittelfristig in allen Branchen und Domänen kein Weg an Agilität vorbeiführen, egal welches Framework man benutzen wird und möchte. Die Komplexitätsherausforderungen der nahen Zukunft (Stichworte: Industrie 4.0, Internet Of Things, Cyber Physical Systems, interkulturelle und interdisziplinäre Teams, etc.) werden derart immens zunehmen, dass der Wasserfall (oder das, was man gemeinhin dafür hält, oft aber eher den Namen "Chaos" verdient), und welcher von seinem Erfinder Winston W. Royce ja nur für die allereinfachsten Projekte beschrieben wurde, gänzlich versagen wird.
Viele Grüße,
Stephan Roth
Hallo Stephan,
danke Dir für Deine ausführliche Rückmeldung!
Meine Erfahrung deckt sich mit deiner Beschreibung. Ich finde es spannend, was gerade in den mechatronischen Entwicklungsprojekten geschieht.
Leider mutiert in meinem Umfeld Scrum gerade zum Management-Modewort und wird wie die Sau durchs Dorf getrieben. Oft endet es dann im Dark Agile Manifesto. Für mich stellt sich die Frage, ob das dann wirklich zielführend ist. Die Autos die gerade rumfahren, sind sicher nicht mit agilen Methoden umgesetzt worden und so schlecht scheinen sie ja nicht zu sein. Auch wenn mit dem V-Modell ein anderer Denkansatz dahinter steckt.
Ich selbst habe schon immer sehr gute Erfahrungen mit agilen Ansätzen gemacht. Mein Plädoyer geht dahin, das die Leute den Kopf einschalten. Dazu ist bei der Implementierung von Scrum halt zu berücksichtigen, dass es eine andere Kultur ist und diese anders umgesetzt wird. Wie du auch treffend beschreibst, macht es Sinn sich zunächst auf eine echte Implementierung zu stützen und dann zu optimieren.
Ich denke auch, dass durch die Anforderungen der Zukunft (Komplexität der Systeme und der Projekte) nur über Weg der agilen Vorgehensweisen in den Griff zu bekommen sind. Interessant finde ich die Frage, wie kann ich die Reife von agilen Vorgehensweisen im Projekt bewerten. Denn SPICE schreibt uns kein Vorgehensmodell vor. Es verlangt nur, dass wir uns vorher Gedanken machen, welche Arbeitsprodukte wir liefern wollen und wie wir das sicherstellen.
Schönen Gruß aus Köln,
Maik