Wir mögen hier bei SoftwareLiefern.de keine dogmatischen Methodik-Debatten. Wir wollen viel mehr wissen, welche Prinzipien man in den gängigen Methodiken beobachten und in der jeweiligen Situation anwenden kann. Daher finde ich es interessant, Scrum einmal durch die Lean-Brille zu betrachten: Wo kann man in Scrum bekannte Prinzipien aus dem Lean Thinking wiederfinden?
Sprints: Es wird iterativ in kurzen Zeiträumen entwickelt, am Ende des Sprints hat man eine benutzbare und zumindest potenziell auslieferbare Software. Das entspricht dem Prinzip “Limited WIP” (work in process): wenn ein Sprint z.B. zwei Wochen lang ist, dann wird maximal Arbeit für zwei Wochen angefangen sein. Die Anzahl User Stories, die wir gerade in Bearbeitung haben, ist also immer begrenzt. Das hat bekannt günstige Auswirkungen, u.a. kürzere Feedback-Zyklen, damit bessere Qualität und weniger Nacharbeit.
Sprint Backlog: Das Team legt am Anfang des Sprints fest, woran gearbeitet wird, neue Wünsche müssen sich hinten anstellen, bis sie beim nächsten Sprint Planning Meeting priorisiert werden. Das entspricht dem Konzept “Flow”, d.h. die Arbeit schreitet fort ohne größere Unterbrechungen und Verzögerungen.
Selbst-organisiertes Team: Die Leute, die die Arbeit tun, wissen am meisten darüber, wie es am besten geht. Daher sollten wir ihnen möglichst viele Entscheidungen überlassen. Das entspricht den Lean-Prinzipien “Respect for People” und “Go and See”, d.h. dass man die Leute fragt, und nicht vom grünen Tisch aus entscheidet.
Retrospektiven: Am Ende jeder Iteration wird reflektiert, wie der Entwicklungsprozess verbessert werden kann. Das ist ein Beispiel für kontinuierliche Verbesserung (Kaizen). Scrum legt allgemein großen Wert auf “inspect and adapt”, kurzfristig im Daily Scrum, längerfristig in den Retrospektiven. Mit der Rolle des Scrum Masters gibt es jemanden, dessen Aufmerksamkeit auch auf die kontinuierliche Verbesserung gerichtet sein sollte.
Definition of Done: Das Team hat ein gemeinsam erarbeitetes Verständnis davon, was “fertig” genau heißt. Dazu kann für Web-Applikationen z.B. gehören, dass die Seitenladezeit unter einer Sekunde ist, und dass alles auf den gängigen Browser-Versionen (einschließlich mobil) funktioniert. Dazu gibt es bei Lean das Konzept “Standard Work”, das u.a. beinhaltet, dass klare Qualitätskriterien vorgegeben sind. Damit vermeidet man Qualitätseinbußen, unnötige Zeitverluste und Nacharbeiten.
Eine frühe Darstellung der Parallelen zwischen Lean und Agile gibt’s übrigens in dem Klassiker von Mary und Tom Poppendieck: Lean Software Development, An Agile Toolkit. Ein historischer Überblick (Stand 2015) ist in dem langen Essay Lean Software Development: The Backstory.
Ich glaube, dass die Betrachtung aus der Lean-Perspektive ganz aufschlussreich sein kann: Wenn Scrum nicht funktioniert, wird oft nur geraten, die empfohlenen (vorgeschriebenen) Praktiken besser einzuhalten. Lean gibt einem ein paar mehr Denkwerkzeuge, um Probleme richtig einzuordnen und den Software-Lieferprozess über den von Scrum vorgegebenen Rahmen hinaus zu verbessern.
So kann man zum Beispiel fragen:
Matthias Berth