Niko Zimmermann

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

Nicht alle Liegezeiten im Wertstrom der zu entwickelnden Software 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.

Ob Sie im Scrum Projekt alle 2 Wochen releasen oder nur 2 mal im Jahr, zum Beispiel rechtzeitig zur halbjährlichen Messe. Oder Sie sammeln beispielsweise Arbeitspakete, die Sie dann regelmäßig abarbeiten. Das nennt man in Scrum den Sprint.

Stapel in einem Product Backlog, im Sprint Backlog, fertige Builds vor Auslieferung (Deployment) der Software ... für mich nicht die wesentlichen Herausforderungen.

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, und zwar nicht nur in diesem Blog, sondern in jedem meiner Projekte, auf den versteckten Liegezeiten der Softwareanforderungen, 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 arbeiten, können sie, jedes Team für sich, erstaunliche Optimierungen ihrer Arbeitsweise erreichen. Zum Beispiel durch regelmäßige Retrospektiven.

ABER, ... zehn optimierte Teams im gemeinsamen Erstellungsprozess des Produktes, des Services, der Software ergeben noch nicht unbedingt eine bessere Time-to-Market. Warum? Weil eine lokale Optimierung der einzelnen Teams weniger 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, 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 (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 einzelner Teams 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 durch die Reduktion der ungeplanten Liegezeiten die Time-to-Market des Produkts/Service/der Software und die Produktivität der Teams (gemeinschaftlich) nimmt auch zu

Es liegt nur nicht mehr so viel rum ...