Controlling als die Methodik der zielorientierten Unternehmenssteuerung basiert grundsätzlich auf dem kybernetischen Steuerungskreislauf, also z. B. dem PDCA-Zyklus. In einem komplexen Umfeld funktioniert dies nicht oder nur sehr eingeschränkt. Daher ist die zu Beginn geschilderte "Entkomplexierung" erforderlich. Für ein Inkrement, also einen Sprint, ist eine klassische PDCA-Steuerung wieder möglich.
Aufgrund der hohen Dynamik erfolgt die Steuerung im agilen Umfeld primär autonom in den agilen Teams. Entscheidungen werden auch primär dort getroffen. Eine Entscheidungsunterstützung durch den Controller erfolgt daher für das Team und nicht für einen Manager in der Struktur-Organisation.
Basis-Elemente der agilen Steuerung, also auch unabhängig einer Skalierung, sind
- Arbeitspakete werden in Backlogs geführt, die bei jedem agilen Neuorientierungspunkt neu priorisiert werden.
Die Bewertung / Sortierung der Backlogs erfolgt nach Kundennutzen. Scrum bietet keine bevorzugte Methode. Es gibt diverse Methoden, eine Priorisierung vorzunehmen. Optionen sind z. B. die Kano-Analyse oder das Theme Screening. Typisch ist bei der Bewertung der Arbeitspakete, dass diese nicht in Geld oder anderen absoluten Einheiten ermittelt werden, sondern relativ zueinander, basierend auf einem Referenzobjekt, meist dem kleinsten Arbeitspaket.
Die Kano-Analyse basiert auf dem Modell von Prof. Noriaki Kano, welches alle Funktionen einer Leistung in drei Kategorien einteilt: Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren. Je nach Erfüllung der Kundenanforderungen tragen Backlog-Positionen (z. B. Features) unterschiedlich stark zur Kundenzufriedenheit und zum Kundennutzen bei.
Die grundsätzliche Steuerung in Scrum umfasst die Planung der inhaltlichen Arbeit (User Stories) pro Sprint durch die Teams und die Messung der (Markt-)Leistung über Burn-Up-/ Burn-Down-Charts. Eine finanzielle Planung und Steuerung sowie eine strategische Rahmenplanung sind keine Standardelemente der agilen Projektsteuerung mit Scrum.
Wenn die Agilisierung das gesamte Unternehmen oder zumindest wesentliche Anteile davon umfasst, muss die Steuerung intensiver sein. Auch kann nicht mehr die gesamte Steuerung durch die einzelnen agilen Teams erfolgen. Die Planungs- und Steuerungsinstrumente im Scaled Agile Framework (SAFe) sind umfangreich und können hier nur ansatzweise beschrieben werden. So gibt es eine strategische Steuerung des Leistungsportfolios mit OKR und kaskadierten Roadmaps, dem Lean Startup Cycle. Anknüpfend an diese Portfolio-Planung erfolgt eine Top-down-Budgetierung, weitgehend unabhängig von der inhaltlichen Planung. Der Budgetierungsgedanke in SAFe geht davon aus, dass die Kapazitäten für die Aufgabenpakete über die festen agilen Teams für den Planungszeitraum fix sind. Auch externe Leistungen werden als fixe Kapazitäten eingekauft. Die Kosten dieser Kapazitäten machen den Großteil der Projektkosten aus, daher können sie unabhängig von der Inhaltsplanung bestimmt werden. Die Budgetierung erfolgt typischerweise für sechs Monate; so besteht auch hier eine Abweichung gegenüber einer typischen stabilen Budgetierung, die meist für ein Geschäftsjahr plant.
Die inhaltliche Aufgabenplanung ist ein Kernstück in SAFe. Hier werden pro ART bzw. bei großen Vorhaben pro Solution Train die Aufgaben auf dem Detaillierungslevel von Produkt-Features für 4-6 Sprints/Increments geplant. Dazu kommt ein "Innovation & Planning"-Increment, welches als Puffer für die Entwicklungstätigkeit, für eine große System Demo mit Retrospektive und zur Vorbereitung des nächsten Planungs-Events dient.
Das PI-Planning (PI = Program Increment) ist eine 2-Tages-Veranstaltung mit allen Beteiligten des ART, insbesondere mit allen Entwicklern. Damit kann die Teilnehmerzahl 50 – 125 Personen erreichen. In diesem PI-Planning wird das nächste PI detailliert, die zwei weiteren grob geplant.
Die Aufgabenpakete werden auch in SAFe in Backlogs dokumentiert. Es gibt neben den Feature-Backlogs, die für das PI-Planning benötigt werden, auch Backlogs für Epics (große Portfolio-Elemente) und für die User-Stories auf Team-Ebene. Meist wird hierfür die Methode WSJF (Weighted Shortest Job First) angewandt. Darin werden neben dem Kundennutzen auch Termindruck und Chancen/Risiken berücksichtigt.
Die Detailplanung pro Sprint erfolgt auch in SAFe durch die einzelnen agilen Teams auf Ebene der User Stories.
SAFe formuliert neben den klassischen Scrum-Metriken, also der Messung des Leistungsfortschritts durch Zählen der bearbeiteten User Stories, diverse weitere Metriken und misst unter anderem den Outcome beim Kunden.
Controlling ändert sich also durch skalierte Agilität. Auch die Rolle des Controllers ändert sich deutlich.