Iterativ vs. kontinuierlich im Kontext von APM

Kanban ist ein fließender, kontinuierlicher Planungs- und Steuerungsprozess. Agile Verfahren wie APM, Scrum etc. setzen stattdessen auf iterationsweise Planung, also Intervalle. Die Bedeutung dieses Unterschiedes ist mir bislang nicht wirklich klar. Er erscheint mir aber zunehmend fundamentaler in dem Sinne, dass es weniger um eine Kanban-Adaption für iterative Verfahren geht, sondern um eine Alternative zu iterativen Verfahren. Die letztendlichen Konsequenzen daraus erscheinen mir sehr weitgehend.

Dann habe ich auch darüber nachgedacht, wie sich unser APM-Vorgehen in diesem Kontext darstellt und möchte, wenn auch ein wenig unstrukturiert, die Gedanken hierzu mal kurz festhalten.

Mit APM erlauben wir explizit, dass Auftragsgutachten (fertig/nicht fertig) auch während der Iteration stattfinden können, dann aber wiederum als Arbeitsauftrag einzuplanen sind. Aber dies ist in APM eher als Möglichkeit und nicht als angestrebtes Ziel gemeint und führt letztendlich auch nicht zu einem kontinuierlichen Prozess.

Vom Unterschied zwischen kontinuierlicher und intervallbasierter Planung, Steuerung und Kontrolle einmal abgesehen, haben wir in APM andere Mechanismen, um ähnlich teilweise Kanban-ähnliche Effekte zu erzielen, bspw. bezogen auf die Vermeidung zu großer Eingangspuffer.

Einer dieser Mechanismen ist der Läufer in Kombination mit der wöchentlichen Wahrscheinlichkeitsabfrage: Der Läufer sammelt einmal wöchentlich Statusinformationen über alle Arbeitsaufträge (entweder als Ampel-Status oder prozentual mit Hilfe der Frage „Wie groß ist die Wahrscheinlichkeit, dass dein Arbeitsauftrag am Iterationsende wie geplant fertig wird?“).

In APM ist dies der zentrale Mechanismus, um zusätzlich zum Feedback am Iterationsende bereits während der Iteration planungs- und steuerungsrelevante Rückmeldungen zu erhalten. Neben der Justierung von Entschwicklungsgeschwindigkeit, Schätzgüte etc. dient dies zur Vermeidung planerischer Überlastungen (zu große Eingangspuffer). Es gibt zwei Varianten dafür

1. Geht bspw. ein Arbeitsauftrag mit einem geschätzen Aufwand von 5 PT auf „rot“ (Wahrscheinlichkeit < 50%, d.h. wird am Iterationsende nicht fertig sein), sind für die Folgeiteration 20 PT weniger an neuen Aufgaben zu erzeugen (bei ansonsten gleichbleibenden Prioritäten).
2. Die prozentuale Variante: geht ein Arbeitsauftrag auf 30% Erfolgswahrscheinlichkeit, liefert die wahrscheinlichkeitsgewichte Verarbeitung der Information (20 PT * 0,7 =) 14 PT Aufwand, den ich zum Iterationsende fakultativ übrig habe, d.h. in diesem Umfang reduzieren sich neu zu kreierende Aufträge für die Folgeiteration, um den Eingangspuffer minimal zu halten.

Der Läufer-/Statusmeldungsmechanismus ist sehr effizient und beruht im Wesentlichen auf direkte Kommunikation, d.h. liefert in der Praxis viel mehr als nur Zahlen. Der Läufer läuft wöchentlich, d.h. das Informationsaufnahmeintervall ist erheblich kürzer als eine Iteration, allerdings auch kein kontinuierlicher Prozess.

Ein anderer Mechanismus in APM betrifft die Frage, ob ich die Aufgaben für die nächste Iteration in den Tagen vor Ergebnisablieferung (also vor Begutachtung fertig/nicht fertig) festlege oder im Orientierungsabschnitt, d.h. zwischen Ergebnislieferung und Start der Folgeiteration. Soweit es vor Ablieferung passiert (was wir in APM tendenziell befürworten bzw. als Standardfall beschreiben), ergäben sich auch Ansätze, mehr vom iterativen zum kontinuierlichen Planen zu kommen. Zumindest ist dies eine Öffnung des streng iterativen Vorgehens zu einer zeitlich flexbleren Planung. Da ich die Unterscheidung iterativ vs. kontinuierlich jedoch als Paradigmenfrage sehe und nicht als Detail, würde ich dies für APM (oder auch für Scrum) nicht ernsthaft und ohne grundsätzliche Diskussionen verfolgen würde.

Die Wartehalle in APM ist ein Mechanismus mit gewissen Bezug zu Kanban.

Grundsätzlich ist es bei Diskussionen m.E. (im Moment) hilfreich zu unterscheiden, ob über die Mikroebene gesprochen wird (das Team mit seiner Planungswand im Zeitraum von der Sprint-Planung bis zur Ergebnisbegutachtung) oder über die Makroebene (also das was der Product-Owner oder das Product-Owner-Team leistet und was (zeitlich) iterationsübergreifend und (organisatorisch) teamübergreifend sein kann). Einen Nutzen kann Kanban einem einzelnen Team bringen (Mikroebene), um seine Selbstgesteuerung besser zu verstehen.

Für den Fall der Makroebene müssen die Planungsartefakte eines SW-Projektes als Fluss/Prozess begriffen werden, d.h. ein Wissen darüber, wer mit dem Ergebnis weiterarbeiten soll (so wie Material im Produktionsprozess weitergegeben wird). In Scrum, zumindest im Kontext Benutzergeschichten, existiert die Absicht oder Forderung, die Abhängigkeiten zwischen Anforderungsartefakten möglichst klein zu halten (wobei noch zu wenig praktische Hilfe/Lösungen dazu angeboten werden…). Je mehr dieses Ziel erreicht würde, desto weniger Prozesscharakter haben die Arbeitsaufträge und desto schwächer ist die Kanbanindikation.

Andererseits heißt dies aber auch, dass die Abhängigkeiten zwischen den Arbeitsaufträgen explizit sein müßten (oder?), d.h. es muss definiert sein, wer Vorgänger oder Nachfolger ist und Tokens bereitstellt oder entnimmt. Bei einem Wasserfallvorgehen habe ich am meisten (trügerisches, d.h. veraltendes und nutzloses) Wissen über diese Abhängigkeiten. Deswegen gehen agile und iterative Verfahren den Weg, die Arbeitskette immer nur mit einem kurzen Zeithorizont aufzubauen und minimal vor sich her zu schieben. Ob ein- oder zwei Iterationen im Voraus geplant wird (auch hier gibts Unterschiede zwischen APM und Scrum), ist hierbei wahrscheinlich nachrangig. Im Vergleich mit der Metapher Produktionsstrasse heißt dies: es sind die Anzahl der vorhandenen Stationen grundsätzlich bekannt und die produzierten Güter durchlaufen auch einen weitgehend festgelegten Weg durch diese Stationen. Nicht mehr so statisch wie früher die Liefer/Förderbänder in einer Autofabrik, aber vom Prinzip her schon.

Beim iterativen Vorgehen erfolgt die Planungsdetaillierung typischerweise mit sehr kurzfristigem Zeithorizont, läßt also nur wenig Aussagen, eher Vermutungen über die weitere Prozesskette zu. Je nachdem, ob bestehende Funktionalität erweitert wird, ob neue Funktionalität programmiert oder nur konfiguriert oder deklariert werden soll, inwieweit die Anforderungen stabil und klar oder volatil und vage sind, ob die Herausforderung eher technisch ist oder die Geschäftsprozesse betrifft, welche fachlichen und technischen Abhängigkeiten die Anforderung impliziert, landen die bei der Detaillierung entstehenden Arbeitsaufträge bei völlig unterschiedlichen Mitarbeitern (Ressourcen).

Ich bekomme eine Ahnung davon, dass APM und Kanban unterschiedliche Wege gehen, aber ähnliche Probleme addressieren bzw. Effekte erzeugen.

Ob kontinuierliche Systeme generell besser als iterative sind bezweifel ich weiterhin, vor allem weil ich die kulturellen, sozialen und psychologischen Effekte (z.B. Belastung der Mitarbeiter, Aspekte der Selbstorganisation) bei iterativen Systemen für attraktiv halte.

Bernd Oestereich