Wir sind mittlerweile recht gut darin, Informationen zu analysieren und zu verwalten (z.B. Anforderungen), komplexe Strukturen in einfachere Substrukturen herunterzubrechen etc., also darin, statische oder strukturelle Komplexität zu meistern. Warum tendieren dann „große“ Systeme (v.a. Softwaresysteme) dazu, immer „schlechter“ zu werden mit einem stetig anwachsenden Fehlerberg?

Die Entwicklung solcher Systeme findet in einem dynamischen Umfeld statt, sie ist selbst ein dynamisches System. Produktentwicklung und komplexe Projekte sind stochastische Systeme (nicht-linear und nicht-deterministisch) und es sind Systeme mit Warteschlangen.

Die Warteschlangentheorie und daraus abgeleitet das Management von Warteschlangen helfen, solche dynamischen Systeme zu verstehen und damit die Durchlaufzeiten von Werten (den Dingen, die für den Kunden einen Wert darstellen und für die er bezahlt) zu verkürzen und die Produktivität zu erhöhen (Reinertsen, D., Managing the Design Factory, Free Press 1997).

Durchlaufzeiten in der Produktentwicklung sind z.B.:

  • die Zeit für Analyse und Design,
  • die Kompilierzeit für die gesamte Software,
  • die Zeit für Integration und Test des gesamten Produktes,
  • die Zeit von der Idee zur Umsetzung (done) für ein Feature,
  • die Zeit von der Idee zum Geldrückfluss für ein Release.

Der Einsatz von Warteschlangenmanagement kann die durchschnittliche Entwicklungszeit im Produktmanagement um bis zu 50% reduzieren (Adler, P., Mandelbaum, A., Nguyen, V., Schwerer, E., 1996. „Getting the Most Out of Your Product Development Process”, Harvard Business Review, Mar-Apr 1996). In der (traditionell sequenziellen) Produktentwicklung gibt es eine ganze Reihe von Warteschlangen nur teilweise erledigter Arbeit (Work In Progress – WIP):

  • Produkte in einem Portfolio, die auf ihre Umsetzung warten,
  • Features / Anforderungen in einem Produktbacklog, die auf ihre Umsetzung warten,
  • Detaillierte Anforderungsspezifikationen, die auf das Design warten,
  • Designdokumente, die auf das Codieren warten,
  • Code, der auf den Test wartet,
  • Code eines Programmierers, der auf die Integration mit dem Code der anderen Programmierer wartet,
  • Komponenten, die auf Integration und Integrations-Test warten.

Neben diesen WIP-Schlangen gibt es typischerweise auch Schlangen, die auf begrenzte Ressourcen zurückgehen, wie z.B. das Warten auf teure Test-Infrastruktur.

Wenn es unser Ziel ist, dem Kunden möglichst schnell einen Wert zu liefern, dann sind Schlangen offensichtlich ein Problem. Sie erhöhen die durchschnittliche Durchlaufzeit und damit die Zeit, bis der Kunde seinen Wert bekommt. Warteschlangen sind Lagerhaltung, in die investiert wurde, ohne dass ihnen ein ROI gegenübersteht (und sie verbergen Fehler, da sie noch nicht weiterverarbeitet wurden – z.B. Code, der noch nicht integriert wurde). Schlangen werden deshalb im Lean Thinking auch als Verschwendung (waste) bezeichnet, die es zu eliminieren gilt.

Klassische Warteschlangen-Strategien hierzu sind:

  • Reduziere die Größe der Warteschlangen,
  • Reduziere die Größe der Arbeitspakte,
  • Reduziere die Variabilität (Variabilität wirkt sich negativ auf die Durchlaufzeit aus. Das Law of Variability Placement (Hopp, W., Spearman, M. Factory Physics, McGraw-Hill, 2008) besagt, dass der schlechteste Platz für Variabilität (mit der größten negativen Auswirkung auf die Zykluszeit) am Anfang eines mehrstufigen Systems mit Warteschlangen ist – im Falle der traditionellen System- und Softwareentwicklung also in der Anforderungsphase mit umfangreichen Spezifikationen.).

Und genau darauf zielt agiles Vorgehen, z.B. Scrum, ab. Agiles Vorgehen gibt uns Werkzeuge an die Hand, um mit dynamischen Systemen besser umgehen zu können. Agiles Vorgehen ist somit keine Mode, sondern basiert auf einem formalen mathematischen Modell, dessen Funktionieren bewiesen werden kann. Ein italienisches Sprichwort sagt, Mathematik ist keine Ansichtssache. Die Warteschlangentheorie auch nicht. Agilität auch nicht.