Viele Organisationen kämpfen mit Priorisierungskonflikten, Unklarheit in Entscheidungen und fehlendem Takt. CALM bringt Struktur, Entscheidungslogik und einen gemeinsamen Rhythmus in den Alltag.
Das CALM‑Modell verbindet Strategie, Taktik und operative Zusammenarbeit in einem klaren System. Die Übersicht zeigt, wie diese Ebenen zusammenspielen, um Entscheidungen, Prioritäten und Teamarbeit zu stabilisieren.
CALM: Clarity & Leadership Model ist ein leichtgewichtiges
Operating Model für Klarheit & Führung,
das Organisationen hilft, besser zu entscheiden, wirksamer zusammenzuarbeiten und stabiler zu liefern.
Als modernes Leadership Operating System bringt es Struktur, Fokus und einen klaren Führungsrhythmus in den Arbeitsalltag.
CALM eignet sich besonders für …
wachsende Organisationen
Unternehmen mit vielen Schnittstellen
Teams, die zu viele Meetings haben
Leadership‑Teams mit Priorisierungskonflikten
Organisationen, die ein leichtgewichtiges Operating Model brauchen
Das sind die Vorteile des Betriebsmodells
CALM verbindet die Vorteile eines Operating Models mit den Prinzipien eines Leadership Operating Systems: ein Führungsrhythmus, der Strategie, Taktik und operatives Arbeiten miteinander verzahnt.
Dadurch erlangt die Organisation:
Klarer Führungsrhythmus
Eindeutige Entscheidungslogik
Strukturierte Zusammenarbeit
Vorhersehbare Lieferung („Releasetakt“)
Weniger Reibung, weniger Doppelarbeit
Warum CALM?
Viele Organisationen kämpfen mit Reibung, unklaren Zuständigkeiten, Priorisierungskonflikten und zu vielen Meetings.
CALM schafft Klarheit durch eine eindeutige Struktur aus Ebenen, Rollen, Routinen und
Führungsrhythmus & Entscheidungslogik.
Damit wird Führung vorhersehbar, Entscheidungen nachvollziehbar und Zusammenarbeit wirksam.
CALM schafft:
Klarheit: über Richtung, Rollen, Prioritäten
Struktur: Durch Ebenen, Routinen, Entscheidungslogik
Fokus: Durch Releasetakt und klare Verantwortlichkeiten
Strategie schafft Richtung. Value Streams schaffen Klarheit darüber, wie Wert entsteht. CALM verbindet beides in einer schlanken Struktur.
Das CALM Operating Model beschreibt, wie aus klarer Strategie über Value Streams ein stabiler Team‑Rhythmus entsteht. Die Grafik zeigt, wie Vision, Prioritäten und Leitplanken in kundenfokussierte Wertströme und verlässliche Teams übersetzt werden. So wird Strategie im Alltag wirksam. Mit klaren Entscheidungen und messbarem Fortschritt.
Was Strategie im CALM bedeutet
Klare Prioritäten statt Wunschlisten
Nordstern und Leitplanken
Fokus auf das Wesentliche
Value Streams
Value Streams definieren, über welche Wege Wert für Kundinnen und Kunden entsteht. Sie sind Grundlage für Teamzuschnitte und Portfolio-Entscheidungen.
Output → Outcome
CALM richtet strategisches Arbeiten auf Wirkung aus, nicht auf Aktivität.
CALM Value Stream Canvas
Das CALM Value Stream Canvas verbindet Strategie, Wertströme und Teamformen zu einem klaren Gesamtbild. Die Darstellung zeigt, wie entlang eines Value Streams unterschiedliche Teams arbeiten; mit ihrem jeweiligen Zweck, ihrer Dauer und ihrem Arbeitsmodus. Das schafft Transparenz, Fokus und einen einheitlichen Führungsrhythmus im gesamten Operating Model.
Teamformen sind der oft fehlende Baustein moderner Organisationen. Wer eine Task Force wie ein Produktteam führt, verliert Zeit, Energie und Motivation – an allen Fronten gleichzeitig. CALM definiert fünf klare Teamformen, jede mit eigenem Zweck, typischer Laufzeit und passender Führungslogik.
Die drei Grundfragen vor jeder Teamform
Bevor eine Teamstruktur designt wird, braucht es drei klare Antworten:
Wofür wird die Einheit gebraucht?
Wie lange soll sie bestehen?
Was braucht sie, um erfolgreich zu sein?
💡CALM-Prinzip Teamarchitektur ist kein HR-Thema. Sie ist ein strategisches Führungsinstrument – und entscheidet darüber, ob Teams liefern oder schlechte Struktur kompensieren.
Die fünf Teamformen im Überblick
Teamform
Zweck
Typische Dauer
Führungsstil
Task Force
Akutes Problem lösen
Sehr kurz
Direktiv, klare Entscheidungen
Zielteam
Taktisches Ziel erreichen
Ca. 6 Monate
Facilitativ, coachend
Projektteam
Komplexere Vorhaben umsetzen
Mittel bis lang
Koordinierend, strukturgestaltend
Produktteam
Kontinuierliche Wertschöpfung
Langfristig
Servant Leadership, Empowerment
Linienteam
Kernprozesse stabil betreiben
Dauerhaft
Stabil führend, entwicklungsorientiert
Teamform bestimmt Führungsstil
Die Teamform gibt die Führungslogik vor – nicht umgekehrt. CALM macht diese Abhängigkeit explizit:
Je temporärer das Team, desto direktiver die Führung.
Je stabiler das Team, desto coachender und servant die Führung.
Je komplexer die Abhängigkeiten, desto koordinierender die Führung.
Je wertschöpfender das Team, desto empowernder die Führung.
Warum Teamformen wichtig sind
Die häufigste Ursache für schlechte Teamleistung ist nicht mangelnde Kompetenz, sondern die falsche Teamform. Eine Task Force, der man Teambuilding-Zeit gibt, die sie nicht hat. Ein Produktteam, das mit Projektlogik gesteuert wird. Ein Linienteam ohne stabile Prozesse. Klare Teamarchitektur reduziert Reibung, erleichtert Priorisierung und macht Führung vorhersehbar.
💡Mehr Details Ausführliche Beschreibungen aller fünf Teamformen, typische Fehler bei der Klassifizierung und Entscheidungshilfen findest du im Begleitartikel: Die 5 Teamformen im CALM Operating Model →
Unklare Rollen erzeugen Reibung. Nicht weil Menschen nicht wollen, sondern weil niemand weiß, wer was entscheiden darf. CALM macht Verantwortung sichtbar. Mit minimalem Aufwand.
Rollenklarheit ist keine Bürokratie. Sie ist eines der wirksamsten Entlastungsinstrumente für Führung und eines der stärksten Autonomie-Enabler für Teams.
Rollen vs. Positionen
CALM unterscheidet klar: Eine Position beschreibt die Stelle in der Organisation (z. B. "Teamleitung IT"). Eine Rolle beschreibt eine Funktion mit konkreter Verantwortung. Eine Person kann mehrere Rollen tragen. Eine Rolle hat immer genau eine accountable Person.
CALM benennt keine Jobtitel, sondern Funktionen. Ob diese Funktion "Product Owner", "Projektleitung" oder "Initiative Lead" heißt, ist kontextabhängig.
Die drei Funktionen in CALM
CALM beschreibt drei Funktionen, die in jeder Organisation vorhanden sein müssen – bewusst oder unbewusst. Wenn sie unbewusst wahrgenommen werden, entstehen Reibung, Doppelarbeit und Eskalation.
1. Richtung geben
Ebene: Team · Bereich · Portfolio
Wer entscheidet, was wichtig ist? Diese Funktion trägt Verantwortung für Ziele, Prioritäten und Fokus. Sie ist letzte Instanz bei Zielkonflikten und hält die Verbindung zwischen Strategie und Delivery.
Ausprägungen: Gruppenleitung · Product Owner · Abteilungsleitung · Bereichsleitung · Initiative Lead · bei mehreren Teams: übergreifende Richtungsverantwortung (analog Area Product Owner in LeSS)
CALM-Regel: Pro Ziel oder Value Stream gibt es genau eine Person, die diese Funktion trägt. Geteilte Richtungsverantwortung führt zuverlässig zu Lähmung.
2. Ergebnis verantworten
Ebene: Team
Wer steht für das Resultat gerade? Diese Funktion trägt Verantwortung für ein konkretes Ergebnis: ein Ziel, ein Produkt, ein Lieferobjekt. Sie ist erste Ansprechperson bei Scope, Blockern und Priorität innerhalb der Delivery.
Ausprägungen: Product Owner · Goal Owner · Gruppenleitung · Projektleitung · Workstream Lead · Tech Lead
CALM-Regel: Jede Arbeit hat genau eine outcome-verantwortliche Person. Das ist das einzige nicht-optionale Element im CALM-Rollenmodell.
3. Fluss erhalten
Ebene: Team · Schnittstellen
Wer sorgt dafür, dass die Zusammenarbeit funktioniert? Diese Funktion hält Routinen, Rhythmus und Abhängigkeiten im Blick. Sie moderiert Entscheidungsprozesse, trifft sie aber nicht selbst. Eine Ausprägung davon ist der Impediment Owner bei akuten Blockaden.
CALM-Regel: Diese Funktion ist optional, wird aber notwendig, sobald ein Team mehr koordiniert als liefert, oder Abhängigkeiten zwischen Teams unkontrolliert wachsen.
Das Minimalprinzip
Jede Arbeit braucht genau eine outcome-verantwortliche Person. Richtungsverantwortung und Flussverantwortung werden nur dann explizit benannt, wenn ihre Abwesenheit zu Reibung führt, nicht als Standard-Overhead.
Meetings sind oft Symptom eines fehlenden Systems. Zu viele Abstimmungen, zu wenig Entscheidungen, zu viel Doppelkommunikation. CALM löst das nicht durch weniger Meetings, sondern durch den richtigen Rhythmus auf der richtigen Ebene.
Jede der drei CALM-Ebenen hat ihre eigenen Regeltermine, ihren eigenen Teilnehmendenkreis und ihre eigene Funktion. Operativ wird geliefert, taktisch wird gesteuert, strategisch wird gerichtet.
💡Planungsprinzip CALM kombiniert die Struktur der Planungszwiebel mit rollierender Planung: Nahe Iterationen werden präzise geplant, weiter entfernte Zeiträume bleiben bewusst grob. Details entstehen Just-in-Time. Nicht auf Vorrat.
Die drei Ebenen und ihre Regeltermine
Operative Ebene -> Team-Kreis
Hier passiert die tägliche und iterative Arbeit. Der Team-Kreis besteht aus den direkt liefernden Personen und ihren unmittelbaren Teamleads. Routinen sind eng getaktet und auf Lieferung ausgerichtet.
💡Teamform beachten Nicht jede Teamform braucht alle operativen Routinen. Eine Task Force arbeitet mit täglichem Sync und klarem Mandat; ohne Retro-Overhead. Ein Produktteam profitiert von stabilen Review- und Retro-Rhythmen. Die Routinen folgen dem Zweck, nicht umgekehrt. → Mehr zu den 5 Teamformen
Taktische Ebene -> Führungskreis
Der Führungskreis steuert Initiativen, Roadmap und Ressourcen. Hier werden keine operativen Detailentscheidungen getroffen, sondern Prioritäten gesetzt, Abhängigkeiten sichtbar gemacht und Releases koordiniert.
Technische und fachliche Richtungsentscheidungen treffen
Business-Planung
quartalsweise
Führungskreis
Ziele, Budget und Kapazitäten für das nächste Quartal abstimmen
Strategische Ebene -> Leitungskreis
Der Leitungskreis setzt Richtung und Rahmen. Hier werden keine Roadmap-Details besprochen, sondern strategische Ziele, Jahresplanung und grundsätzliche Priorisierungsentscheidungen getroffen.
Regeltermin
Rhythmus
Teilnehmende
Zweck
Strategischer Jour-Fixe
monatlich
Leitungskreis
Strategische Lage einschätzen, Initiativen bewerten, Richtung halten
Quartalsabstimmung (Direction Day)
quartalsweise, Halbtag bis ganzer Tag
Leitungskreis, ggf. Führungskreis
Quartalsziele reviewen, Roadmap und Prioritäten für die nächsten 12 Wochen ausrichten, gemeinsames Lagebild herstellen
(Halb-)Jahresplanung
1–2× jährlich
Leitungskreis
Strategische Ziele, Roadmap-Rahmen und Investitionsschwerpunkte festlegen
Von der Idee zur Umsetzung: Wann ist ein Thema bereit?
Ein häufiges Problem in der Praxis: Themen wandern zu früh in die operative Umsetzung, ohne ausreichende Klarheit. CALM nutzt rollierende Planung als Leitprinzip: Details entstehen erst, wenn die Umsetzung unmittelbar bevorsteht. Die folgende Checkliste zeigt, wann ein Thema von der strategischen oder taktischen Ebene in die operative Planung übergehen darf.
Checkliste: Von der Idee in die Iteration
Strategische Einordnung geklärt: Das Thema ist einem Strategic Objective oder einer Initiative zugeordnet und passt zur aktuellen Prioritätslogik.
Epic beschrieben: Es gibt eine klare Beschreibung mit erkennbarem Kundennutzen oder Plattformnutzen. Reine Betriebsaufgaben und Bugfixes gehören nicht in die Roadmap.
Akzeptanzkriterien vorhanden: Es ist definiert, wann das Epic als abgeschlossen gilt (Definition of Ready auf Epic-Ebene erfüllt).
Abhängigkeiten geklärt: Schnittstellen zu anderen Teams oder Initiativen sind identifiziert, dokumentiert und abgestimmt.
Kapazität geprüft: Das Team hat realistisch Kapazität in der geplanten Iteration. Engpässe sind frühzeitig kommuniziert.
Priorisierung bestätigt: Der Führungskreis hat das Epic in der Roadmap priorisiert und in eine Iteration eingeplant.
Tickets vorbereitet: Mindestens die ersten Stories oder Tasks sind ausreichend beschrieben, damit das Team ohne Verzögerung starten kann (Definition of Ready auf Ticket-Ebene erfüllt).
💡Grundprinzip Solange nicht alle Punkte erfüllt sind, bleibt das Thema auf der taktischen Ebene in Vorbereitung. Kein Epic startet ohne Klarheit, das verhindert Nacharbeiten, stille Verschiebungen und Frustration im Team.
Zentrale Regeln von CALM
Pull-Prinzip: Das Team zieht sich Arbeit aus den übergeordneten Ebenen nach unten, sobald Kapazität frei wird.
Vermeidung von Waste: Details werden erst erstellt, wenn die Anforderung kurz vor der Umsetzung steht.
Echtzeit-Feedback: Erfahrungen aus der operativen Ebene fließen direkt in die taktische Planung zurück und verändern die Roadmap.
Viele Meetings, wenige Entscheidungen. Das ist kein Kommunikationsproblem, es ist ein Strukturproblem. CALM macht Entscheidungswege explizit: wer entscheidet was, in welchem Modus, und wann geht eine Entscheidung nach oben.
Eine Entscheidung, die nicht getroffen wird, ist keine Entscheidung, sie ist ein verstecktes Risiko. CALM schafft den Rahmen, damit Entscheidungen dort getroffen werden, wo die Kompetenz liegt.
Entscheidungstypen: drei Ebenen, drei Logiken
Nicht jede Entscheidung hat dieselbe Tragweite. CALM unterscheidet drei Typen und verknüpft jeden Typ mit der richtigen Ebene und dem passenden Modus.
Je operativer die Entscheidung, desto mehr Autonomie sollte beim Team liegen. Je strategischer, desto klarer muss der Entscheidungsträger benannt sein.
Die vier Entscheidungsmodi
CALM unterscheidet vier Modi, nicht als starre Kategorien, sondern als bewusst gewählte Haltungen je nach Situation, Teamform und Tragweite.
Autonom
Wann: Operative Entscheidungen mit klarem Rahmen, stabile Produktteams, Linienteams
Das Team entscheidet innerhalb eines definierten Rahmens eigenständig. Führung ist informiert, aber nicht involviert. Voraussetzung: Rahmen und Ziele sind klar.
Autonomie ohne Klarheit ist Chaos. Autonomie mit Klarheit ist Empowerment.
Delegiert
Wann: Taktische Entscheidungen, Zielteams, Projektteams mit klarem Scope
Führung definiert den Entscheidungsrahmen und übergibt ihn bewusst. Das Team entscheidet innerhalb dieses Rahmens. Führung ist Rückfallebene, nicht Entscheidungsinstanz.
Delegation ohne Übergabe ist Mikromanagement mit anderen Worten.
Relevante Perspektiven werden eingeholt, Führung trifft die finale Entscheidung. Der Unterschied zu Direktiv: hier wird aktiv Input gesucht, bevor entschieden wird.
Konsultativ heißt: zuhören und dann entscheiden, nicht: Konsens erzwingen.
Direktiv
Wann: Krise, Task Force, hohe Unsicherheit, Zeitdruck
Führung entscheidet klar und ohne ausgedehnte Konsultation. Dieser Modus ist nicht autoritär, er ist situativ notwendig. Und er sollte zeitlich begrenzt sein.
Direktiv ist kein Dauerzustand. Wer dauerhaft direktiv führt, verhindert Autonomie.
Eskalation: wann geht eine Entscheidung nach oben?
CALM definiert Eskalation nicht als Schwäche, sondern als strukturellen Mechanismus. Eine Entscheidung wird eskaliert, wenn:
sie den definierten Entscheidungsrahmen überschreitet,
sie Ressourcen betrifft, die außerhalb der Teamhoheit liegen,
sie zwei oder mehr Teams mit konfligierenden Zielen betrifft,
oder sie Auswirkungen auf die strategische Richtung hat.
Wer eskaliert, übernimmt Verantwortung, nicht wer entscheidet. Eskalation ist kein Versagen, fehlende Eskalation kann es sein.
ADR: Entscheidungen über Teamgrenzen hinweg dokumentieren
Aus der Softwarearchitektur bekannt, im Organisationskontext selten genutzt: Architecture Decision Records (ADR) sind ein leichtgewichtiges Format, um wichtige Entscheidungen nachvollziehbar zu machen, besonders dort, wo sie mehrere Teams betreffen oder langfristige Auswirkungen haben.
CALM adaptiert das Konzept für operative und taktische Entscheidungen jenseits von Teamgrenzen. Ein CALM-ADR beantwortet vier Fragen:
Kontext: Welche Situation hat diese Entscheidung ausgelöst?
Entscheidung: Was wurde entschieden und von wem?
Begründung: Warum dieser Weg und nicht ein anderer?
Konsequenzen: Was ändert sich dadurch, für welche Teams, welche Prozesse?
ADRs ersetzen keine Entscheidungsprozesse, sie machen sie nachvollziehbar. Das reduziert Rückfragen, verhindert, dass Entscheidungen verloren gehen, und schafft eine gemeinsame Basis für zukünftige Entscheidungen.
Ein ADR muss nicht lang sein. Ein Satz pro Feld reicht oft. Entscheidend ist, dass er existiert.
Führung entsteht nicht durch Begabung, sondern durch Klarheit, Konsequenz und den richtigen Rahmen. CALM definiert, was wirksame Führung in der Praxis bedeutet, und macht den Führungsstil zur bewussten Entscheidung.
Führung, die nicht situativ angepasst wird, kostet Teams Energie. Wer immer gleich führt, führt die meisten Teams falsch.
Die fünf CALM Leadership Essentials
CALM beschreibt keine Führungspersönlichkeit, sondern fünf Verhaltensweisen, die wirksame Führung in jeder Teamform und auf jeder Ebene ausmachen.
01 Klarheit zuerst
Bevor delegiert wird, muss Klarheit bestehen: über Ziel, Rahmen und Erfolgskriterien. Unklare Aufträge erzeugen Rückfragen, Fehler und Demotivation. Klarheit ist keine Einschränkung, sie ist die Voraussetzung für Autonomie.
02 Entscheidungen messbar machen
Entscheidungen, die keine Kriterien haben, werden endlos diskutiert oder still ignoriert. CALM erwartet von Führungskräften, dass sie definieren, woran eine gute Entscheidung erkennbar ist, bevor sie getroffen wird.
03 Stabilität da, wo sie gebraucht wird
Stabile Routinen, klare Erwartungen und verlässliche Rhythmen entlasten Teams. Führung, die ständig wechselt, zwingt Teams dazu, Energie für Orientierung aufzuwenden statt für Lieferung.
04 Flexibilität da, wo sie sinnvoll ist
Struktur schafft Spielraum, kein Korsett. Wo Teams Kompetenz haben, lässt CALM-Führung Methode, Vorgehensweise und Umsetzungsweg bewusst offen. Kontrolle auf das Ergebnis, nicht auf den Weg.
05 Routinen statt Aktionismus
Wirksame Führung wirkt durch Rhythmus, nicht durch ständige Eingriffe. Regelmäßige Reviews, klare Entscheidungsrunden und verlässliche Feedbackformate ersetzen Ad-hoc-Runden und bilaterale Eskalationen.
Führungsstil je Teamform
Die Teamform gibt die Führungslogik vor. CALM macht diese Abhängigkeit explizit, damit Führungskräfte ihren Stil bewusst anpassen, statt ihn unreflektiert beizubehalten.
Teamform
Führungsstil
Worauf es ankommt
Task Force
Direktiv
Schnelle, klare Entscheidungen. Enger Feedback-Loop. Kein langer Konsultationsprozess.
Zielteam
Coachend, facilitativ
Fokus und Klarheit sicherstellen. Blockaden frühzeitig erkennen. Nicht im Weg stehen.
Projektteam
Koordinierend, strukturgebend
Abhängigkeiten managen. Scope schützen. Entscheidungen herbeiführen, nicht treffen.
Produktteam
Servant Leadership
Hindernisse beseitigen. Autonomie ermöglichen. Richtung halten, ohne Micro-Management.
Linienteam
Stabil, entwicklungsorientiert
Klare Erwartungen. Stärken fördern. Kultur und Qualität langfristig sichern.
Je temporärer das Team, desto direktiver die Führung. Je stabiler das Team, desto mehr Führung durch Struktur und Coaching.
Feedback- und Lernkultur
Wirksame Zusammenarbeit braucht eine Kultur, in der Rückmeldung selbstverständlich ist, nicht außergewöhnlich. CALM verankert Feedback nicht als Event, sondern als Routine.
Feedback als Strukturelement
Feedbackgespräche, die nur auf Jahresgespräche warten, kommen zu spät. CALM integriert Feedback in den Führungsrhythmus: in Reviews, Retros und regelmäßigen 1:1-Formaten. Kurz, direkt, auf Verhalten bezogen.
Fehler als Lerngelegenheit
Psychologische Sicherheit ist keine Soft-Skill-Forderung, sie ist eine Leistungsvoraussetzung. Teams, die Fehler verstecken, lernen nicht. Teams, die Fehler besprechen, verbessern sich. CALM-Führung schafft den Rahmen, in dem Fehler benannt werden können, ohne dass Konsequenzen befürchtet werden.
Wer Fehler bestraft, bekommt keine Fehler gemeldet, sondern Überraschungen.
Retrospektiven als Minimalformat
Eine Retro muss kein aufwändiges Format sein. CALM empfiehlt ein minimales, regelmäßiges Format: Was lief gut? Was hat gebremst? Was ändern wir konkret? Entscheidend ist die Regelmäßigkeit, nicht die Perfektion des Formats.
Agile Transformation heißt nicht Scrum, sondern Organisationsdesign
Ergänzender Artikel zur praktischen Vertiefung des CALM Operating Models
Die meisten Organisationen scheitern nicht an Methoden, sondern an ihrem Betriebssystem.
Boards, Dailies, Sprints. All das ist leicht. Der eigentliche Umbau beginnt dort, wo es unbequem wird: in Entscheidungen, Prioritäten, Führung und Verantwortung.
In diesem Artikel zeige ich praxisnah, warum echte agile Transformation Organisationsdesign ist, wie Unternehmen an den falschen Stellen investieren und was wirklich Wirkung entfaltet.
Warum „Agile Transformation“ selten das ist, was Unternehmen denken
Viele Unternehmen starten eine agile Initiative, indem sie Teams schulen, Frameworks einführen oder neue Rollen benennen. Doch das greift zu kurz. Agilität entfaltet sich nur dann, wenn das Operating Model der Organisation angepasst wird, also das Zusammenspiel von Entscheidungen, Zusammenarbeit, Führung und Struktur.
Es geht nicht darum, agile Rituale einzuführen, sondern agile Arbeitsfähigkeit zu schaffen.
Kurz: Agilität ist kein Deko‑Element. Es ist Organisationsdesign.
Scrum einführen ≠ Agilität leben
Scrum einzuführen ist vergleichsweise einfach:
Boards aufhängen
Stand-ups organisieren
Product Owner ernennen
Das schafft Struktur, aber noch keine bessere Zusammenarbeit.
Agilität beginnt dort, wo Entscheidungen schneller, Prioritäten klarer und Verantwortung mutiger werden. Das ist anstrengend, weil es Verhalten betrifft und nicht Methoden.
Mini‑Case: Das Unternehmen, das „agil werden“ wollte
Ein Mittelständler führte Scrum in drei Teams ein. Alles sauber umgesetzt: Sprintpläne, Retros, Definition of Done.
Ergebnis nach sechs Monaten: Keine bessere Time-to-Market.
Warum? Die Prioritäten wurden weiterhin im Management wöchentlich neu diskutiert. Entscheidungen zogen sich über mehrere Hierarchieebenen. Rollen waren unklar.
Scrum war eingeführt. Agilität aber nicht.
Warum Agile Coaches scheitern und Teams frustriert zurückbleiben
Viele Agile Coaches sind fachlich hervorragend. Doch sie scheitern nicht an der Methode, sondern am System:
Entscheidungen dauern zu lange
Prioritäten ändern sich zu oft
Rollen sind nicht geklärt
Führung bleibt im Mikromanagement
Strukturen verhindern Fokus
Dort hilft keine neue Retro-Technik der Welt.
Wichtige Erkenntnis:
Agilität braucht ein Operating Model, das Agilität ermöglicht.
Operating Model schlägt Methodensammlung
Ein häufiges Missverständnis: „Wenn wir genug Methoden schulen, wird es schon agil.“
Nein.
Ein gutes Operating Model definiert:
Wie entschieden wird
Wer wofür Verantwortung hat
Wie schnell Prioritäten entstehen
Wie Informationen fließen
Wie Teams fokussiert arbeiten können
Methoden sind Tools. Das Operating Model ist das Fundament.
Was End‑to‑End‑Begleitung wirklich bedeutet
Transformation entsteht nicht in Trainings, sondern im Doing. End‑to‑End heißt:
nicht nur Workshops geben
nicht nur Frameworks erklären
nicht nur Impulse setzen
Sondern das Unternehmen so zu begleiten, dass sich Struktur, Führung und Zusammenarbeit im echten Alltag verändern.
Das passiert:
in echten Konflikten
in Entscheidungen
in Verantwortungsübergaben
im Tagesgeschäft
Transformation endet dort, wo PowerPoint beginnt und dort, wo Verhalten sich ändert.
Der Hebel, den fast alle unterschätzen: Entscheidungsarchitektur
Die wichtigste Frage jeder Organisation lautet:
Wer entscheidet? Wie schnell? Auf welcher Basis?
Solange das unklar bleibt, ist jede Veränderung ein Kampf gegen das eigene System.
Das ist der größte Hebel und der am seltensten adressierte.
Unklare Rollen? Willkommen im Meeting‑Overload
Wenn Rollen nicht klar sind, passiert das:
Doppelarbeiten
Rückversicherungsrunden
Verantwortungs-Wirrwarr
endlose Meetings
Klare Rollen reduzieren sofort rund 50 % der Meetings. Ohne neue Tools, ohne neue Methoden.
Wie gelingt echte Agile Transformation?
Checkliste für Organisationen, die es ernst meinen
1. Entscheidungslogiken klären
Wer entscheidet?
Woraus entstehen Prioritäten?
Wie schnell sind Entscheidungen möglich?
2. Führung weiterentwickeln
Weg vom Mikromanagement
Hin zu Klarheit, Transparenz, Verantwortung
Fokus statt Aktionismus
3. Rollen und Verantwortungen präzisieren
Wer hat welche Autorität?
Wofür wird jemand gemessen?
Wo beginnt und endet Verantwortung?
4. Strukturen ausrichten
Teams, die Wertflüsse abbilden
Weniger Schnittstellen, mehr End‑to‑End
Weniger Komplexität, mehr Fokus
5. Zusammenarbeit neu denken
Konflikte nutzen statt vermeiden
Meetings konsequent entlasten
Kommunikationswege verkürzen
Fazit: Agilität entsteht nicht durch Methoden, sondern durch Systemdesign
Wer Agilität als Methodensammlung versteht, wird keine bessere Organisation bauen. Wer Agilität als Organisationsdesign versteht, kann schneller entscheiden, klarer führen und besser zusammenarbeiten.
Und genau dort entsteht Wert.
Wenn du dein Operating Model weiterentwickeln willst, oder herausfinden möchtest, wo in deiner Organisation die größten Hebel liegen, begleite ich dich gerne durch den Prozess. Schreib mir einfach eine kurze Nachricht.
FAQ: Agile Transformation, Operating Models & moderne Führung
1. Was verstehst du unter „echter Agile Transformation“?
Echte Transformation bedeutet keinen Methoden-Zirkus, sondern den Umbau des Organisationsbetriebssystems: Entscheidungen, Rollen, Führung, Zusammenarbeit und Strukturen. Agilität ist Organisationsdesign – kein Deko‑Element.
2. Was ist der Unterschied zwischen „Agilität“ und „Scrum einführen“?
Scrum einführen ist leicht. Agilität leben ist schwer. Methoden schaffen Struktur – Menschen schaffen Ergebnisse.
3. Warum scheitern so viele Agile Coaches in Organisationen?
Nicht an Methodenkompetenz, sondern am System: unklare Prioritäten, langsame Entscheidungen, alte Führungsmuster. Agilität braucht ein passendes Operating Model.
4. Was meinst du mit „Operating Model schlägt Methodensammlung“?
Methoden sind Tools. Das Operating Model ist das Fundament: Entscheidungswege, Prioritätenbildung, Verantwortungsräume, Informationsfluss.
5. Was ist End‑to‑End‑Begleitung?
Keine Workshops allein, sondern echte Veränderung im Alltag: Entscheidungen, Konflikte, Prozesse, Zusammenarbeit.
6. Warum scheitert Agilität oft an der Führung?
Weil Teams nur so gut arbeiten können wie ihre Führung: Prioritäten, Klarheit, Entscheidungen.
7. Woran erkennst du gute Zusammenarbeit?
An klaren Zielen, mutiger Verantwortung, Transparenz, Fokus und offenem Umgang mit Konflikten.
8. Warum bringen Trainings allein keine Transformation?
Weil Verhalten am System abprallt, wenn Strukturen und Entscheidungen gleich bleiben.
9. Was ist der meist unterschätzte Hebel?
Die Entscheidungsarchitektur: Wer entscheidet wie schnell?
10. Warum führt fehlende Rollenklarheit zu Meeting‑Overload?
Weil unklare Verantwortung zu Doppelarbeit und Abstimmungsschleifen führt.
11. Warum endet Transformation dort, wo PowerPoint beginnt?
Weil Folien erklären, aber nicht verändern. Das passiert im Alltag.
12. Was bedeutet „Agilität ist Organisationsdesign“?
Agilität bestimmt, wie Wert entsteht, wie entschieden wird und wie schnell Organisationen reagieren können.
13. Welche strukturellen Blocker begegnen dir am häufigsten?
Team Architecture: Die 5 Teamformen im CALM Operating Model
Ergänzender Artikel zur praktischen Vertiefung des CALM Operating Models
„Team" ist das meistgenutzte und zugleich schlechteste definierte Wort in modernen Organisationen. Wer eine Task Force wie ein Produktteam führt, verliert Zeit, Energie und Motivation – an allen Fronten gleichzeitig.
Die drei Grundfragen vor jeder Teamform
Bevor eine Teamstruktur designt wird, braucht es drei klare Antworten: Wofür wird die Einheit gebraucht? Wie lange soll sie bestehen? Was braucht sie, um erfolgreich zu sein? Diese drei Fragen sind im CALM Operating Model der Einstieg in jede Teamarchitektur-Entscheidung.
💡CALM-Prinzip: Teamarchitektur ist kein HR-Thema. Sie ist ein strategisches Führungsinstrument – und entscheidet darüber, ob Teams liefern oder schlechte Struktur kompensieren.
Die 5 Teamformen im CALM-Modell
CALM unterscheidet fünf klar definierte Teamformen. Jede hat einen eigenen Zweck, eine typische Laufzeit und eine passende Führungslogik.
I
Task Force
Krisen- & Problemlösung
Dauer: sehr kurz
Kurzfristiges Team aus Experten, das ein akutes Problem löst und sich danach wieder auflöst. Hoher Entscheidungsdruck, oft direktes Reporting an Führungsebene oder Krisenstab. Fokus auf schnelles Handeln – nicht auf Prozessharmonie. Geringes Teambuilding notwendig.
Zweck: Akutes Problem lösen
Stabilität: Niedrig
Führungsstil: Direktiv, klare Entscheidungen, hohe Lenkung
II
Zielteam
Taktische Einheit für Fokus
Dauer: +/− 6 Monate
Klar abgestecktes Ziel, klarer Fokus. Besteht aus Experten für genau dieses Ziel. Löst sich nach Zielerreichung auf oder bekommt ein neues Ziel. Häufig in OKR-Logiken eingesetzt (Quartalsziele). Ergebnisorientiert, nicht strukturerhaltend. Moderates Teambuilding.
Verfolgt ein größeres oder mehrere kleinere Ziele. Häufig Matrixstruktur: Mitglieder gehören weiterhin ihrer Linie an. Rollen sind stärker formalisiert (PM, PO, Beteiligte). Abhängigkeiten zu anderen Teams möglich. Starkes Teambuilding bei längerer Zusammenarbeit sinnvoll.
Crossfunktionale Aufstellung, die alle Bereiche des Produkts abdeckt. Begleitet den gesamten Produktlebenszyklus. Hohe Stabilität der Teamzusammensetzung. Starke Teamidentität und -kultur. Fokus auf Outcome statt Output. Essentielles Teambuilding.
Dauerhaft und stabil zusammengesetztes Team mit klaren Rollen, Prozessen und Verantwortlichkeiten. Fokus auf Stabilität und Qualität. Wenig bis kein Auflösungsmoment. Moderate bis starke Teamkultur. Kern der operativen Verlässlichkeit.
Die Teamform gibt die Führungslogik vor – nicht umgekehrt. CALM macht diese Abhängigkeit explizit:
Je temporärer das Team, desto direktiver die Führung.
Je stabiler das Team, desto coachender und servant die Führung.
Je komplexer die Abhängigkeiten, desto koordinierender die Führung.
Je wertschöpfender das Team, desto empowernder die Führung.
Führungskräfte, die ihren Stil bewusst an den Teamkontext anpassen, erreichen mehr – mit weniger Reibung.
Fehlklassifizierungen und ihre Folgen
Die häufigste Ursache für schlechte Teamleistung ist nicht mangelnde Kompetenz, sondern die falsche Teamform. Eine Task Force, der man Zeit für Teambuilding gibt, die sie nicht hat. Ein Produktteam, das mit Projektlogik gesteuert wird. Ein Linienteam ohne stabile Prozesse.
Drei Fragen klären die Teamform: Wofür wird das Team gebraucht? Wie lange soll es bestehen? Was braucht es, um erfolgreich zu sein?
Team Architecture im CALM-Gesamtbild
Team Architecture ist Layer 3 von CALM. Sie verbindet die strategische Ebene (Richtung & Value Streams) mit den operativen Routinen (Arbeitsrhythmus, Meetings, Entscheidungen). Erst wenn klar ist, welche Teamform vorliegt, lassen sich passende Rollen, Routinen und Führungslogiken definieren.
Rollen & Verantwortlichkeiten im CALM Operating Model
Ergänzender Artikel zur praktischen Vertiefung des CALM Operating Models
Rollenunklarheit ist selten ein Personalproblem. Sie ist ein Strukturproblem.
Irgendwann in jedem wachsenden Unternehmen passiert dasselbe: Plötzlich gibt es mehr Menschen, mehr Initiativen, mehr Abhängigkeiten und niemand weiß mehr genau, wer für was zuständig ist. Nicht weil die Leute nicht wollen. Sondern weil niemand es je explizit gemacht hat.
Die häufigste Reaktion: Org-Chart anpassen, neue Titel vergeben, vielleicht ein RACI-Modell aufsetzen. Das kostet Zeit, erzeugt Widerstand und löst das eigentliche Problem oft nicht.
Dieser Artikel zeigt, warum Rollenunklarheit entsteht, was sie wirklich kostet und wie du mit einem minimalen Rollenmodell Klarheit schaffst, die hält.
Was Rollenunklarheit wirklich kostet
Rollenunklarheit ist selten dramatisch. Sie zeigt sich in kleinen, wiederkehrenden Mustern:
Entscheidungen werden verschoben, weil niemand sicher ist, ob er sie treffen darf.
Meetings enden ohne klares Ergebnis, weil unklar ist, wer das letzte Wort hat.
Dieselbe Arbeit wird doppelt erledigt, oder gar nicht, weil jeder denkt, der andere macht es.
Führungskräfte werden zum Flaschenhals, weil alle Entscheidungen eskaliert werden.
Das Ergebnis: Teams kompensieren fehlende Struktur durch informelle Wege. Das funktioniert kurzfristig und kostet langfristig enorm viel Energie. Wachstum verstärkt jeden dieser Effekte.
Rollenklarheit ist keine Bürokratie. Sie ist eines der wirksamsten Entlastungsinstrumente für Führung und eines der stärksten Autonomie-Enabler für Teams.
Warum klassische Lösungen oft nicht helfen
Der Griff zum RACI-Modell ist verständlich. Aber ein vollständiges RACI für alle Prozesse und Entscheidungen zu pflegen, ist aufwändig und veraltet schneller, als es aktualisiert werden kann. Stellenbeschreibungen beschreiben Positionen, nicht Funktionen. Und neue Jobtitel lösen keine strukturellen Verantwortungslücken.
Das eigentliche Problem ist kein Dokumentationsproblem. Es ist ein Klarheitsproblem: Wer darf was entscheiden? Wer steht für welches Ergebnis gerade? Wer hält den Laden am Laufen, wenn die Arbeit komplex wird?
Das CALM-Rollenmodell: drei Funktionen, minimaler Overhead
CALM – das Clarity & Leadership Model – unterscheidet Rollen von Positionen. Eine Position beschreibt die Stelle in der Organisation. Eine Rolle beschreibt eine Funktion mit konkreter Verantwortung. Und es braucht nicht viele Rollen. Es braucht die richtigen.
CALM beschreibt drei Funktionen, die in jeder Organisation vorhanden sein müssen, bewusst oder unbewusst:
Funktion 1: Richtung geben
Wer entscheidet, was wichtig ist?
Diese Funktion trägt Verantwortung für Ziele, Prioritäten und Fokus. Sie ist letzte Instanz bei Zielkonflikten. Auf Teamebene, auf Bereichsebene, und bei mehreren Teams auf Portfolioebene. Wenn diese Funktion unklar ist, entstehen Priorisierungskonflikte, die sich niemand erklären kann.
Ausprägungen je nach Kontext: Product Owner, Bereichsleitung, Initiative Lead. Bei mehreren Teams kann diese Funktion auch übergreifend wahrgenommen werden, analog zum Area Product Owner-Konzept in LeSS.
Die entscheidende Regel: Pro Ziel oder Value Stream gibt es genau eine Person, die diese Funktion trägt. Geteilte Richtungsverantwortung führt zuverlässig zu Lähmung.
Funktion 2: Ergebnis verantworten
Wer steht für das Resultat gerade?
Diese Funktion trägt Verantwortung für ein konkretes Ergebnis: ein Ziel, ein Produkt, ein Lieferobjekt. Sie ist erste Ansprechperson bei Scope, Blockern und Priorität innerhalb der Delivery. Fehlt sie, entstehen Abstimmungsschleifen, informelle Führung und Eskalationen nach oben.
Ausprägungen je nach Kontext: Goal Owner, Projektleitung, Workstream Lead, Tech Lead.
Die entscheidende Regel: Jede Arbeit hat genau eine outcome-verantwortliche Person. Das ist das einzige nicht-optionale Element im CALM-Rollenmodell.
Funktion 3: Fluss erhalten
Wer sorgt dafür, dass die Zusammenarbeit funktioniert?
Diese Funktion hält Routinen, Rhythmus und Abhängigkeiten im Blick. Sie moderiert Entscheidungsprozesse, trifft sie aber nicht selbst. Eine spezifische Ausprägung ist der Impediment Owner. Eine Person, die bei akuten Blockaden aktiv daran arbeitet, sie aufzulösen.
Ausprägungen je nach Kontext: Scrum Master, Agile Coach, PMO-Rolle, Koordination.
Die entscheidende Regel: Diese Funktion ist optional, wird aber notwendig, sobald ein Team mehr koordiniert als liefert, oder Abhängigkeiten zwischen Teams unkontrolliert wachsen.
Das Minimalprinzip in der Praxis
CALM folgt einer einfachen Logik: Nur so viel Struktur wie nötig, so wenig wie möglich.
Funktion
Zwingend?
Bedingung
Richtung geben
Immer
Pro Ziel / Value Stream
Ergebnis verantworten
Immer
Pro Arbeitsergebnis
Fluss erhalten
Situativ
Ab gewisser Komplexität oder Teamgröße
Funktion 3 entfällt zum Beispiel in einer Task Force: Dort ist Zeit die knappste Ressource, die Verantwortung ist klar, und jede zusätzliche Koordinationsrolle wäre Overhead. In einem Produktteam mit mehreren Abhängigkeiten ist dieselbe Funktion unverzichtbar.
Wie ihr damit startet
Rollenklarheit einzuführen muss kein großes Projekt sein. Ein pragmatischer Einstieg in fünf Schritten:
1. Bestandsaufnahme machen
Welche Rollen existieren heute – formal und informell? Wer übernimmt de facto Richtungsverantwortung, auch ohne Titel? Wer hält den Laden zusammen, ohne dass es jemand offiziell weiß?
2. Kritische Bereiche identifizieren
Wo entstehen regelmäßig Abstimmungsschleifen oder Eskalationen? Das sind die Stellen, an denen eine der drei Funktionen fehlt oder unklar ist.
3. Funktion 2 zuerst klären
Für jede laufende Initiative oder jedes Ziel: Wer ist outcome-verantwortlich? Eine Person, klar benannt. Das ist der wirksamste erste Schritt.
4. Funktion 1 dort explizit machen, wo Zielkonflikte entstehen
Nicht überall braucht es eine explizite Richtungsverantwortung. Aber dort, wo Prioritäten unklar sind oder Teams gegeneinander priorisieren, muss eine Person diese Funktion tragen.
5. Funktion 3 nur einführen, wenn sie gebraucht wird
Nicht jedes Team braucht einen Scrum Master oder eine Koordinationsrolle. Aber wenn Abhängigkeiten wachsen und Meetings mehr kosten als liefern, ist es Zeit.
Was CALM nicht ist
CALM ersetzt keine bestehenden Rollen, weder Scrum-Rollen noch klassische Projektstrukturen noch Linienverantwortung. Es beschreibt die Funktionen hinter den Titeln. Ein Product Owner kann Funktion 1 oder 2 tragen, je nach Teamaufstellung. Ein Scrum Master ist eine klassische Ausprägung von Funktion 3. Die Funktion bleibt gleich; der Titel ist Kontext.
Und CALM ist kein Grund, ein vollständiges RACI-Modell aufzusetzen. Für kritische Entscheidungsbereiche und Schnittstellen kann RACI ein sinnvolles Ergänzungswerkzeug sein, aber nicht als bürokratisches Vollbild, das niemand pflegt.
Fazit
Rollenunklarheit ist selten ein Personalproblem. Sie ist ein Strukturproblem. Und Strukturprobleme brauchen keine neuen Titel, sie brauchen klare Funktionen.
Drei Funktionen reichen: Richtung geben, Ergebnis verantworten, Fluss erhalten. Wer diese drei Funktionen in seiner Organisation explizit macht, reduziert Reibung, entlastet Führung und gibt Teams den Raum, den sie brauchen, um wirklich autonom zu arbeiten.
Wenn alles wichtig ist, ist nichts wichtig – Prioritäten in der Führungsrolle setzen
Ergänzender Artikel zur praktischen Vertiefung des CALM Operating Models
Priorisierung ist kein Luxus. Es ist ein Must-Have.
Kennst du das Gefühl, morgens mit einer klar sortierten To-do-Liste zu starten, nur um abends festzustellen, dass du zwar viel getan, aber wenig bewegt hast? Führungskräfte berichten davon regelmäßig. Der Kalender ist voll, die Mails stapeln sich, das Team fragt nach Entscheidungen. Und irgendwie fühlt sich alles gleich dringend an.
Das Problem: Wer alles gleichzeitig priorisiert, priorisiert gar nichts. Der Kopf ist beschäftigt, aber die Wirkung bleibt aus. Effektive Führung beginnt deshalb nicht mit dem Abarbeiten von Listen, sondern mit einer klaren Antwort auf die Frage: Was ist wirklich wichtig, und wer ist eigentlich dafür verantwortlich?
Dieser Artikel zeigt drei Methoden, die genau dabei helfen: die RACI-Matrix, Delegation Poker und die MoSCoW-Priorisierung.
Warum Führungskräfte so selten klar priorisieren
Prioritäten setzen klingt simpel. In der Praxis ist es das nicht. Es bedeutet, Nein zu sagen. Es bedeutet, Entscheidungen zu treffen, wenn noch nicht alle Informationen vorliegen. Und es bedeutet, loszulassen, also Verantwortung zu übergeben, auch wenn man selbst es vielleicht schneller oder besser könnte.
Dazu kommt: Viele Teams haben keine klare Aufgabenteilung. Alle wissen, dass Projekt X wichtig ist, aber niemand weiß genau, wer was entscheidet, wer zuarbeitet und wer am Ende die Verantwortung trägt. Das kostet Zeit, erzeugt Reibung und führt zu der typischen Führungsfalle: Die Führungskraft zieht alles an sich, weil es sonst niemand klar geregelt hat.
💡Hinweis Die drei Methoden in diesem Artikel greifen ineinander. Am wirksamsten sind sie, wenn du sie der Reihe nach einführst: erst Rollenklarheit (RACI), dann Delegation klären (Delegation Poker), dann gemeinsam priorisieren (MoSCoW).
RACI-Matrix: Klarheit über Rollen und Verantwortung
Bevor man priorisieren kann, muss klar sein, wer überhaupt für was zuständig ist. Genau hier hilft die RACI-Matrix, ein einfaches, aber wirkungsvolles Framework für Rollenklarheit.
RACI steht für vier Rollen, die jede Aufgabe oder Entscheidung braucht:
R – Responsible: Wer erledigt die Aufgabe?
A – Accountable: Wer trägt die finale Verantwortung und trifft die letzte Entscheidung?
C – Consulted: Wer wird einbezogen und um Input gebeten, bevor die Entscheidung fällt?
I – Informed: Wer wird über das Ergebnis informiert, aber nicht aktiv eingebunden?
Der entscheidende Unterschied zwischen R und A: Responsible kann auf mehrere Personen verteilt sein, also alle, die aktiv an einer Aufgabe arbeiten. Accountable liegt immer bei genau einer Person. Wenn zwei Personen A tragen, trägt es de facto niemand.
Ein konkretes Beispiel
Stell dir vor, dein Team soll einen neuen Onboarding-Prozess für neue Mitarbeitende entwickeln. Ohne klare Rollenverteilung passiert das, was viele kennen: HR denkt, der Team-Lead kümmert sich. Der Team-Lead denkt, IT hat das übernommen. Und am Ende landet es wieder auf dem Tisch der Führungskraft.
Mit einer RACI-Matrix sieht dasselbe Szenario so aus:
Aufgabe
HR-Leitung
Team-Lead
IT
Geschäftsführung
Prozess konzipieren
A
R
C
I
Tool-Entscheidung treffen
C
R
A
I
Kommunikation nach außen
R
C
I
A
Auf einen Blick ist erkennbar: Die HR-Leitung trägt die Gesamtverantwortung für die Konzeption, der Team-Lead arbeitet es aus, die IT wird gefragt, und die Geschäftsführung muss nur informiert werden, nicht in jeden Schritt einbezogen.
💡Hinweis Wenn du in deiner RACI-Matrix in zu vielen Zeilen als A stehst, hast du noch zu viel bei dir. Die Matrix macht das sichtbar und gibt dir die Grundlage, gezielt zu delegieren.
Delegation Poker: Was kannst du wirklich abgeben?
Delegieren ist mehr als jemanden beauftragen. Es gibt verschiedene Grade der Entscheidungsfreiheit, und wer das nicht klar kommuniziert, erzeugt Frustration in beide Richtungen: Das Team fühlt sich kontrolliert, die Führungskraft fühlt sich übergangen.
Delegation Poker (aus dem Management 3.0 Framework von Jurgen Appelo) bringt genau diese Abstufungen in ein einfaches Format. Es unterscheidet sieben Ebenen:
Tell – Ich entscheide und informiere das Team danach.
Sell – Ich entscheide, erkläre aber meine Gründe und hole Verständnis ab.
Consult – Ich frage das Team vorher um Input, entscheide dann selbst.
Agree – Wir entscheiden gemeinsam, Konsens ist das Ziel.
Advise – Das Team entscheidet, ich gebe eine Empfehlung, die es berücksichtigen kann.
Inquire – Das Team entscheidet, informiert mich danach kurz.
Delegate – Das Team entscheidet vollständig autonom, ohne Rückkopplung.
So funktioniert das Spiel in der Praxis
Du nennst eine konkrete Entscheidung oder Aufgabe, zum Beispiel: Wer entscheidet, welches Tool wir für die Projektkommunikation einsetzen? Dann schätzen Führungskraft und Teammitglieder gleichzeitig ein, auf welcher Ebene (1-7) sie diese Entscheidung verorten würden, ähnlich wie beim Planning Poker im Scrum.
Wenn du als Führungskraft Consult zeigst und dein Team Inquire erwartet hatte, habt ihr ein wertvolles Gespräch vor euch. Nicht weil jemand falsch liegt, sondern weil ihr unterschiedliche Erwartungen hattet, und die jetzt klären könnt.
Ein Beispiel aus dem Führungsalltag
Eine Teamleiterin stellt fest, dass ihr Team immer wieder auf Entscheidungen wartet, die es auch selbst treffen könnte. Im Delegation Poker stellt sich heraus: Bei Budgetfragen unter 500 Euro hat sie innerlich Advise im Kopf, ihr Team aber Sell erwartet. Nach dem Gespräch ist klar: Für Ausgaben unter 500 Euro entscheidet das Team selbst. Die Teamleiterin wird nur informiert, wenn das monatliche Budget knapp wird.
Das Ergebnis: weniger Rückfragen, mehr Eigenverantwortung, und eine Führungskraft, die sich auf tatsächlich wichtige Entscheidungen konzentrieren kann.
💡Hinweis Delegation Poker hilft dir zu erkennen, welche Aufgaben du getrost freigeben kannst, und bei welchen dein aktives Urteil wirklich gefragt ist. Wer weniger entscheidet, kann sich auf das konzentrieren, was wirklich zählt.
MoSCoW-Priorisierung: Was kommt wirklich zuerst?
Wenn klar ist, wer wofür zuständig ist und was delegiert werden kann, stellt sich die nächste Frage: In welcher Reihenfolge arbeiten wir das ab? Hier kommt die MoSCoW-Methode ins Spiel, ein pragmatisches Framework, das ursprünglich aus der Softwareentwicklung stammt, sich aber hervorragend auf Führungsaufgaben und Projektplanung übertragen lässt.
MoSCoW kategorisiert Aufgaben in vier Gruppen:
Must have – Nicht verhandelbar. Ohne diese Aufgabe scheitert das Projekt oder die Periode.
Should have – Wichtig und wertvoll, aber bei Zeitdruck verschiebbar. Der Schaden ist überschaubar.
Could have – Wünschenswert, aber nur dann, wenn Zeit und Ressourcen es erlauben.
Won't have (this time) – Bewusste Entscheidung: nicht jetzt. Vielleicht im nächsten Quartal. Vielleicht nie.
Die letzte Kategorie ist dabei oft die schwierigste, und die wirksamste. Won't have bedeutet nicht unwichtig, sondern: Wir haben eine bewusste Entscheidung getroffen, den Fokus anders zu setzen. Das ist echter Führungsmut.
Ein Beispiel: Quartalsplanung im Team
Ein Team plant das nächste Quartal und hat deutlich mehr Ideen als Kapazität. Gemeinsam sortieren sie:
Must have: Produktfehler aus dem letzten Release beheben, Kundenpräsentationen vorbereiten, neues Teammitglied einarbeiten.
Should have: Prozessdokumentation aktualisieren, interne Schulung zu neuen Tools durchführen.
Could have: Blogbeiträge für die Unternehmenswebsite schreiben, eine neue Vorlage für Statusberichte entwickeln.
Won't have this quarter: Eine vollständige Neugestaltung des Onboarding-Prozesses. Das Thema ist wichtig, aber zu groß für dieses Quartal. Es kommt auf die Agenda für Q3.
Das Ergebnis: Das Team weiß, worauf es sich konzentriert, und hat eine begründete Antwort, wenn jemand fragt, warum das Onboarding noch nicht überarbeitet wurde. Kein Schulterzucken, sondern eine klare Entscheidung.
💡Tipp für die Praxis Nutze MoSCoW nicht nur für Projekte, sondern auch für deine persönliche Wochenliste. Was muss diese Woche passieren? Was sollte? Was könnte, und was entscheidest du aktiv, jetzt nicht anzugehen?
Die drei Methoden im Zusammenspiel
Einzeln sind RACI, Delegation Poker und MoSCoW bereits hilfreich. Zusammen entfalten sie ihre volle Wirkung:
Erst Klarheit über Rollen (RACI), dann entscheiden, wie viel Entscheidungsfreiheit du abgibst (Delegation Poker), und schließlich gemeinsam festlegen, was wirklich zuerst kommt (MoSCoW).
Das klingt nach Aufwand. Ist es am Anfang auch. Aber Teams, die einmal gemeinsam eine RACI-Matrix erarbeitet und eine MoSCoW-Runde gedreht haben, berichten regelmäßig: Meetings werden kürzer, Entscheidungen werden klarer, und das Gefühl von alles ist gleich dringend lässt spürbar nach.
Fazit: Priorisieren ist eine Führungsaufgabe, keine Fleißaufgabe
Effektive Führungskräfte sind nicht diejenigen, die am meisten arbeiten. Sie sind diejenigen, die am klarsten wissen, was zählt, und die Energie dorthin lenken. Das braucht Methoden. Aber vor allem braucht es den Mut, auch mal Nein zu sagen: zu Aufgaben, zu Meetings, zu Erwartungen.
RACI gibt Klarheit über Verantwortung. Delegation Poker schafft Raum für das Team. MoSCoW setzt den Fokus. Drei Werkzeuge, eine Wirkung: Du führst bewusster, und dein Team arbeitet selbstständiger.
Kannst Du für mich vlt. „outcome>output“ erläutern? Ich hab‘s erst als „größer“-Zeichen gelesen.
Gute Frage.
„Outcome > Output“ meint nicht „größer als“, sondern „wichtiger als“.
Output ist das, was du produzierst: Features, Tasks, Tickets, Berichte.
Outcome ist die Wirkung dahinter: Problem gelöst, Wert geschaffen, Kunde zufriedener.
Team Architecture: Die 5 Teamformen
Arbeiten alle Teamformen mit den gleichen Methoden?
Nein. Jede Teamform braucht eigene Routinen, Artefakte und Entscheidungswege.
Eine Task Force arbeitet anders als ein Produktteam.
Wenn Methodik und Teamform nicht zusammenpassen, entsteht Reibung. Selbst wenn die Personen kompetent sind.
CALM Overview
Für welche Organisationsgrößen ist CALM geeignet?
CALM eignet sich für Organisationen ab ca. 3 Teams aufwärts, überall dort, wo Koordination, Abhängigkeiten und Priorisierungskonflikte zum Alltag gehören. Typisch sind IT-Bereiche, Produktorganisationen und Plattformteams.
Wenn alles wichtig ist, ist nichts wichtig – Prioritäten in der Führungsrolle setzen
Für welche Teams eignen sich RACI, Delegation Poker und MoSCoW?
Für alle, ob klein oder groß, ob remote oder im Büro. Besonders wirksam sind sie in Phasen hoher Belastung oder beim Start neuer Projekte, wenn viele Aufgaben gleichzeitig auf dem Tisch liegen.
CALM Overview
Gibt es einen empfohlenen Einstiegspunkt in CALM?
Typischer Einstieg ist ein kostenfreies Orientierungsgespräch, in dem Ziele, Engpässe und sinnvoller Scope geklärt werden. Optional folgt ein kurzes Operating Rhythm Assessment mit ausgewählten Stakeholdern.
Entscheidungsmechanismen
Kann ein Team den Modus selbst wählen?
Ja, wenn der Rahmen es erlaubt. In autonomen und delegierten Kontexten entscheidet das Team auch darüber, wie es entscheidet. In konsultativen oder direktiven Situationen gibt Führung den Modus vor. CALM empfiehlt, den Modus explizit zu benennen, nicht implizit vorauszusetzen.
Team Architecture: Die 5 Teamformen im CALM Operating Model
Kann ein Team die Teamform im Laufe der Zeit wechseln?
Ja – und das ist sogar erwünscht. Ein Zielteam kann nach Zielerreichung in ein Projektteam übergehen, wenn der Scope wächst. Ein Projektteam kann zum Produktteam werden, wenn Dauerverantwortung entsteht. CALM beschreibt diese Übergänge explizit, damit die passende Führungslogik rechtzeitig angepasst wird.
Rollen & Verantwortlichkeiten
Kann eine Person mehrere Funktionen übernehmen?
Ja – in kleinen Teams ist das häufig sinnvoll. Die Flussverantwortung kann mit der Ergebnisverantwortung zusammenfallen. Richtungsverantwortung und Ergebnisverantwortung sollten möglichst getrennt sein, wenn Zielkonflikte wahrscheinlich sind.
Wenn alles wichtig ist, ist nichts wichtig – Prioritäten in der Führungsrolle setzen
Kann ich MoSCoW auch für meinen persönlichen Führungsalltag nutzen?
Absolut. Viele Führungskräfte nutzen die Kategorien als tägliches oder wöchentliches Sortierprinzip, nicht nur für Projekte, sondern auch für die eigene Agenda.
Team Architecture: Die 5 Teamformen
Können Personen gleichzeitig in mehreren Teamformen aktiv sein?
Grundsätzlich ja, aber mit Bedacht. Parallelarbeit in mehr als zwei Teams führt häufig zu Kontextwechsel, verringerter Lieferqualität und diffuser Verantwortung. CALM empfiehlt, Mehrfachzugehörigkeiten explizit zu machen und regelmäßig zu hinterfragen.
Arbeitsroutinen & Meetings
Muss jede Teamform dieselben Routinen haben?
Nein. CALM passt Routinen an die Teamform an. Eine Task Force braucht tägliche Abstimmung und kein strategisches Planning. Ein Produktteam profitiert von stabilen Review- und Retro-Rhythmen. Ein Linienteam arbeitet mit einem operativen Jour-Fixe ohne Iterationsplanung. Das Grundprinzip: Routinen folgen dem Zweck, nicht umgekehrt.
Rollen & Verantwortlichkeiten im CALM Operating Model
Passt das CALM-Rollenmodell auch für klassisch geführte Unternehmen?
Ja. CALM ist rollenneutral – es beschreibt Funktionen, keine Methoden. Ob die Organisation nach Scrum, PRINCE2 oder klassischer Linie arbeitet, ist für das Grundprinzip irrelevant. Die drei Funktionen sind überall vorhanden – in manchen Organisationen nur nicht explizit gemacht.
Entscheidungsmechanismen
Wann brauche ich ein ADR und wann nicht?
Ein ADR lohnt sich, wenn die Entscheidung mehrere Teams betrifft, langfristige Auswirkungen hat oder erfahrungsgemäß immer wieder diskutiert wird. Rein operative Entscheidungen innerhalb eines Teams brauchen kein ADR.
Team Architecture: Die 5 Teamformen im CALM Operating Model
Wann macht eine Task Force Sinn – und wann nicht?
Eine Task Force ist das richtige Instrument bei akuten Krisen, dringendem Problemlösungsbedarf oder kritischen Entscheidungen unter Zeitdruck. Sie macht keinen Sinn, wenn das Problem strukturell ist und länger anhält – dann ist ein Ziel- oder Projektteam die richtige Wahl. Task Forces scheitern, wenn sie zu lange bestehen oder mit zu viel Prozess belastet werden.
Team Architecture: Die 5 Teamformen
Wann macht eine Task Force Sinn und wann nicht?
Eine Task Force ist das richtige Instrument bei akuten Krisen oder kritischen Entscheidungen unter Zeitdruck. Sie macht keinen Sinn, wenn das Problem strukturell ist und länger anhält – dann ist ein Ziel- oder Projektteam die richtige Wahl. Task Forces scheitern, wenn sie zu lange bestehen oder mit zu viel Prozess belastet werden.
Team Architecture: Die 5 Teamformen
Warum ausgerechnet 5 Teamformen? Warum nicht 3 oder 7?
Die fünf Teamformen sind nicht willkürlich, aber auch keine starre wissenschaftliche Taxonomie. Es ist ein Ansatz, der aus der Praxis gewachsen ist und deshalb im Alltag funktioniert. Ein Modell, das sich aus Mustern gebildet hat, die immer wieder auftreten.
Welche Einheiten tauchen in Organisationen wieder und wieder auf?
Welche Muster sind stabil? Welche unterscheiden sich strukturell und nicht nur semantisch?
Dabei ergeben sich fünf Formen, die sich entlang dreier Dimensionen klar trennen lassen:
-> Zweck: Problem lösen, Ziel erreichen, Projekt liefern, Produkt entwickeln, Betrieb sichern
-> Dauer: sehr kurz bis dauerhaft
-> Stabilität und Rollenlogik: adhoc bis hoch formalisiert
Warum nicht 3 oder 7?
Weil 3 zu grob wäre und 7 zu kleinteilig.
Fünf ist der Punkt, an dem das Modell praktisch bleibt, ohne die Realität zu verzerren.
Die „Ontologie“ dahinter ist also:
Unterschiedliche Formen entstehen aus Zweck, Dauer, Stabilität und Wertschöpfungslogik.
Und diese Kombination bildet in der Praxis genau fünf wiederkehrende Klassen.
Team Architecture: Die 5 Teamformen
Warum führt fehlende Teamarchitektur zu Frust und Überlastung?
Weil Menschen Erwartungen erfüllen wollen. Wenn aber unklar ist, welche Form sie gerade sind, für welches Ziel sie arbeiten und wie Entscheidungen fallen, entsteht ein Dauerzustand von Unsicherheit.
Struktur schützt.
Sie schafft Orientierung und reduziert mentale Last.
Team Architecture: Die 5 Teamformen
Warum funktionieren kleine Teams oft besser?
Kleine Teams (4–7 Personen) treffen schneller Entscheidungen, arbeiten fokussierter und koordinieren sich leichter.
Das gilt über alle Teamformen hinweg.
Größere Teams neigen zu Subgruppen, Parallelkommunikation und mehr Abstimmungsschleifen.
Rollen & Verantwortlichkeiten
Warum hat CALM kein vollständiges RACI-Modell?
Weil RACI als Vollbild schnell zum bürokratischen Overhead wird. CALM setzt auf das Minimalprinzip: Jede Arbeit braucht genau eine outcome-verantwortliche Person. RACI kann als ergänzendes Werkzeug sinnvoll sein – für kritische Entscheidungsbereiche und Schnittstellen, nicht als Standard.
Agile Transformation heißt nicht Scrum, sondern Organisationsdesign
Warum reicht die Einführung von Scrum nicht für eine agile Transformation?
Scrum verändert die Arbeitsweise von Teams, aber nicht die Organisation als Ganzes. Entscheidungsstrukturen, Budgetierungsprozesse, HR-Systeme, Führungsverständnis und Unternehmenskultur müssen ebenfalls transformiert werden, damit Agilität nachhaltig wirkt.
Führung & Zusammenarbeit
Was bedeutet situatives Führen in CALM?
Den Führungsstil und die Führungsintensität an Situation und Reifegrad des Teams anpassen, nicht eine Haltung für alle Situationen durchhalten. CALM gibt den Rahmen, wann Direktive, Coaching oder Delegation das richtige Mittel ist, und macht diese Entscheidung bewusster.
Führung & Zusammenarbeit
Was hat psychologische Sicherheit mit Führung zu tun?
Psychologische Sicherheit entsteht nicht von selbst, sie wird durch Führungsverhalten erzeugt oder verhindert. Wer Fehler bestraft, bekommt keine Fehler gemeldet, sondern Überraschungen. Wer Feedback einfordert, aber nicht auf Rückmeldung reagiert, zerstört Vertrauen. CALM-Führung verankert Feedback als Routineelement und macht diese Zusammenhänge explizit.
Agile Transformation heißt nicht Scrum, sondern Organisationsdesign
Was ist agile Transformation?
Agile Transformation bezeichnet den tiefgreifenden Wandel einer Organisation hin zu mehr Agilität – also mehr Anpassungsfähigkeit, Kundenorientierung und Innovationskraft. Sie geht weit über die Einführung von Scrum oder Kanban hinaus und betrifft Strukturen, Prozesse und Kultur.
Team Architecture: Die 5 Teamformen
Was ist der Unterschied zwischen einem Projektteam und einem Produktteam?
Ein Projektteam ist temporär und löst sich nach Abschluss auf. Ein Produktteam ist dauerhaft, crossfunktional und begleitet den gesamten Produktlebenszyklus. Der entscheidende Unterschied liegt in Stabilität, Ownership und Führungslogik: Projektteams brauchen koordinierende Führung, Produktteams Servant Leadership und Empowerment.
Team Architecture: Die 5 Teamformen im CALM Operating Model
Was ist der Unterschied zwischen einem Projektteam und einem Produktteam?
Ein Projektteam ist eine temporäre Organisationseinheit mit klarem Ende – es löst sich nach Abschluss auf. Ein Produktteam ist dauerhaft, crossfunktional und begleitet den gesamten Produktlebenszyklus. Der entscheidende Unterschied liegt in Stabilität, Ownership und Führungslogik: Projektteams brauchen koordinierende Führung, Produktteams Servant Leadership und Empowerment.
Rollen & Verantwortlichkeiten
Was ist der Unterschied zwischen einer Rolle und einer Position?
Eine Position beschreibt die organisatorische Stelle (z. B. Teamleitung IT). Eine Rolle beschreibt eine Funktion mit konkreter Verantwortung. CALM benennt ausschließlich Funktionen – welcher Titel dazu passt, entscheidet der Kontext.
Strategie & Value Streams
Was ist der Unterschied zwischen strategischen Objectives und taktischen Zielen?
Strategische Objectives (1-2 Jahre) definieren die Richtung und Leitplanken, ohne Detailsteuerung. Taktische Ziele (1-12 Monate) übersetzen diese Richtung in konkrete Initiativen und messbare Ergebnisse für Teams und Programme.
Arbeitsroutinen & Meetings
Was ist ein Direction Day in CALM?
Der Direction Day ist das Format für die quartalsweise Ausrichtung auf strategischer Ebene. Er dauert einen halben bis ganzen Tag und bringt den Leitungskreis – bei Bedarf erweitert um den Führungskreis – zusammen, um Quartalsziele zu reviewen, die Roadmap für die nächsten 12 Wochen auszurichten und ein gemeinsames Lagebild herzustellen. Er ersetzt viele kleinere Einzelabstimmungen und schafft die Grundlage für alle taktischen und operativen Routinen des Quartals.
Rollen & Verantwortlichkeiten im CALM Operating Model
Was ist, wenn eine Person alle drei Funktionen trägt?
In sehr kleinen Teams ist das häufig. Es ist legitim – solange die Person weiß, welche Funktion sie gerade ausführt. Problematisch wird es, wenn Richtungsentscheidungen und Ergebnisverantwortung dauerhaft bei einer Person liegen und gleichzeitig Skalierung erwartet wird. Dann ist eine bewusste Trennung der nächste Schritt.
Entscheidungsmechanismen
Was passiert, wenn der falsche Modus gewählt wird?
Zu viel Autonomie ohne Rahmen führt zu Orientierungslosigkeit. Zu viel Direktive ohne Notwendigkeit führt zu Demotivation und Abhängigkeit. CALM macht den Modus explizit, damit er bewusst gewählt und bei Bedarf angepasst werden kann.
Rollen & Verantwortlichkeiten
Was passiert, wenn niemand die Ergebnisverantwortung trägt?
Dann trägt sie formal alle – und praktisch niemand. Das Ergebnis sind Abstimmungsschleifen, informelle Führung und Eskalationen nach oben. Die fehlende Funktion entsteht trotzdem – nur ungeplant und ohne Mandat.
Team Architecture: Die 5 Teamformen
Was passiert, wenn Teamformen vermischt werden?
Viele Organisationen erwarten von einem Team gleichzeitig die Geschwindigkeit einer Task Force, die Struktur eines Projektteams und die Stabilität eines Linienteams.
Das führt fast immer zu widersprüchlichen Erwartungen, unnötigen Abstimmungen und Frust.
Klarheit über die Form schafft Klarheit über Arbeitsweise, Verantwortlichkeiten und Erfolgskriterien.
Führung & Zusammenarbeit
Was sind die CALM Leadership Essentials?
Fünf Verhaltensweisen, die wirksame Führung in jeder Teamform ausmachen: Klarheit zuerst, Entscheidungen messbar machen, Stabilität wo nötig, Flexibilität wo sinnvoll, Routinen statt Aktionismus. Sie beschreiben keine Persönlichkeit, sondern konkrete Führungshandlungen.
Arbeitsroutinen & Meetings
Was sind die drei Teilnehmendenkreise in CALM?
CALM unterscheidet drei Kreise, die jeweils einer Ebene entsprechen: Der Team-Kreis umfasst die direkt liefernden Personen und ihre Teamleads – er trifft operative Entscheidungen auf Iterationsebene. Der Führungskreis besteht aus Führungspersonen, die Initiativen, Roadmap und Ressourcen steuern – taktische Ebene. Der Leitungskreis setzt strategische Ziele und Rahmenbedingungen – er entscheidet über Richtung, nicht über Details. Die Trennung verhindert, dass strategische Themen operative Meetings blockieren – und umgekehrt.
CALM Overview
Was unterscheidet CALM von Frameworks wie SAFe oder LeSS?
CALM ist kein Skalierungsframework, sondern ein Operating-Model-Gerüst. Es definiert keine spezifischen Rollen oder Zeremonien, sondern gibt Prinzipien, Ebenen und Mechanismen vor: framework-agnostisch und anpassbar. Es kann bestehende Setups ergänzen oder ersetzen.
Arbeitsroutinen & Meetings
Was unterscheidet Review und Retrospektive?
Die Review bewertet das Ergebnis: Was wurde geliefert, was wurde gelernt, was kommunizieren wir nach außen? Die Retrospektive bewertet den Prozess: Wie haben wir zusammengearbeitet und was wollen wir verbessern? CALM empfiehlt beide als getrennte Formate, auch wenn sie zeitlich nah beieinander liegen.
Strategie & Value Streams
Was versteht CALM unter einem Value Stream?
Ein Value Stream beschreibt den Weg vom Kundenimpuls bis zur Lieferung. Er macht sichtbar, welche Teams, Systeme und Prozesse an der Wertschöpfung beteiligt sind, und wo Engpässe entstehen. Im CALM-Kontext ist er Grundlage für Teamzuschnitte und Priorisierungsentscheidungen.
Agile Transformation heißt nicht Scrum, sondern Organisationsdesign
Was versteht man unter agiles Organisationsdesign?
Agiles Organisationsdesign beschreibt die bewusste Gestaltung von Strukturen und Prozessen, die Agilität ermöglichen: flache Hierarchien, cross-funktionale Teams, dezentrale Entscheidungsfindung, schnelle Feedback-Schleifen und eine Kultur, die Experimente und Lernen fördert.
Wenn alles wichtig ist, ist nichts wichtig – Prioritäten in der Führungsrolle setzen
Was, wenn das Team beim Delegation Poker sehr unterschiedliche Einschätzungen hat?
Genau dann entfaltet die Methode ihren größten Nutzen. Unterschiede in der Einschätzung zeigen, wo Erwartungen auseinandergehen, und eröffnen das Gespräch, das vorher nie stattgefunden hat.
Wenn alles wichtig ist, ist nichts wichtig – Prioritäten in der Führungsrolle setzen
Welche Methode sollte ich zuerst einführen?
Starte mit MoSCoW – sie lässt sich sofort und ohne Vorbereitung im nächsten Teammeeting einsetzen. RACI und Delegation Poker brauchen etwas mehr Zeit und eignen sich gut für einen dedizierten Workshop-Slot.
Team Architecture: Die 5 Teamformen
Welche Risiken entstehen, wenn Mitarbeitende in mehreren Teamformen gleichzeitig arbeiten?
Mehrfachzugehörigkeit führt häufig zu Kontextwechsel, diffusen Zielen, Priorisierungskonflikten und psychischer Belastung.
CALM empfiehlt, Mehrfachrollen transparent zu machen und klar zu priorisieren, welche Einheit Vorrang hat (Linie, Projekt oder Produkt).
Team Architecture: Die 5 Teamformen im CALM Operating Model
Welche Rolle spielt Teambuilding je nach Teamform?
Das hängt stark von der Teamform ab: Eine Task Force braucht kein intensives Teambuilding – Zeit ist ihr knappste Ressource. Ein Zielteam braucht moderates Teambuilding. Ein Projektteam profitiert bei längerer Laufzeit von gezielten Teamaktivitäten. Produktteams und Linienteams benötigen essentielles Teambuilding, da Stabilität und Kultur dort direkte Leistungstreiber sind.
Führung & Zusammenarbeit
Wie begleitet CALM Führungskräfte in der Transformation?
CALM kombiniert strukturelle Maßnahmen mit Führungskräfte-Coaching. Ziel ist nicht nur ein besseres Modell auf dem Papier, sondern veränderte Führungsgewohnheiten im Alltag. Begleitung über Wochen, nicht durch einmalige Workshops.
Entscheidungsmechanismen
Wie finde ich den richtigen Modus für eine Entscheidung?
Zwei Fragen helfen: Wer trägt die Konsequenz? Und wie viel Zeit und Information ist vorhanden? Je klarer der Rahmen und je stabiler die Situation, desto mehr Autonomie ist möglich. Je höher Unsicherheit oder Tragweite, desto eher ist ein konsultativer oder direktiver Modus angemessen.
Rollen & Verantwortlichkeiten im CALM Operating Model
Wie führe ich Rollenklarheit ein, ohne einen großen Change-Prozess auszulösen?
Starte mit Funktion 2: Für jede laufende Initiative eine outcome-verantwortliche Person benennen. Das ist eine Entscheidung, keine Reform. Kein neues Framework, keine Umstrukturierung. Der Rest folgt, wenn der Bedarf entsteht.
Team Architecture: Die 5 Teamformen
Wie groß sollte ein Team idealerweise sein?
CALM orientiert sich an der '2-Pizza-Regel': 5-9 Personen sind ideal. Kleinere Teams kommunizieren effizienter und haben klarere Verantwortung. Größere Teams tendieren zu Subgruppen und erhöhtem Koordinationsaufwand. Entscheidend ist, dass das Team autonom liefern kann.
Entscheidungsmechanismen
Wie hängen Entscheidungsmechanismen und Rollenklarheit zusammen?
Ein Entscheidungsmodus ohne klar benannte accountable Person bleibt wirkungslos. Deshalb bauen Entscheidungsmechanismen (Layer 5) direkt auf Rollen und Verantwortlichkeiten (Layer 3) auf. Wer welchen Modus nutzen darf, hängt davon ab, wer welche Funktion trägt.
Team Architecture: Die 5 Teamformen im CALM Operating Model
Wie hängt Team Architecture mit dem restlichen CALM-Modell zusammen?
Team Architecture ist Layer 3 von CALM. Sie verbindet die strategische Richtung (Layer 1: Strategie & Value Streams) mit den operativen Ebenen (Rollen, Routinen, Entscheidungen). Erst wenn klar ist, welche Teamform vorliegt, lassen sich passende Rollen (RACI, Ownership), Meetings und Entscheidungsmechanismen definieren. Ohne klare Teamarchitektur bleibt jedes Operating Model unvollständig.
Strategie & Value Streams
Wie häufig sollte die Strategie überprüft werden?
CALM empfiehlt einen strategischen Direction Day einmal pro Quartal sowie eine tiefere Strategie-Review einmal pro Jahr. Wichtig ist nicht die Häufigkeit, sondern dass die Überprüfung zu konkreten Entscheidungen und Anpassungen führt.
CALM Overview
Wie lange dauert eine typische CALM-Einführung?
Blueprint und Einführung dauern in der Regel 2-3 Wochen (Design) plus 6-10 Wochen (Enablement/Pilot). Der genaue Umfang hängt von Größe, Anzahl Teams und gewünschter Begleitungstiefe ab.
Wenn alles wichtig ist, ist nichts wichtig – Prioritäten in der Führungsrolle setzen
Wie oft sollte man die RACI-Matrix aktualisieren?
Bei größeren Veränderungen im Team oder bei neuen Projekten lohnt es sich, die Matrix kurz zu überprüfen. Sie ist kein starres Dokument, sondern ein lebendiges Orientierungsinstrument.
Arbeitsroutinen & Meetings
Wie oft sollten taktische Routinen stattfinden?
CALM empfiehlt einen 2-wöchentlichen Taktischen Jour-Fixe für laufende Initiativen sowie eine monatliche Release- und Roadmap-Planung. Bei hoher Dynamik kann der Jour-Fixe auf wöchentlich verdichtet werden. Wichtig ist die Konstanz: Unregelmäßige taktische Routinen führen zu Informationsverlusten, Überraschungen im Planning und sinkendem Vertrauen in die Roadmap.
Rollen & Verantwortlichkeiten im CALM Operating Model
Wie unterscheidet sich das CALM-Rollenmodell von RACI?
RACI beschreibt, wer bei einer Entscheidung oder Aufgabe welche Rolle spielt (Responsible, Accountable, Consulted, Informed). CALM beschreibt drei Grundfunktionen, die in jeder Organisation strukturell vorhanden sein müssen. Beide Ansätze ergänzen sich: CALM gibt die Struktur vor, RACI kann für kritische Entscheidungsbereiche ergänzend eingesetzt werden.
Team Architecture: Die 5 Teamformen
Wie unterscheidet sich ein Zielteam von einem Projektteam?
Zielteams haben einen klar abgesteckten, einzelnen Fokus – oft ein OKR-Ziel – und eine typische Laufzeit von rund 6 Monaten. Projektteams verfolgen mehrere oder komplexere Ziele, haben oft Matrixstrukturen und formalisierte Rollen. Zielteams sind leichtgewichtiger und ergebnisorientierter, Projektteams stärker koordiniert und strukturiert.
Team Architecture: Die 5 Teamformen im CALM Operating Model
Wie unterscheidet sich ein Zielteam von einem Projektteam?
Zielteams haben einen klar abgesteckten, einzelnen Fokus (oft ein OKR-Ziel) und eine typische Laufzeit von rund 6 Monaten. Sie sind ergebnisorientiert, nicht strukturerhaltend. Projektteams verfolgen mehrere oder komplexere Ziele, haben oft Matrixstrukturen, formalisierte Rollen und mehr Abhängigkeiten. Zielteams sind leichtgewichtiger und taktischer.
Führung & Zusammenarbeit
Wie unterscheidet sich Führung je nach Teamform?
Eine Task Force braucht direktive, klare Führung mit engem Feedback-Loop. Ein Produktteam braucht Servant Leadership, das Autonomie ermöglicht und Hindernisse beseitigt. Ein Linienteam braucht Stabilität und Entwicklungsorientierung. CALM hilft Führungskräften, den Stil bewusst an den Teamkontext anzupassen, nicht unreflektiert beizubehalten.
Team Architecture: Die 5 Teamformen im CALM Operating Model
Wie unterscheidet sich Führung je nach Teamform?
Eine Task Force braucht direktive, klare Führung mit engem Feedback-Loop. Ein Zielteam braucht facilitative, coachende Führung, die Fokus und Klarheit sicherstellt. Ein Projektteam braucht koordinierende, strukturgebende Führung. Ein Produktteam braucht Servant Leadership und Empowerment. Ein Linienteam braucht stabile, entwicklungsorientierte Führung. CALM macht diese Unterschiede explizit und hilft Führungskräften, ihren Stil bewusst anzupassen.
Rollen & Verantwortlichkeiten
Wie verhält sich CALM zu Scrum, PRINCE2 oder klassischer Linienorganisation?
CALM ersetzt keine bestehenden Rollen, sondern beschreibt die Funktionen hinter den Titeln. Ein Product Owner kann Richtungs- oder Ergebnisverantwortung tragen – je nach Teamaufstellung. Ein Scrum Master ist eine klassische Ausprägung der Flussverantwortung.
Arbeitsroutinen & Meetings
Wie verhindert CALM Meeting-Overload?
Durch feste Routinen auf klar definierten Ebenen entfällt der Bedarf an Ad-hoc-Abstimmungen. Jedes Meeting hat eine klare Eigenschaft: Ebene, Frequenz, Teilnehmendenkreis und Entscheidungsmandat. Meetings ohne Entscheidungsoutput werden konsequent hinterfragt oder gestrichen. Wer auf der richtigen Ebene spricht, muss nicht überall mitsprechen.
Strategie & Value Streams
Wie viele Value Streams braucht eine Organisation?
So wenige wie möglich, so viele wie nötig. Typisch sind 2-5 Value Streams für mittelgroße IT-Organisationen. Zu viele Streams erzeugen neue Silos; zu wenige schaffen unklare Verantwortung. Entscheidend ist, dass jeder Stream einen klaren Kundennutzen und einen Owner hat.
