Keep It Lean And Agile (KILAA)

Agile Development mit Scrum
Kommentare

Mehr und mehr Unternehmen, die bisher mit konservativen Methoden wie Wasserfall oder RUP Software entwickelt haben, steigen auf „lean“ und agile Praktiken um. Basierend auf Best Practices bieten agile Vorgehensweisen so genannte Process Frameworks, die individuell auf die jeweiligen Teams und Projekte abgestimmt werden. Klingt gut! Lassen Sie uns jedoch auch kritische Fragen nach den Vor- und Nachteilen, den Einsatzgebieten, der Umsetzung, der langfristigen Anwendung und den Abgrenzungen zu Vorgehensmodellen wie CMMI stellen, bevor wir ein abschließendes Urteil bilden.

Lang, lang ist’s her, dass die erste Software entwickelt wurde und fast ebenso lange, dass das erste Projekt nicht in Zeit und Budget (das kenne ich doch irgendwoher!) abgeschlossen wurde. Vorgehensmodelle wie das Wasserfallmodell oder RUP wurden in der Hoffnung geboren, man könne Ingenieurpraktiken auch in der Softwareentwicklung anwenden. Diese Vorgehensweisen sind strukturiert, dokumentenbasiert und versuchen, die Softwareentwicklungsprozesse zu vereinheitlichen. Wie bei industriellen Produkten, wird hier viel Zeit und Energie auf die Planung im Vorfeld gelegt. Anforderungen werden niedergeschrieben, langfristige Planungen sollen Sicherheit geben und ausführliche Dokumente garantieren, dass alles jederzeit nachvollziehbar ist. All dies erscheint sinnvoll und wird in vielen Unternehmen auch umgesetzt.

Aber woher kennen wir dann diesen Satz, dass über 50 Prozent aller Projekte nicht in der geplanten Zeit und dem geplanten Budget abgeschlossen werden? Sprich, dass die meisten Projekte scheitern? Richtig: der Chaos Report der Standish Group. Dieser wird gern und häufig von allen möglichen Toolherstellern genutzt, um aufzuzeigen, wie das Dilemma abzustellen ist. Und obwohl es sicher richtig ist, dass Tools sehr hilfreich sein können, um die tägliche Arbeit zu erleichtern und zu unterstützen, so ist auch richtig, dass Tools die Prozesse nicht verbessern.

Warum scheitern nun Projekte, trotz strukturierter Prozesse und unterstützender Tools? Ganz einfach, erfolgreiche Softwareentwicklung bedeutet erfolgreiches Umgehen mit Änderungen. Denn im Gegensatz zu vielen industriellen Produkten, unterliegen Softwareprodukte ständigen und häufigen Änderungen. Softwareprojekte ohne Änderungen, und dazu gehören auch neue Anforderungen, gibt es schlichtweg nicht. Und darum sind Vorgehensweisen, die Prozesse in den Vordergrund stellen, die versuchen Vorgänge regelmäßig und wiederholbar zu machen, nur schlecht für die Entwicklung von Software geeignet.

Mögliche Lösungen für das Problem sind agile Methoden. Und obwohl die „Regeln“, wie Sie z.B. im Manifesto for Agile Software Development niedergeschrieben sind, andere Prioritäten setzten, bedeutet dies nicht, das man sich zwingend zwischen konservativ und agil entschieden muss. Agil sein, heißt flexibel sein, heißt den Menschen in den Vordergrund zu stellen und heißt auch, darauf zu vertrauen, dass ein selbstverantwortliches Team mehr erreichen kann, als eines, das lediglich starr festgelegten Prozessen folgt. Agil sein heißt nicht, chaotisches Vorgehen oder „Jeder macht was er will“. In wie weit sich traditionelle und agile Praktiken vereinbaren lassen, sehen wir später.

Agile Methoden

Das agile oder lean Vorgehen in Projekten kommt ursprünglich aus der Automobilindustrie. Erstmals setzte Toyota ein agiles Vorgehensmodell ein, und auch heute noch wird dort nach diesem Prinzip gearbeitet. Dieses agile Toyota-Vorgehen diente unter anderem als Basis für Scrum.

Kent Beck führte 1995 bei Chrysler erstmalig bei einem internen Pilotprojekt agile Softwareentwicklungsprozesse ein und rief damit das eXtreme Programming ins Leben (PDF, 192 KB). XP wird als reines Vorgehensmodell der Softwaretechnik je nach Bedarf getailort und so an die individuellen Bedürfnisse angepasst. Das Framework Scrum kann sehr gut mit XP kombiniert werden, setzt aber nicht, wie oft angenommen wird, den Einsatz von XP-Praktiken voraus.

Im Agile Manifesto haben die Vertreter beider agiler Bewegungen die Gemeinsamkeiten von Scrum und XP zusammengefasst und niedergeschrieben:

  • Menschen und Zusammenarbeit vor Prozessen und Werkzeugen
  • Funktionierende Software vor umfassender Dokumentation
  • Zusammenarbeit mit dem Kunden vor vertraglicher Verhandlung
  • Reaktion auf Veränderung vor Einhaltung eines Plans

Abb. 1: Bekannte agile Methoden im Überblick

Scrum – eine agile Methode

Der Begriff Scrum kommt aus dem Rugby und bedeutet soviel wie „den Ball im Spiel halten“. Andrew Scotland, Head of Development bei der BBC New Media Division, hat Scrum auf der JAOO 2005 in Aarhus, Dänemark, sehr treffend beschrieben:

Scrum is a simple ‚Inspect and Adapt‘ Framework that has three Roles, three Ceremonies, and three Artifacts designed to deliver working Software in Sprints, usually 30-day Iterations.

  • Roles: Product Owner, Scrum Master, Team
  • Ceremonies: Sprint Planning, Sprint Review and Daily Scrum Meeting
  • Artefacts: Product Backlog, Sprint Backlog and Burn-down Chart [3]

Scrum ist ein iteratives und inkrementelles Vorgehen für die Produktentwicklung und die Organisation von Teams. Das so genannte Scrum Framework definiert eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden, mithilfe derer Aufgaben schneller und mit höherer Qualität erfüllt werden können. Dies gelingt zum einen durch sehr hohe Eigenmotivation – denn mit Scrum legt das Team selbst fest, welche Aufgaben auf welche Art und Weise erledigt werden –, zum anderen entstehen durch kontinuierliche Reflektionen optimale Arbeitsweisen, die es ermöglichen, Kundenanforderungen zu priorisieren und diese iterativ und schnell zu realisieren.

[ header = Seite 2: Scrum – in a Nutshell? ]

Scrum – in a Nutshell?

Wie schon erwähnt, beinhaltet Scrum drei direkt beteiligte Rollen:

  1. Der Product Owner erhebt die fachlichen Anforderungen, priorisiert sie und stellt sie dem Team vor.
  2. Der so genannte Scrum Master managt den Ablauf und sorgt dafür, dass das Team während einer Iteration (Sprint) ungestört arbeiten kann.
  3. Das Team, verantwortlich für die Entwicklung des Produkts, vervollständigt das Dreigestirn.

Anders als bei anderen Methoden, ist das Team bei Scrum aber nicht nur das ausführende Organ, sondern muss zunächst durch Fragen an den Product Owner genau herausfinden, was sich hinter den fachlichen Anforderungen verbirgt. Dem Team wird nicht vorgeschrieben, wie z.B. Features realisiert werden sollen, sondern es ist selbst, nachdem es die fachlichen Belange verstanden hat, für die richtige Umsetzung verantwortlich. Neben diesen drei Rollen gibt es noch weitere Stakeholder, die z.B. als Beobachter und Ratgeber dienen.

Die Anforderungen oder auch Requirements werden im Product Backlog niedergeschrieben, gepflegt, erweitert und vor allem auch priorisiert. Die jeweils am höchsten priorisierten Anforderungen werden im Sprint Planning Meeting, das zu Beginn der Iteration (Sprint) stattfindet, mit dem Team diskutiert. Hier findet das Team heraus, was sich hinter einer fachlichen Anforderung verbirgt und schätzt die notwendige Zeit für die Entwicklung. Alle Anforderungen, die nach dieser Schätzung in einem Sprint erledigt werden können, werden aus dem Product Backlog entfernt und vom Entwicklerteam während des Sprints realisiert. Dieses Arbeitspaket wird während der laufenden Iteration nicht durch Zusatzanforderungen modifiziert, um seine Fertigstellung nicht zu gefährden. Denn nur was am Ende fertig ist – und fertig heißt bei Scrum getestet und dokumentiert –, kann vom Product Owner im so genannten Review Meeting abgenommen werden. Bekannte Aussagen wie „… ich bin zu 80 Prozent fertig…“ gibt es nicht mehr. Alle anderen Anforderungen im Product Backlog werden vom Product Owner für den nachfolgenden Sprint vorbereitet, verändert oder auch neu priorisiert.

Die Tasks, aus dem Arbeitspaket heruntergebrochen, werden im Sprint Backlog festgehalten und täglich mit der Angabe über die Restaufwände versehen. So entsteht das immer aktuelle Burn-down Chart.

Abb. 2: Ein Sprint Burn-down Chart in Agilo for Scrum. Das Open-Source-Tool kann unter www.agile42.com kostenlos heruntergeladen werden.

Während des Sprints kann das Team konzentriert und ungestört die Tasks aus dem Sprint Backlog abarbeiten. Es trifft sich täglich zu einem Timeboxed Meeting von 15 Minuten, dem Daily Scrum Meeting, um auftretende Probleme zu klären und über Ergebnisse zu sprechen. Der Scrum Master sorgt während des gesamten Prozesses dafür, dass die Regeln eingehalten werden und dass keine Störungen von außen auftreten.

Am Ende des Sprints präsentiert das Team dem Product Owner und den Stakeholdern im Sprint Review Meeting die implementierten Funktionalitäten.

Scrum – ganz einfach, oder?

So unkompliziert Scrum auch klingt, das einfach und schnell einzusetzende Framework setzt dennoch eine Menge voraus. Verantwortlichkeiten müssen definiert, das Rollenverständnis geklärt und Techniken erlernt werden. Es reicht bei Weitem nicht aus, ein Training zu besuchen oder sich zum Scrum Master ausbilden zu lassen. Wer Scrum, wie jede andere Methode auch, erfolgreich einsetzen will, muss Prozesse analysieren, die Stärken und Schwächen der Teams bewerten und unter Umständen Strukturen aufbrechen und neu organisieren. Wichtig ist, dass auch ein Framework wie Scrum nicht einfach „out of the Box“ angewandt werden kann. Individuelles Consulting, Training und Coaching von praxiserfahrenen Beratern ist sinnvoll und angeraten. Aber keine Sorge, nach schon einem Sprint ist auch der Erfolg sichtbar. Und der Erfolg ist, wie wir aus vielen Projekten wissen, herausragend.

Scrum – ein Erfolgsrezept?

Würde das Marketing eines Unternehmens mit Angaben wie „300 Prozent schnellere Entwicklungszeiten“, „100 Prozent mehr Kundenzufriedenheit“ oder Ähnlichem werben, wir würden es nicht glauben. Und dennoch, im Falle von Scrum stimmen diese oder ähnliche Ergebnisse nicht selten. Aber wie kommt es dazu?

Der Erfolg von Scrum beruht neben der schnellen Umsetzung auf einer ganz einfachen Tatsache: Die Teams haben Spaß. Wer Spaß hat, arbeitet gern und erzielt bessere Resultate. Denn vergessen wir nicht, die Entwicklung von Software ist ein kreativer Beruf. Bis ins Detail vorgegebene Anforderungen, die womöglich auch noch die technische Umsetzung beschreiben, lassen jedoch kaum Raum für Kreativität. Die Verantwortung und der Teamgeist, die durch Scrum erzeugt werden, bewirken eine Motivationssteigerung, die mit nichts zu vergleichen ist.

Vorteile von agilen Prozessen wie Scrum

  • Hohe Flexibilität im Entwicklungsprozess
  • Schnelle Reaktionsmöglichkeit auf Änderungswünsche
  • Frühzeitige und intensive Einbindung des Kunden
  • Einfachheit und ein hoher Fokus auf Teamarbeit
  • Kollaboration auch Teamübergreifend
  • Verbesserte Kommunikation
  • Ergebnisse sind nach jeder Iteration sichtbar und verkäuflich
  • Höhere Qualität der Software durch Tests
  • Hohe Transparenz des Prozesses
  • Herausragende Produktivität des Projektteams

Nachteile dieser Prozesse könnten sein:

  • Kommunikation kann bei räumlich getrennten Teams mehr Aufwand bedeuten
  • Flexibilität zu Lasten von Formalität (eventuell problematisch bei sicherheitskritischen Anwendungen)
  • Kein Fokus auf Dokumente

[ header = Seite 3: Von Äpfeln und Birnen ]

Von Äpfeln und Birnen

Ein agiles Framework wie Scrum mit CMMI (Capability Maturity Model Integration) zu vergleichen, heißt Äpfel mit Birnen zu vergleichen. Scrum basiert auf Best Practices und geht davon aus, dass ein Team, das Verantwortung trägt und in Entscheidungen involviert ist, weitaus bessere und schnellere Ergebnisse erzielen kann, als ein Team, das streng nach vorgegebenen Prozessen arbeitet.

CMMI ist dagegen ein komplexes Gebilde, bestehend aus einem Prozessmodell, einem Qualitätsstandard und einem Validierungsmodell. Mit Vorgehensmodellen wie CMMI oder auch Prozessmodellen wie dem V-Modell wird versucht, Arbeitsabläufe so genau wie möglich zu definieren, sodass eine Wiederholung jederzeit und durch jedes Team möglich ist. Sie können zwar durch gezieltes Tailoring auf die organisationsspezifischen Belange zugeschnitten werden, ansonsten sind Vorgehensmodelle oder Prozessmodelle starre Gebilde, deren Fokus auf Planung, Prozessen und Dokumentation liegt. „Agil“ bedeutet hingegen „beweglich“, „wendig“ und steht für die Fähigkeit, flexibel auf neue Anforderungen oder Änderungen reagieren zu können. Der pragmatische Ansatz von Scrum fokussiert darum ergebnisorientierte und teamorientierte Arbeitsweisen an.

Abb. 3: Fokus der unterschiedlichen Methoden

Während die Kritiker agiler Methoden Scrum häufig als Chaosmanagement bezeichnen, müssen sich CMMI-Befürworter oft Starrheit, Kreativitätslosigkeit, hohe Kosten und Schwerfälligkeit vorwerfen lassen.

Aber nun zur Vergleichbarkeit. Es gibt keine, denn, wie schon erwähnt, würde man versuchen, Äpfel mit Birnen zu vergleichen. Was jedoch möglich ist, ist die Kombination und die Verbindung beider Ansätze. Denn was sollte dagegen sprechen, im Rahmen der Umsetzung von CMMI in einem Unternehmen, Scrum als Methode in der Entwicklung zu nutzen, um so die Softwareentwicklungsprozesse zu optimieren?

Eine detaillierte Analyse, in wieweit Scrum und die CMMI Process Areas kompatibel sind, haben Martin Fritzsche und Patrick Keil 2007 an der Universität München erstellt [1] (PDF, 144 KB). Das Ergebnis ist eindeutig. Bis auf wenige Ausnahmen lassen sich die scheinbar so widersprüchlichen Vorgehensweisen zielführend kombinieren.

Abb. 4: Abdeckung der CMMI Process Areas durch XP und Scrum (XX=Umfassend unterstützt, X=Unterstützt)

Von der Theorie zur Praxis

Wir sehen also, auch wenn Äpfel und Birnen nicht direkt vergleichbar sind, kombinieren lassen sich die beiden sehr gut. Aber gehen wir noch einen Schritt weiter. Egal, welche Methode oder Vorgehensweise ein Unternehmen einsetzen und nutzen möchte, die Entscheidung, welches Vorgehen richtig, falsch, zielführend oder hemmend ist, kann anhand der Theorie häufig nur unzureichend untersucht werden. Zum einen, weil jede Veränderung der Prozesse auch strukturelle Veränderungen mit sich bringt, die man erst im vollen Umfang erkennt, wenn es an die Umsetzung geht. Und zum anderen, da in der Regel Methoden in der Praxis nicht in ihrer Reinform bzw. wie im Idealfall zum Einsatz kommen können.

Es genügt also nicht, dass z.B. lediglich das Entwicklerteam nach Scrum arbeitet, wenn der Vertrieb, das Marketing oder auch die Geschäftsleitung wie bisher, zu jeder Zeit Änderungen und neue Wünsche anbringen kann, ohne die Sprintphasen zu respektieren. Mit Methoden wie Scrum kann das Entwicklerteam effizienter und schneller arbeiten, aber nur, wenn alle am Entwicklungsprozess beteiligten im Unternehmen verstehen, was Scrum ist und unter welchen Umständen diese Methode zum Erfolg führt. Jeder Beteiligte hat ein Rolle, mit Rechten und Pflichten, und das Verständnis und der Respekt bezüglich der Regeln sind zwingend notwendig, um Scrum, wie auch jede andere Methode, zielführend einzusetzen.

Daraus ergibt sich zwangsläufig die Tatsache, dass Methoden häufig nicht eins zu eins in jedem Unternehmen gleich und unverändert angewendet werden können. Nehmen wir zum Beispiel einen Sprint. In der Regel beginnt ein Sprint mit dem Sprint Planning Meeting und dauert 4 Wochen, in denen das Team ungestört an seinen Aufgaben arbeitet. In den meisten Fällen ist dieses Szenario plausibel und funktioniert in der Praxis ohne Weiteres. Was aber passiert z.B. mit Supportanfragen oder Bugs? Muss ein Kunde dann einen Monat warten, bis sein Fehler behoben wird? Oder sollte in diesem Unternehmen sinnvollerweise kein Scrum eingesetzt werden? Weder noch! Auch wenn man sich bei der Einführung von Methoden zunächst an die theoretischen Vorgaben halten sollte, damit die Grundprinzipien verstanden und verinnerlicht werden können, müssen für das Business angepasste Modifikationen gefunden werden. Was spricht denn dagegen, dass entweder in den Sprintphasen auch tägliche Supportanfragen behandelt werden? Oder warum sollte man einen Sprint nicht einfach auf zwei Wochen verkürzen? Darum ist der Begriff „Framework“ in Bezug auf Scrum wesentlich treffender als der Begriff „Methode“. Denn letztendlich bestimmen die zielführenden und passenden Bestandteile des Frameworks die Umsetzung im jeweiligen Unternehmen.

Wo und vor allem auch wann Anpassungen und Veränderungen von Standardmethoden sinnvoll und geeignet sind, wissen erfahrene Berater wie Dr. Andrea Tomasini, agile42 GmbH:

Änderungen oder Anpassungen beruhen häufig auf Faktoren wie Time-to-Market, Teamkonstellationen oder spezifischen Kundenwünschen. Dr. Andrea Tomasini, 2008

Fest steht, wenn Sie sich für den Einsatz von agilen Methoden entscheiden, müssen folgende Punkte Schritt für Schritt gewährleistet werden:

  • Alle Beteiligten müssen eingebunden werden und die Einführung mittragen.
  • Das Management muss den Beratern und Pilotteams 100-prozentige Rückendeckung geben, denn Veränderung tut manchmal auch weh.
  • Alle Teams und Rollen brauchen spezielle Trainings und individuelles Coaching, bis die neuen Strukturen in Fleisch und Blut übergegangen sind. Ein Buch zu lesen oder lediglich ein Training zu besuchen, reicht nicht.
  • Zu Beginn sollten sich die Prozesse strenger an die Methodentheorien halten. Erst wenn man die Prinzipien verstanden und verinnerlicht hat, sollten Änderungen und Anpassungen vorgenommen werden.

[ header = Seite 4: Von Wasserfällen und anderen Naturschauspielen ]

Von Wasserfällen und anderen Naturschauspielen

Viele, wie ich sie nenne „Nicht-Techies“, denken, dass Software einfach, schnell und ohne großen Aufwand zu ändern sei. Diese simple Annahme erwächst sicher aus dem Gebrauch der Software und der Erleichterung, die sie bei täglichen Arbeiten mit sich bringt. Wie sollten Softwareanwender auch die Probleme der Softwareentwicklung kennen? Wie oft haben wir schon die bekannten Beispiele gehört: „Software entwickeln ist wie ein Haus bauen, oder stell dir eine Industriefertigungsstraße vor…“. Wie könnte man auch erwarten, dass Begriffe wie Traceability oder Change Management einem „normalen“ Anwender etwas sagen?

Diese gern verwendeten Beschreibungen darüber, wie Softwareentwicklung funktioniert, machen uns aber auch etwas anderes deutlich. Sie beschreiben nämlich etwas, was lange als richtig angesehen wurde, in der Realität aber häufig nicht bestehen konnte: Das Wasserfallmodell und andere starre Vorgehensweisen sind in vielen Projekten weit weniger geeignet als agile Ansätze.

In vielen Jahren, durch viele Projekte und mit jeder Menge neuer Methoden haben wir gelernt, dass Software eben nicht mit aufeinander folgenden, festgelegten und durchgeplanten Schritten zu entwickeln ist. Vorgehensweisen wie das Wasserfallmodell basieren auf Ingenieurtechniken und erwarten, dass bereits zu Beginn alle Anforderungen feststehen und geplant werden. Sie lassen keine dynamische Entwicklung zu und werden iterativen und inkrementellen Aspekten nicht gerecht.

Die Softwareentwicklung ist aber oft von ständig neuen Anforderungen, von wechselnden Marktstrategien und von häufigen Änderungen geprägt. Und wenn wir hier von Änderungen sprechen, dann geht es dabei nicht nur um die Änderungen an der Software selbst, dann geht es dabei ebenso um Änderungen im Team, von Arbeitsweisen, von Prozessen. Softwareentwicklung basiert auf evolutionären Abläufen und ist darum mit einem Hausbau oder einer Produktionsstraße nicht vergleichbar – auch wenn die Beispiele für Laien sicherlich auch in Zukunft ihren Zweck erfüllen.

Agile Methoden und ihre Grenzen

Agile Methoden haben ihre Grenzen häufig in „großen“ Projekten. Natürlich ist die Projektgröße (Projektumfang, -dauer, -kosten, -risiken) relativ, aber die notwendige Kommunikation muss in großen Projekten gezielt koordiniert werden und kann häufig nicht synchron geschehen.

Auch bei Festpreisprojekten können Methoden an ihre Grenzen stoßen, denn die Erstellung eines vollständig spezifizierten Anforderungskatalogs widerspricht definitiv den agilen Ideen. Nichtsdestotrotz lässt sich hier ein Ausweg finden. So könnte man z.B. Festpreise für Meilensteine oder Releases festlegen, anstatt für ein komplettes Projekt.

Und da wären noch die Projekte, in denen eine umfangreiche Dokumentation gefordert ist. Ob diese Auflage aufgrund von Sicherheitsvorgaben oder anderen Gründen erfolgt, spielt keine Rolle. Für solche Projekte sind agile Methoden weniger geeignet.

Fazit

Agil sein ist sicherlich mehr als nur ein Hype, und wer denkt, dass agile Methoden wie Scrum nur in Bereichen der Webentwicklung und für unkritische Softwareentwicklung einsetzbar ist, liegt falsch. Scrum kann überall da eingesetzt werden, wo ein neues Wertesystem keine Angst macht, wo Ergebnisse mehr zählen als Hierarchien und wo Kosten gespart werden sollen. Denn agil sein hat nichts mit unstrukturiertem oder chaotischem Vorgehen zu tun, im Gegenteil, agile Teams arbeiten konstruktiver und effizienter. Und obwohl agile Methoden wie Scrum auch ihre Grenzen haben, z.B. in Projekten mit strengen gesetzlichen Regularien, lohnt sich immer eine Analyse über mögliche Einsatzgebiete. Denn die Erfahrung zeigt, dass viele Probleme in Softwareentwicklungsprojekten nicht technischer, sondern sozialer Natur sind. In agilen Projekten sind daher neben den fachlichen Qualifikationen, insbesondere die Soft-Skills von großer Bedeutung. Wer agil arbeiten will muss:

  • Aktiv sein
  • Teamfähigkeit beweisen
  • Kommunikation beherrschen
  • Selbstkritisch sein können
  • Mutig sein

In diesem Sinne, keep it lean and agile!

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -