Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Wir machen Scrum und wann werden wir agil?

Immer wieder gibt es neue Ideen und Ansätze, wie man Agilität erreichen kann. Die haben alle etwas für sich, ergänzen sich ideal und würden im Großen und Ganzen ein supergeiles agiles Unternehmen ergeben. Aber zu Beginn hinterlässt diese Themenbreite auch oft Verwirrung. Müssen wir alles davon machen, sollen wir keines davon machen, sind wir denn richtig agil, wenn wir was weglassen?

Eine Art Kampf der Methoden oder anders gesagt, „der Practices“, fängt damit an. „Tja, Scrum allein ist nicht genug, Kanban ist doch besser!“, “ Was ist mit Design Thinking?“, “ Lean IT Management?“, „Lean Product Development?“, “ Wasserfall hat doch seine guten Seiten?“, „Sollen wir wirklich Test Driven Development oder Pair Programmimg einführen?“, „Wir brauchen doch traditionelles Projektmanagement?“, „Und die Rolle des Managers?“, “ Es gibt doch keine einzelne Lösung, die Lösungsmethode ist doch hybrid, oder?“

Was mache ich mit diesem Blumenstrauß?
Aber was bedeutet Agilität eigentlich, was bedeutet „Scrum machen“?  Eigentlich ganz einfach: Ein einfacher Rahmen, kombiniert mit einer Sammlung von ausgewählten Best Practices, die zusammen die Art zu denken und zu arbeiten vollkommen verändert. Agil sein passiert erst dann, wenn ihr die Grundprinzipien und Werte von Scrum verinnerlicht habt.

Der Einfluss und die Auswirkung dieses Umdenkens ist schwer auf einen Teil der Organisation zu begrenzen, da unter anderen mit Scrum die Kommunikation insgesamt und vor allem die interdisziplinäre Kommunikation und Zusammenarbeit schnell alle Bereich der Organisation betreffen. Alle Individuen sind damit konfrontiert, ihre alten Denkmuster und Arbeitsweisen auf den Prüfstand zu stellen und sie werden die neuen Ansätze kritisch oder zumindest hinterfragend betrachten.

Wie werde ich wirklich agil im Kopf?

Der erste Schritt dazu, agil zu werden, ist agil zu handeln und herauszufinden, was heute zu einer Organisation passt. Genauso müsst ihr aber herausfinden, was erst morgen oder übermorgen passen wird.

  • Welchen Cocktail von Best Practices braucht ihr heute, welchen erst morgen?
  • Ab wann werdet ihr bestimmte Praktiken für eure Organisation selbst entwickeln müssen?
  • Welche Praktiken könnt ihr heute überhaupt schon ertragen und welche verlangen ein grundsätzliches Umdenken?

So, wie wollen wir das rausfinden? Wie schon gesagt: tun! Es ist an dieser Stelle wichtig, folgende Punkte zu betrachten:

Scrum ist kein Selbstzweck
Wisst ihr überhaupt, warum und wofür das Ganze? Was bedeutet für euch Erfolg? Ist eure Organisation mehr mit den Kunden oder mit sich selbst beschäftigt (prozessgetrieben)? Sucht euch einen Teil eurer Organisation aus, in dem ihr mit agilen Vorgehensweisen anfangen wollen. Sucht euch einen Bereich, der übersichtlich ist, wo ihr grundlegende Rahmenbedingungen anbieten könnt – vor allem Ressourcen und die Unterstützung des Managements.

Leute befähigen
Um sich zu ändern, soll ein Mensch etwas Neues lernen. Ja, das Scrum-Rahmenwerk ist einfach, bedeutet aber trotzdem für viele Menschen eine große Veränderung. Zeigt eurer Mannschaft, dass ihr es ernst nehmt, schätzt diese Veränderung nicht gering und bietet jedem einzelnen Betroffenen (und damit AUCH dem involvierten Management!!) Trainings und Schulungen an.

Schutz und Rahmen schaffen
Lasst ein Team und einen ScrumMaster nie dabei allein, sich mit Scrum in der Organisation zurechtzufinden. Stellt Manager an ihre Seite, um die ersten Impediments aufzuräumen, den Rahmen klarzustellen und sie vor allem durch Kommunikation mit dem Rest des Unternehmens zu unterstützen. Informiert und involviert von Anfang an Personen in anderen Teams oder Abteilungen, die mit eurem Pilot-Team zu tun haben werden.

Zeit lassen
Sobald ihr klar gemacht habt, warum ihr euch für ein agiles Vorgehen entschieden habt (kürzere Releasezyklen, Kundenausrichtung, Time to Market, etc.): Lasst die Leute arbeiten! Lasst eure alten Berichtsformate links liegen und wagt euch an die neuen Artefakte wie Release Plan, Burndownchart oder Review Meeting.

Neue Wege, Änderung der Organisation und der Prozesse fordern
Jetzt kommen wir zurück zu unserem Blumenstrauß. Einmal gestartet, werden sowohl das Team als auch das Management identifizieren, welche Praktiken sie gerne versuchen würden bzw. werden sich basierend auf den priorisierten Problemen oder Herausforderungen ein paar agile Ansätze sofort als Lösungsansatz anbieten. So wie ein Team nicht über Nacht alle Best Practices anwenden kann und muss, wird auch die Organisation nicht alle Veränderungen durchführen können und müssen, um über Nacht agil zu sein. Der notwendige Lernprozess und Assessmentprozess kann nur inkrementell durchgeführt werden. Ein Schritt nach dem anderen. Das Motto: Versuchen und … lernen. Gemeinsam lernen, kontinuerlich lernen! Neu versuchen, anders versuchen, etc. Seid mutig und seid offen, neue Dinge zu probieren. Geht respektvoll miteinander um und setzt euch den gemeinsamen Anspruch, in kürzerer Zeit Qualität und Ergebnisse zu liefern und vor allem: euch aufeinander verlassen zu können.

Tja, dann fangen wir mal an, agil zu sein!

  • HPKorn

    „Wir machen Scrum (oder xxxyyyzzz) – und damit werden wir agil“ entspringt einem recht mechanistischen Denken … und ist deshalb so beliebt.
    Leider funktioniert das nicht…. und bald folgt dann eben die Frage „Wir machen Scrum … und wann werden wir agil?“
    Besser wäre das:
    „Wir werden agil – und später dann praktizieren wir auch agile Methoden und Techniken der SW-Entwicklung als Kombination verschiedener Rahmenwerke“.
    So ist es auch bereits 2010 im Forrester Report „Agile Development: Mainstream Adoption Has Changed Agility“ als gängige Praxis in unterschiedlichsten Unternehmen beschrieben.
    Und „agil“ sein hat nichts mit dem Praktizieren der Regeln von Scrum (oder xxxyyyzzz) zu tun sondern z.B. damit:
    o Etablierte Konversationsräume
    o Daily Standup
    o Erfahrungs- und Praxisgemeinschaften
    o Transparente Informationen
    o Sichtbarkeit, Verfolgbarkeit, Analysierbarkeit der Zusammenarbeit
    o Arbeitsplanung im Team durch das Team – nicht durch den Teamleiter
    o Kontinuierliche Verbesserung der Kooperation im Team
    o Anpassbare Kreise (statt starrer Hierarchien) mit Führungs-Meetings, wöchentlichen taktischen Meetings und Daily Standup Meetings
    o „Agile“ Art der Führung

  • Sven Winkler

    Hi LN,

    danke für den Artikel, insbesondere den 2. Teil.
    Der Punkt „Schutz und Rahmen schaffen“ ist für mich zentral. Wenn das nicht gegeben ist, dann brauche ich eigentlich mit agil als Managementziel nicht anfangen. Ein Erneuerer, was die Rolle eines ScrumMasters durchaus sein kann, braucht immer ein Backup, sonst verbrennt er ohne Wirkung. Dazu gehört auch, dass man sich auf neue Formate einlässt und so den Rücken stärkt.

    Grüßle, Sven :-)