(openPR) Wasserfall-Prozesse haben bei komplexen Aufgaben keine Chance. Warum Agile Entwicklung und Scrum die Lösung für die Entwicklung komplexer Produkte sind.
Von Johanna Schoenberger und Felix Neumann
Was ein Programmierer in einem Monat schafft, schaffen zwei Programmierer in zwei Monaten.
Der alte Softwareentwickler-Witz zeigt das Hauptproblem, das bei der Entwicklung komplexer Produkte oder Services auftaucht: Mehr Ressourcen, sprich Mitarbeiter, bedeuten im Normalfall nicht mehr Effizienz, sondern weniger.
Umso größer das Team, umso mehr Selbstumkreisung betreibt es. Besonders in großen Unternehmen arbeiten Teams meist nur einen kleinen Teil ihrer Zeit an der konkreten Weiterentwicklung des eigentlichen Produkts / Services. Den deutlich größeren Teil ihrer Zeit verbringen sie mit Meetings, Abstimmungsrunden, Entscheider-Kreisen… Agile Entwicklung und Scrum ist das genaue Gegenteil.
Komplexe IT-Aufgaben und der „Wasserfall“
Softwareentwicklung ist ein hochkomplexes Unterfangen. Die Komponenten, die entwickelt werden, stehen miteinander in Wechselwirkung. Die geringste Störung kann das gesamte System beeinflussen. Die Zusammenarbeit von Teams muss also sitzen. Probleme oder Bugs sind unvorhersehbar, müssen aber unmittelbar gelöst werden.
Klassische Wasserfall-Prozesse mit Planungsphasen, Lastenheften und hierarchischen Entscheidern, die alle Verantwortung tragen, haben unter solchen Bedingungen keine Aussicht auf Erfolg.
Die Antwort heißt „Agile Entwicklung“
So sind in der IT schon in den frühen 90ern „agile“ Arbeitsweisen entstanden. Komplexe Aufgaben werden hierbei soweit zerlegt, bis sie handhabbar und umsetzbar werden.
Um agil arbeiten zu können, braucht es eine Grundhaltung, die in der traditionellen Wasserfall-Welt eher ungewöhnlich erscheint.
So heißt es im „Agile Manifest“:
Die vier Leitsätze der agilen Entwicklung lauten:
„Wir schätzen…
• …Individuen und Interaktionen mehr als Prozesse und Werkzeuge“
• …funktionierende Software mehr als umfassende Dokumentation“
• …Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung“
• …Reaktionsfähigkeit mehr als das Befolgen eines Plans“
Pragmatismus statt Hierarchie
Statt Protokollen, Lastenheften und Hierarchiediskussionen rückt die konkrete Umsetzbarkeitin den Fokus: ein gesunder, zielgerichteter Pragmatismus übernimmt.
Von vornherein ist klar, dass sich Anforderungen ändern und technische Probleme auftauchen können, die im Voraus nicht abzusehen sind. Statt im Detail zu planen und sich gegen persönliche Planungsfehler abzusichern, werden Veränderungen von Anfang an als natürlicher Bestandteil im Vorgehen mit eingeplant. Das Team übernimmt gemeinsam die Verantwortung für das Ergebnis.
Rahmenwerke (Frameworks)
Die Leit- und Grundsätze des agilen Arbeitens sind sehr allgemein gehalten: „Einfachheit […] ist essenziell“, „Die besten Architekturen […] entstehen durch selbstorganisierte Teams“, etc.
Um die Prinzipien in die Praxis zu übertragen, gibt es zahlreiche agile Rahmenwerke wie Scrum(Empirische Prozesskontrolle), Kanban (Optimierung des Arbeitsflusses durch Visualisierung) oder Lean Management (Wertmaximierung durch die Vermeidung von Verschwendung). Sie alle leisten verschiedene Aufgaben und werden häufig im Zusammenspiel genutzt.
Kurzer Einblick: Scrum
Scrum ist eines der populärsten agilen Prozess-Rahmenwerke. Scrum dient „zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte“. Scrum beschreibt ein überschaubares Set von „Scrum Rollen“, „Ereignissen“, „Artefakten“ und „Regeln“, die sie miteinander verbinden. Das Ziel von Scrum ist es, die relative Wirksamkeit des Produktmanagements und der Arbeitstechniken eines Teams sichtbar zu machen, damit man das Produkt, das Team und die Arbeitsumgebung laufend verbessern kann.
Das Scrum Team & Rollen
Scrum bestimmt, welche der drei Rollen innerhalb eines Scrum Teams – Product Owner, Scrum Master und Entwicklungsteam – welche Aufgaben umzusetzen hat:
• Der Produkt Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren. Er steuert ihn vor allem durch die Spezifikationen des Produktes über das Product Backlog.
• Das Entwicklungsteam ist ein Team aus Profis, das seine Arbeit selbst organisiert und managed. Seine Aufgabe ist es, die Spezifikationen umzusetzen.
• Der Scrum Master ist der „Servant Leader“, der Team-Coach: er räumt sämtliche Unternehmens-bedingte Hinderungsgründe aus dem Weg, so dass das Entwicklungsteam effizient arbeiten kann. Und er sorgt vor allem für eine gute Kommunikation im Team – der Faktor, der am Ende über Gelingen oder Scheitern eines Teams bestimmt.
In schönstem Entwickler-Humor zeigt das folgende Video die Tätigkeiten des Scrum-Masters:
Sprint
Im Zentrum von Scrum steht der sog. „Sprint„: Ein definierter Zeitraum von meist zwei oder drei (max. vier) Wochen. In dieser Zeit wird genau ein nutzbares, potenziell auslieferbares „Produktinkrement“ umgesetzt. Jeder Sprint wird auf die immer gleiche Weise mit einem Planungs- und einem Reviewereignis begonnen bzw. abgeschlossen. (Der Begriff “Meeting” wird bewusst vermieden – schließlich soll während eines Ereignisses gearbeitet werden).
Während eines Sprints trifft sich das Entwicklerteam täglich zu einem 15-minütigen „Daily Scrum“. Dabei wird die Arbeit für die nächsten 24 Stunden geplant und der Arbeitsfortschritt überprüft. Am Ende eines Sprints wird außerdem nicht nur über das Ergebnis reflektiert (Sprint Review). Auch die Zusammenarbeit im Team (Sprint Retrospektive) wird besprochen und man überlegt, was im nächsten Sprint verbessert werden sollte.
Reporting ist abgeschafft
Eine erwähnenswerte (und besonders für traditionell gesteuerte Unternehmen fast kuriose) Scrum-Regel ist: das Reporting ist abgeschafft! Wer wissen will, wo die Entwicklung aktuell steht, kann sich über das Backlog oder eine Teilnahme an Sprint Reviews selbst ein Bild vom Status Quo machen. Eine der Hauptaufgaben des Managements fällt dadurch weg – und es entsteht viel freie Zeit, in der sich der Product Owner neue Ideen für die Verbesserung des Produkts ausdenken kann.
Die kleine Scrum-Schule
Wer sich mit Scrum noch nicht auskennt und ins Detail gehen möchte:
• PDF: Die offiziellen Schulungsunterlagen zum Thema Scrum (auf Deutsch).
• Hörbuch: Der Scrum Guide als Hörbuch zum freien Download
Das „Aber“
Für die meisten (und vor allem für kreativ veranlagte) Menschen klingen agile Prinzipien nach paradiesischen Zuständen. Auch immer mehr Unternehmen verstehen, dass unsere „connected times“ neue Arbeitsweisen verlangen und schwenken um auf agile Prozesse. Leider sind sie natürlich trotzdem noch lange kein Wundermittel: Nicht jedes Team arbeitet automatisch effizienter, nur weil es „agil“ unterwegs ist. Das liegt vor allem daran, dass der Weg vom bekannten, hierarchisch geprägten Wasserfall-Prozess hin zu einem selbstgesteuerten System (ohne Reporting!) für ältere Unternehmen (und die damit einhergehenden Strukturen v.a. im Kopf der Mitarbeiter) schwer zu verdauen ist.
Zu diesem Punkt lohnt sich ein eigener Artikel, den wir demnächst liefern. Wer sich davor aber schon mal inspirieren lassen möchte – hier ein schöner Podcast zum Thema:
Mein Scrum ist kaputt
Fazit
Agile Methoden gehören zu modern geführten Unternehmen dazu. Nicht alles muss oder kann agil gelöst werden, das ist klar. Aber richtig eingesetzt können agile Arbeitsweisen ein Team hocheffizient und vor allem glücklich machen. Im Unterschied zu klassischen Unternehmensprozessen sehen Teams in agilen Settings nämlich, dass ihr Tun einen konkreten Beitrag zum Gelingen eines Unternehmens beiträgt. Selbstbefähigung is king.
Was hat das jetzt mit Digitaler Marktforschung zu tun?
Dazu haben wir einen Artikel geschrieben: Agile Daten für Agile Entwicklung.
Hier geht es zu dem Artikel.
Weiterführende Links und Quellen
• Das Agile Manifest
• Podcasts:
o Agiles Produktmanagement
o Zukunftsarchitekten: Thema Systems Engineering (mit Schwerpunkt Automotive), hier gehts auch immer wieder um agile Themen
• Bücher:
o Essential Scrum von S. Rubin Kenneth
o Agiles Produktmanagement mit Scrum von Roman Pichler
o User Stories für die agile Software-Entwicklung mit Scrum, XP u. a. von Mike Cohn
o Scrum – A Pocket Guide – der Verfasser, Gunter Verheyen, hat an den Scrum-Prüfungen von scrum.org mitgewirkt
o The Mythical Man Month – in der deutschen Übersetzung – von Fred Brooks
Haben wir Ihr Interesse geweckt? Dann vereinbaren Sie einen Termin. Wir unterstützen Sie gerne mit Digitaler Marktforschung bei Ihren Entwicklungsprozessen.
