Niko Zimmermann

In der agilen Community ist längs angekommen, dass wir Metriken benötigen, um den Erfolg unserer agilen Initiative in den Teams und im Unternehmen zu messen. Das gilt für Scrum- und Kanban-Teams gleichermaßen.

Nicht alle Liegezeiten im Wertstrom sind schlecht. Denken Sie zum Beispiel an einen Bäcker, der sicherlich nicht für ein einziges Brötchen den Ofen anschmeißen würde.

Genauso ist es mir egal, ob Sie im Scrum Projekt alle 2 Wochen releasen oder nur 2 mal im Jahr, zum Beispiel rechtzeitig zur halbjährlichen Messe. Was ist daran ein Problem? Für mich rein gar nichts, weder bei Scrum, Kanban oder Wasserfall. Oder Sie sammeln beispielsweise Arbeitspakete, die Sie dann regelmäßig abarbeiten. Das nennt man in Scrum den Sprint.

Stapel vor einen Sprint Board, ob im Sprint Backlog, fertige Builds vor Auslieferung (Deployment) ... alles für mich gut.

Richtig ist aber auch, dass diese bewusst geschaffenen Puffer, end-to-end betrachtet, von der Idee bis zum Kunden, die Time-to-Market erhöhen. Sie werden wissen, warum Sie es tun. Und wenn Ihnen das zu lang ist, dann verkürzen Sie halt den Sprint, die Release-Zyklen und welchen Stapel Sie sonst noch in Betracht ziehen. Dies sind die guten Liegezeiten, nämlich geplante oder neudeutsch "committete" Stapel. Wie gesagt, Sie werden schon wissen, warum Sie den Ofen nicht für ein Brötchen anschmeißen.

Mein Fokus liegt aber und zwar nicht nur in diesem Blog, sondern in jedem meiner Projekte, auf den versteckten Liegezeiten, den ungewollten, nicht geplanten Liegezeiten. Die möchten wir auf alle Fälle reduzieren.

Teams fokussieren zuallererst ihre eigene Softwareentwicklung im Team und die Qualität als Teil des Ganzen. Wenn diese Teams lange genug mit Scrum oder Kanban agil arbeiten, können sie erstaunliche Optimierungen ihrer Arbeitsweise erreichen. Zum Beispiel durch regelmäßige Retrospektiven.

ABER, ... zehn optimierte Teams im gemeinsamen Erstellungsprozess des Produktes ergeben noch nicht unbedingt eine bessere Time-to-Market. Warum? Weil eine lokale Optimierung der einzelnen Teams nichts bringt, sobald es Abhängigkeiten der Teams im Erstellungsprozess zueinander gibt.

Ein Beispiel für schlechte Liegezeiten, wenn ein Team nicht weitermachen kann. Wenn es häufig auf ein anderes Team warten muss. Zum Beispiel weil jenes Team eine wichtige Softwarebibliothek zuliefert.

Welche Konsequenzen hat es aber, wenn Arbeit ungeplant liegenbleibt? Was aus unserem System rausgeht, muss im anderem System (Abteilung, anderes Team) vielleicht erst wieder priorisiert werden. Stößt diese Arbeit zum Beispiel auf ein anderes Scrum-Team, muss unsere Arbeit mindestens einen Sprint warten, bis wir an der Reihe sind. Die fehlende Berücksichtigung der Abhängigkeit kann zu weiteren Verzögerungen führen. Weil Arbeit umdisponiert, verschoben oder wieder aus dem Sprint genommen werden muss. Arbeit, die dann nochmal wieder später eine weitere Einarbeitung benötigt.

Ein Lösungsansatz ist sicherlich teamübergreifende Kommunikation vor Beginn der Arbeit. Arbeit muss aktiv zwischen unserem Team und seiner Umgebung koordiniert werden. Und zwar immer wieder, regelmäßig zum Beispiel durch gemeinsames Planning oder auch während des "Sprintens" im Integration-Daily zwischen den Teams.

Den Fokus auf die Reduktion schlechter Liegezeiten zu legen, ist besser und wichtiger als zum Beispiel auf die Reduktion der reinen Durchlaufzeit oder in Scrum auf die Velocity zu schauen.

Warum? Weil bei der Reduktion der schlechten Liegezeit keine Gefahr der Qualitätsminderung besteht!

Als Scrum Master verstehe ich mich nicht als der Galeerenschiff-Trommler, der den Arbeitstakt beschleunigt.

Lautet die Devise "Wir wollen schneller werden oder mehr im Sprint schaffen", dann kann man sich das auch im Team durchaus billig erkaufen: indem weniger auf die Qualität geachtet wird.

Trotzdem verbessert sich die Time-to-Market und die Produktivität der einzelnen Teams nimmt zu

Es liegt nur nicht mehr so viel rum ...