Lean von Scrum

Von David Starr. David Starr ist Chief Software Craftsman für Scrum.org und konzentriert sich auf die Verbesserung des Metiers der Softwareentwicklung. Zudem hat er die technische Onlinecommunity ElegantCode.com gegründet.

Juli 2012

Erforschen Sie die inhärenten Lean-Qualitäten des Scrum-Frameworks, und lernen Sie mehrere Möglichkeiten kennen, mit denen die Scrum-Teams die Anwendung von Lean Thinking verbessern können.

Betrifft

Team Foundation Server

Übersicht

Scrum aus der Lean-Perspektive

Leaner Scrum

Conclusion

In aktuellen Diskussionen über agile Softwareentwicklung fallen auf jeden Fall die Begriffe Scrum, Lean und Kanban – drei Tools zur Planung, Überwachung und Ausführung von Aktivitäten im Rahmen der Softwareentwicklung. Diese Tools werden häufig von einigen agilen Anwendern, die proklamieren, dass das Scrum-Framework und Lean Thinking (schlankes Denken) gut zusammen funktionieren, verglichen und gegenübergestellt. Von anderen hingegen werden die Tools als grundsätzlich unterschiedliche Möglichkeiten für die Softwarebereitstellung angesehen.

Übersicht

Scrum ist unglaublich beliebt: Rund 92 % der mit agilen Entwicklungsmethoden arbeitenden Teams geben an, dass sie Scrum[1] nutzen. Nachdem sie sich vom Erfolg überzeugt haben, den Scrum ermöglicht, möchten viele Teams die Anwendung über das grundlegende Scrum-Framework hinaus ausdehnen. Dieser Artikel untersucht eine Erweiterung des Scrum-Frameworks mit Lean- und Kanban-Verfahren, mit einer auf Kaizen – also der kontinuierlichen Verbesserung – basierenden Denkweise.

Scrum

Das Scrum-Framework wurde im Jahre 1995 von Ken Schwaber und Jeff Sutherland vorgestellt. Es handelt sich um eine Methode, mit der Teams bei der Softwarebereitstellung iterativ und inkrementell zusammenarbeiten. Scrum-Teams organisieren die Arbeit in Zeitfeldern, die als Sprints bezeichnet werden und einen Monat oder weniger umfassen. In jedem Sprint ist am Ende eine vollständige und funktionierende Funktionalität vorhanden.

Das Scrum-Framework ist einfach zu verstehen und wird von Softwareentwicklungsteams und deren Kunden ausgesprochen gern eingesetzt. Scrum fördert funktionsübergreifende und selbst organisierende Teams, die sich während des gesamten Sprints darauf konzentrieren, ein funktionierendes und potenziell auslieferbares Softwareinkrement zu liefern.

Scrum ist im Scrum-Leitfaden festgeschrieben, in dem auch die Scrum-Rollen, -Artefakte und -Ereignisse dokumentiert sind. Der Scrum-Leitfaden wird von den Scrum-Entwicklern aktualisiert und ist online unter Scrum.org verfügbar.

Lean

Lean Thinking (schlankes Denken) ist eine Herangehensweise an die Systemoptimierung. Der Schwerpunkt hierbei liegt auf der Reduzierung von Verschwendung und der Verbesserung des allgemeinen Wertstroms in einem System. Lean verfügt über eine lange Geschichte im Bereich der Produktion, in den letzten Jahren ist dieses Konzept auch in der Softwareentwicklung populärer geworden.

Im Bereich der Softwareentwicklung verkörpert Lean Thinking die folgenden sieben Prinzipien, die zuerst im Buch Lean Software Development: An Agile Toolkit[2] veröffentlicht wurden.

1. Verschwendung vermeiden

2. Lernen verstärken

3. So spät entscheiden wie möglich

4. So früh ausliefern wie möglich

5. Verantwortung an das Team geben

6. Integrität einbauen

7. Das Ganze sehen

Es ist nicht das finale Ziel, diese Prinzipien auf die Arbeit, ein Softwareprodukt zu liefern, anzuwenden. Es heißt nicht: „Mach Lean“, sondern vielmehr werden die Lean-Prinzipien als Anleitung bei der Entscheidungsfindung und zur Auswahl von Methoden, die eine Verbesserung des gesamten Systems nach sich ziehen, herangezogen. Beispielsweise wird bei der Anwendung der testgesteuerten Programmierung die Softwareintegrität eingebaut, indem die Software zum Zeitpunkt der Erstellung überprüft wird. Das entspricht dem Lean-Prinzip des Integritätseinbaus während des Erstellungsprozesses.

Kanban

Ein Verfahren, das seine Wurzeln in Lean Thinking hat, ist Kanban[3]. Bei Kanban wird Lean Thinking als formelle Methode zur Fokussierung auf die Reduzierung von Verschwendung, auf JIT-Lieferung und das Vermeiden einer Überlastung der Mitarbeiter eingesetzt. Anders als Scrum ist Kanban keine iterative und inkrementelle Methode; anstelle von Iterationen stehen bei der Kanban-Methode fünf Hauptaktivitäten im Vordergrund:

1. Workflow visualisieren

2. In Bearbeitung befindliche Arbeit begrenzen

3. Fluss steuern

4. Explizite Prozessregeln schaffen

5. Gemeinsam verbessern

Verschiedene Teams, die mit der Kanban-Methode arbeiten, haben häufig sehr unterschiedliche Prozesse. Die Kanban-Methode ist lediglich eine Reihe von Verfahren zum Verwalten eines Prozesses, der dann mit Bedacht optimiert wird. Kanban kann einfach auf bereits vorhandene Prozesse, einschließlich Scrum, angewendet werden.

Scrum und Kaizen

Sobald mit jedem Sprint funktionierende Softwareinkremente geliefert werden, suchen die Scrum-Teams nach neuen Möglichkeiten, um ihre Methoden zu verbessern. Das Herz von effektivem Scrum ist Kaizen, die Denkweise der kontinuierlichen Verbesserung. Gut funktionierende Scrum-Teams arbeiten bei ihrer Fokussierung auf Kaizen mit unzähligen Methoden. Tools und Verfahren wie relative Schätzung, testgesteuerte Programmierung, Buildautomatisierung und Paarprogrammierung zählen in Scrum-Teams zum Standard.

Scrum wird durch andere Tools, Verfahren und Methoden nicht nur gut ergänzt, sondern es gibt sogar ein Scrum-Erweiterungsmodell, das unter scrum.org beschrieben und verwaltet wird. Dieses Erweiterungsmodell für Scrum fördert die Community-Beteiligung, indem Methoden dokumentiert werden, die als Ergänzung für Scrum dienen und gut mit dem Framework harmonieren. Zum Zeitpunkt dieses Artikels sind bereits einige Erweiterungen vorgeschlagen worden, in denen es insbesondere um die Verwendung von Lean-Methoden in Scrum geht.

Die Vorteile bei der Anwendung von Lean Thinking in Scrum sind unbestritten. Es überrascht daher nicht, dass bereits viele Scrum-Nutzer eine bessere Leistung und Qualität realisiert haben, indem sie Lean Thinking in ihre Scrum-Methode einbezogen.

Scrum aus der Lean-Perspektive

Das Scrum-Framework besteht aus den folgenden Rollen, Artefakten und Ereignissen. Wenn Sie mit dem grundlegenden Scrum-Framework nicht vertraut sind, lesen Sie den Scrum-Leitfaden, bevor Sie fortfahren.

Rollen	Artefakte	Ereignisse
Produktbesitzer Scrum-Master Entwicklungsteam	Produktrückstand Sprint-Rückstand Increment	Sprint Sprintplanung Tägliche Scrum-Besprechung Sprintüberprüfung Sprintretrospektive

Im Scrum-Leitfaden werden Regeln vorgegeben, wie diese Komponenten zusammenspielen, aber Lean Thinking bietet ein Framework, um das Wechselspiel der Rollen, Artefakte und Ereignisse von Scrum noch weiter zu optimieren. Scrum-Teams wählen eine Teilmenge aus dem Produktrückstand aus, die in den einzelnen Sprints geliefert werden soll. Dann konzentrieren sich die Teams darauf, ein Inkrement mit entsprechender Qualität und Funktion zu liefern. Lean Thinking kann dabei helfen, einen reibungslosen Workflow im Sprint zu schaffen und Verschwendung im gesamten Wertstrom zu reduzieren.

Sowohl bei Scrum als auch bei Lean soll eine hohe Qualität gehalten werden, denn diese ist für den Erfolg der gesamten ausgeführten Arbeit ausschlaggebend. Um die gemeinsamen Prinzipien von Lean Software Development und Scrum in Aktion zu erleben, analysieren Sie einfach die Scrum-Rollen, -Artefakte und -Ereignisse aus der Lean Thinking-Perspektive.

Ereignisse

Mit Ausnahme des Sprints, der als Container für alle anderen Ereignisse fungiert, sind die Scrum-Ereignisse tatsächlich reine Besprechungen. Bei Lean Thinking werden Besprechungen generell als Verschwendung betrachtet, und diese gilt es, unablässig zu vermeiden.

Das könnte einen zu der Schlussfolgerung verleiten, dass Scrum-Ereignisse überflüssig sind. Jedoch ist jedes Ereignis in Scrum so sorgfältig konzipiert, dass andere Besprechungen, die ansonsten eine Unterbrechung darstellen würden oder spontan stattfinden müssten, nicht erforderlich sind. Gut ausgeführte Scrum-Ereignisse führen zu weniger Besprechungen und weniger Zeit, die für eine Reaktion auf ungeplante Unterbrechungen aufgewendet werden muss.

Jedes Scrum-Ereignis ist darauf ausgelegt, etwas zu überprüfen und etwas abzustimmen. Die Überprüfung unterstützt die Lean-Prinzipien des verstärkten Lernens und des Einbaus von Integrität in den Erstellungsprozess. Das Anpassen eines Plans, einer Anforderung oder eines anderen Artefakts während eines Scrum-Ereignisses unterstützt die Lean-Prinzipien, so spät zu entscheiden wie möglich und das Ganze zu sehen. In der folgenden Tabelle werden Scrum-Ereignisse und das, was während der Besprechungen überprüft und angepasst wird, angezeigt.

Ereignis	Überprüft	Angepasst
Rückstandsbereinigung	Produktrückstand	Produktrückstand
Sprintplanung	Produktrückstand Vorherige Inkremente	Sprintziel Sprint-Rückstand
Tägliche Scrum-Besprechung	Sprint-Rückstand Fortschritt hin zum Sprintziel	Sprint-Rückstand Tagesplan
Sprintüberprüfung	Aktuelles Inkrement Aktueller Sprint Produktrückstand	Produktrückstand Weitere langfristige Pläne
Sprintretrospektive	Aktuelles Inkrement Aktueller Sprint Scrum-Team selbst Technische Methoden	Verhalten des Scrum-Teams Technische Methoden In Scrum verwendete Methoden der Arbeitsverwaltung

Artefakte

Scrum-Artefakte sollen so einfach wie möglich und nicht einfacher sein. Die von einem Scrum-Team gelieferten Anforderungen, Pläne und sogar Software sind besonders nützlich, wenn sie nur die zum Fertigstellen der Aufgabe benötigten Details enthalten.

Produktrückstand

In einer perfekten Welt gäbe es keine Notwendigkeit, Anforderungen zu erstellen, da die Menschen einfach miteinander reden. Die Person, von der die Software angefordert wird, würde von Natur aus von den Personen, die die Software erstellen, verstanden. Eine Zwischenform des Ausdrucks wäre nicht nötig. Dies ist zwar in sehr kleinen Teams mit enger Kundenbeziehung möglich, lässt sich aber in größerem Maßstab nicht umsetzen. Für die Planung ist es notwendig, vor der Lieferung von Funktionen entsprechende Anforderungen zu erstellen. Im Lean-Bereich werden Anforderungen zum Bestand gezählt, der in Lean Thinking allgemein als Verschwendung gilt, die minimiert werden sollte.

In Scrum werden Anforderungen im Produktrückstand verwaltet, der kaum eine Form oder Struktur vorgibt. Es ist nicht erforderlich, die Produktrückstands-Elemente sehr detailliert oder perfekt zu formulieren.

Zur Planung der Arbeit sind ein Produktrückstand und Anforderungen vonnöten. Die perfekte Verwendung besteht allerdings darin, Produktrückstands-Elemente mit einem kleinen Vorsprung vor dem Entwicklungsteam, das an diesen arbeitet, zu erstellen und anzupassen. Effiziente Scrum-Teams vermeiden es, Anforderungen im Produktrückstand zu erstellen, die möglicherweise niemals bearbeitet werden.

Sprint-Rückstand

In einer perfekten Welt gäbe es keine Notwendigkeit, zu planen. Ein Entwicklungsteam würde einfach die nächste Funktionsanforderung aus der Reihe bearbeiten und Kontext sowie Kosten der Anforderung ignorieren. Während dieses einfache Modell des Arbeitsablaufs sehr flexibel ist, berücksichtigt es jedoch nicht, dass es sich bei der Softwareentwicklung um ein grundsätzlich komplexes Unterfangen handelt. Bei der Entwicklung von Produkten mit erheblicher Komplexität ist es vorteilhaft, einen Plan zu haben, auch wenn dieser Plan einfach ist und keine Details enthält.

Im Scrum-Leitfaden wird der Sprintrückstand als Teilmenge der für einen Sprint ausgewählten Produktrückstands-Elemente und einem Plan für deren Lieferung definiert. Der Sprintrückstand zeigt einen Bestand (Verschwendung) der projektierten Arbeit für den Sprint an, der mindestens täglich angepasst wird. Diese tägliche Anpassung stellt sicher, dass der Plan niemals zu einem Versprechen wird, und sie ermöglicht es dem Entwicklungsteam, Implementierungsentscheidungen bis zum letztmöglich vertretbaren Zeitpunkt hinauszuzögern.

Um die Kosten zu minimieren, erstellen die Scrum-Teams Anforderungen und Pläne, die gerade noch ausreichend sind. Dieser Lean-Ansatz zur Bestandsminimierung sorgt dafür, dass Entscheidungen so spät wie möglich getroffen werden, und dass das Team sich im Sprint eigenverantwortlich organisiert. Die Scrum-Teams konzentrieren sich auf den Wert, der in den einzelnen Inkrementen geliefert wird, und nicht auf die Anforderungen oder den Plan.

Increment

Jeder Sprint enthält die Bereitstellung von mindestens einem funktionierenden Softwareinkrement. Dieses Produkt-Inkrement ist das einzige Scrum-Artefakt, das im Lean Thinking nicht als Verschwendung betrachtet wird. Dennoch kann sich auch im Produkt-Inkrement Verschwendung finden lassen. Die Verschwendung kann in Form von ungenutzten Funktionen, Fehlern, unvollständiger Funktionalität, aufwendig zu verwaltendem Code oder schlecht gestalteten Designs vorliegen.

Leistungsstarke Scrum-Teams beseitigen schonungslos Verschwendung im Produkt selbst. Dies geschieht oftmals durch häufiges Überprüfen der Inkremente während des Sprints, und indem jederzeit ein hoher Qualitätsstandard gehalten wird. Damit wird die Kernaussage des Lean-Prinzips zum Integritätseinbau realisiert.

Auch beim Liefern des Inkrements ist es für Scrum-Teams sinnvoll, die Lean-Prinzipien im Kopf zu behalten. Das Scrum-Framework selbst stellt sicher, dass ein Inkrement zum Zeitpunkt der Sprintüberprüfung für eine Überprüfung zur Verfügung steht. Im Rahmen der Sprintüberprüfung erhaltenes Feedback zum Sprint ist elementar, um das Lernen zu verstärken.

Rollen

Die in Scrum vorgegebenen Rollen sind sorgfältig ausbalanciert, damit das Scrum-Team Verantwortung erhält und Spannungen innerhalb des Teams abgefangen werden. Scrum-Master, Entwicklungsteams und Produktbesitzer arbeiten zusammen, um erfolgreich zu sein. Das heißt, jeder der Beteiligten muss auch die Perspektive der jeweils anderen kennen. Diese Zusammenarbeit gewährleistet, dass die Scrum-Teammitglieder das Gesamtbild des Scrum-Systems erkennen. Außerdem wird sichergestellt, dass jede Entscheidung, durch die eine Rolle der anderen vorgezogen und damit eine Schwächung des Scrum-Teams erfolgen würde, transparent ist.

Der Scrum-Mitentwickler Jeff Sutherland beschreibt die Bottom-up-Intelligenz und entscheidungsbefugte Mitarbeiter mit unterstützenden Managern als Basis der erfolgreichen Lean-Implementierung. Die sich selbst organisierenden Scrum-Entwicklungsteams verkörpern die entscheidungsbefugten Mitarbeiter von Lean Thinking, die in der Lage sind, das Lernen in der Organisation zu verstärken, anstatt zum Lernen gezwungen zu werden.

Die Rolle des Scrum-Masters ist einzigartig und wird im Scrum-Leitfaden folgendermaßen beschrieben:

Der Scrum Master ist dafür verantwortlich, dass Scrum verstanden und korrekt angewandt wird. Dies erreichen Scrum Master durch die Sicherstellung, dass das Scrum Team sich konform zur Scrum Theorie verhält und die gültigen Praktiken und Regeln einhält. Der Scrum Master ist eine dienende Führungskraft („servant-leader“) für das Scrum Team.Scrum-Leitfaden, Oktober 2011

Eine der Hauptkompetenzen und Hauptaktivitäten eines guten Scrum-Masters ist die Unterstützung. In den meisten Fällen unterstützen Scrum-Master die Scrum-Ereignisse. Scrum-Master sind Manager, ungeachtet der Scrum-Umsetzung und Scrum-Einhaltung, keine Personen.

Leaner Scrum

Die im Rahmen von Scrum auftretenden Probleme mit Lean Thinking zu überdenken und zu lösen, ist häufig ausgesprochen gewinnbringend und eine großartige Möglichkeit, eine Kaizen-Kultur zu pflegen. Scrum-Teams lernen immer noch, wie sie Lean in Scrum anwenden können. Viele Methoden haben inzwischen an Ansehen gewonnen, da sie nachweislich zu einer höheren Effektivität der Scrum-Teams führen.

Im Bereich Knowledge Work werden zahlreiche gängige Methoden und Verfahren eingesetzt, die Lean-Prinzipien direkt unterstützen. Einige dieser Verfahren werden nachfolgend erläutert, besonderes Augenmerk gilt dabei ihrer möglichen Umsetzung in einem Scrum-Team.

Die folgende Liste ist nicht vollständig, sondern gibt einfach Beispiele dafür, wie sich Scrum-Teams mithilfe von gängigen Verfahren, die auch von Lean-Anwendern genutzt werden, verbessern können. Darüber hinaus kann jedes dieser Verfahren auf verschiedene Weise angewendet werden. Hier werden nur einige Lean-Verfahren beschrieben. Scrum-Teams gehen die folgenden Szenarios möglicherweise anders an als in diesem Artikel beschrieben.

Vermeiden von Verschwendung

Möglicherweise ist das Vermeiden von Verschwendung das grundlegendste Lean-Prinzip. Bei Lean gilt alles als Verschwendung, was nicht unbedingt zum Erzielen des gewünschten Ergebnisses nötig ist. Bei der Softwareentwicklung werden die folgenden Punkte im Allgemeinen als Verschwendung betrachtet:

1. Ungenutzter Code und nicht benötigte Funktionen

2. Fehler, die zu Nacharbeiten führen

3. Verzögerungen oder Zeit, die mit Warten auf etwas verbracht wird

4. Übergaben zwischen Personen, Teams oder Geschäftsprozessen

5. Stark detaillierte Anforderungen

6. Unzureichende Anforderungen

7. Langsame oder mangelhafte Kommunikation

Ein bestimmtes Maß an Verschwendung lässt sich nicht vermeiden und ist sogar erforderlich. Nach der striktesten Definition gelten beispielsweise auch Anforderungsdokumente als Verschwendung. Eine Karteikarte, die eine Anforderung darstellt, wird am Ende nicht an den Kunden ausgeliefert. Daher ist die Karteikarte Verschwendung. Die Anforderungskarte selbst ist nicht die Produktfunktion, sie gibt Arbeitstätigkeiten an, die zum Erstellen der Funktion ausgeführt werden müssen. Die Anforderungskarte ist vorhanden, um Entwicklern zu helfen, ihre Arbeit zu durchdenken und nachzuverfolgen. Obwohl die meisten Teams dies als erforderliche Methode ansehen, lässt sie sich schnell als Verschwendung erkennen.

Einiges an Verschwendung ist nötig, aber ein Großteil kann verringert, optimiert oder sogar entfernt werden. Im Wertstrom der Softwareentwicklung findet sich Verschwendung, z. B. zu lange warten, um Code einzuchecken, die schnell erkannt und beseitigt werden kann. Andere Verschwendung findet in Softwareentwicklungsteams statt, so beispielsweise das Erstellen umfangreicher Anforderungsdokumente vor Entwicklungsbeginn. Dies hat sich als Kultur etabliert, eine solch fundamentale Änderung erfordert erheblichen Aufwand und Zeit.

Szenario

Scrum wird seit sechs Monaten angewendet. Die Entwicklungsteams erstellen in jedem der zwei Wochen andauernden Sprints funktionierende Softwareinkremente, und alle gemessenen Qualitätsindikatoren weisen einen positiven Trend auf.

Lean-Ansatz

In einer Besprechung erörtern die Scrum-Master das Coachen ihrer Teams mit dem Ziel höherer Produktivität und Qualität. Ein Scrum-Master schlägt vor, die Verschwendung gemäß Lean Thinking zu vermeiden. Alle einigen sich darauf, es zu versuchen. Die Scrum-Master suchen nach Beispielen für Verschwendung und kategorisieren sie in zwei Listen: Solche, die sofort vermieden werden können, und solche, bei denen es Zeit erfordert.

Die erste Liste enthält Verschwendungen, die entweder von den Scrum-Mastern selbst oder vom Entwicklungsteam beseitigt werden können und weder Genehmigungen noch Wartezeiten benötigen. Die zweite Liste wird als „Verschwendungsrückstand“ bezeichnet. Sie enthält die Verschwendungen, deren Vorhandensein von allen anerkannt wird, bei denen eine Änderung aber erheblichen Aufwand bedeutet oder viel Zeit in Anspruch nimmt. Beispiele der beiden Listen werden unten angezeigt:

Sofort vermeiden

Verschwendungsrückstand

Einige Builds werden manuell auf einem Buildcomputer ausgeführt, der speziell zu diesem Zweck verwaltet werden muss. Das Verpacken einer Website ist ein manueller ZIP-Prozess. Das wird automatisiert. Alle Entwickler arbeiten mit einer gemeinsam genutzten Entwicklungsdatenbank, und die Datenänderungen führen häufig zu Unterbrechungen im Entwicklungsfluss. Es wird zu einem Modell gewechselt, bei dem jeder Entwickler über eine dedizierte Entwicklungsdatenbank verfügt. Tests werden erst geschrieben, wenn eine Funktion vorhanden ist. Testgesteuerte Methoden werden unterstützt und Testspezialisten in deren Anwendung geschult.

Für alle Funktionen werden vor der Programmierung UML-Modelle erstellt. Die Kommunikation wird durch die Bürostruktur erschwert, bei der Mitglieder desselben Entwicklungsteams für kurze, spontane Gespräche zwischen den Büros hin und her laufen müssen. Wo möglich, werden Installationsprogramme eingeführt, damit möglichst keine manuellen Vorgänge bei der Bereitstellung nötig sind. Viele Felder im Berichtssystem für die Fehlerverfolgung sind erforderlich, werden aber selten genutzt. Die Zeit, die zum Erstellen der Daten für diese Felder aufgewendet wird, kann gespart werden, indem diese optional werden.

Bewaffnet mit diesen Listen treffen sich die Scrum-Master mit ihren jeweiligen Scrum-Teams und unterbreiten umsetzbare Vorschläge für unmittelbare Verbesserungen. Obwohl Scrum-Master ihre Teams für höhere Qualitätslevel coachen, erfordert es die selbstorganisierende Natur der Scrum-Teams, dass die Teams selbst den Wert der Änderungen erkennen und einen Plan zu deren Umsetzung ausarbeiten.

Die Sprintretrospektive ist ein dediziertes Forum, um Verbesserungsvorschläge auszutauschen und sich Unterstützung für deren Umsetzung zu sichern. Effektive Sprintretrospektiven führen häufig zu Plänen für die Umsetzung von Verbesserungen und unterstützen damit eine Kaizen-Kultur. Um die im Rückstand erfasste Verschwendung zu vermeiden oder zu verbessern, sind möglicherweise auch Aktivitäten außerhalb des Scrum-Teams nötig. Dies liegt in der Verantwortung des Scrum-Masters, dessen Aufgabe es ist, die Umsetzung von Scrum zu verbessern und Flexibilität in der gesamten Organisation zu fördern.

Begrenzen von in Bearbeitung befindlicher Arbeit

Szenario

Ein Entwicklungsteam mit fünf Mitgliedern nutzt Scrum seit 12 Wochen und hat drei Sprints mit jeweils vier Wochen Dauer mit gemischten Ergebnissen abgeschlossen. Obwohl die erstellten Inkremente eine höhere Qualität aufweisen als die vor der Scrum-Implementierung entwickelte Software, scheinen weniger Arbeitsaufgaben erledigt zu werden. Zudem arbeiten die Mitglieder des Entwicklungsteams immer noch nicht zusammen. Die tägliche Scrum-Besprechung enthält auch eine tägliche Erinnerung, dass die einzelnen Teammitglieder isoliert an den jeweiligen Aufgaben arbeiten, aber dennoch scheint sich die Situation nicht zu bessern.

Während der Sprintplanung erstellt das Entwicklungsteam eine Aufgabenliste mit den Arbeiten, die zur Lieferung der einzelnen, für den Sprint ausgewählten Produktrückstands-Elemente ausgeführt werden müssen. Mit diesem Verfahren wird im Rahmen der Sprintplanung ein Sprintrückstand erstellt, außerdem wird ein Mechanismus erzeugt, mit dem der Fortschritt des Entwicklungsteams über den gesamten Sprint nachverfolgt werden kann.

Das Entwicklungsteam verwendet ein an der Wand des Arbeitsbereichs gut sichtbar angebrachtes Taskboard, um die Fortschritte im Sprintverlauf zu verfolgen. Im letzten Sprint hat der Scrum-Master jeden Tag vor der täglichen Scrum-Besprechung Fotos vom Taskboard gemacht. Einige der Fotos werden unten angezeigt.

Tag 1	Tag 4
Tag 9	Tag 14
Tag 17	Tag 20

Der Scrum-Master zeigte diese Fotos dem Entwicklungsteam. Einiges war sofort offensichtlich, z. B.:

• Es sind mehr Aufgaben regelmäßig auszuführen, als Mitglieder im Entwicklungsteam sind.

• An Tag zwei zog ein Entwickler alle Aufgaben für Funktion C in den Status „In Bearbeitung“, wo sie während der Dauer des Sprints verblieben.

• Funktion B wurde bis zum Ende des Sprints nicht bearbeitet und auch nicht abgeschlossen.

• Funktion C wurde im Sprint bearbeitet, aber nicht abgeschlossen. Die an Funktion C arbeitende Entwicklerin war frustriert, weil sie keine Hilfe erhielt, als sie sich mit unbekannten Problemen konfrontiert sah. Trotz ihrer subtilen Hinweise in den täglichen Scrum-Besprechungen, dass sie dankbar für Hilfe wäre, erhielt sie keine. Die anderen Teammitglieder waren auf ihre eigene Arbeit konzentriert und fühlten sich nicht zuständig für Funktion C.

• Bei der Sprintplanung wurden die Funktionen im Sprintrückstand nach ihrer Priorität angeordnet. Der Produktbesitzer war folglich sehr enttäuscht, weil Funktion B im Sprint nicht fertig gestellt wurde, obwohl diese Funktion eine höhere Priorität aufwies als andere, gelieferte Funktionen.

• Bei einigen Funktionen wurde sofort mit der Bearbeitung begonnen, was dazu führte, dass sehr unterschiedliche Codeabschnitte gleichzeitig angepasst werden mussten. Während des Sprints verursachte dies einige Buildfehler und Nacharbeiten, da die Entwickler unwissentlich gegenseitig ihren Code beeinflussten.

Alle gemachten Beobachtungen laufen an der Methode des Entwicklungsteams, gleichzeitig an vielen verschiedenen Sachen zu arbeiten, zusammen. Die Mitglieder des Entwicklungsteams versuchten, zwischen den Aufgaben umzuschalten und sich auf viele Dinge gleichzeitig zu konzentrieren. Dadurch fühlten sie sich durch die Arbeitsaufgaben im Sprintrückstand überlastet und überfordert. Folglich konzentrierte sich jedes Teammitglied auf seine eigene Arbeit und handelte als Einzelperson, nicht als Mitglied eines Teams.

Lean-Ansatz

Bei der Sprintretrospektive erklärte der Scrum-Muster dem Entwicklungsteam das Konzept, die in Bearbeitung befindliche Arbeit zu begrenzen. Das Team beschloss, dieses Verfahren auszuprobieren. Das Entwicklungsteam entschied sich, drei neue Regeln umzusetzen, mit denen die in Bearbeitung befindliche Arbeit im nächsten Sprint verringert wird:

1. Funktionen im Sprintrückstand werden in der Reihenfolge von oben nach unten implementiert.

2. Es werden nicht mehr als drei Elemente auf einmal bearbeitet. Wenn ein viertes Element in Bearbeitung genommen wird, unterbricht das Team die Arbeit und ermittelt, warum es im System einen Engpass gibt.

Der Scrum-Master machte während des nächsten Sprints erneut Fotos. Einige Fotos werden unten angezeigt.

Tag 2	Tag 8
Tag 12	Tag 20

Wieder wurden die Fotos in der Sprintretrospektive vom Entwicklungsteam angesehen, das die folgenden Änderungen für das Team im letzten Sprint beobachtete:

1. Die Mitglieder des Entwicklungsteams arbeiteten gemeinsam an den komplexeren Elementen. Obwohl es manchmal unterschiedliche Meinungen gab, wie die Arbeit erledigt werden sollte, wurden diese Unstimmigkeiten ausgeräumt, und das Team machte insgesamt schnellere Fortschritte.

2. Die Mitglieder des Entwicklungsteams begannen, sich mit Produktfunktionen zu befassen, auf die sie sich zuvor nicht konzentriert hatten. Jedes Teammitglied beschrieb, für das Produkt als Ganzes ein Gefühl des Kollektiveigentums zu haben. Das bedeutete eine immense Entlastung im Vergleich zur vorigen Methode, bei der sich die Einzelpersonen ausschließlich auf die Funktionen konzentrierten, die sie verstanden.

3. Die komplexe Aufgabe, Änderungen in vielen unterschiedlichen Codeabschnitten koordinieren zu müssen, konnte drastisch reduziert werden. Und zwar so massiv, dass die Produktivität des Entwicklungsteams deutlich anstieg.

4. Zwar wurde Funktion E nicht innerhalb des Sprints abgeschlossen, aber alle gelieferten Funktionen wiesen eine höhere Priorität auf als Funktion E. Der Produktbesitzer war begeistert und entschied, das Inkrement auch ohne diese Funktion geringer Priorität an den Kunden auszuliefern.

Während der Sprintplanung einen Sprintrückstand zu erstellen, begrenzt die Batchgröße der für den Sprint ausgewählten Arbeit. Dennoch kann eine weitere Begrenzung der in Bearbeitung befindlichen Arbeit im Sprint zu einem schnelleren Durchsatz und höherer Produktivität führen. Zudem fördert eine Begrenzung der in Bearbeitung befindlichen Arbeit die Zusammenarbeit und senkt das Risiko, technische Spezialisten zu haben, deren Arbeit von anderen nicht verstanden wird.

Reduzieren von Wartezeiten

In der Softwareentwicklung wird viel Zeit damit verbracht, auf etwas zu warten. Diese Form der Verschwendung lässt sich bei den meisten Entwicklungsteams schnell finden. Neue Scrum-Teams warten auch während eines Sprints auf verschiedene Sachen, darunter:

• Genehmigung, um etwas Bestimmtes zu tun

• Abschluss eines langen Prozesses

• Übergabe von einem anderen Team oder einer Einzelperson

• Auszuführende Tests oder Validierungen, die abgeschlossen werden müssen

• Zugriff auf eine benötigte Ressource

• Kooperation von einer Person außerhalb des Teams

Noch schlimmer als die Untätigkeit von wartenden Scrum-Teams ist die Zeit, die Kunden und Unternehmen darauf warten müssen, dass Software integriert, verpackt und versendet wird. Dieses Problem nimmt mit der Größe der Entwicklungsorganisation zu. Je mehr Entwickler oder Teams an einem Projekt arbeiten, desto mehr erhöhen sich die Kosten der Integration ihrer Arbeit in ein einzelnes Produkt.

Die längste Wartezeit, die in Scrum möglich ist, ist der Sprint. Da der Sprint der Container für alle Scrum-Ereignisse ist, wird von der Sprintdauer nur gefordert, dass sie maximal einen Monat beträgt. Damit wird die Zeit, die mit Warten auf ein funktionierendes Softwareinkrement verbracht wird, auf maximal einen Monat begrenzt. Die meisten Scrum-Teams liefern sogar häufiger funktionierende Inkremente.

Szenario

Ein Unternehmen verfügt über sechs Scrum-Teams, die an einem großen und komplexen Softwareprodukt arbeiten. Jedes Scrum-Team konzentriert sich auf einen bestimmten Funktionsbereich, die Arbeit wird über einen Master-Produktrückstand koordiniert. Sprints dauern drei Wochen lang und schließen die Integration der Arbeit von allen Entwicklungsteams ein.

Vorher waren die Sprints zwei Wochen lang, aber mit zunehmender Größe des Produkts wuchs auch die Komplexität, es zu erstellen. Neue Scrum-Teams wurden hinzugefügt, die mehr Zeit benötigten, um ihre Arbeit zu integrieren. Um den Integrationsaktivitäten Rechnung zu tragen, wurden die Sprints verlängert.

Die dritte Sprintwoche wird nun allgemein als Integrationswoche bezeichnet. Die Hauptaktivität in diesem Zeitraum besteht in der Integration neuer Funktionen in die Hauptcodezeilen. Für jede Integrationswoche wird ein Integrationsteam zusammengestellt, in dem Mitglieder der einzelnen Entwicklungsteams vertreten sind. Sie leiten die Arbeit der Integrationsaktivitäten.

Während der Integrationswoche nimmt das Integrationsteam keine neuen Funktionen an, aber zur Behebung von Integrationsproblemen fordert es kleinere Änderungen an. Diese Anforderungen des Integrationsteams verursachen während der Integrationswoche ein Durcheinander von Ad-hoc-Codeänderungen.

Die folgende Grafik zeigt die typische Konfigurationsverwaltung während eines Sprints an. Die Entwicklungsteams erstellen zu Beginn der Sprints ihre eigenen Entwicklungsverzweigungen. Sie führen ihren Code am Ende der zweiten Woche zusammen. In der dritten Woche bearbeiten die Entwicklungsteams die nach Bedarf eingehenden Anforderungen des Integrationsteams.

Die Integration muss zwar während des Sprints erfolgen, aber dennoch wird ein Drittel der Kapazität aller sechs Scrum-Teams durch diese Integration gebunden. Während dieser Zeit wird viel Kapazität der Teams für Aktivitäten außerhalb des Sprints verwendet. Wie Sie im obigen Beispiel sehen, hatte Team 5 während der Integrationswoche überhaupt keine Arbeitsaufgaben.

Die Kosten der Integrationswoche steigen aufgrund der Arbeitsunterbrechung in den Scrum-Teams, die häufig im Kontext wechseln müssen. Einige Teams versuchen, in der Woche produktiv zu sein, indem sie alleine Codezeilen verzweigen und gabeln. Das wiederum erhöht die Gesamtkomplexität und untergräbt die Transparenz, die für eine gute Entscheidungsfindung benötigt wird.

Lean-Ansatz

Die Scrum-Master für die Teams besprechen die Optionen. Ein Scrum-Master legt dar, dass das Team in den ersten beiden Wochen der Sprints recht erfolgreich bei der Begrenzung der in Bearbeitung befindlichen Arbeit ist. Wenn jedes Team die in Bearbeitung befindliche Arbeit auf eine Funktion zurzeit begrenzen würde, könnte es möglicherweise die Arbeit bereits direkt nach Fertigstellung der jeweiligen Funktion integrieren, stellen die Scrum-Master fest.

Wenn dieses Verfahren von allen Entwicklungsteams eingesetzt werden könnte, würde kein Team mit der Integration der Arbeit bis zum Ende der zweiten Woche warten. Anstatt nun darauf zu warten, die neuen Funktionen zu integrieren, könnte jedes Team überlegen, gemäß der „Definition of Done“1 (DoD, Definition von„fertig“) die Integration in den Hauptcodezeilenabschnitt für jede Funktion vorzunehmen, sobald diese funktioniert.

In Scrum ist die „Definition of Done“ ein Konzept, bei dem die Entwicklungsteams sich auf Punkte einigen, die für jedes der für den Sprint ausgewählten Produktrückstands-Elemente erfüllt sein müssen, damit dieses Element als „fertig“ angesehen wird. Weitere Informationen über die „Definition of Done“ finden Sie im MSDN-Artikel Fertig und unfertig.

Während der folgenden Sprintretrospektiven verständigen sich die Entwicklungsteams darauf, dass sie versuchen möchten, die einzelnen Funktionen nach ihrer Fertigstellung zu integrieren. Die folgenden neuen Regeln werden von den Teams festgelegt und befolgt:

1. Jedes Entwicklungsteam begrenzt die in Bearbeitung befindliche Arbeit auf eine Funktion zurzeit.

2. Eine Funktion ist erst abgeschlossen, wenn sie in die Hauptcodezeilen integriert ist.

3. Bevor mit der Arbeit an einer neuen Funktion begonnen wird, aktualisieren die Entwicklungsteams ihre Codezeilen mit einer aktuellen Version des Hauptcodekorpus.

Die daraus folgende Aktivität wird in der Grafik dargestellt:

Aufgrund der neuen Regeln haben die Teams einen reibungsloseren Ablauf bei der Funktionslieferung festgestellt. In der dritten Sprintwoche müssen die Entwicklungsteams nicht mehr untätig und einzeln warten, da es keine Integrationswoche mehr gibt.

Zunächst nimmt das Integrieren der Änderungen im Sprint mehr Zeit in Anspruch. Aber nachdem das Modell der kontinuierlichen Integration vertrauter geworden ist, weist jedes einzelne Entwicklungsteam eine höhere Produktivität auf. Im Laufe der Zeit erhöht sich die Anzahl von im Sprint hinzugefügten Funktionen.

Mit einer Funktion „fertig“ zu sein, bedeutet nun, dass diese Funktion in die Hauptcodezeilen integriert ist. Daher stellt sich auch nicht länger die Frage, ob eine Funktion wirklich fertig gestellt ist. Die Integration der einzelnen Funktionen in den Hauptcodekorpus ist jetzt in die „Definition of Done“ eingebunden. Das Risiko einer fehlerhaften Integration ist erheblich verringert worden.

Am Ende hat die Entscheidung, die Zeitspanne zu reduzieren, die ein Entwicklungsteam auf die Codeintegration warten muss, zu einer Steigerung der allgemeinen Produktivität der Entwicklungsteams geführt und die Integrationswoche überflüssig gemacht. Somit können die Scrum-Teams möglicherweise zu kürzeren Sprints zurückkehren, sodass der Produktbesitzer gegebenenfalls häufiger ausliefern kann.

Verzögern von Festlegungen

Das Verzögern von Festlegungen zählt zu den ursprünglichen Lean-Prinzipien, die als Wert für Lean Software Development aufgestellt worden sind. Dieses Prinzip wird häufig auch als „bis zum letzten vertretbaren Zeitpunkt warten“ beschrieben.

Die zugrunde liegende Denkweise ist die Folgende: Es bringt wenig bis keinen Wert, eine Entscheidung zu treffen, die einen frühzeitig auf eine bestimmte Vorgehensweise festlegt. Warum also nicht warten, bis die Entscheidung getroffen werden muss, damit bis dahin die größtmögliche Menge an Informationen zu diesem Thema bekannt ist? Dadurch verringert sich das Risiko einer Fehlentscheidung, und es wird mehr Zeit gegeben, damit sich weitere Optionen oder Aktionsmöglichkeiten eröffnen können.

Szenario

Während der Sprintplanung erstellt das Entwicklungsteam detaillierte Pläne, wie die für den Sprint ausgewählten Produktrückstands-Elemente implementiert werden sollen. Häufig wird dieser Plan während des Sprints geändert, da weitere Informationen in Erfahrung gebracht werden. Das Team stellt fest: Je unklarer die Arbeit, desto mehr ändert sich der Plan. In dem Wissen, dass ungenutzte Anforderungen zu Verschwendung zählen, möchte das Team diese Planungsnacharbeiten vermeiden.

Sich auf eine Vorgehensweise festzulegen, bedeutet, andere Optionen zu verwerfen. Häufig führt das dazu, dass andere Ideen aufgrund der Festlegung nicht verfolgt werden. Es gibt mehrere Möglichkeiten, eine bestimmte Funktion zu implementieren. Wenn jedoch bereits eine Vorgehensweise gewählt wurde, denken die Entwickler womöglich nicht mehr über andere Methoden nach, ein Problem anzugehen. Damit sinkt auch das Innovationspotenzial.

Lean-Ansatz

Das Entwicklungsteam entscheidet, größere und weniger definierte Elemente in den Sprintrückstand aufzunehmen. Das Team legt sogar fest, dass auch ein Produktrückstands-Element gänzlich ohne detaillierten Plan im Sprint zulässig ist.

Nun wartet das Entwicklungsteam mit dem Erstellen des detaillierten Plans, bis weitere Informationen vorliegen. Für das Team bedeutet dies, wenn die Arbeit tatsächlich beginnt oder im Gange ist, muss das große Produktrückstands-Element in kleinere Teile aufgebrochen werden. Dadurch wird die Detailplanung so lange verzögert, bis sie wirklich gebraucht wird. Das gibt dem Team die Möglichkeit, mit dem Näherrücken der Implementierung auch andere Wege für diese zu berücksichtigen. Außerdem ist so gewährleistet, dass der bestmögliche Plan ausgeführt wird (und nicht einer, der möglicherweise schon keine Gültigkeit mehr hat).

Das führt zu einer besseren Kenntnis der Implementierungsoptionen zum Zeitpunkt der Funktionsimplementierung. Das Entwicklungsteam hat bei der Implementierung vorheriger Funktionen im Sprint viel über das Produkt gelernt, und es hat nun bei Bedarf Zeit für Überprüfungen eingeräumt.

Visualisieren des Workflows

Der erste Schritt in der Kanban-Methode erfordert das Visualisieren des Workflows, der tatsächlich im Team stattfindet. Damit wird das Lean-Prinzip „das Ganze sehen“ realisiert, bei dem der tatsächliche Workflow abgebildet werden muss. Eine idealisierte Version, die von einem Geschäftsprozessdokument oder einem anderen vorhandenen Modell vorgeschrieben wird, ist nicht erwünscht. Eine sinnvolle Visualisierung stellt dar, was tatsächlich passiert.

Sobald die Arbeitsvisualisierung vorhanden ist, kann die Arbeit darin nachverfolgt werden. Ein Beispielmodell eines Entwicklungsprozesses mit typischem Stage-Gate-Modell oder üblicher Wasserfall-Methode und mehreren in Bearbeitung befindlichen Funktionen wird nachstehend angezeigt.

Um die Arbeit des Sprints zu sehen, nutzen Scrum-Teams seit Jahren die Workflowvisualisierung. Die häufigste Nutzungsform der Workflowvisualisierung in Scrum-Entwicklungsteams ist das „Scrum-Taskboard“ oder einfach „Scrum-Board“. Diese Visualisierung ist in der Regel einfacher als das oben gezeigte Modell, und es entspricht möglicherweise dem folgenden Modell.

Diese typische Form der Workflowvisualisierung wird stark von den in Scrum vorgeschriebenen funktionsübergreifenden Entwicklungsteams beeinflusst. Der gesetzte Schwerpunkt auf funktionsübergreifende Entwicklungsteams ist ein Hauptmerkmal des Scrum-Frameworks. Ein funktionsübergreifendes Team verfügt über alle Kompetenzen, die es zum Liefern eines vollständigen und funktionierenden Softwareinkrements in den einzelnen Sprints benötigt. Die Teammitglieder führen bei der Softwareentwicklung zahlreiche Aktivitäten gleichzeitig aus.

Funktionsübergreifende Teams übernehmen bei der gemeinsamen Implementierung einer Funktion möglicherweise ein bisschen von allem. Das unterscheidet sich erheblich vom plangesteuerten Modell, bei dem sich die Spezialisten darauf konzentrieren, alle Schritte einer Aktivität auszuführen. Die Mitglieder von funktionsübergreifenden Teams verfügen natürlich über Spezialkenntnisse, aber alle Teammitglieder arbeiten regelmäßig an allen Aktivitäten, die zum Liefern der Software erforderlich sind, und zwar unabhängig davon, ob diese Aktivitäten in den Spezialbereich des Teammitglieds fallen. Funktionsübergreifende Softwareentwicklungsteams neigen dazu, eine bessere Leistung zu erbringen als Teams mit ausgewiesenen Spezialisten.

Szenario

Ein Entwicklungsteam liefert funktionierende Softwareinkremente, aber die Teammitglieder arbeiten nicht gut zusammen. Die Programmierer arbeiten alleine an Problemen, bevor sie Codeabschnitte an die Tester übergeben, die zum Ende des Sprints in Eile die Validierung durchführen müssen.

Damit bleibt am Ende des Sprints nur wenig Zeit zum Testen, sodass das Entwicklungsteam diese Phase manchmal auslässt und das Inkrement mit unvollständigen Regressionstests liefert. Hätte das Team die Regressionstests für die Funktion vollständig ausgeführt, wären Fehler, die nun im laufenden Betrieb auftreten, viel früher behoben worden.

Lean-Ansatz

Der Scrum-Master arbeitet mit dem Entwicklungsteam, um den tatsächlichen Workflow der einzelnen Sprints zu modellieren. Obwohl das Team in der täglichen Scrum-Besprechung mit einem Scrum-Board arbeitet, wird schnell offenbar, dass es sich bei dem tatsächlichen Workflow um einen Prozess nach dem Stage-Gate-Modell handelt. Das Team erzeugt das folgende Modell, das den tatsächlichen Workflow widerspiegelt:

Der Scrum-Master hilft dem Team, die potenzielle Produktivitätssteigerung nachzuvollziehen, die durch eine funktionsübergreifende Arbeitsweise entsteht. Obwohl sie Zweifel haben, stimmen die Teammitglieder zu. Sie möchten versuchen, ihren Workflow zu verbessern, damit sie funktionsübergreifender arbeiten.

Das Entwicklungsteam belässt die Visualisierung unverändert und nutzt sie, um die Arbeit im Sprint zu überwachen, achtet jedoch auf jede sich bietende Möglichkeit, um die Phasen zu reduzieren. Das heißt, das Team schaut, ob zwei Phasen vielleicht zu einer zusammengefasst werden können, um so eine Übergabe durch Zusammenarbeit zu ersetzen. Dies wird in jeweils kleinen Schritten umgesetzt, indem absichtliche Änderungen an der Art und Weise der Zusammenarbeit der Mitglieder im Entwicklungsteam vorgenommen werden. In jeder Sprintretrospektive wird das Modell überarbeitet, um die vom Team erreichten Verbesserungen abzubilden.

Zuerst einigen sich Arnie und Kyle darauf, beim Zusammenführen der Entwurfs- und Programmierphasen zusammenzuarbeiten. Sie probieren mehrere Verfahren zur Verbesserung der Zusammenarbeit und stellen schnell fest, dass sich ihr Workflow folgendermaßen geändert hat:

Dieses Entwicklungsteam lernt schnell, nicht bestandene Regressionstests für Funktionen vor der Codeimplementierung zu erstellen, was zu den folgenden Änderungen führt:

In den kommenden Monaten sucht das Entwicklungsteam nach Möglichkeiten, um die Anzahl von Phasen in der Lieferpipeline zu reduzieren. Die Kultur des Teams ändert sich tatsächlich, als Spezialisten ihre Kenntnisse mitteilen und jeder einspringt, damit der Workflow des Teams reibungsloser verläuft. Mit zunehmender Zusammenarbeit beginnen die Teammitglieder, sich selbst als „spezialisierte Generalisten“ zu sehen.

Durch die erhöhte Zusammenarbeit des Teams verstärken sich auch die gemeinsamen Kenntnisse über die zu erstellende Software sowie die Einblicke der einzelnen Teammitglieder in die Verantwortungsbereiche der anderen. Aufgrund dieser Zusammenarbeit reduzieren sich auf natürliche Weise die Arbeitsphasen im Sprint, was sich in einer einfacheren Visualisierung des im Sprint vorhandenen Workflows ausdrückt. Das Entwicklungsteam arbeitet nun funktionsübergreifend und bildet den tatsächlichen Workflow entsprechend ab, wie nachfolgend dargestellt.

Die schrittweise Herangehensweise des Teams beim Reduzieren der Prozessphasen führte letztlich zu einem Workflow, den Scrum als erstes vorschreibt, nämlich eine einzige Entwicklungsphase in Bearbeitung. Das zeigt, wie sich ein vollständig optimiertes Kanban-Board am Ende als herkömmliches Scrum-Board erweist.

Einbauen von Integrität

Viele Verfahren in der Softwareentwicklung konzentrieren sich auf den Einbau von Integrität in den Erstellungsprozess. Softwareentwurfsmuster, testgesteuerte Programmierverfahren, Umgestaltung und Paarprogrammierung dienen alle dazu, die Qualität der Software zum Zeitpunkt ihrer Erstellung zu erhöhen. Der Einsatz von Verfahren, mit denen die Qualität frühzeitig im Erstellungsprozess verbessert wird, gewährleistet, dass sich die Teams nicht auf eine nachträgliche Qualitätsprüfung zum späteren Testen der Qualität verlassen.

Szenario

Ein Entwicklungsteam hat mit testgesteuerten Programmierverfahren experimentiert. Es arbeitet nun erfolgreich mit dem Gegeben/Wenn/Dann-Ausdruck (Given/When/Then) der Akzeptanzkriterien in Komponententests, die von Entwicklern während der Entwicklung erstellt werden.

Format der Akzeptanzkriterien Gegeben/Wenn/Dann
Gegeben <ursprünglicher Kontext> Wenn <Aktion geschieht> Dann <dies ist das Ergebnis>

Das Team hat gute und lesbare Komponententestsammlungen, die von Entwicklern zum Entwerfen und Testen von Code in einer automatisierten Testumgebung benötigt werden.

Obwohl dieser Ansatz auf Ebene der Komponententests funktioniert, nutzen die Testspezialisten des Entwicklungsteams nach wie vor Microsoft Word-Dokumente zum Erstellen der Akzeptanzkriterien für funktionale Tests. Diese werden manuell überprüft, wenn die Funktionen programmiert und abgeschlossen sind. Da diese Tests erst ausgeführt werden, wenn die Programmierer der Ansicht sind, dass eine Funktion abgeschlossen ist, werden von den Testspezialisten zahlreiche Fehler gefunden. Dies verursacht Nacharbeiten innerhalb des Sprints und führt manchmal dazu, dass Funktionen nicht vor der Sprintüberprüfung abgeschlossen werden.

Lean-Ansatz

Beim Besprechen des Workflows für Akzeptanzkriterien in der Sprintretrospektive entscheidet das Entwicklungsteam, Folgendes zu versuchen:

1. Die Testspezialisten erstellen die Akzeptanzkriterien nicht als Microsoft Word-Dokumente, sondern als automatisierte Fehlertests ohne interne Implementierung.

2. Diese neuen automatisierten Tests werden täglich um 05:00 und 15:00 Uhr ausgeführt und erzeugen einen Bericht der bestandenen und nicht bestandenen Tests. Neu erstellte Tests schlagen immer fehl.

3. Wenn Programmierer eine neue Funktion auswählen, um daran zu arbeiten, beginnen sie mit der Implementierung der Funktionalität des gekürzten Akzeptanztests.

4. Der Test kann vom Programmierer verfeinert werden; jedoch sollte dies in Zusammenarbeit mit dem Testspezialisten geschehen, der den Test erstellt hat, damit der ursprüngliche Zweck des Tests erhalten bleibt.

5. Die Funktion ist erst abgeschlossen, wenn der Test bestanden ist.

6. Alle Tests müssen am Ende des Sprints bestanden werden.

Nach einigen Sprints, in denen dieses Verfahren angewendet wurde, sind Fehler und Nacharbeiten zurückgegangen. Das Entwicklungsteam überwacht den Bericht, der von den zweimal täglich automatisch ausgeführten Testläufen aktualisiert wird. Das Team stellt fest, dass bestandene und nicht bestandene Tests als Trend darstellbar sind. Es wird ein Bericht erstellt, der mit jedem automatisierten Testlauf aktualisiert wird. Dieser Bericht zeigt die bestandenen und nicht bestandenen Akzeptanztestergebnisse als Trend für die Dauer des zweiwöchigen Sprints an. Die Grafik wird unten angezeigt.

Das Entwicklungsteam erkennt, dass es sinnvoller ist, anstelle des üblichen Burndown-Diagramms diesen Bericht in der täglichen Scrum-Besprechung durchzugehen. Der Scrum-Master bestätigt, dass diese neue Grafik als wichtiges Element des Sprintrückstands fungieren kann.

Im Scrum-Leitfaden wird angegeben, dass der Sprintrückstand die Menge der für den Sprint ausgewählten Produktrückstands-Elemente sowie einen Plan für deren Lieferung umfasst. Für dieses Entwicklungsteam wird der Plan nun aus nicht bestandenen Akzeptanztests erstellt. Fortschritte in Bezug auf den Abschluss werden nachverfolgt, indem die Anzahl von bestandenen und nicht bestandenen Tests als Trend dargestellt wird. Wie bei verwendeten Aufgaben im Sprintrückstand können auch Tests im gesamten Verlauf des Sprints hinzugefügt, gelöscht oder ergänzt werden. Häufig wird ein bestimmter Test einige Tage vor der zugehörigen Funktion implementiert.

Dass tatsächlich automatisierte Tests als Voraussetzung und Mechanismus für funktionale Regression verwendet werden, bedeutet, dass die Tests die Anforderungen sind. Damit wird die Arbeit im Sprint als Entwicklungsfortschritt hin zum Bestehen der automatisierten Tests betrachtet. Dieses testgesteuerte Programmierverfahren hat die Denkweise des Teams in Bezug auf die Verwendung von Scrum verändert und dafür gesorgt, dass die Anforderungsvalidierung direkt in den Erstellungsprozess selbst einfließt – somit wird Integrität in das Produkt eingebaut.

Viele Aspekte des ungemein populären Scrum-Frameworks unterstützen Lean-Prinzipien. Je mehr die Scrum-Teams reifen und sich verbessern, desto häufiger finden sie in Lean Thinking ein effektives Tool, das mehr Wert in iterativer und inkrementeller Entwicklung bietet.

Spezielle Verfahrensweisen mögen kommen und gehen, aber die beständige Konzentration auf Verbesserung ist immer entscheidend, um gut funktionierende Teams für die Softwareentwicklung zu haben. Das Scrum-Framework ist flexibel genug, um Lean-Verbesserungsmethoden ebenso wie Kanban-Methoden aufzunehmen. Scrum aus dem Lean Thinking-Blickwinkel zu betrachten, führt häufig zu besserer Qualität, höherer Produktivität und weniger Verschwendung.

Die Scrum-Implementierung eines Teams absichtlich optimieren zu wollen, kann sich als heikel erweisen. Wenn Sie nach Verbesserungsmöglichkeiten suchen, achten Sie darauf, dass „perfekt“ nicht zum Feind von „gut genug“ wird. Die Perfektion von Scrum ist deutlich weniger wichtig, als funktionierende Software mit hoher Qualität zu liefern, die von den Kunden wertgeschätzt wird. Zuerst sollten Sie sich also auf die Elemente konzentrieren, die eine echte Verbesserung des Produkts bedeuten.

Verweise

1. West, D. (2011). XXXXX. Forrester Research

2. Poppendieck, M. P. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional.

3. Anderson, D. (2010). Kanban: Evolutionäres Change Management für IT-Organisationen. dpunkt.