Agile Worst Practices – Teil 3

2 Kommentare

Willkommen zum nächsten Post aus der Serie Agile Worst Practices, die ich mit diesem Post begonnen hatte. Wir bleiben bei den Worst Practices für das Team und greifen ein häufiges Missverständnis im agilen Umfeld auf:

Team Worst Practice #3: Alles ist selbstorganisiert

Beschreibung: Wir als Team sind ja selbstorganisiert. Uns hat keiner etwas vorzuschreiben und wir wissen selber am besten, was für uns gut ist. Feste Regeln gelten für uns nicht, sondern wir klären basisdemokratisch, was wir unter agilem Vorgehen verstehen und wie wir das machen wollen. Auch Scrum ist ja eher so eine Art Empfehlung als eine Methode und wir diskutieren ausführlich in jedem Sprint, wie wir das machen wollen. Schließlich sind die Retrospektiven doch dafür da, dass wir unsere Methode nach jedem Sprint (und bei Bedarf auch während des Sprints) ändern können, oder?

Konsequenz: Das Konzept der Selbstorganisation ist vielfach falsch verstanden worden und wird leider auch bis heute noch vielfach falsch vermittelt. Zunächst einmal bedeutet Selbstorganisation nicht komplette Anarchie und Team Empowerment bedeutet auch nicht Basisdemokratie. Es gibt sehr wohl feste Regeln und Ziele, die von außen vorgegeben werden und die ein Team erfüllen muss. Die Selbstorganisation findet innerhalb dieser Regeln und Ziele statt. Die Regeln und Ziele hingegen sind fest und können vom Team nicht nach Belieben umdefiniert werden.

Ein einmal gewähltes Vorgehen wie z.B. Scrum gehört zu den festen Regeln und kann (und sollte auch) nicht nach Belieben geändert werden. Es ist Aufgabe des Scrum Masters, dafür zu sorgen, dass die entsprechenden Regeln eingehalten werden. Tut man das nicht, hat man das große Problem, dass die initiale Lernphase fehlt, in der man versteht, welche Wirkungen die verschiedenen Regeln von Scrum haben. Nicht ad hoc offensichtliche Auswirkungen von Regeln werden nicht verstanden, sie werden mangels Verständnis in der Regel frühzeitig verworfen und es werden typischerweise bequemere, aber auch suboptimale Alternativen eingesetzt.

In Summe führt das Vorgehen typischerweise zu geringerer Produktivität, einmal weil viel Zeit und Energie für die Diskussionen über das Vorgehen verbraucht werden und andererseits, weil das Vorgehen weniger gut ist. Zusätzlich birgt das Vorgehen die Gefahr, dass sich das Verfahren nicht stabilisiert, sondern zu einem dauerhaften Ausprobieren führt.

Maßnahmen: Hier ist insbesondere der Scrum Master gefragt. Er muss die nicht diskutierbaren Anteile des Vorgehens klar kommunizieren und die Einhaltung forcieren. Bei den ergänzenden Anteilen (z.B. das verwendete Schätzverfahren) muss er auch dafür sorgen, dass sich zunächst auf ein Verfahren geeinigt wird und das auch eine Zeitlang ohne Diskussion gelebt wird.
Zusätzlich sollte er das Team auf eine Lernphase ohne Diskussion der Vorgehensweise einschwören.

Für ein erstes Scrum-Projekt sind dafür mindestens 6 Sprints, eher noch einige Sprints mehr zu empfehlen. Nach dieser Lernphase hat das Team dann genug Erfahrung mit der Methode sammeln können, um qualifiziert beurteilen zu können, an welchen Stellen Optimierungen möglich und sinnvoll sind. Aber auch dann noch muss der Scrum Master darauf achten, dass keine von außen vorgegebenen Regeln und Ziele angefasst werden, denn diese sind wie bereits geschrieben fest bzw. müssen in Fällen von Problemen in Form von Impediments angegangen werden und können nicht einfach eigenmächtig vom Team angepasst werden.

Zum Abschluss des Posts wie immer noch ein wenig Verlinkung:

  • Den Link zum ersten Post dieser Serie findet Ihr hier.
  • Den Link zum nächsten Post dieser Serie findet Ihr hier.

PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind wie immer herzlich willkommen!

Uwe Friedrichsen

Uwe Friedrichsen ist ein langjähriger Reisender in der IT-Welt. Als Fellow der codecentric AG ist er stets auf der Suche nach innovativen Ideen und Konzepten. Seine aktuellen Schwerpunktthemen sind Skalierbarkeit, Resilience und die IT von (über)morgen. Er teilt und diskutiert seine Ideen regelmäßig auf Konferenzen, als Autor von Artikeln, Blog Posts, Tweets und natürlich gerne auch im direkten Gespräch.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Marc Clemens

    10. Februar 2011 von Marc Clemens

    Ich glaube, dass sich Selbstorganisation und Regeln nicht ausschließen.

    Es geht hier um die Selbstorganisation von Projektteams und nicht um ein individuelle der einzelnen Teammitglieder. So ist es normal, dass sich das Team im Rahmen der Selbstorganisation Regeln gibt und die Mitglieder diese auch einhalten müssen. Da Projekte nicht im luftleeren Raum agieren, gibt es natürlich auch externe Regeln und Vorgaben.

    Das ist aber keine spektakuläre Erkenntnis sondern trivial. Wichtiger ist hier, wie stark das Team durch externe Regeln behindert wird. Lassen diese Regeln dem Team nur noch die Wahl zwischen ein paar feste Optionen (z.B. Planing Poker oder Affinity Estimation) würde ich das nicht mehr selbstorganisiert Arbeiten nennen.

    Viele von Dir beschriebene Problempunkte gelten für die Einführungsphase. Das ist auch nicht verwunderlich, da Selbstorganisation eine Fähigkeit ist die man lernen und trainieren muss. Daher wird die Selbstorganisation nicht von Anfang an gut funktionieren und benötigt Unterstützung (z.B. durch einen Coach). Hierzu finde ich den Blogeintrag von Dr. Eberhard Huber interessant.
    Gerade Regeln zur Entscheidungsfindung sollte sich das Team selber geben. Diese sind aber nicht zwangsläufig basisdemokratisch. Siehe hierzu auch folgenden Blogeintrag von Bernd Oestereich.
    Und gerade die Selbstadaption durch Retrospektiven ist ein sehr hohes agiles Gut, das ich ungern begrenze. Dabei ist es vollkommen OK das Teams Teile von SCRUM anpassen oder gar ganz raus schmeißen. Was für SCRUM auch gar kein Problem darstellt, da es sich „nur“ als Framework für ein Vorgehensmodell versteht. Dass diese nur mit Augenmaß erfolgen sollte und natürlich alle Prinzipien einer guten Performance Optimierung, wie z.B. optimiere nur wenn Du auch ein Problem hast, zu beachten sind versteht sich von selbst.
    Was aber oft nicht klar ist, obwohl etwas durch das Team selbst organisiert wird oder zum Verantwortungsbereich des Teams gehört, muss das Team seine Entscheidung nach außen rechtfertigen können.

  • Uwe Friedrichsen

    Hallo Marc,

    grundsätzlich gebe ich Dir in Deinen Anmerkungen recht und sehe darin auch keinen Widerspruch zu meinen Aussagen.

    Nur eine Ergänzung hätte ich noch, die vielleicht eher allgemeiner Natur ist: Du schreibst, die Erkenntnis XYZ sei nicht spektakulär, sondern „trivial“.

    Das ist grundsätzlich ebenfalls richtig. Warum schreibe ich trotzdem darüber?

    Weil sie aus meiner Erfahrung nur scheinbar trivial ist, wenn Du dich einmal umschaust. Wie sieht denn die Realität im Umfeld der IT aus (ich kenne primär das IT-Umfeld, kann daher nicht mit Sicherheit sagen, ob das spezifisch für dieses Umfeld ist oder ein allgemeines Phänomen)?

    Die scheinbar trivialen Apekte werden – da ja „trivial“ – einfach beiseite geschoben und es wird sich auf die „echt schwierigen“ Dinge gestürzt, denn daran erkennt man doch den echten „Eperten“, oder? Der zu beobachtende Effekt ist damit viel zu häufig, dass man die Grundlagen nicht durchdrungen hat und sich in letztlich irrelevanten Details festbeißt.

    Man hat in diesem Beispiel die Grundidee der Selbstorganisation noch nicht verstanden und auch nicht die Effekte und Wechselwirkungen der verschiedenen Scrum-Techniken (ist doch alles klar, ist doch „trivial“) und philosophiert viel lieber stundenlang darüber, was es für coole Schätzverfahren gibt und warum Planning Poker ja total out ist … ist jetzt bewusst etwas überspitzt, aber charakterisiert hoffentlich ganz gut das Phänomen, denn ich sehr häufig beobachten muss.

    (Um Missverständnisse zu vermeiden: Das bezieht sich jetzt nicht auf Dich; ich habe Dich anders kennengelernt. Dass ich jetzt gerade die Schätzverfahren als Beispiel aufgegriffen habe, liegt nur daran, dass Du sie gerade – in einem anderen Kontext – erwähnt hattest … war bequem … 😉 … das kannst du aber gegen beliebige andere Detaildiskussionen austauschen.)

    Das Phänomen kann man auch auf beliebige andere Themengebiete übertragen: Man ignoriert die Grundlagen und essentiellen Prinzipien eines Gebietes (da „trivial“) und fokussiert stattdessen auf beliebige Details. Mir fallen da auf Anhieb jede Menge Beispiele ein, ich lasse sie hier aber mal weg, weil sie nichts weiter zu dem Kommentar beitragen.

    Ich bin mir nicht sicher, warum dieses Verhalten so häufig zu beobachten ist: Unlust vor der unbequemen Aufgabe (die scheinbar trivialen Dinge entpuppen sich nämlich meistens als ziemlich harte Brocken, wenn man sie mal ernsthaft angeht), mangelnde Hipness (diese Themen gelten allgemein i.d.R. nicht als hip), mangelnde Erfahrung (man versteht die Tragweite mancher Dinge erst im Laufe der Zeit – geht zumindest mir so), missverstandenes Expertentum, …? Ich weiß es nicht wirklich, ich kann nur das Phänomen beobachten.

    Und ich bin mittlerweile davon überzeugt, dass wir in der IT wesentlich weniger Probleme hätten, wenn sich mehr Leute Gedanken um die scheinbar „trivialen“ Grundlagen und essentiellen Prinzipien machen würden als sich im x-ten scheinbar „coolen“ und „hippen“, aber letztlich irrelevanten Detail zu verlieren.

    Deshalb bin ich mit dem Begriff „trivial“ sehr vorsichtig und deshalb schreibe ich auch immer mal wieder über die scheinbar „trivialen“ Dinge … 😉

    Gruß, Uwe

    PS: Ich weiß, dass Du auch gerne mal „hinter die Kulissen“ schaust und Dich üblicherweise nicht von Faktoren wie „Coolness“ oder so treiben lässt. Da war halt nur der Begriff, den ich noch einmal aufgreifen wollte.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.