Agil ist das neue Schwarz

Agil ist das neue Schwarz

Kunde: „Wir machen jetzt alles agil“. Auch in der Prozessberatung haben wir laufend mit agiler Softwareentwicklung zu tun. Aber welche Bedeutung hat ‚agil‘, wofür stehen Begriffe wie ‚Scrum, ‚User Story‘, ‚Epic‘ eigentlich und wann macht das alles wirklich Sinn? Darüber schreibe ich in meinem Blog.

Agile Softwareentwicklung

Laut Duden bedeutet agil „von großer Beweglichkeit zeugend; regsam und wendig“ und so sollte es in der agilen Softwareentwicklung auch zugehen: Mit schlanken und flexiblen Prozessen, wenig Regeln und geringem bürokratischem Aufwand werden schnell sichtbare, funktionierende Ergebnisse erreicht. Dabei steht die Software im Fokus und der Auftraggeber ist aktiver Teil des Projektteams. Dies führt zu besserer Kommunikation sowie mehr Transparenz und Vertrauen.

Der agilen Softwareentwicklung steht die klassische Vorgehensweise gegenüber. Diese ist linear angelegt und kommt durch ein höheres Maß an Bürokratie und Standardvorgaben langsamer voran.

Agile Softwareentwicklung – eine epische Story?

Eine bekannte Methodik in der agilen Softwareentwicklung ist die Arbeit mit Epics und User Stories. Im Vergleich zur klassischen Methodik ist ein Epic so etwas wie ein modulares Fachkonzept. Eine User Story ist vergleichbar mit einer fachlichen Anforderung oder einem Use Case.

In einem idealen Szenario erstellt der Kunde auf Basis übergeordneter fachlicher Ziele Epics, aus denen er dann User Stories ableitet. Die User Stories werden um Akzeptanzkriterien ergänzt, welche die Abnahme einer User Story nach Fertigstellung vereinfachen.

Ein beliebtes Medium, um User Stories zu dokumentieren, sind Story Cards. Das sind einfache Klebezettel oder digitale Kärtchen, die auf einem Story Board oder in einer Datenbank-Software (wie z. B. Trello) visualisiert und je nach Zustand versetzt werden.

Von Scrum Mastern, Artefakten und anderen Tieren

Der wohl bekannteste agile Softwareentwicklungsprozess ist Scrum (übersetzt: ‚das Gedränge‘). Scrum setzt sich im Kern aus den folgenden Aktivitäten (Termine und Meilensteine), Artefakten (Dokumentation) und Rollen im Scrum Team zusammen:

  • Aktivitäten: Sprint-Planung, Daily Scrum, Sprint Review, Sprint Retrospective und Product Backlog Refinement
  • Artefakte: Product Backlog, Sprint Backlog und Product Increment
  • Scrum Team: Product Owner, Entwicklungsteam und Scrum Master

Henry und der agile Softwareentwicklungsprozess

Um die Begrifflichkeiten unter einen Hut zu bringen und den Prozess zu veranschaulichen, haben wir unseren Henry mal als Kunden in einen agilen Softwareentwicklungsprozess gesteckt und den Prozess in der Infografik darunter visualisiert:

  1. Henry möchte eine Software entwickeln lassen. Er stellt seine fachlichen Ziele und Anforderungen an die neue Software mithilfe von Epics und User Stories in einem Product Backlog zusammen. Das Product Backlog kann sich laufend ändern — durch neue Anforderungen oder Entwicklungsthemen.
  2. Auf Basis des Product Backlogs plant das Scrum Team die einzelnen Sprints. Hierfür werden passende User Stories aus dem Product Backlog als umzusetzende Tasks im Sprint Backlog festgelegt. Diese sind nicht veränderbar.
  3. Die Tasks aus dem Sprint Backlog werden vom Entwicklungsteam im Sprint umgesetzt. Ein Sprint darf nicht länger dauern als einen Monat.
  4. Während des Sprints finden täglich 15-minütige Treffen, so genannte Daily Scrums oder Dailys, statt. Hier informiert sich das Entwicklungsteam gegenseitig über Erledigtes, To-dos und Hindernisse.
  5. Im Sprint Review am Ende eines Sprint-Durchlaufs wird die Umsetzung der Tasks aus dem Sprint bewertet. Idealerweise wird hierbei das Product Increment (aktueller Softwarezustand) als done (abgenommen und lauffähig) bestätigt.
  6. In der Sprint Retrospective werden Lessons Learned des abgeschlossenen Sprints aufgearbeitet und für nächste Sprints berücksichtigt.

Der Scrum Master sorgt laufend dafür, dass Dailys richtig stattfinden und Hindernisse aus der Welt geschafft werden.

Quelle blc: Henry im agilen Softwareentwicklungsprozess

Sinn und Unsinn der agilen Vorgehensweise

Für reine Softwareentwicklungsprojekte macht ‚agil‘ absolut Sinn und ist aktuell das Vorgehen der Wahl. Viele Entwickler haben bereits lange vor ‚ädschail‘ so gearbeitet. Sie ahnten nicht, dass dies als agile Softwareentwicklung einmal Furore machen würde.

Für komplexe Beratungsprojekte, die nur zu einem Bruchteil Softwareentwicklung beinhalten und die zum Großteil aus fachlichen Prozessanalysen bestehen, ist die agile Vorgehensweise aus unserer Sicht nicht so sinnvoll.

Fragmentiert versus ganzheitlich

Warum ist das so? Bei agiler Softwareentwicklung geht es naturgemäß fragmentiert zu: Man verliert das große Ganze vorübergehend aus den Augen, um sich effektiver auf einzelne Module zu konzentrieren. Aus allen Modulen ergibt sich am Ende — wie in einem Mosaik — wieder das große Ganze. Genau dieser Vorteil der agilen Methode, die fragmentierte Sicht, ist für komplexe Beratungsprojekte sehr gefährlich. Analysen, Kommunikation und Abstimmungen mit ständigem Blick auf das große Ganze sind in komplexen Beratungsprojekten erfolgskritisch. Eine Lösung ist, solche Projekte im Mischverfahren durchzuführen. Hierbei werden nur die Softwareentwicklungsbestandteile ‚agil‘  gestaltet, der Rest ‚klassisch‘.

Ein weiteres Problem entsteht, wenn noch nicht alle Softwareprozesse im Unternehmen agil sind. Zum Beispiel: Ein Sprint aus dem agilen Projekt darf nur 20 Tage dauern, das Release für die Liniensoftware hat aber 90 Tage Zeit. Wie soll man das zusammen bringen?

Quelle: Pixabay

Und täglich grüßt das Daily

Allen Schwierigkeiten zum Trotz: Viele Elemente aus der agilen Softwareentwicklung werden immer häufiger auch für fachlich-organisatorische Prozesse eingesetzt. Zum Beispiel halten sich Mitarbeiter in Beratungsagenturen mit Dailys gegenseitig auf dem neusten Stand. Das ist vor allem für verteilte Teams, deren Mitglieder nicht alle am gleichen Ort sitzen, die aber an gleichen Projekten arbeiten, sehr nützlich.

Wichtig ist, dass immer die goldenen Regeln des Daily eingehalten werden:

  • Dauer insgesamt nicht länger als 15 Min., stehend
  • Erzählen, was man am Vortag geschafft hat und was man sich für heute vorgenommen hat
  • Befürchtete Hindernisse angeben (Zeit, Komplexität…)

Auch wir bei blc führen bereits eine ganze Weile Dailys durch, visualisieren unsere Aufgaben mit Post-its und haben Trello und Slack im Einsatz. Und auch wenn dies anfänglich gewöhnungsbedürftig war: Heute weiß jeder im Team über aktuelle Themen Bescheid, Hindernisse werden sofort ausgeräumt und das Team ist erheblich wendiger bei der Priorisierungen wichtiger Aufgaben.

Also: Henry und ich möchten das Daily nicht mehr missen!

Tags:

Related Posts