Planung, Scrum und mein Planungstyp

„Wenn Du wenig Zeit hast, nimm Dir am Anfang viel davon“, rät uns Ruth Cohn.

Kennen Sie das auch: So manches Vorhaben beginnt diffus und endet dann auch so. Der Ergebnisdruck ist hoch, schnelle Erfolge werden erwartet und daher fängt man schon mal an, denn „der Appetit kommt ja beim Essen“.

Wenn ich dann die Befürworter dieser „schon mal loslegen“ Strategie näher befrage, höre ich oft, dass die Planung sowieso zu lange dauere und man eh ja keinen so bürokratischen Prozess brauche. Und dann kommt die Frage, ob ich mich mit Scrum und agilen Methoden auskennen würde…
…eine gute Gelegenheit, mit dem Missverständnis aufzuräumen, dass bei SCRUM keine Pläne mehr nötig sind. Vielmehr beinhaltet das SCRUM framework die Möglichkeit, Pläne ständig anpassen zu können.

Planung bekommt eine neue Funktion: flexibel Agieren auf der Grundlage einer soliden Planung. Das ist kein Widerspruch, sondern gerade die Kunst eines wirksamen Managements. Pläne sind dazu da, Orientierung zu geben. Sie stecken den Korridor ab, in dem man in der nächsten Phase mit hoher Wahrscheinlichkeit tätig sein wird. Pläne, die nach diesem neuen Verständnis erstellt werden, geben den Managern und Mitarbeitern die notwendige Orientierung, um auch unter wechselnden Rahmenbedingungen handlungsfähig zu sein.

Pläne sind notwendig, um eine Veränderung überhaupt zu beurteilen und nicht der Beliebigkeit anheimfallen zu lassen. So wird ein Kapitän auch im schwersten Sturm die Steuerung und den Betrieb seines Schiffes nicht dem freien Spiel der Kräfte überlassen; denn sonst droht Chaos und – wenn die Mannschaft emotional aufgeladen ist – vielleicht sogar Anarchie. Er wird deshalb immer genau in die Mitte der Fahrrinne zwischen unverrückbaren Plänen und kontextloser Beliebigkeit steuern.

6 Kommentare zu „Planung, Scrum und mein Planungstyp“

  1. Lieber Olaf,

    finde ich sehr zutreffend, Deine Zusammenfassung. Wir vergessen zu oft, das Pläne lediglich Hilfsmittel sind und keine Wahrheit abbilden. Sie sind in meinem Verständnis vielmehr lediglich eine Visualisierung all der Gedanken, die wir uns eh machen.

    Beste Grüße aus dem Süden
    Holger

  2. Widerspruch zu „Pläne sind notwendig, um eine Veränderung überhaupt zu beurteilen und nicht der Beliebigkeit anheimfallen zu lassen“:

    Ersetze „Pläne“ durch „Ziele und Messungen“. Pläne sind notwendig, um nicht beliebige, nicht zielführende Veränderungen zu verfolgen.

    ja/nein/anders? 🙂

    liebe grüße
    sacha

  3. Pläne sind notwendig, weil es einen Referenzpunkt braucht, an dem ich (be)merken kann, dass es eine Veränderung gibt/ braucht. Wenn es also „nicht nach Plan“ läuft, bemerke ich die Notwendigkeit einer Veränderung.
    So war es gemeint…

  4. Lieber Olaf, ich lese das mit Interesse, finde aber, die Unterscheidung zwischen „Planung“ und „Vorbereitung“ hätte dem Blogartikel gut getan. Denn in der Tat gibt es bei SCRUM keine Planung (wenn man mal genau hinschaut, wie das funktioniert); sondern es gibt Vorbereitung. Das ist ein ganz anderes Genre. Planung ist ja vom Handeln zeitlich, personell und oft geografisch entkoppelt. Bei Scrum (und Co.) ist das zusammengelegt. Ähnlich wie z.B. im PDCA-Zyklus oder in Lean usw. Der Unterschied ist gewaltig. Und auch in der Sprache sollte der ausgedrückt werden, damit endlich mehr das verstehen und auch machen können.

  5. Ich kann den Rat „Wenn Du wenig Zeit hast, nimm Dir am Anfang viel davon“ nur unterstreichen.

    Als Scrum-Master erlebe ich es live, dass die Anforderungen halb gar in die Entwicklung genommen werden. Es gibt zwar einen groben Fahrplan, der jedoch aufgrund mangelnder Anforderungsqualität nie erfüllt werden kann.

    Hintergrund ist ein Project-Chaining, also das Aneinanderreihen von Folgeprojekten.

    Weil der Fachbereich neben der Klärung auch testen, schulen und seinen Urlaub nehmen muss, können für das nachfolgende Projekt die Anforderungen nicht hinreichend geklärt werden. Die Entwickler müssen also entweder Aufräumen (Refactoring); was für das Management keinen erkennbaren Benefit bringt, oder halb fertige Anforderungen umsetzen und dann hinterher korrigieren.

    Das Management denkt häufig, dass mit Agilität alles schneller geht oder halb klare Anforderungen umgesetzt werden können. Natürlich klappt das nicht.

  6. Pingback: Der Chef, die Strategie und die Folien vom McKinsey-Berater - Olaf Hinz-wirkt

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen