SCRUM statt MURCS oder „Warum muss es immer Scrum sein?“

Agilität und Scrum sind aus der Software-Entwicklung nicht mehr wegzudenken. Ist man in einem Projekt tätig, in dem nach anderen (agilen) Vorgehensweisen entwickelt wird, dann erntet man schnell mitleidige Blicke: „Was? Kein Scrum? Geht das überhaupt?“

Die Realität

Beim Einsatz von Scrum gibt es viele Fallstricke. In der Realität bedeutet es etwa:

• Viele Meetings, die das konzentrierte Arbeiten unterbrechen
• Alle “sprinten” nur noch, übergreifende Aufgaben bleiben liegen
• Alte Strukturen, versehen mit neuen englischen Namen

Die Irrtümer

Scrum wird oft eingesetzt, weil es „fancy“ ist oder „weil es alle machen“. So beginnt die Einführung agiler Methoden mit falschen Erwartungen. Die Entwickler denken: „Super, da brauchen wir keine Dokumentation!“ Der Projektleiter sagt sich: „Oh, da kann ich im Daily überwachen, wer was tut!“ Der Kunde stellt fest: „Agil, klasse, da kann ich kurz vor Auslieferung noch alles ändern!“ Und das Management glaubt: „Mit Scrum geht alles schneller, da können wir noch mehr Anforderungen und Projekte umsetzen.“

Die Mythen

Agilität ist nicht automatisch der beste und einzige Weg, um Software zu entwickeln, genauso wie „agil“ auch nicht immer Scrum bedeuten muss. Und Agilität ist auch nicht so leicht umzusetzen, wie oft geglaubt wird:

„It’s simple, but it’s not easy.“

Nicht überall, wo Scrum drauf steht, ist auch Scrum drin! Nicht alles, auf dem ein Post-It klebt, ist agil. Oft begegnet man in der Praxis dem sog. Cargo-Kult. Der Begriff entstand auf den pazifischen Inseln im 2. Weltkrieg. Für Lebensmittel-Lieferungen warfen Flugzeuge dort Kisten ab, wo Fluglotsen mit Paddeln Signale gaben. Nach Kriegsende und dem Abzug der Soldaten entwickelten die Inselbewohner den „Kult“ mit Paddeln zu winken: Sie hofften, damit den gleichen Effekt zu erzielen – nämlich die Lieferung von Lebensmitteln.

So ähnlich ist es bei vielen Scrum-Projekten: Es wird agiler Aktionismus entwickelt und mit Begriffen wie Sprint, Retro oder Backlog um sich geworfen. Dabei bleibt das agile Mindset unverstanden und der gewünschte Erfolg bleibt aus. Damit Scrum nicht nur ein wildes Herumfuchteln mit Paddeln ohne entsprechende Lieferung wird, ist eine problemorientierte Herangehensweise wichtig.

Die Problemanalyse

Welche Probleme gibt es im bestehenden Verfahren? Was möchtest Du besser machen? Organisiere einen Workshop mit allen an der Software-Entwicklung Beteiligten, unter Leitung eines Coaches. Entwickle eine Vision Deiner Ziele und mach Dir bewusst, welche Qualitätsmerkmale für Dein Software-Produkt die wichtigsten sind.

Die Methodenwahl

Dann suche für diese Ziele geeignete Methoden; sie sollten Mittel, aber nicht Zweck sein, nutze was Dir nutzt. Wie sind diese Maßnahmen umzusetzen? Was sollen sie bewirken? Erst wenn alle ein gemeinsames Verständnis davon entwickelt haben, kann das ganze Team die Veränderungen tragen.

Die Nebeneffekte

Bei der Reflexion der Vorgehensweise und der Suche nach Lösungen fallen vielleicht Sätze wie: „Wir wollen nicht immer die gleichen Fehler machen – eine gemeinsame Retrospektive wäre gut.“ Oder: „Der Austausch mit dem Kunden ist schlecht, wir wissen nicht genau, was er will, und er weiß nicht, was wir tun – gemeinsame Reviews würden helfen.“ Oder auch: „Die Kommunikation sollte besser sein – wir könnten interdisziplinäre Teams bilden.“

Vielleicht bist Du auch bereits viel agiler als gedacht. Agilität muss dabei nicht automatisch Scrum bedeuten. Evtl. gibt es andere Vorgehensweisen, die sich für Dein Projekt besser eignen. Scrum ist kein Allheilmittel! Scrum ist ein kleines Rahmenwerk mit viel Interpretationsspielraum, das oft falsch gelebt wird.

Die Umsetzung

Wenn Du Dich für eine Methode entschieden hast, dann sollte sie umgesetzt und ausprobiert werden. Prüfe kontinuierlich, ob die Änderungen den gewünschten Effekt haben. Verliere nicht aus den Augen, warum Du etwas tust! Mit Kennzahlen bewertest Du, ob sich eine Situation verbessert hat. Visualisiere den aktuellen Zustand verständlich für alle, etwa zu den Aufgaben im Backlog oder mit Burndown Charts für offene Tickets. Dies muss gepflegt und beobachtet werden, damit Du Korrekturen rasch einleiten kannst.

Die Dynamik

Ist eine Maßnahme nicht erfolgreich, wird sie verändert oder eine andere Methode ausprobiert. Agilität ist die Fähigkeit auf Veränderungen in einem dynamischen Umfeld zu reagieren. Es gilt flexibel zu bleiben und den Mut zu haben, eingeführte Vorgehensweisen auch wieder zu ändern.

Die Mitarbeiter

Nimm bei der Einführung neuer Vorgehensweisen alle Beteiligten ins Boot. Erkläre, warum Du etwas tust und was Du damit erreichen willst. Motiviere die Mitarbeiter und zwinge sie nicht zur Umsetzung. Räume ihnen Mitspracherecht bei der Teameinteilung ein. Teams brauchen Zeit sich zu formen, damit es nicht heißt: TEAM, toll ein andrer macht‘s.

Soll Dein Unternehmen flexibler werden, damit Du auf die Anforderungen des Marktes besser reagieren kannst, dann muss die gesamte Organisation agiler werden. Es nutzt nichts, im Zwei-Wochen-Turnus ein lieferbares Software-Produkt zu entwickeln, wenn die Prozesse in Deinem Unternehmen nur eine halbjährliche Lieferung zulassen.

Die Meetings

Oft werden sämtliche Meetings eingeführt, die ein Vorgehen zu bieten hat. Aber: Jede Besprechung bedeutet eine Unterbrechung der Arbeit. Installiere doch mal bei jedem Meeting einen Zähler für die Personalkosten und frage Dich anschließend: War uns das Ergebnis dieses Treffens x-tausend Euro wert?

Das Fazit

Es geht immer darum, die GMV-Methode zu benutzen, genau das sind nämlich agile Methoden: Gesunder MenschenVerstand. Dann wird es SCRUM statt MURCS oder auch etwas anderes. Es muss nicht immer Scrum sein, auch ohne lässt sich gute Software entwickeln. Das ist auf jeden Fall besser als enttäuschte Menschen, die mit Paddeln winken und sich wundern, warum nichts passiert.