Anstatt lesen: Unterwegs hören! |
Und der Ausstieg
Hybride Anwender? Da gibt es klare Studien mit Beweisen, siehe oben. In Anforderungen zu Projektvergaben erkenne ich im 3. Satz schon einen halbherzigen, hybriden Ansatz! (Ja, ich plakatiere jetzt PROvokant, da müssen Sie jetzt durch, damit eine Gedankenanstoß ausgelöst wird.) Die weiteren Daten der Studie können Sie hier einsehen. Mir stellt sich an dieser Stelle die Frage(n): Was veranlasst Unternehmen, derart inkonsequent zu sein? Ich habe da so meine Vermutungen …
Harter Tobak, diese Frage, und eine aus den nun folgenden Mythen und Beobachtungen ist genau diese: Wollen die Unternehmen, wenn es “an das Eingemachte” geht, diese Ergebnisse überhaubt sehen oder wahrhaben? Ich glaube, da sind wir noch nicht (so ganz …).
Die beschriebenen Forschungsergebnisse zeigen, dass agile Methoden sich nicht nur wachsender Beliebtheit erfreuen, sondern, wie nachgewiesen, die Projekte erfolgreicher machen. Da ein Rückschluss auf Einzelfälle bekanntlich nicht zulässig ist, bleibt allerdings offen, ob wir allein durch agile Methoden schon seit dem Jahr 2016 von BER (Willi Brandt) hätten fliegen können. (Nachtrag 2019: Immer noch – leider nicht.)
12 Scrum-Irrtümer
Mythen und Fehl-Erwartungen
Keinen Glauben schenken …
In einem Umfeld, in dem Scrum, Kanban, etc. wenig oder noch nicht bekannt ist, kommt mir die oft die fest zementierte Überzeugung entgegen, wo es schon im Ansatz klingelt: “Bei uns funktioniert Scrum nicht!“, “Mit unseren Kunden können wir Scrum oder so etwas nicht machen!” oder “Scrum ist für große Projekte nicht geeignet!“. Da gibt es noch mehr dieser Dogmen – Und alle Humbug. Das Missverständniss sehe ich in der fälschlichen Vermutung, die sich auf die Verwendung von Scrum ‘Top Bottom down’, beziehen. In der Vergangenheit wurde es ‘ja schon immer so gemacht’. Da ist das gesamte Rahmenwerk mit einer Beschreibung der Regeln, Werte, Rollen, Events und Artefakte gerade mal um die 25 Seiten beschrieben und das soll reichen? Definitiv ja, aber genau anders herum, mit einem UND-Element, also auch ‘Bottom Up’ wird ein Schuh draus. Nicht von ungefähr postulieren Schwaber / Sutherland in ihrer Definition von Scrum, dass es leichtgewichtig, einfach zu verstehen und schwierig zu meistern ist. Auf die einzelnen wenigen Regeln gehe ich hier nicht ein – Nur wo ist das Problem, diese erstmal einfach hinzunehmen und auch auszuprobieren? Erster Versuch einer Antwort: Schon wieder Regeln?
Es sind einfache Glaubenssätze. Mehr nicht. Und wieder kommt das Beispiel mit dem Kind und dem Fahrradfahren: Es ist eine gute Idee, das Kind die ersten paar hundert Meter mit Stützrädern fahren zu lassen. Aber: Selbst fahren lassen, nicht nur erklären. Einige der anderen (Irr-) Glaubenssätze, denen ich in Kundenprojekten immer wieder begegne, habe ich hier mal zusammengestellt. Sie haben eins gemeinsam: Sie basieren auf Fehlannahmen, sind irreführend und alles andere als zielführend. Scrumbug, Humban oder ‘Un’-sicht – also nix mit Sicht. Dort, in die mahlenden Mühlen einen Finger (oder mehr) reinzustecken, ist oft mit Schmerzen und deren Überwindung mit Mühe verbunden.
Irrglaube 1: Lasst uns Scrum nutzen und alles wird schneller (oder besser)
- “Unser Wasserfall-Ansatz hat ausgedient. Wenn wir Scrum nutzen, dann lösen wir unsere vorherigen Probleme im Handumdrehen.”
Schön wäre es! Hier wird Scrum nicht als Rahmenwerk verstanden, sondern als Ersatz für bereits im Einsatz befindliche Projektmanagement-Methoden und etablierte Prozesse – und dieser Vergleich wird (zu) gerne genommen, weil er so schön einfach ist. Eine Täuschung, nicht im Vorgang, sondern im Kopf mit dem direkten Vergleich (noch nicht mal wie Äpfel mit Birnen, sondern anders …)
Scrum beseitigt keine Probleme, sondern macht diese erst sichtbar. Die Versprechen, die bei der Einführung von Scrum gemacht werden, sind blumig bis opulent – im Hirn des Managers oder der Führungskraft entstehen Begehrlichkeiten und Fehlannahmen, dass mit Scrum gegenüber den plangetriebenen Methoden in kürzerer Zeit mehr erreicht werden kann. Die Wünsche, die von Unternehmen geäußert werden, lauten nicht “Wie können wir bessere Lösungen gemeinsam mit unseren Kunden entwickeln und diese größtmöglich zufriedenstellen?” oder “Was müssen wir tun, damit unsere Mitarbeiter selbständig und motiviert gesteckte Ziele erreichen?”. Es werden (mehr) Fragen in diesem Tenor (old school, BWL getrieben) gestellt wie “Wie können wir effektiver werden (mehr produzieren)?” oder “Wie können wir Liefertermine vorziehen und einhalten?”. Fragwürdiger Ansatz – denn das ist das falsche Fundament für Scrum und in sich ad absurdum geführt. Das sind die falschen, überholten Fragen aus einem bestehenden Kontext in einer sich rasant verändernden Welt. Denn:
Der reale Wert ist nicht im “höher”, “schneller” oder “besser als Wasserfall” sondern liegt in der Auslieferung von Lösungen, die erst den Kunden (und dann den Dienstleister) zufriedenstellen. Mit den Scrum-Werten (Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt), die für jedes Scrum-Team genereller Bestandteil der Team-DNA werden müssen, ergibt sich ein Potenz-Mix, mit dem Teams sich auftretenden Problemen stellen, UM und gemeinsam mit dem Kunden das zu erarbeiten, was dieser braucht oder als für sich notwendig empfindet. Das ist eine externe Referenz. Um es plakativ zu sagen: Scrum ist der Turbo-Staubsauger, der aus den (verd(r)ecketen) Ecken das (an bisherigen), was nicht funktioniert hat, herausholt und sichtbar macht, was bisher, ja, auch die Leitung, nicht sehen möchte oder wollte. Das ist der Trugschluss.
Irrglaube 2: Mit Scrum haben wir viel mehr Probleme
- “Scrum haben wir versucht – funktioniert bei uns nicht.”
Normal: Neue Projekte starten und ich werde gefragt, wie es am besten geht. (Scrum ist kein Projekt, das ist ein weiterer Trugschluss, siehe weiter unten). Ich werde gefragt, wie man das am sinnvollsten macht und wie lange das Projekt dauern wird. “Habt ihr schon mal über eine agile Methode wie Scrum nachgedacht?”. Versteinerte Gesichter mit einer Farbgebung ins Grau ist die erste Reaktion. Auf vorsichtige Nachfrage kommt dann “Scrum funktioniert bei uns nicht, haben wir versucht – damit haben wir viel mehr Probleme als vorher!”. Soso. “Und was ist mit den Problemen ‘vorher’ passiert?” Jetzt ist behutsames Vortasten nötig und die Beteiligten erzählen lassen. Guter Tip: Flipchart und Ausführungen stichpunktartig mitschreiben.
Aus den Ausführungen lassen sich in der Regel zwei Gruppen ableiten:
- 1. Gruppe: Scrum wurde halbherzig eingeführt (wenn überhaupt). Es kam da mal ein Trainer, der hat eine Schulung (halben Tag, den anderen halben Tag F&A) abgehalten … und damit sind die Team-Mitglieder “irgendwie” gestartet. Das geht irgendwie – nicht gut.
- Das Scrum-Framework ist ausgelegt, es in Gänze zu nutzen, weil die einzelnen Teile, also alle, sich gegenseitig ergänzen und logisch verzahnt sind. Wie in einem Räderwerk: Wenn nur einzelne Teile genutzt werden (z. B. nur Standups, aber keine Plannings und keine Retrospektiven), fehlen letztendlich wesentliche Bestandteile, das Räderwerk arbeitert nicht. Es ist wie beim Kochen, siehe Anfang des Artikels … Lasse ich Essentielles weg oder verändere gleich die Mechanik: Fehler. Punkt.
- 2. Gruppe: Scrum wurde richtig eingeführt, aber plötzlich tauchen viele Probleme auf, die vorher nicht da waren. Wirklich? Denken Sie nochmal über das Ursache-Wirkung Prinzip nach. Ursache ist: Noch unbekannt (Hurra! Ein echtes Impediment!) Wirkung ist: Es wird sichtbar.
- Hand auf’s Herz: Waren die Probleme vorher wirklich nicht da? Oder wurden sie nur irgendwie umschifft oder ignoriert und durch die plötzliche Transparenz an die Oberfläche gespült? Heisst: Ein ‘weggucken’ war gar nicht mehr möglich (das wäre Ignoranz)?
Der Scrum-Guide sagt dazu Folgendes: “Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Entwicklungsvorgehens sichtbar, so dass Sie sich verbessern können.”
Und dass Probleme jetzt plötzlich sichtbar werden und man mehr oder weniger gezwungen wird, sich damit zu beschäftigen, ist der elementare Vorteil. Jetzt kann man etwas dagegen tun und versuchen, die Probleme nachhaltig zu lösen. Wenn jetzt diese Probleme (also die wirkliche Ursache und keine Symptome) angegangen werden, kann Scrum zu dem gewünschten Geschwindigkeitsschub führen, den die Menschen IN Scrum mit eigenen Mitteln und Möglichkeiten lösen, um besser reagieren zu können. Nicht Scrum wirkt, sondern die Sichtbarkeit.
