Agile Missverständnisse: Scrum funktioniert auch in Ansätzen

Der Scrum Guide der beiden Scrum-Schöpfer Ken Schwaber und Jeff Sutherland ist mit seinen 19 Seiten (im englischen Original, Stand November 2017) ein recht kompaktes Regelwerk. Treffend mit der Überschrift The Rules of the Game eingeleitet.

Der Scrum-Guide ist zudem in einer direkten und exakten Sprache verfasst und erläutert recht genau, wie und warum das Scrum-Framework funktioniert und anzuwenden ist.

Gleich zu Beginn des Scrum-Guides ist aber auch eine Art Warnung, die – mit der jahrzehntelangen Erfahrung von Ken Schwaber und Jeff Sutherland betrachtet – so etwas wie ein „I told you so“ sein könnte. So sehe ich das zumindest.

Die Warnung lautet wie folgt:

Scrum is:

– Lightweight
– Simple to understand
– Difficult to master

Scrum Guide

Auf Difficult to master werde ich etwas näher eingehen. Denn allzu oft werden die Spielregeln und Empfehlungen aus dem Scrum Guide in der Praxis schlicht ignoriert oder recht frei ausgelegt. Zu Risiken und Nebenwirkungen fragen sie irgendjemanden, der sich mit dem Kram auskennt …

Scrum-Framework nach Lehrbuch vs. Realität in vielen Firmen

Der Scrum Guide liefert quasi die Blaupause, um komplexe Arbeit in variablen Märkten mit wechselnden Technologien zu ermöglichen. Dabei beschränkt sich der Scrum Guide nicht ausschließlich auf die Softwareentwicklung. Im Gegenteil, der Scrum Guide spricht von „complex work“, was auf nahezu alle Bereiche der Wissensarbeit zutrifft … wenn man sich an die beschriebenen Spielregeln hält.

Diese Spielregeln, die im Scrum-Guide als erprobt und bewährt beschrieben werden, stellen Organisationen aber häufig vor Schwierigkeiten. Denn über dem Scrum Guide schwebt so etwas wie die folgende Grundvoraussetzung: „Die Rahmenbedingungen können nach Belieben angepasst werden.“

Der Abgleich mit der Realität zeigt aber oft, in welchen Bereichen sich Organisationen noch schwer tun.

Wo es oft klemmt

Wir möchten unsere Kunden wirksam im Sinne einer agilen Arbeitsweise machen. Um dieses ambitionierte Ziel zu erreichen, liegt es in der Natur der Sache, die richtigen, umbequemen Fragen zu stellen und den Ursachen auf den Grund zu gehen – sprich den Finger in die Wunde zu legen.

Dadurch werden aber auch interessante Aspekte und Einblicke zu Tage gefördert, die eins klar machen: Die Herausforderungen vor denen viele Organisationen stehen und die die Etablierung agiler Arbeitsweisen erschweren, ähneln sich durchaus. Die folgenden Themenbereiche sind exemplarisch zu sehen und begegnen uns regelmässig:

Denke in Multiprojekten, nicht in Produkten

Scrum als eines der weit verbreiteten Frameworks hat seinen Fokus ganz klar auf der Produktauslieferung. Es handelt sich also um ein Liefermodell.

Dieses Modell kann aber nur dann funktionieren, wenn sich die beteiligten Teams in ihrer Tätigkeit klar auf das Liefern fokussieren, commiten und Störfaktoren ferngehalten werden. Das funktioniert dann am besten, wenn der Zeitanteil für Abstimmungen und Wissensverteilung, den es braucht um als Team kollaborativ an einem Produkt zu arbeiten, in einem guten Verhältnis zu der Zeit steht, die für die Erstellung bzw. Weiterentwicklung des Produktes investiert wird.

Die im Scrum Guide beschriebenen Empfehlungen bezüglich der Anzahl und Dauer der Rituale hat dann ein optimales Verhältnis, wenn ein Team ausschließlich an einem Projekt oder Produkt arbeitet. Allen, die sich schwer tun, die Vorteile hinter diesem Arbeitsmodus zu erkennen, seien dabei die folgenden Punkte ans Herz gelegt, die allzuoft vergessen oder unterschätzt werden:

• Das Zeitinvest für Abstimmung, Arbeitsorganisation und Wissensverteilung multipliziert sich mit Anzahl der parallelen Projekte und reduziert gleichzeitig die Zeit, in der effizient am Produkt gearbeitet werden kann.
• Mit jedem Wechsel zwischen den Projekten geht durch den Kontextwechsel Zeit verloren, vergleichbar mit den Rüstzeiten von Maschinen in der Industrie. Also eine Art digitale Wissens-Rüstzeit, die für Mitarbeiter fordernd und anstrengend ist.
  Diese Zeit müsste fairerweise aus der Arbeitszeit herausgerechnet werden, denn in dieser Zeit können Mitarbeiter keine Ergebnisse liefern. De facto sollte Kontextwechsel so gut wie möglich vermieden werden.
• Der Fortschritt innerhalb der Projekte wird mit jedem zusätzlichen Projekt aus den oben genannten Punkten abnehmen. Das wiederum wirkt sich äußerst negativ auf die Motivation der Mitarbeiter aus.
• Planung und Koordination inner- und ausserhalb der Teams, auch in Bezug auf Tech-Stack, externe Abhängigkeiten, Organisation etc., wird mit jedem zusätzlichen Projekt erschwert.
• Eine klare und notwendige Priorisierung / Fokussierung ist in einem solchen Kontext nicht realisierbar. Bottom line: Viele Projekte werden begonnen, in der Summe gibt es aber zu wenig Fortschritt über alle Projekte verteilt.

Fehlende Transparenz und Sichtbarkeit der Abhängigkeiten

Würde es gelingen, die Multiprojekt-Situation sichtbar, transparent und mit allen seinen Abhängigkeiten aufzuzeigen, würden sich einige der oben genannten Punkte herausdestillieren.

Was mich zu folgender Theorie verleitet: Wären die Seiteneffekte und Abhängigkeiten im Vorfeld klar, würden sich Entscheider bewusst gegen eine Multiprojekt-Situation entscheiden.

Warum ist es dann nach wie vor die Regel statt der Ausnahme? Ich sehe da folgende Abhängigkeiten:

• Gewohnheit: es war ja schon immer so, alle anderen machen es doch auch so.
• Das große nach wie vor vorherrschende Missverständnis: Je mehr Arbeit in in System einfließt, desto mehr Arbeit wird erbracht.
• Oft sind die Auswirkungen des Handelns örtlich und zeitlich von den Auswirkungen getrennt.
  Beispiel: Manager sagt heute „ja“ zu Projekt A. Dadurch wird der Fortschritt von Projekte B, C und D in vier Monaten aber deutlich gebremst, da alle Projekte die gleichen Ressourcen binden.
• Die gewünschte Transparenz am besten firmenweit zu etablieren ist natürlich kein Spaziergang und setzt die Zusammenarbeit in vielen Unternehmensbereichen voraus.

Fehlendes Grundlagenverständnis in Bezug auf agiles Arbeiten

Wenn innerhalb der unterschiedlichen Hierarchien der Organisation ein unterschiedliches oder gar fehlendes Grundlagenverständnis existiert, wird eine einheitliche Ausrichtung und Priorisierung kaum möglich. Ist ein Teil der Organisation noch klassisch hierarchisch unterwegs, der andere Teil möchte aber flexibel und agil planen und handeln, ist die Schnittmenge nicht sehr groß.

Das was ich als Schnittmenge umschrieben habe, ist eher eine Annäherung von zwei oft gegensätzlichen Sichtweisen, die von vielen Missverständnissen geprägt ist. Hier wird schlicht Potenzial verschenkt, da das Wissen über grundsätzlich andere Herangehensweisen unbekannt ist.

Auf dem Product Owner Camp haben wir die Teilnehmer gefragt, was Sie (bzw. ihre Organisation) davon abhält, agil arbeiten zu können. Der meist genannte Punkt bei über 60 Prozent der Teilnehmer: Fehlendes agiles Grundlagenwissen.

Rollen werden doppelt, falsch oder gar nicht besetzt

Das fehlendes Grundlagenverständnis auf Entscheidungs- und Managementebene die Führung einer Organisation erschwert, wurde weiter oben erläutert. Aber wie sieht es im operativen Bereich aus? Was passiert, wenn die Auslegung der Rollen z. B. aus dem Scrum-Framework nur sehr frei oder schlicht falsch erfolgt? Die folgenden Beispiele verdeutlichen das:

Product Owner

Der Product Owner sollte laut Scrum Guide die einzige Person sein, die am Ende darüber entscheidet, welche Items aus dem Backlog in welcher Priorität umzusetzen sind. Und zwar aus dem einen entscheidenen Grund, dass er es am besten kann! Weil er alle Abhängigkeiten, den Markt sowie die Stakeholder am besten kennt.

In der Praxis werden Product Owner aber von den wenigsten Organisationen befähigt, genau das zu tun. Anders ausgedrückt: Das Potenzial, ein Produkt wert- und kundenzentriert zu entwickeln, wird durch Hierarchie und Machtkämpfe im Keim erstickt. Am Ende hat eben oft nicht der Product Owner das letzte Wort, sondern der, der in der Hierarchie über ihm steht, wenn er seine Interessen voranbringen will. Auf lange Sicht nachteilig für den Erfolg des Produkts und/oder der Organisation.

Scrum Master

Der Scrum Master ist der Servant Leader im Team. Die Rolle des Scrum Master hat deswegen im Management oft völlig zu Unrecht das Label „optional“, „anteilig“ und „nicht unbedingt notwendig“.

Dass seine Arbeit aber immens wichtig ist, wird spätestens dann klar, wenn durch sein Fehlen die Lieferfähigkeit des Teams beeinträchtigt wird. Und das ist unserer Erfahrung nach die unmittelbare Konsequenz.

Entwicklerteam

Jede Organisation hat mehr Projekte und Baustellen mit Entwicklungs-Bedarf als verfügbare Entwickler. Deswegen lässt man diese kostbare Ressource auch gerne an möglichst vielen Projekten mitarbeiten. Die Seiteneffekte die so entstehen sind bereits weiter oben aufgeführt.

Ein effektiver Weg weniger Dinge abzuschließen ist und bleibt Multitasking – oder in diesem Kontext eine Multiprojekt-Situation. Sprich: die Verteilung der verfügbaren Ressourcen auf mehrere Projekte.

Intention/Verantwortung/Abhängigkeit der Rollen ist Entscheidern oft gar nicht klar

Darum ist es umso wichtiger, den Entscheidern Klarheit zu verschaffen, damit sie befähigt sind, die Konsequenzen ihres Handelns besser verstehen zu können. Denn die bewusst getroffenen Entscheidungen rühren der Erfahrung nach in bester Absicht.

Aufgrund des fehlenden Wissens was z. B. die Abhängigkeiten und Verantwortung der Rollen (Product Owner, Scrum Master, Entwicklerteam) angeht, können aber gar keine tragfähigen Entscheidungen getroffen werden. Und am Ende läuft es oft auf ein „das Gegenteil von Gut, ist gut gemeint“ hinaus.

Wo eine Abweichung der Spielregeln ein agiles Arbeiten noch ermöglicht

Weiß man um die genannten Nachteile, Abhängigkeiten und Seiteneffekte einer Teiladaption, steht nun noch die Frage im Raum, wo man die Grenze zieht. Wo ist eine Abweichung vom Scrum-Framework noch sinnvoll, an welcher Stelle schon zu groß?

Das ist jedoch keine einfach zu beantwortende Frage. Denn es hängt – wie so oft in komplexen Umfeldern – von vielerlei Dingen ab und muss individuell betrachtet werden.

Eine Hilfestellung kann sein, sich nicht im Mikromanagement zu verlieren, sondern mit ausreichendem Abstand einen Blick auf die wichtigsten Bereiche zu werfen, die eine Organisation mit dem Scrum-Framework erreichen möchte. Also eine Art Indikator dafür zu haben, ob Scrum in der Art und Weise, wie es aktuell in der Organisation eingesetzt wird, gut funktioniert. Denn der Einsatz von Scrum ist kein Selbstzweck, sondern verfolgt klare Ziele.

Was fehlt, was würde helfen?

Ein guter Start wäre eine sachliche Beurteilung, wie weit man sich vom Scrum Guide beziehungsweise den Spielregeln entfernt hat. Zur Orientierung habe ich hier einige Fragen, die man mit Ja oder Nein beantworten kann:

• Sind die Scrum-Teams in der Lage, kontinuierlich ein Inkrement zu liefern?
• Können sich die Scrum-Teams primär auf das Liefern der Software fokussieren?
• Erfolgt ein kontinuierliches Release des Produktes?
• Sind die Teammitglieder mit der Arbeitsweise, dem Ausfüllen ihrer Rolle und dem Fortschritt in Bezug auf die Weiterentwicklung des Produktes zufrieden?
• Wird genug getan, um regelmässig Feedback der Kunden/Stakeholder in die Weiterentwicklung des Produktes einfließen zu lassen?

Können alle Fragen mit Ja beantwortet werden? Super! Weiter so.

Falls nicht: Bitte zurück auf Start und mit Hilfe der sachlichen Beurteilung samt Ableitung der Zusammenhänge geeignete Maßnahmen finden.

Und ja, Recht hatten Ken Schwaber und Jeff Sutherland meiner Meinung nach mit „Scrum is: Difficult to master“ durchaus. Keiner hat gesagt, dass es einfach ist.

Lohnend aber auf jeden Fall!

Unsere Serie Agile Missverständnisse