Blog

Fließende Entwicklung - Fokus auf Finishing

Olger Warnier

Aktualisiert Oktober 21, 2025
5 Minuten

Eine kleine Geschichte: Scrum, KanBan und DevOps

In den letzten 15 Jahren hat die IT-Branche begonnen, 'agil' zu arbeiten, oft durch die Einführung von Scrum. Scrum ist ein Entwicklungsprozess, der eine Kadenz von Sprints vorsieht, die jeweils ein paar Wochen dauern. Anhand von Benutzergeschichten wird die zu erledigende Arbeit festgelegt. Diese Benutzergeschichten werden geplant, festgelegt, erstellt und geliefert. Es besteht auch die Möglichkeit, die Arbeit zu bewerten, um sie gemeinsam zu verbessern.

In den letzten 5 Jahren gab es große Entwicklungen bei der Geschwindigkeit, mit der Software bereitgestellt werden kann. Dank der DevOps-Bewegung haben wir unser Denken und Handeln so angepasst, dass wir Software vollautomatisch bereitstellen können. Die Hindernisse wurden beseitigt und wir können jetzt neue Software sofort ausliefern, sobald sie fertig ist und von den Benutzern akzeptiert wird.

Die Kombination aus agilem Denken und den DevOps-Möglichkeiten für eine sofortige Lieferung führte zu einer weiteren Entwicklung des Herstellungsprozesses in der IT: die Einführung von KanBan. KanBan unterteilt den Herstellungsprozess in Phasen und begrenzt den Umfang der Arbeit, die in jeder Phase erledigt werden kann. Mit KanBan wird der Umfang der laufenden Arbeit begrenzt.

KanBan liegt eine tiefere Philosophie zugrunde, die als Theory of Constraints (ToC) bekannt ist. Diese Theorie konzentriert sich auf die Vorlaufzeit der Arbeit und zielt darauf ab, diese zu reduzieren.

Eine schnelle Lieferung an Ihre Kunden ist immer eine gute Idee.

Wie lange dauert es, bis Sie Ihr Ergebnis erhalten?

Laut ToC liegt die Grundlage für die Reduzierung der Durchlaufzeit in der Begrenzung der Anzahl der Dinge, die gleichzeitig erledigt werden müssen. Genau das tut KanBan: die Begrenzung der laufenden Arbeit. Die Wirksamkeit von KanBan wird durch das Little'sche Gesetz bewiesen, das besagt, dass

Vorlaufzeit = laufende Arbeiten x Flussrate

Mit anderen Worten: Wenn Sie Aufgaben haben, die jeweils 2 Tage Arbeit erfordern (Flussrate), sind Sie in 6 Tagen fertig (Vorlaufzeit), wenn 3 der Aufgaben noch in Arbeit sind. Und: Wenn Sie gebeten werden, etwas zusätzlich zu tun, dauert es 8 Tage, bis Sie fertig sind, weil sich Ihre unfertige Arbeit auf 4 erhöht hat.

Wie machen Sie das als Team?

Da wir nun wissen, dass es am besten ist, nicht zu viel gleichzeitig zu tun und nicht zu viel Arbeit in Arbeit zu haben, wie können wir uns als Team organisieren? Ein Team kann einen optimalen Arbeitsfluss schaffen, wenn es die folgenden Schritte unternimmt:

  1. Machen Sie Ihren Entwicklungsprozess sichtbar.
  2. Legen Sie fest, welcher Teil die 'unfertige Arbeit' ist.
  3. Bestimmen Sie das Limit für die laufende Arbeit.

Diese 3 Schritte verschaffen Ihnen einen Überblick über das, was vor sich geht. Aber Sie brauchen noch mehr, um einen guten Fluss zu gewährleisten: Neue Arbeit kann nur begonnen werden, wenn die laufende Arbeit abgeschlossen ist. Auf diese Weise stellen Sie sicher, dass die Arbeit sozusagen durch das System "gezogen" wird, und Sie haben ein so genanntes Pull-System. Dieser Ansatz ist als flussbasierte Entwicklung bekannt.

Vom Team zum Prozess

Teams bestehen in der Regel aus Spezialisten, die jeweils über ihre eigenen spezifischen Kenntnisse und Fähigkeiten verfügen. Normalerweise gibt es keine Überschneidungen, weil die Arbeit zu spezialisiert ist. Die Gefahr dabei ist, dass es zu "Wartezuständen" kommt: ein Spezialist wartet, bis ein anderer fertig ist, bevor er oder sie weitermachen kann. Die Spezialisten innerhalb eines Teams sollten lernen, so zusammenzuarbeiten, dass sie die Arbeit gemeinsam, ordnungsgemäß und pünktlich erledigen können.

Manchmal hat ein Spezialist nichts zu tun, weil andere Dinge zuerst erledigt werden müssen. Die größte Gefahr dabei ist, dass man anfängt, 'andere Arbeiten' zu erledigen, die einem nützlich erscheinen. Das erhöht die laufende Arbeit und damit die Vorlaufzeit. Es ist besser, die Swarming-Taktik im Team anzuwenden.

Das bedeutet, dass die Mitarbeiter bereit sein sollten, sich gegenseitig zu helfen, auch in Bereichen, auf die sie nicht spezialisiert sind. Kurz gesagt, Sie brauchen echte Teamarbeit und nicht eine Ansammlung von Einzelpersonen. Außerdem sollten die Teams die Aufgaben intelligent aufteilen, so dass jeder Spezialist weiterarbeiten kann und alle Aufgaben aufeinander abgestimmt sind.

In dieser Hinsicht ist es auch wichtig, die Art und Weise zu überprüfen, wie Spezifikationen erstellt werden. Innerhalb eines Teams von Spezialisten sollte es Raum geben, damit sie eine Lösung für ein bestimmtes Problem finden können. Ein Format mit wasserdichten User Stories, in denen festgelegt wird, dass eine Schaltfläche auf einer Webseite platziert werden soll, wird dazu führen, dass nicht jedes Teammitglied an der Anfrage arbeiten kann. Ein Problem so zu definieren, dass das Team optimal arbeiten kann: Das ist die Grundlage für eine erfolgreiche flussbasierte Entwicklung.

Flussbasierte Entwicklung

Die flussbasierte Entwicklung konzentriert sich auf die Verkürzung der Vorlaufzeit zwischen Start und Nutzung. Der Prozess wird von einem Team von Spezialisten durchgeführt, die für die Suche nach einer funktionierenden Lösung, ihre technische Umsetzung und ihre Inbetriebnahme verantwortlich sind.

Das Setzen von Limits für die laufende Arbeit ermöglicht eine schnelle Lieferung der begonnenen Arbeit. Dieser Prozess kann sichtbar gemacht werden, und die daraus resultierenden Daten können für Prognosen und das Denken in Szenarien verwendet werden. Auf diese Weise wird auch die Planung schneller und effizienter.

Möchten Sie mehr erfahren?

Wenn Sie sich mit mir unterhalten möchten oder Unterstützung bei der fließenden Entwicklung benötigen, können Sie mich jederzeit kontaktieren

Verfasst von

Olger Warnier

Co-founder of Batav and one of the two main contributors of Cafienne.io a CMMN based Rapid Application Development platform.

Contact

Let’s discuss how we can support your journey.