Category: Liefern, was gebraucht wird

Dialog zu Scrum

9. September 2014

Scrum

Scrum ist ein agiles Projektmanagement-Framework, das um die Jahrtausendwende von Ken Schwaber und Jeff Sutherland vor dem Hintergrund der Software-Krise erdacht und seitdem kontinuierlich weiterentwickelt worden ist.

Fliegengewicht mit 17 Seiten Dokumentationsumfang

Scrum ist ein leichtgewichtiges Framework und grenzt sich damit von umfangreichen Projektmanagement-Regelwerken ab. Der Scrum Guide, die offizielle Definition von Scrum, umfasst gerade einmal 17 Seiten. Scrum nutzt ein iterativ-inkrementelles Vorgehen, um am Ende einer jeden Iteration (Sprint genannt) ein fertiges Teilprodukt ausliefern zu können. Diese Sprints sind alle gleich lang (zwischen wenigen Tagen und vier Wochen) und schließen nahtlos aneinander an. Dadurch entsteht ein Takt, in den das Projektteam einschwingt und der einem Scrum-Projekt eine verlässliche Struktur gibt. Scrum besteht im Kern aus drei Rollen, vier Meetings, drei Artefakten sowie der Definition of Done, die im Scrum Guide beschrieben sind:

Rollen

Product Owner
  • ist verantwortlich für das „Was“, d.h. für die inhaltliche Gestaltung des Produkts, sowie für die Finanzierung der Produktentwicklung
  • kommuniziert mit Kunden und anderen Interessenvertretern
  • ist verantwortlich für das Product Backlog und dessen kontinuierliche Pflege
  • sorgt dafür, dass das Entwicklungsteam die User Stories aus dem Product Backlog soweit versteht, dass es deren Komplexität abschätzen und die Stories in ein nutzbares (Teil-)Produkt überführen kann
  • nimmt die Sprint-Ergebnisse ab
Entwicklungsteam
  • ist verantwortlich für das „Wie“, d.h. für die handwerklich solide Softwareentwicklung unter Nutzung geeigneter und zukunftssicherer Technologien und bürgt für eine hohe Qualität des am Sprint-Ende gelieferten Teilprodukts
  • besteht aus drei bis neun Personen und ist idealerweise über die gesamte Projektlaufzeit personell stabil
  • vereint alles Wissen, alle Fähigkeiten und Fertigkeiten, die notwendig sind, um das Produkt gemäß der „Definition of Done“ zu erstellen (cross-funktionales Team)
  • arbeitet selbstorganisiert und selbstbestimmt; legt beispielsweise eigenverantwortlich fest, wie viele User Stories in einen Sprint aufgenommen werden
Scrum Master
  • ist verantwortlich dafür, dass Scrum von allen Projektbeteiligten ver-standen und zum Zwecke der Zieler-reichung eingesetzt wird
  • ist ein dienender Führer für die an-deren Scrum-Rollen und methodi-scher Vermittler für alle Personen aus dem Projektumfeld
  • ist Moderator, Coach, Innovator, So-zialarbeiter, Schiedsrichter und Evangelist

Die Rollenbeschreibungen deuten es an: Scrum ist zwar leichtgewichtig, aber keinesfalls leicht in der Anwendung. Es bedarf eines gut ausgebildeten und vor allem lernwilligen Teams, um Scrum erfolgreich einzusetzen. Dank der klaren, überschneidungsfreien Aufteilung der Verantwortlichkeiten auf die drei Rollen kann Scrum die Zusammenarbeit in einem solchen Team bestmöglich unterstützen.

Meetings

Ein weiterer Baustein für die erfolgreiche Zusammenarbeit sind die regelmäßigen Meetings, die einen kontinuierlichen Dialog auf der inhaltlichen und der Prozessebene gewährleisten.

Meeting Agenda
Sprint Planning
Zu Beginn eines Sprint
  • Welche User Stories aus dem Product Backlog werden Bestandteil des Produktinkrements, das am Ende des Sprint geliefert wird?
  • Was ist zu tun, um das Produktinkrement liefern zu können?
Daily Scrum
Täglich, max. 15 min.
  • Was habe ich gestern getan, um das Entwicklungsteam bei der Erreichung des Sprint-Ziels zu unterstützen?
  • Was werde ich heute tun, um das Entwicklungsteam bei der Erreichung des Sprint-Ziels zu unterstützen?
  • Welche Hindernisse sehe ich, die das Entwicklungsteam von der Erreichung des Sprint-Ziels abhalten?
Sprint Review
Am Ende eines Sprint
  • Welche User Stories wurden gemäß der „Definition of Done“ fertiggestellt, welche nicht?
  • Live-Präsentation der fertiggestellten User Stories durch das Entwicklungsteam
  • Beantwortung offener Fragen, Sammeln neuer Ideen für das Product Backlog
  • Vorschau auf den nächsten Sprint und das nächste Release
Sprint-Retrospektive
Am Ende eines Sprint
  • Bewertung des vergangenen Sprint hinsichtlich der Individuen im Team, deren Beziehungen, des Prozesses und der verwendeten Werkzeuge
  • Sammeln von Erfolgsfaktoren und Verbesserungspotenzialen
  • Definieren und Priorisieren von Maßnahmen zur Prozessverbesserung; welche dieser Maßnahmen sollen im kommenden Sprint umgesetzt werden?

Das Agile Manifest bewertet funktionierende Software höher als umfassende Dokumentation. Deshalb beschränkt sich der Scrum Guide auf die minimal notwendige Dokumentation. Das bedeutet natürlich nicht, dass in Scrum-Projekten nicht zusätzliche Dokumentation geliefert werden darf. Insbesondere in regulierten Domänen ist dies gesetzlich vorgeschrieben. Allerdings sollten auch in diesen Bereichen immer die drei Mu-Prinzipien aus dem Toyota-System berücksichtigt werden.

Artefakte

Product Backlog Das Product Backlog ist eine geordnete Liste der Anforderungen an das Produkt, meist beschrieben in Form von User Stories. Diese Anforderungen sind

  • nach verschiedenen, definierten Kriterien geordnet, beispielsweise Geschäftswert, Risiko und Abhängigkeiten zwischen User Stories.
  • umso detaillierter beschrieben, je größer die Wahrscheinlichkeit ist, dass sie in einem der kommenden Sprints umgesetzt werden sollen; große Themenbereiche, die bisher nur grob skizziert wurden, ohne die darin verborgenen User Stories zu beschreiben, werden als Epics bezeichnet.
  • vom Entwicklungsteam bezüglich ihrer Komplexität abgeschätzt.
  • veränderlich: sie können sich inhaltlich ändern, in kleinere User Stories aufgeteilt, gelöscht oder um neue User Stories ergänzt werden.
Sprint Backlog Die Liste der User Stories, die für den Sprint ausgewählt wurden, ergänzt um die Tätigkeiten (Tasks), die notwendig sind, um diese User Stories zu implementieren.
Inkrement Der Produktumfang, der durch die Fertigstellung der User Stories im letzten Sprint erweitert wurde. Hier werden nur jene User Stories gezählt, die gemäß der „Definition of Done“ fertiggestellt worden sind.
Definition of Done Eine genaue Beschreibung aller Kriterien, die erfüllt sein müssen, damit eine User Story als fertiggestellt betrachtet werden kann. Diese Definition wird vom gesamten Scrum-Team gemeinsam erstellt und kann im Laufe des Projekts überarbeitet werden.

Auf der Basis des Scrum-Frameworks lässt sich ein einfaches, tagesgenaues Controlling installieren, das im Wesentlichen den Abarbeitungsstand der User Stories und der Tasks erfasst. Abweichungen vom prognostizierten Sprint-Verlauf können frühzeitig erkannt und behandelt werden. Die Auswirkungen auf eine übergeordnete Release-Planung werden ebenfalls frühzeitig sichtbar.

Weiterführende Informationen

  • www.scrumalliance.org – die Gralshüter von Scrum
  • www.scrum.org – Scrum-Erfinder Jeff Sutherland gründete aus Unzufriedenheit mit dem Stand der Dinge in Sachen Scrum 2009 diese Organisation

Dialog zum Kapitel „Liefern, was gebraucht wird“

9. September 2014

Im Kapitel Liefern, was gebraucht wird erläutert Holger Koschek, wie Teams anhand der Produktidee agil ein reales Produkt herstellen und dabei flexibel auf Kundenbedürfnisse reagieren.

Was ist Ihnen aufgefallen, was ging Ihnen beim Lesen durch den Kopf? Diese Webseite bietet Raum für Austausch, Fragen, Anregungen und vertiefende Materialien zu diesem Kapitel.

Zum Einstieg in die wesentlichen Themen gibt es im Internet hervorragende Artikel, gerade in Wikipedia. Googlen sie los! Welche Materialien würden Sie hier vorschlagen zu ergänzen? Zu welchen spezifischen Fragen wünschen Sie sich weitere Informationen?

Andere Leser freuen sich über Ihre Fragen und Anregungen, wie auch wir.  Nutzen Sie die Möglichkeit, Ihre Gedanken hier zu teilen! Am unteren Rand dieser Seite finden Sie ein entsprechendes Eingabefeld.

Volltreffer!

Das Feedback der ersten Nutzer des Prototypen signalisiert, dass die Idee eine Bedürfnislücke beim Kunden füllen kann. Hier scheint genau das richtige Produkt zu entstehen! Aber wie lange ist es „das Richtige“? Neue und geänderte Anforderungen sind zu erwarten, sobald eine erste Version des Produkts auf dem Markt ist. Je eher das passiert, desto besser – schließlich gibt es nichts Hilfreicheres, als von (und mit) echten Kunden zu lernen.

Es reicht demnach nicht, die richtige Produktidee zu haben – man muss dieses Produkt auch richtig (d.h. auf handwerklich bestmöglichem Wege) herstellt können – und das mit derselben Überzeugung und Hingabe, die auch schon bei der Produktidee aufgewendet wurde. Da es schnell gehen soll, konzentriert sich das Entwicklungsteam auf die wichtigsten Wünsche der Kunden. So sind sie in der Lage, genau das zu liefern, was gebraucht wird – nicht mehr, aber auch nicht weniger. Dazu bedarf es eines Entwicklungsprozesses, der den Lösungsraum möglichst weit offen hält. Unter dem Schlagwort „Agil“ haben engagierte Praktiker deshalb eine Reihe von Methoden und Rahmenwerken entwickelt, die sich dieser Herausforderung stellen.

Mehr zum Thema Agil …

Dialog zu Kanban

9. September 2014

Kanban

Das aus der Lean Production stammende Kanban-Prinzip hat zum Ziel, die Lagerbestände zu minimieren und damit Kosten zu sparen und die Produktion zu flexibilisieren.

Software Kanban

David Anderson hat dieses Prinzip auf die Softwareentwicklung übertragen. Beim sogenannten Software Kanban geht es darum, die Durchlaufzeit fachlicher Anforderungen (von der Idee bis zur Produktivsetzung) zu minimieren und die Qualität zu verbessern.

Die Einführung eines Kanban-Systems beginnt mit der Visualisierung der existierenden Wertschöpfungskette. Jeder Prozessschritt wird dabei durch eine eigene Spalte im Kanban Board dargestellt.

Die Anforderungen werden auf Karteikarten oder Haftnotizzettel geschrieben und dem Prozessschritt zugeordnet, in dem sie sich aktuell befinden. Sie durchlaufen das Kanban Board von links nach rechts. Allein durch diese Visualisierung bekommen die Prozessbeteiligten sehr schnell einen Eindruck davon, wie sich die Arbeit verteilt und wo es zu Problemen kommen kann – nämlich dort, wo sich viele Zettel stauen, wohingegen der nächste Prozessschritt keine oder kaum Zettel aufweist. Der Grund kann ein personeller Engpass in einem Team sein, oder aber die Tatsache, dass das Team an zu vielen Anforderungen gleichzeitig arbeitet, anstatt eine Anforderung zügig abzuschließen. Diesem Problem begegnet man, indem die Menge der in Arbeit befindlichen Anforderungen (Work in Progress, WIP) je Prozessschritt begrenzt wird.

Im Zuge der Etablierung solcher WIP Limits sollte der Prozess von einem Push- auf ein Pull-Verfahren umgestellt werden. Anstatt also die fertigen Anforderungen von einem Prozessschritt zum nächsten weiterzuschieben (Push), zieht sich das nachfolgende Team die Anforderungen in seine Prozessspalte (Pull) – und zwar maximal so viele Anforderungen, wie das WIP Limit zulässt. Dazu ist es hilfreich, die mittleren Spalten zu unterteilen in „in Arbeit“ und „erledigt“.

Durch die Einführung von Pull-Prinzip und WIP Limits wird sich nicht nur die Durchlaufzeit erhöhen, sondern auch die Qualität wird besser, weil sich die Teammitglieder auf die Erledigung weniger Anforderungen konzentrieren. (Personal-)Engpässe werden jetzt noch deutlicher sichtbar und können behoben werden. Handelt es sich um ein temporäres Problem, beispielsweise eine schwierig umzusetzende Anforderung, dann kann diese von den selbstorganisiert und eigenverantwortlich handelnden Teams dadurch gelöst werden, dass sich alle Prozessbeteiligten gemeinsam um die Bearbeitung dieser das System blockierenden Anforderung kümmern, bevor sie sich wieder ihrem eigenen Prozessschritt zuwenden.

Die Koordination der Prozessbeteiligten wird – ähnlich wie bei Scrum – durch eine Reihe von Meetings unterstützt. Es gibt mindestens ein Daily Standup Meeting und regelmäßige Retrospektiven, um kurzfristig auf Probleme reagieren zu können und sich mittelfristig zu verbessern. Das ist Kaizen – die Kunst der kontinuierlichen Verbesserung. Zur Unterstützung des Kaizen-Prinzips werden in Kanban-Systemen verschiedene quantitative Kennzahlen erhoben, die den Fluss der Anforderungen durch das System messen. Die entscheidende Messgröße ist die Durchlaufzeit, d.h. die Zeit, die eine Anforderung benötigt, um den Prozess komplett zu durchlaufen. Je kürzer diese Zeit, desto schneller kann dem Kunden etwas Wertvolles geliefert werden. Der Durchsatz gibt Aufschluss über die Anzahl an Anforderungen, die in einem bestimmten Zeitraum (z.B. einem Monat) fertiggestellt wurden. Um Durchlaufzeit und Durchsatz nicht auf Kosten der Qualität zu erhöhen, sollte auch die Fehlerrate ermittelt und deren Trend beobachtet werden.

Personal Kanban

Was in der Produktion und in der Softwareentwicklung funktioniert, kann auch im Privatleben hilfreich sein. Personal Kanban ist ein mächtiges Werkzeug, um die vielen kleinen und großen Aufgaben besser zu koordinieren und schneller abzuarbeiten.

Weiterführende Informationen

Dialog zu Agilen Methoden

9. September 2014

Agil

Agile Methoden sind kein Allheilmittel. Sie machen Projekte auch nicht schneller oder besser. Sie machen Probleme früher sichtbar. Aber genau darin liegt die Chance, die Dinge schneller und besser zu machen. Schon der Begriff “Methode” ist irreführend. Er suggeriert, dass es Patentrezepte für agile Projektmanagement gibt, bei deren richtiger Anwendung sich der Projekterfolg fast zwangsläufig einstellt. Tatsächlich ist agil eine Geisteshaltung und Denkweise, geprägt durch Werte wie Vertrauen, Mut und Verantwortungsgefühl. Diese Geisteshaltung kommt in den vier Wertepaaren und zwölf Prinzipien des Agilen Manifests gut zum Ausdruck.

Ein Wertekanon ist eine gute Basis, aber keine hinreichende Bedingung für zielgerichtete Produktentwicklung. Darüber hinaus bedienen sich die agilen Vorgehensweisen vieler Prinzipien des Lean Thinking, das nicht zuletzt aufgrund seiner Erfolge in der japanischen Automobilindustrie (Toyota-Produktionssystem) bekannt geworden ist.

Lean Management

Das Toyota-System wird durch drei Prinzipien bestimmt, die sich auf die Mitarbeiter, die Technik, die Methode und die Zeit beziehen:

  • Muri (Überlastung): Lean bewertet einen hohen Geschäftswert höher als starre Prozesse.
  • Mura (Unregelmäßigkeit, Unausgeglichenheit): Lean sorgt für einen kontinuierlichen Flow im System.
  • Muda (Verschwendung): Alle Aktivitäten, die keinen Geschäftswert liefern und für die der Kunde nicht zu zahlen bereit ist.

Fokus auf den Geschäftswert, kontinuierlicher Fluss dank iterativ-inkrementeller Entwicklung und fester Timeboxes, Pull-Prinzip – das sind die Prinzipien, die agile Methoden aus dem Lean Thinking entlehnt haben.

Kaizen

Darüber hinaus gilt auch in den agilen Methoden das Kaizen-Prinzip der kontinuierlichen Verbesserung: die Wertschöpfungskette wird schrittweise und evolutionär kleinen Änderungen unterzogen, deren Auswirkungen anschließend beobachtet und bewertet werden.

Kompliziert vs. komplex

Die agilen Methoden entfalten ihr volles Potenzial vor allem in komplexen Systemen. “Komplex? Sind wir nicht.”

Tatsächlich?

Eine für den Management-Kontext geeignete Kennzeichnung des Komplexitätsbegriffs liefert das Cynefin-Framework von Dave Snowden. Es verortet Probleme entsprechend ihrer Ursache-Wirkungs-Beziehung in einer von fünf verschiedenen Domänen:

Einfache (simple) Probleme haben eine offensichtliche, lineare Ursache-Wirkungs-Beziehung. Hier funktionieren die allgemeinen oder domänenspezifischen „Best Practices“. Stehen Ursache und Wirkung in einem linearen, nicht trivialen Zusammenhang, dann ist das Problem kompliziert (complicated), kann aber mit Hilfe einer Analyse unter Anwendung bewährter Praktiken bewältigt werden. Komplexe (complex) Probleme und Systeme sprengen die Kausalkette. Ihr Verhalten lässt sich nicht vorherbestimmen, weil zu viele Parameter das Verhalten beeinflussen und teilweise rekursiv auf sich selber angewendet werden. Sie können lediglich das Ergebnis betrachten und beurteilen, ob sie damit zufrieden sind. Auf diese Weise lassen sich emergente Praktiken aufspüren. In chaotischen (chaotic) Systemen gibt es keinerlei Zusammenhang mehr zwischen Ursache und Wirkung. Hier lassen sich neue, innovative Praktiken entdecken. Kennt man die Kausalität nicht, dann befindet man sich in der fünften Domäne (Disorder).

Für jede der ersten vier Domänen gibt es eine empfohlene Vorgehensweise. Bei komplexen Problemen kommt das Muster „Probe – Sense – Respond“ der Domäne „Complex“ zur Anwendung: Untersuchen (auf der Basis der erhobenen Daten); Erkennen von Problemen oder Verbesserungsmöglichkeiten; Reagieren durch Anpassung. Auf diese Weise lassen sich nicht nur Verbesserungen schrittweise umsetzen, sondern vor allem auch Risiken früher erkennen und besser beherrschen. Dieses Muster hat noch einen anderen Namen: Empirismus.

Empirismus

Die Theorie des Empirismus besagt, dass Wissen auf Erfahrung beruht und Entscheidungen auf der Grundlage dieses Wissens getroffen werden. Empirismus gründet auf drei Voraussetzungen:

  • Transparenz: Eine allgemeine Verfügbarkeit der relevanten Daten und Informationen muss gegeben sein, um auf deren Basis eine Entscheidung treffen zu können. Daten und Informationen werden zum Allgemeingut und verlieren infolgedessen ihre Wirkung als Machtinstrument. Entscheidungen (auch falsche) werden für alle nachvollziehbar.
  • Überprüfung: In angemessenen zeitlichen Abständen wird über-prüft, wie gut die gewählten Arbeitsweisen zur Zielerreichung beitragen.
  • Anpassung: Hat die Überprüfung ergeben, dass die gewählte Vorgehensweise noch Verbesserungspotenzial bietet, dann soll die Vorgehensweise so angepasst wer-den, dass das Ziel besser oder schneller erreicht wird.

Der Empirismus ist die theoretische Grundlage für das Prinzip des „Inspect and Adapt“, das im agilen Projektmanagement-Framework Scrum eine zentrale Rolle spielt.

Agile Vorgehensmodelle

Die bekanntesten Vertreter agiler Vorgehensmodelle mit dem höchsten Verbreitungsgrad in Organisationen weltweit sind:

  • Scrum: ein schlankes Rahmenwerk, das der effizienten und effektiven Organisation von Produktentwicklungsprojekten (ursprünglich für die Softwareentwicklung) mit hoher Anforderungsdynamik dient.
  • (Software) Kanban: eine Methode, die den Durchsatz der Ergebnisartefakte im Kontext der Entwicklung und Wartung von Software sichtbar macht und optimiert.

Mehr Informationen zu Scrum und Kanban finden Sie unter den obigen Links.