Agile Teams sollen selbstorganisiert arbeiten. Wie können auf diese Weise Ziele erreicht, Kunden gut versorgt und Unternehmensziele erreicht werden?

Einleitung

In einer der wenigen Umfragen zur Verbreitung von Scrum entstand an der Hochschule Koblenz inzwischen die vierte Auflage zum «Status Quo (Scaled) Agile». Dabei bezeichneten 93% der Befragten, dass die Vorteile und Verbesserungen die Nachteile überwögen und sich die Einführung agiler Methoden als sinnvoll erwiesen habe.

Als nachteilig wurden häufig

1. die Rahmenbedingungen in den Unternehmen sowie
2. die Überforderung der Führungskräfte (!) genannt.

Das ist Stoff für weitere Beiträge. Da Führungskräfte an Zielen gemessen werden, untersuche ich heute die Frage, wie Sie genau mit agilen Methoden Ziele erreichen können.

Können mit agilen Projektmanagement-Methoden überhaupt Ziele erreicht werden?

Manche eher «old-school» Führungskräfte würden schon die Frage in Frage stellen und bezweifeln, ob man mit agilen Methoden überhaupt Ziele erreichen kann.

Da es bei «agile» keinen rigiden Top-Down Macht- und Durchsetzungsanspruch zur Zielerreichung gibt, erscheint die Skepsis durchaus berechtigt: Wie sollen in einem Unternehmen zum Beispiel vordefinierte Wachtums- und Umsatzziele erreicht werden, wenn selbstorganisierte Teams nur das tun, was sie wollen?

Gewinn ist ein «lag»-Indikator.

Dabei wird übersehen, dass finanzielle Kennzahlen keine lead- sondern sogenannte lag-Indikatoren sind: Höchstens wenn ich direkt Geld produziere, also Geld drucke, kann ich dessen Herstellung direkt steuern. Sonst ist Gewinn und der finanzielle Erfolg eine notwendige Beschränkug eines Unternehmens, der nach Peter Drucker durch Innovationen und dem «produzieren von Kunden» begegnet werden muss.

Nur wenn ich mich also innovativ am Markt behaupte und damit Kunden binde, kann ich den notwendigen Gewinn erzielen, um zu bestehen und zu wachsen.

Damit sind wir schon mitten im eigentlichen Problem: Kunden lassen sich offenbar so wenig «produzieren» wie sich Geld drucken lässt; man muss Kunden erst für das eigene Produkt oder den eigenen Dienst gewinnen.

Wie können wir somit Innovationen und Marketing (als dem Gewinnen von Kunden) als Ziel definieren und gemeinsam auf die Erreichung hinarbeiten?

Und wie sind zündende Innovationen und kreatives Marketing in einem volatilen und komplexen Umfeld und einer fast chaotischen Umwelt möglich?

Sicher nicht mit dem klassischen instruktiven top-down Management der letzten Jahrzehnte. Das gilt übrigens genau so im militärischen Kontext, in dem das lokale, eben agile Handeln kleiner autonomer Einheiten gleichermassen eine Erfolgsvoraussetzung für das Bekämpfen von Guerilla und zivil verkleideten terroristischen Attentätern ist¹.

Wir halten fest, dass agile Methoden heute eine anerkannte und wirksame Möglichkeit für eine erfolgreiche Unternehmensführung – und sogar für das Erzielen von militärischen Erfolgen darstellen.

Zielfestlegung bei agilem Projektmanagement

Der «leane Ansatz» zielt auf die reibungsfreie (5S zur Vermeidung von «Waste»), teamreflexive (Hansei) Wertschöpfung (Value Stream) , die am Arbeitsplatz (Gemba) entsteht und fortlaufend optimiert wird (Kaizen) und häufig mit Pull-Prinzipien über Wertkarten (Kanban) gesteuert wird.

Mit Value Stream Mapping kann die Wertschöpfung beobachtet und transparent gesteuert werden. Mit dem leanen Ansatz und dem im digitalen Kontext vergleichbaren DevOps Konzept wird somit ein bestehender Dienst fortlaufend optimiert und verbessert. Lean und Kanban setzen konsequent auch genau dort, wo man gerade steht.

In einem gewissen Kontrast dazu möchte man bei agile hingegen beliebige, oft auch disruptive und fast unrealistisch wirkende Ziele erreichen und den Kunden damit direkt und beeindruckend besserstellen. Deshalb werden Kundenerwartungen proaktiv reflektiert und dem zur Abdeckung benötigten Aufwand gegenübergestellt.

Daraus ergibt sich ein gesamtes «Backlog», das dann in intervallartig getakteten Zeitfenstern als ergebnisoffenen «Sprints» umgesetzt wird. In diesen monatlichen, zwei- oder wöchentlichen Zeitfenstern wird jeweils eine als Sprint-Backlog definierte Untermenge aller Produktfeatures realisiert um anschliessend wieder intern und mit dem Kunden bewertet und in ein neues Sprint-Backlog gegossen zu werden, das im nächsten Sprint umgesetzt wird.

Diese intervallgetriggerte Anpassung und Umstellung der Anforderungen ist nicht bei jeder Projektart möglich: So müssen bei einem Hochhaus zunächst das Fundament erstellt werden (fixe Reihenfolge) und hatte man bei der Mondlandung 1969von vornherein auch die Rückkehr eingeplant (volle Anforderungsumfangsabdeckung im Vorhinein).

Ein agiles Timeboxing lediglich des Hinflugs hätte dazu wohl geführt, dass die Austronaut*innen auf dem Mond so lange verweilen bis sie gestorben sind.

Es ist deshalb kein Zufall, dass agile aus der Software-Domäne stammt, bei der sich Features leichter vor- oder nachreihen lassen – und mit dem Kunden besprechen werden können. Wobei die Voraussetzung auch dort – wie beim Hausbau – eine gute Software-Architektur ist, die man besser vorab erstellt und die dem Kunden nicht so einfach wie ein GUI gezeigt werden kann. Um dem Sorgen zu tragen beinhaltet Disciplined Agile sowohl eine explizite Inception-Phase, in der die Architektur zugrundegelegt werden kann, als auch die Rolle eines Solution-Architekten, der während der ganzen Projektlaufzeit eine der wichtigsten Rollen innehat – beides Konzepte, die bei Scrum fehlen.

Agile im Scrum-Typ ist deshalb aus Sicht des klassischen Projektmanagements nichts anderes als eine rollierende Projektplanung, bei der Ziele in timeboxes definiert und im engen Kundenkontakt jeweils im Hinblick auf die pragmatisch erzielbare Wertschöpfung in den Sprint-Backlogs neu gesetzt werden.

Agiles Projektmanagement öffnet also wie bei der Eroberung eines militärisch unsicheren Gebiets einen Handlungsraum, der schrittweise erschlosen wird und bei dem am Anfang «nur» die Stossrichtung, aber nicht die genaue abgrenzbare Landkarte des Zielgebiets festseht.

Agiles Projektmanagement funktioniert also genau so zielorientiert wie klassisches. Im Unterschied dazu fährt es aber nicht langsam wie ein Tanker Richtung Gesamtziel, sondern rast in der Timebox mit Vollgas auf Sicht zum Zwischenziel, um die nächste Strecke nach einer Standortbestimmung im Kundenkontakt festzulegen und erneut im Team «auf die Tube zu drücken».

Durch diesen engeren Fokus im aktuellen Doing können auch Widrigkeiten rascher verräumt werden, dazu dient die in der Regel tägliche Abstimmung. Risikomanagement ist bei agile durch den engeren Informationsausgleich im Team und durch die Einbeziehung des Kunden als Kontakt mit der Realität fix eingebaut. Scrum bezeichnet sich deshalb im Scrum Guide² als empirische Methode, die die Realität in Form von Projektschwierigkeiten und Kundenkritik so früh wie möglich in das Projekt zurückbinden und sich daran jeweils neu ausrichtet.

Agile und Scrum funktionieren gleichermassen zielorientiert wie herkömmliches Projektmanagement.

Wir können also festhalten, dass agile auch konkrete Vorstellungen für die Zielfestlegung kennt und deren Erreichung sowie Möglichkeiten zur Verbesserung der Arbeitsweise in Sprint-Reviews und Retrospektiven – quasi als Quality-Gates nach herkömmlicher Terminologie – überprüft. Die Testbarkeitsbedingungen eines Scrum Projekt stehen also nur bezogen auf den nächsten Sprint im Sprint-Backlog fest, nicht bezogen auf das finale, abschliessende Produkt. (Wobei es bei Services und bei DevOps gar nie ein endgültiges Produkt geben wird.)

Agile Zielfestlegung

Wie werden nun Ziele im «agile Style» festgelegt?

Die von agile-affinen Werkzeugen wie Jira dazu genutzten Kozepte definieren aus Kundensicht ein «Epic» als Erlebnisgeschichte, aus dem heraus dann «Stories» abgeleitet und als konkrete «Features» umgesetzt werden. Andere agile Ansätze wie Extreme Programming und das Agile Manifesto, aber auch Methoden zur innovativen Produktentwicklung wie Design Thinking lassen hier terminologisch grüssen.

Während das klassische Projektmanagement über Jahrzehnte laufend für SMART-Projektziele (auf deutsch ungefähr: Spezifisch, Machbar, Erreichbar, Realistisch, Zeitbeschränkt) als unbedingte Anforderungen für Ziele geworben hat, schaut das heute etwas differenzierer aus: Die von SMART geforderte Präzision und Vorsicht kombiniert die Zielvision mit Risikomanagement. Damit wird eine sichere Projektumsetzung möglich, der erreichbare Zielhorizont aber von vornherein stark eingeschränkt.

Ein Moonshot-Projekt, bei dem ein ganz grosser Wurf geplant ist, könnte mit SMART-Zielen nie realisiert oder auch nur angedacht werden. Wenn zum Beispiel mit dem Projekt 100 Millionen Menschen erreicht werden oder sonst massive Verbesserungen für die ganze Menschheit möglich werden sollen – dann erscheint inbesondere auch das dafür benötigte Kleingeld unbeachtlich.

Auch die Mondlandung von 1969 wäre nach diesen SMART-Prinzipien wohl nie zustande gekommen. Die extrem hohen Risiken, waren den teilweise sehr jungen Mitwirkenden wohl bewusst, sie konnten aber in einem angstfreien Kontext arbeiten und das schwer Erreichbare, für manche unmögliche erscheinende Ziel tatsächlich erreichen³.

Maja Storch stellt solchen SMART-Zielen Motto-Ziele gegenüber. Diese sind im Prinzip von der Art, wie sie offenkundig Kennedy mit der Mondlandung vorgab: Sie führen zu einer überkognitiven, symbolischen und emotionalen Verankerung und ermöglichen damit eine ganz andere Zielverfolgungsqualität als SMART-Ziele – gerade auch im Team⁴.

Saint-Exupéry hat das ähnlich ausgedrückt, wenn er nicht SMART-Ziele (Holz beschaffen, Planung, Arbeit einteilen) als Voraussetzung für einen erfolgreichen Schiffbau definiert, sondern die Sehnsucht nach dem endlosen Meer⁵,⁶.

Agile Zielsetzungen

Agiles Projektmanagement setzt also das Kundenerlebnis quasi als Mottoziel oben auf eine Pyramide und leitet von dort konkrete Umsetzungspunkte ab. Das ist im Prinzip analog zum klassischen Projektmanagement-Vorgehen.

Einen wesentlichen Unterschied gibt es allerdings:

Das agile Team entscheidet über die Art der Umsetzung

Das klassische Projektmangement, in der extremen Ausprägung des V-Modells und im Geiste des Scientific Managements zielt darauf ab, auch die Umsetzungsdetails im Vorhinein festlegen. Arbeitspakete werden vorab geschnürt mit zahlreichen Anweisungen und Details zur konkreten Umsetzung.

Die Art und Weise, wie Anforderungen umgesetzt werden sollen, wird beim agilen Konzepten hingegen nicht vorgegeben, sondern dem Team überlassen.

Das agile Team entscheidet über die Art der Umsetzung.

Das Team kann das, weil es sich selbst organisieren soll und interdisziplinär besetzt ist – was bei Kanban nicht zwingend der Fall sein muss: Kanban sieht auch spezialisierte Teams vor. Diversität wird bei agile und bei Disciplined Agile sogar explizit als wesentliche Erfolgsvoraussetzung gesehen. Agilen Ansätzen sind eshalb die in vielen Unternehmen lähmenden Kommunikationshürden zwischen Abteilungen fremd.

Agile kennt keine abteilungsübergreifenden Kommunikationsprobleme, weil es auf durchmischte interdisziplinäre Teams setzt, die gemeinsam Verantwortung tragen.

Vom Ziel zur Aufgabe

Wie gelangt man nun von den Anforderungen im Backlog zur konkreten Aufgabe, die im Sprint zu erledigen ist? Wie kann das epic über die story mit dem feature verbunden werden und in eine task münden, so dass am Ende das vom Kunden gewünschte Ergebnis herauskommt?

Erstaunlicherweise findet sich im Scrum Guide das Wort task überhaupt nicht: Das Team soll auf Basis der Scrum Werte («commitment, courage, focus, openness und respect») zusammen goals erreichen und in Eigenverantwortung organisieren, wie es das hinbekommt.

Entsprechend gibt Scrum – im Unterschied zu manch agiler Projektmanagement-Software – weder Tasks vor, noch dass nur eine Person an einer Task arbeiten soll oder muss.

Scrum kennt keine Tasks.

Kybernetisch optimierte Informationsnutzung?

Warren McCulloch hat diese These zur bestmöglichen Nutzung von Information formuliert⁷:

Organisiere so, dass immer derjenige entscheiden kann, der die besten Informationen dafür zur Verfügung hat, und sorge dafür, dass alle systemerhaltenden Funktionen jederzeit von mindestens zwei verschiedenen Elementen ausgeübt werden können.

Automatisch ensteht diese beste Organisation sicher auch nicht durch die einfache Anwendung der Scrum-Regeln. Nur wenn es das Team schafft, die oben erwähnte Werte auch praktisch zu leben, kann es funktionieren und idealerweise auch die angestrebte Redundanz erreicht werden. Auch hier bietet Disciplined Agile mehr Unterstützung, durch den Way of Work, Light Governance und Continous Guided Improvement.

Wie finden sich die notwendigen «Tasks», um die Ziele sicher zu erreichen?

Im Bereich der Software-Entwicklung wird oft das Konzept der testgetriebenen Entwicklung angewendet. Für Zieldefinitionen aus dem Produkt Backlog («features, functions, requirements, enhancements, and fixes») werden Tests definiert, die von einem Testprogramm automatisch überprüft werden kann.

Logisch gesehen müssen die notwendigen Ursachen – und eben auch nur die – gesetzt werden, um die gewünschte Wirkung zu erzielen. Der Logical Thinking Process ist eine ausgefeilte Methode und Weiterentwicklung Theory of Constraints, die diese Abklärung der benötigen Ursache-Wirkungszusammenhänge auf höchstem Niveau und für komplexeste Projekt und Systeme zuverlässig erlaubt.

David Allen, der Schöpfer von Getting Things Done⁸ schlägt dazu eine einfacher handhabbare Methode in fünf Schritten vor, die er als natürliche Schritte zur Projektplanung bezeichnet, vor:

1. Zweck und Grundsätze – defining purpose & principles: Warum und nach welchen Regeln soll etwas getan werden?
2. Sich das Ergebnis vorstellen – outcome visioning Wie fühlt sich die angestrebte Veränderung an, wenn sie vollbracht ist?
3. Brainstorming – brainstorming: Wie können wir das Ziel am Besten erreichen?
4. Organisieren – organizing: Wie genau bekommen wir das hin?
5. Nächste Schritte bestimmen – next action: Welche Handlungen müssen als nächstes gesetzt werden? Dies wird in der Folge nach jeder einzelnen Handlung erneut gefragt – was muss jetzt als nächstes nachfolgen? (Next action wird nach jeder durchgeführten Handlung erneuert)

Der erste Schritt ist bei Scrum nicht explizit verfügbar, bei Disciplined Agile hingegen als Inception sorgfältig entwickelt worden. Er ermöglicht im Konzernumfeld eine Verortung der konkreten Umsetzungsbedingungen, so dass die optimale Bezugnahme des Projekts zu Werten, Complianceregeln und Arbeitsbedingungen («Way of Work») erfolgen kann.

Die weiteren entsprechen im groben der Epic>Story>Feature>Task Abfolge. Dabei wird vom vorgedachten Projekterfolg aus der Kundensicht her gedacht und werden daraus die einzelnen Features abgeleitet, die das Team dann in einzelnen Tasks umsetzen kann. Entscheidend ist dabei, dass idealerweise selbst die Features sich weitgehend Kundenbenefits zuordnen lassen. Dazu werden die Stories so «geschnitten», dass sie sich in rasch umsetzbare Aufgaben ableiten lassen.

Alistair Cockburn hat dazu eine Übung entwickelt, das sogenannte Elefanten-Carpaccio. Damit wird angestrebt, dass jede Lieferung dem Kunden durch ein vielleicht noch unrundes aber schon brauchbares Produkt die Wertschöpfung deutlich macht. Das Ziel ist dabei, bezogen auf den Ressourceneinsatz und den Zeitverbrauch möglichst viel Wertschöpfung früh zu liefern (vgl. die Grafik unten). Idealerweise ist jedes Delivery bereits ein Minimum Viable Product, wie Henrik Kniberg schön illustriert hat.

Von Anfang an entsteht so etwas, was aus Kundensicht Sinn macht, wenn es auch noch nicht ganz rund ist. Genau diese wahrnehmbare Unrundheit bietet dann jeweils den Anlass, die nächsten Sprints zu planen…

Messung des Projektfortschritts

Der Scrum Guide sieht auf Seite 17 vor, dass der offene Arbeitsaufwand im Sprint jederzeit aufsummiert und berichtet werden kann:

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed².

Bedenkt man, wie schwierig es im hektischen Projektgeschäft oft ist, den Überblick zu behalten, ist das eine starke Ansage!

Da (1) ein Sprint nicht so lange läuft, (2) jeden Tag besprochen wird, was wo klemmt und welche Auswirkungen das haben wird, und (3) alle Tasks sich wertschöpfend auf den gesamten Sprintzusammenhang beziehen sollten, ist dieser Anspruch aber tatsächlich auch einlösbar.

Atomare Vereinzelung & Qual des Daily Standups

Wird Scrum hingegen als «lipstick agile» nur als Methode zur Aufgabenverteilung gesehen, also nur auf die Tasks fokussiert und von diesen her gedacht, entsteht lediglich eine atomare iterative Aufgabenflut. Die Vorteil der engegen Zusammenarbeit verpuffen so, weil einzelne Teammitglieder mit den losgelösten Aufgaben zugeschüttet werden und keinen gesamten Überblick mehr haben.

Das Daily Standup wird dann rasch zur Qual, weil der Bezug zu den Aufgaben der anderen und zum gesamten Projektziel fehlt. Da sich die Aufgaben nicht mehr auf eine, aus Kundensicht sinnhafte Gesamtheit beziehen, sind auch die Fortschrittsangaben nur quantitative Ansagen ohne einen brauchbaren Bezug zur einzig massgeblichen Kundenerwartung an das Sprintergebnis.

Zusammenfassung

1. Mit der Inceptions-Phase und dem Way of Work bietet Disciplined Agile im Unterschied zu Scrum die Möglichkeit, ein Projekt und die Zusammenarbeit von Anfang an auf einen konkreten Kontext einzustellen.
2. Agile ist eine strikt ergebnis- und outputorientierte Projektmanagement-Methode. Im Unterschied zur herkömmlichen Projektplanung denkt Scrum nicht vom finalen Projekteende her, sondern vom konkreten Vorteil für den Kunden am Ende von jedem Sprint.
3. Die User-Stories sollen granular top-down gestaltet werden, nur so wird die Wertschöpfung in jedem Sprint für den Kunden greifbar.
4. Wird Scrum hingegen als reine iterative Task-Verwaltung missverstanden und bottom-up missbraucht, so entsteht eine Aufgaben-Kakaphonie, die den Vorteil der interdisziplinären Teamarbeit untergräbt und zunicht macht.
5. Der Scrum Guide sieht explizit vor, dass der Sprint-Fortschritt jederzeit rapportierbar ist.

Weiterführende Themen

Weiterführende Themen für den Einsatz und die Skalierung von agile im Unternehmen, die hier weiter verfolgt werden:

• Easy Governance und Guided Continous Improvement als wertvolle Werkzeuge von Disciplined Agile im Unternehmen
• OKRs als Anwendung dieser Ideen im agilen Feedback-Management
• Lean und DevOps als weitere Anwendungsoptionen von agile auf Basis von Disciplined Agile Delivery
• Mission, Vision und Purpose als unternehmensweite Rahmenbedingungen für erfolgreiches agiles Projektmanagement