Softwareentwicklung, Scrum und Lean Thinking

In vielen Diskussionen über agile Softwareentwicklung hört man häufig den Begriff Scrum in Verbindung mit Lean Softwareentwicklung. Es handelt sich hierbei um ein sehr effizientes Hilfsmittel um die Planung, Überwachung und Ausführung von Aktivitäten im Rahmen der Softwareentwicklung  effektiv durchzuführen.

Sehen wir uns das Scrum-Framework näher an. Scrum ist ein schlankes Framework, welches die Iterativ-inkrementelle Arbeit forciert. Durch die Auslieferung von potentiell auslieferbarer Funktionalität in kurzen Abständen ermöglicht Scrum frühes Kunden-Feedback. Einfache und klare Regeln sowie eindeutige Rollen vermeiden unnötigen Overhead. Stringentes Einhalten von sogenannten  Zeit-Boxen für die Entwicklungszeit (den so genannten Sprints) als auch für die vorgesehenen Meetings, sowie ein starker Fokus auf Qualität, Effektivität und Effizienz zeichnen Scrum aus.

Das Framework selbst  ist im „Scrum-Guide“ festgeschrieben, in dem auch die Scrum-Rollen, -Artefakte und -Ereignisse dokumentiert sind. Der „Scrum-Guide“ wurde von den beiden „geistigen Vätern“ von Scrum, Dr. Jeff Sutherland und Ken Schwaber erstellt und ist auf den Webseiten der Scrum.org und Scruminc online verfügbar.

Zum Scrum-Framework hinzu kommt das Bestreben, Lean Thinking zu betreiben. Im Bereich der Softwareentwicklung verkörpert Lean Thinking die folgenden sieben Prinzipien, die zuerst im Buch Lean Software Development von Mary Poppendieck und Tom Poppendieck beschrieben wurden:

  • Verschwendung vermeiden
  • Lernen verstärken
  • So spät entscheiden wie möglich
  • So früh ausliefern wie möglich
  • Eigenverantwortung für das Team
  • Integrität einbauen
  • Immer das Ganze sehen

Es ist sicher nicht das endgültige Ziel, alle Lean Prinzipien auf die Softwareentwicklung zu „mappen“, sondern es wird vielmehr versucht die Lean Prinzipien als „Blue Print“ bei der Auswahlsentscheidung von Prozessen und Methoden, die eine Verbesserung des Gesamten nach sich ziehen, zu verwenden.  So wird zum Beispiel beim Einsatz von Test getriebener Entwicklung die Integrität frühzeitig in die Software eingebaut, indem das Product bzw. Teile davon gleich bei der Erstellung überprüft wird und nicht erst im Nachgang. Dies entspricht dem Lean Prinzip des Integritätseinbau.

Scrum und die Vermeidung von Waste

Eines der grundlegendsten Lean-Prinzipien ist das Vermeiden von Verschwendung. 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 (Overproduction)

2.       Fehler, die zu Nacharbeiten führen (Defects)

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

4.       Wissensverlust bei Übergaben zwischen Personen, Teams oder Geschäftsprozessen (Transportation)

5.       Nicht “Fertige” Software (Inventory)

6.       Multitasking (Motion)

7.       Prozesse ohne Wertschöpfung z.B. Stark detaillierte Anforderungen (Over-Proceeding)

Als Beispiel mögen die Anforderungen als Verschwendung im klassischen Entwicklungsprozess im Vergleich zu Scrum dienen. Betrachtet man Anforderungsdokumente in klassischen Entwicklungsprozessen wie z.B. im Wasserfallmodell so sind die Anforderungen in diesen Dokumenten im Vorfeld der eigentlichen Entwicklung zu 100% zu spezifizieren. In Scrum erstellt man die Anforderungen nur soweit im Detail, wie man in etwa abschätzen kann, wie diese in einer hohen Wahrscheinlichkeit zeitnah umgesetzt werden. Dies sind in der Regel zwei bis drei Sprints im Voraus. Die restlichen Anforderungen sind zwar bereits bekannt und in den allermeisten Fällen auch schon grob geschätzt, aber sie haben noch keinen 100% Detaillierungsgrad.

 Ein weiteres Beispiel für Verschwendung ist, dass in der Softwareentwicklung viel Zeit damit verbracht wird, auf etwas zu warten. Dieses Problem nimmt mit der Größe der Entwicklungsorganisation zu. Je mehr Entwickler oder Entwicklerteams an einem Produkt arbeiten, umso aufwändiger wird die Integration ihrer Arbeit in ein einzelnes Produkt.  Die längste Wartezeit, die in Scrum möglich ist, ist die Sprintlänge. Üblicher Weise ist diese Sprintlänge nicht länger wie maximal ein Monat. Damit ist die Wartezeit auf ein funktionierendes Softwareinkrement , auf maximal einen Monat begrenzt. Die meisten Scrum-Teams liefern sogar häufiger funktionierende Inkremente.

Scrum und Kaizen

Nach jedem Sprint, sprich nach jeder Interation in der am Ende ein Teil potentiell auslieferbarer Software geliefert wurde, führt jedes Scrum-Team eine Retrospektive durch. In der Retrospektive reflektieren die Teams, was lief in diesem Sprint besonders gut und wo können wir uns noch verbessern. Sprich die Teams suchen kontinuierlich nach neuen Möglichkeiten um sich selbst bzw. ihre Prozesse etc.  zu verbessern. Diese Idee der Retrospekive und der kontinuierlichen Verbesserung spiegelt das Kaizen Prinzip wieder, dass wir aus den Lean Prinzipien kennen.

Viele Scrum Teams ergänzen das eigentliche Scrum-Framework um Verfahren und Methoden die man aus dem Lean Thinking kennt. Es überrascht daher nicht, dass bereits einige Scrum-Teams eine bessere Effektivität und Qualität realisiert haben, indem sie Lean Thinking in ihr Scrum-Framework einbezogen haben.

Wer mehr über Scrum in Verbindung mit Lean Thinking erfahren möchte kann dies in einen unserer Scrum Zertifizierungskurse tun. Sie finden diese unter www.scrum-events.de

Advertisements

Ein Gedanke zu “Softwareentwicklung, Scrum und Lean Thinking

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s