Planlos agil

8 Kommentare

Schon seit einigen Jahren fühlt es sich für mich immer irgendwie komisch an, in agilen Projekten von Planung zu sprechen und sogar Planungs-Meetings durchzuführen. Hier ein paar Gedanken, warum die Verwendung dieses Begriffs fragwürdig erscheint.

Planung, auch Projektplanung, kommt aus der Welt der klassischen Organisationsstruktur. Hier werden Pläne von Managern erstellt, die anschließend innerhalb von Abteilungen oder Projektteams umgesetzt werden. Eine strikte Trennung von Denken und Handeln, die wir in der agilen Welt nicht kennen.

Klassische Organisationsstrukturen sind aufgebaut wie eine Pyramide. In der Spitze der Pyramide werden von wenigen Entscheidern Ziele definiert. Manager auf den darunter liegenden Ebenen überlegen sich Wege, auf denen diese Ziele erreicht werden sollen. Diesen Prozess nennt man Planung.

Der Weg, der zur Erreichung eines Ziels führen soll, wird Plan genannt.

Auf den oberen Ebenen der Pyramide werden also mehrere Arten von Entscheidungen getroffen:

  • Entscheidung über das Ziel
  • Entscheidung über den Plan, also den Weg zum Ziel

Die unteren Ebenen der Pyramide werden anschließend zur Durchführung des Plans herangezogen.

Klassische Organisation

Diese Pyramide gibt es in verschiedenen Varianten (in Form unterschiedlicher Organisationsstrukturen). Alle  Varianten haben gemeinsam, dass  der Ort der Entscheidung weit vom Ort des Handelns entfernt liegt. Es existiert also immer eine strikte Trennung von “Denken” und “Handeln”, von “Plan Erstellung” und “Plan Ausführung”. Planung ist der Prozess mit dem die Denkenden den Handelnden vorschreiben, wie sie ein Ergebnis erzielen sollen.

Während eine Trennung von Denken und Handeln für einfache und komplizierte Probleme funktionieren kann, führt sie bei zunehmend komplexeren Aufgabenstellungen zu schlechten Ergebnissen. Das liegt vor allem daran, dass die immer komplexer werdenden Probleme und Aufgabenstellungen nicht mehr von wenigen Entscheidern, weit weg von den Problemstellungen, gelöst werden können. Das strikte Einhalten eines einmal erstellten Plans erweist sich in einem komplexen Umfeld als kontraproduktiv, da Pläne trotz eines Informationsdefizits und auf Basis von falschen Annahmen zustande kommen.

In agilen Unternehmen geht man davon aus, dass die Komplexität heutiger Aufgabenstellungen am besten adressiert wird, indem die Lösungsfindung von Personen möglichst nah an der Problemstellung durchführt wird.  Eine gute Strategie zur Lösung komplexer Probleme ist es, sich der Intuition eines Kollektivs zu bedienen. Das heißt, Entscheidungen werden am besten von den Handelnden selbst getroffen. Dadurch werden keine Ziele und Pläne zur Steuerung der Handelnden mehr benötigt. Der Prozess der Planung wird überflüssig.

Doch wie werden in agilen Unternehmen ohne Ziele und Pläne Ergebnisse erzeugt? – Wer definiert, welche Ergebnisse erzielt werden sollen?

An die Stelle eines festen Ziels tritt eine Vereinbarung zwischen Kunde und agiler Organisation. In dieser Vereinbarung wird festgelegt, welche Art von Kundennutzen erzeugt werden soll. Die konkrete Ausgestaltung des Kundennutzen ergibt sich erst im Verlauf der Zusammenarbeit. Dabei werden immer wieder Hypothesen aufgestellt, die im Anschluss in Form von Experimenten validiert oder verworfen werden. Dadurch wird eine Arbeitsweise geschaffen, bei der die Steuerung der Inhalte durch kontinuierliche Rückmeldung des Kunden erfolgt. Planung wird durch Vorbereitung der nächsten Iteration von Hypothese und Experiment ersetzt. Der Kunde entscheidet, ob das bereitgestellten Ergebnis ausreichend Nutzen erbringt und auf der geschaffenen Basis weitere Iterationen erfolgen sollen, oder ob mit Hilfe von weiteren Experimenten nach besseren Varianten gesucht werden muss.

screen-shot-2016-09-26-at-23-04-57

Worin besteht der Unterschied zwischen der Vorbereitung eines Experiments und klassischer Planung?

Laut Wikipedia bezeichnet Planung “die menschliche Fähigkeit zur gedanklichen Vorwegnahme von Handlungsschritten, die zur Erreichung eines Zieles notwendig scheinen”

Grob gesagt: Ohne Ziel kein Plan. Da man sich an das Ziel in einem komplexen Umfeld jedoch zunächst mittels iterativem Vorgehen annähern muss, ist es nicht sinnvoll von Planung im herkömmlichen Sinne zu sprechen. Darüber hinaus wird die Vorbereitung der Experimente im agilen Umfeld immer von den handelnden Personen selbst durchgeführt. Es handelt sich bei der Vorbereitung also nicht um einen Prozess bei dem Denkende Vorschriften für Handelnde erstellen.

Sprechen wir im agilen Umfeld von Planung meinen wir also etwas völlig anderes, als im klassischen Umfeld damit gemeint ist. Für verschiedene Dinge denselben Begriff zu verwenden führt spätestens dann zu Problemen, wenn Personen aus beiden Umfeldern aufeinandertreffen.
Eine klare Abgrenzung der Begrifflichkeiten würde hier helfen.

Lars Rückemann

Lars Rückemann leitet die Niederlassung Solingen der codecentric AG. In seiner fast 20-jährigen IT-Laufbahn hat er in den Rollen Softwareentwickler, Architekt, Solution Engineer und Agile Coach in verschiedenen Branchen und mit unterschiedlichen Technologien Erfahrungen sammeln können. Aktueller Schwerpunkt seiner Arbeit ist es, Unternehmen beim Setup agiler Softwareentwicklungsprojekte zu unterstützen. Dabei liegt sein Fokus sowohl im Bereich der Backlog-Erstellung als auch darauf, Software-Entwicklungs-Praktiken und Continuous Delivery in den Teams zu etablieren.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Weitere Inhalte zu Agile Management

Kommentare

  • 1. Oktober 2016 von Matthias

    Provokation aber durchaus korrekt.
    Ich denke nur es gibt auch viele weitere Begriffe oder Artefakte die im klassischen und im agilen Kontext unterschiedlich ausgeprägt sind. Betrachtet man alleine den Prozess Schätzen ergeben sich weitere Brillen.

    • Lars Rückemann

      Ja, dass stimmt. Es gibt bestimmt noch viele weitere Begriffe die ebenfalls in einem Kontext eine feste Bedeutung haben, dann aber einfach in einem anderen Kontext mit völlig anderer Bedeutung verwendet werden.
      Sobald Personen aus den unterschiedlichen Kontexten miteinander arbeiten sollen, entstehen dadurch aus meiner Sicht immer Probleme. Sie verwenden zwar die gleichen Begriffe, meinen aber unterschiedliche Dinge. Das erschwert die Kommunikation und sorgt für eine sehr lange Phase, die zur Annäherung und Auflösung von sprachlichen Missverständnisse benötigt wird.
      In Softwareentwicklungsprojekten wissen wir schon lange, wie wichtig das Thema „Naming Things“ ist. Teams legen hier sehr viel Wert darauf eindeutige Begriffe zu verwenden und gleiche Dinge immer gleich zu bezeichnen. Darauf sollte man auch an anderer Stelle viel mehr achten.

  • Andreas Houben

    2. Oktober 2016 von Andreas Houben

    Aus handelnder Sicht bin ich ganz bei dir. Wie aber verkauft man einem Kunden das Prinzip?
    „Wir experimentieren so lange bis es passt“ klingt nach einer betriebswirtschaftlichen Katastrophe.

    • Lars Rückemann

      Auch im Vergleich zu der Variante: „Wir planen und bauen monatelang etwas und merken dann, dass es nicht passt, weil der Nutzer nichts damit anfangen kann“?
      Ist das nicht auch ein Experiment, nur wesentlich teurer?

      • Nino Martincevic

        3. Oktober 2016 von Nino Martincevic

        Genau das ist der Konter, den es benötigt 🙂
        Und der dann hoffentlich zu einem Nachdenken, Verstehen und Ändern von Gewohnheiten führt.
        Leider kontern darauf aber auch viele widerum mit „Wir kennen unser Geschäft und wissen, wie man das macht (wie es funktioniert, u.Ä….) und so hat es funktioniert, warum sollte es diesmal nicht?“ Darauf sollte man vorbereitet sein, aus meiner Erfahrung kommt es fast immer. Dann stelle man z.B. die Frage „Warum aber macht man dann das Gleiche neu (oder anders aber mit gleichem Ziel), wenn man doch beim Alten wusste, dass es funktioniert?“. Natürlich auf eine diplomatische Art und Weise 🙂

  • 3. Oktober 2016 von Stephan Roth

    Frei nach Dr. Gerhard Wohland: Planung ist die Vorwegnahme der Zukunft. Wenn der Weg zu einem Ziel festgelegt werden kann, BEVOR man losgeht, dann genügt ein Plan. In einem Umfeld hoher Dynamik, d.h. Überraschungen sind an der Tagesordnung, versagt Planung sehr schnell.

    Auch in agilen Softwareprojekten plant man, allerdings nur die nächsten zwei bis drei Wochen, um die Störanfälligkeit durch das dynamische Umfeld möglichst klein zu halten. Man fährt sozusagen „auf Sicht“. In Projekten mit einem sehr stabilen Umfeld, in denen es diese Unsicherheiten nicht gibt, kann man sich daher in der Tat fragen, ob das für alle Beteiligten durchaus anspruchsvolle agile Vorgehen z.B. nach Scrum sogar verzichtbar ist.

Kommentieren

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