Angeberwissen zu Scrum - Teil 3 von 3

Zum Abschluss der kleinen Reihe noch der dritte Teil mit zwei Angeberweisheiten:

Scrum hat alles nur geklaut!

Fast richtig. Wenn man mal die bunten Prospekte der vielen Scrum-Trainer und –Experten zur Seite legt und sich auf die guten, alten Projektmanagement-Traditionen besinnt: da findet sich doch vieles, was in Scrum auch wieder hochkommt. Beispiele? Also:

Autonomes Team

Fast religiös ist die Diskussion der echten und selbsternannten Gurus darum, was das Team alles entscheiden darf – und was die anderen, in Unternehmen gelegentlich anzutreffenden unwichtigen Leute wie Chefs und Manager auf keinen Fall dürfen. Abgesehen von der Schwierigkeit, die Vielfalt real existierender Unternehmen auf eine einzige Methode mit dem immer gleichen Mantra zu reduzieren: gab es schon als „Empowerment“. 

Wann genau das aufkam, kann ich nicht rekonstruieren, meinem Gedächtnis nach Ende der 80er und Anfang der 90er. Der Trick: Übernahme von Verantwortung durch den, der die Arbeit wirklich macht. Das übliche Toyota-Beispiel ist ja: jeder darf das Band anhalten, wenn die Qualität gefährdet ist – auch eine Form von Empowerment, früher hätte man Meldung machen müssen. 

Neu ist: ein Team wird „empowered“ – nicht einzelne. Das  Team muss in der Gruppe entscheiden und handeln. Das ist bekanntermaßen schwierig, kann aber erlernt werden. Ziel: die Herde entscheidet besser als ein einzelner Ochse...

Stetige Verbesserung – Kaizen 

Scrum versucht durch regelmäßige Reviews und Retrospektiven Hindernisse und Fehlentwicklungen aufzudecken. Insbesondere wird dabei auch beleuchtet, wie denn der Prozess selbst angepasst ist. Das ist mitunter anstrengend, vor allem nach den ersten Monaten, alles ist eingeschwungen und läuft, und jetzt schon wieder Bauchnabelschau?

Der stetige Wandel zum Besseren wurde vor allem in der Industrie von Toyota nach dem Krieg vorangetrieben – bis es zum Allgemeinplatz wurde. Ich persönlich halte eine stetige Optimierung von Prozessen für schwer vorstellbar, irgendwann ist die Zitrone ausgequetscht, oft versumpft das „Lessons Learned“ dann zu einem Pflichttermin. Vorteilhafter scheint mir eine „stetige Anpassung“ – weil sich Anforderungen und Technologien ändern, weil Mitarbeiter und Strukturen sich ändern. Vielleicht war das sogar mit Kaizen gemeint? Auf jeden Fall ist die effektivste und beste Optimierung die Evolution: nicht der „fitteste“ gewinnt (das ist ein Übersetzungsfehler!) – sondern der am Besten angepasste! Byebye T-Rex – Welcome Säugetier!

Kurze Sprints

Häufige Überprüfung des Erreichten geht einher mit Verbesserung. Ich selbst kam Anfang des Jahrtausends mit dem Rational UnifiedProcess® (RUP), heute ein Warenzeichen der IBM, in Kontakt. Ein Kernpunkt ist die iterative Herangehensweise: beherrschbare und überprüfbare Abschnitte, statt jahrelanger Arbeit im Verborgenen. Der RUP hatte noch viele Elemente von traditionellen Kommandostrukturen in Projekten – aber das iterative und inkrementelle Vorgehen erwies sich in meinen Projekten als wertvolle und risikomindernde Taktung. Scrum geht da weiter: statt Iterationen von sechs oder acht Wochen reduziert man die Planung auf zwei bis vier. Und zwar aus dem gleichen Grund: Transparenz und Steuerbarkeit – lieber den Aufwand von vier Wochen mit zehn Personen wegwerfen (ca. 200 PT) als den Aufwand von zwei Monaten (ca. 400 PT).

Seit Anfang des Jahrtausends – glaube ich – sind auch Änderungshektik und Erwartung schneller Ergebnisse deutlich gestiegen. Und welcher Fachbereich hält sich heute schon noch gerne mit wochenlangen Spezifikationen auf?

Scrum rettet mein Projekt!

Kommen wir mal auf den Blog-Titel zurück: Wird Scrum Ihr in Schieflage befindliches Projekt retten? Möglicherweise!

Die wichtigsten Punkte einer Rettung sind:

• Ziele bestimmen – sind die Anforderungen klar beschrieben, bekannt und abgeschätzt?
• Standort bestimmen – was wurde wirklich schon erreicht?
• Einen Weg suchen – kann Ihr Team die Ziele noch erreichen? Was waren denn die Gründe, warum es bisher nicht geklappt hat? Können Sie diese Hindernisse aus dem Weg räumen?
• Anpassen – Ziel und Weg sind ja voneinander abhängig. Wenn Sie die Ziele gar nicht erreichen können – welchen Teil davon können Sie denn erreichen, lohnt sich das? Wichtig ist, dass Sie realistische Ziele beim Neustart haben. Alles andere bringt keine Verbesserung.
• Neustart – Klarer Start, klare Ziele, klarer Weg.
• Häufige Überprüfung des Erreichten – ist ein Nutzen zu erkennen? Passt Ihr Plan zur Realität? Manchmal muss man wieder vorne starten.
• Häufige Überprüfung des Prozesses – tut Ihr Team eigentlich das Richtige? Oder erzeugt es seitenlange Dokumente, „weil man das hier so macht“?
• Motivation und Einbindung – fragen Sie die Experten für Teamarbeit – Ihr Team. Menschen, die selbst über ihre Arbeitsweise entscheiden, identifizieren sich viel mehr mit den Ergebnissen und Zielen. Dafür müssen Sie als Projektverantwortlicher manchmal auch loslassen können!

Schön und gut – aber war das jetzt Scrum? Noch nicht – aber weit sind Sie nicht mehr davon entfernt...