Scrum: Der bessere Scrum Master
Es ist zwar schon eine Weile her, als über die Fünf Schwachpunkte von Scrum geschrieben habe. Die Resonanz auf diesen provokanten, aber aus meiner Sicht treffenden Artikel war durchaus unterschiedlich. Man hat mich des Plagiats bezichtigt, man hat mich als unkonstruktiven Satzbauartisten bezeichnet, man hat mir Rollen-Personifizierung vorgeworfen und mich als nachhilfebedürftig abgestempelt (inkl. Links zu „guten Coaches“). Ach ja, es gab auch tatsächlich einige ernsthafte Diskussionen, die von nachdenklichen Lesern über die einzelnen Punkte geführt worden sind.
Wie dem auch sei, am Ende des besagten Artikels hatte ich einen Ausblick darauf gegeben, dass ich nicht nur die Punkte nennen werde, die ich als Schwachstelle in Scrum sehe, sondern auch meine Ideen dazu beitragen werde, diese Schwachstellen zu stärken und damit Scrum als agile Managementmethode für mein Verständnis erfolgreicher zu implementieren. Das habe ich für das Thema “bessere Sprintdauer” schon getan, und damit widme ich mich heute einem ganz besonderen „Schwachpunkt“ – dem Scrum Master.
Die innere Handbremse
„Oh je, der Scrum Master ist ein Schwachpunkt von Scrum?“ werden sich nun viele stirnrunzelnd denken. Ja, genau so ist es, der Scrum Master ist meiner Meinung nach sogar eine richtig hinterlistige Schwachstelle in Scrum-Projekten. Das liegt viel weniger an dem Scrum Master als Person als am Scrum Master als Rollenimplementierung, wie er in vielen Büchern beschrieben wird und von Scrum-Trainern bei Unternehmen „antrainiert“ wird.
Viele Scrum Master in heutigen Organisationen sind „Vollzeit-Scrum Master“, die dediziert ein Scrum Team betreuen und sich tagtäglich mit den Sorgen, Nöten und Bedürfnissen Ihres Teams auseinandersetzen. Meiner Meinung nach ist hier schon der erste Schwachpunkt erkennbar. Obwohl die Rollendefinition in „Scrum-Bibeln“ nicht oft vom Scrum Master als institutionalisierte Position spricht, wird sie überall diskutiert, implementiert und implantiert.
Ein Scrum Master ist dazu da, sich überflüssig zu machen. Eines seiner größten Ziele ist es, sein Team in die Selbstorganisation zu führen und dort zu halten. Doch wie geht das bei einem Scrum Master, der eine Planstelle in einer Organisation ist? Mehr noch, hinter der Rolle Scrum Master verbirgt sich dann eine konkrete Person, ein konkreter Arbeitsplatz, ein konkretes Schicksal. Und diese Person soll sich jetzt überflüssig machen? Das wird wohl selbst der barmherzigste Mensch nicht tun. Jetzt könnte man diesen Vorwurf mit „don’t blame the tool“ abwiegeln, aber das wäre zu einfach. Die Schwachstelle liegt viel tiefer begraben als es auf der Oberfläche sichtbar ist.
Zwischen den Stühlen
Zumeist befindet man sich als Scrum Master innerhalb einer „agilen“ Organisation sowieso in der Zwickmühle. Einerseits sollte man das Team nicht führen, sondern begleiten. Andererseits bleibt das Management als „Chicken“ selten mehr als die ersten paar Sprints ruhig. Nicht selten trägt es „Erwartungen“ und „Strategische Leitlinien“ an den oder die Scrum Master heran. Schließlich ist der Scrum Master ja überzeugt von Scrum und der Idee, dass der Product Owner nun das Management betreiben soll. Die Kennzahlen über Team- und Projektperformance holt man dennoch beim Scrum Master ein, weil der „einfach näher dran am Geschehen ist“.
Viele Scrum Master fügen sich in diese organisatorische „Kneifzange“, anstatt sie mit Kraft zu durchbrechen. Wie soll man auch, wenn z.B. der eigene Job daran hängt oder die letzte (dicke) Auszahlung des Dienstleistungsvertrages mit dem Kunden noch aussteht?
Der Alleskönner
Viele eingefleischte Scrum-Experten und erfahrene Trainer stellen deshalb die Rolle des Scrum Masters auf ein hohes Podest. Der Scrum Master sei „eine Führungsrolle im Prozess“, es dauere tausende von Stunden, die Charakteristika und schwierigen Aufgaben eines Scrum Masters zu meistern. Ein Change Agent und Facilitator hat es eben nicht leicht.
Der Scrum Master als Rolle wird oft als Alleskönner dargestellt. Schließlich muss er die Grundlagen des Managements beherrschen, ein absoluter Teamplayer sein und obendrein auch noch ein feiner Kerl den jeder mag. Der Scrum Master ist der neue MacGyver in der agilen Software-Entwicklungslandschaft und kann selbst aus den schwierigsten und aussichtslosesten Situationen mit Einfallsreichtum, Know-How und Cleverness den Erfolg hin zur effektiven & profitablen Software-Entwicklung gestalten.
Eine schöne Vorstellung. Doch die Realität ist eine andere. In der Realität gibt es nur einen MacGyver, und den sogar nur im Fernsehen. Schade für die vielen Softwarefabriken und Weborganisationen, schade für die vielen Scrum Trainer und Berater, schade für die Tausenden von „Certified Scrum Master“. Doch Karten auf den Tisch: Es wäre auch zu schön gewesen, oder?
Mittlerweile ziehen sogar Alpha-Agilisten und Scrum-Kenner das „Scrum Is Always Better, Scrum Master Is Always Hero“-Gefühl durch den Kakao. Mit wunderbar leichtem und gleichzeitig nachdenklich stimmendem Humor schreitet seit einiger Zeit „Scrum Norris“ durch die geistigen Pfade der Agilität.
Quo Vadis Scrum Master?
Doch weder Humor noch Lamentiererei helfen einem dabei, diesen Schwachpunkt des „Scrum Master-Daseins“, nämlich die viel zu starke Fokussierung der Rolle und deren Implementierung, zu verbessern. Was tun? Wie kann man in einem Scrum-Team oder in einer Organisation mit Scrum-Teams diesen viel zu starken Fokus auf den Scrum Master mindern? Ich möchte hier einen konkreten Verbesserungsvorschlag und eine konzeptionelle Perspektivänderung als Diskussionsgrundlage vorstellen.
Dazu möchte ich ein Szenario aus der Entwicklung selbst voranstellen, um den Effekt der Maßnahme deutlicher hervorzuheben. Es wäre meines Erachtens sehr hilfreich für Team und Scrum Master, wenn die Abhängigkeiten zum Scrum Master zu allen anderen Rollen sowie zu der umgebenden Organisation so gering wie möglich sind. Um Abhängkeiten voneinander zu entkoppeln, gibt es in der Software-Entwicklung einige bewährte Methoden. Eine davon ist die sog. „Dependency Inversion“ oder „Inversion of Control“. Das hört sich doch genau nach dem an, was gebraucht wird, nämlich eine „Inversion of Control“ im wörtlichen Sinne. Nicht der Scrum Master organisiert das Team, das Team organisiert das Team.
Scrum Master in Bewegung
Übertragen auf den Prozess und die Rahmenbedingungen, die die Scrum-Methode vorgibt, ließe sich eine solche Indirektion mit einem einfachen Mittel erreichen: Die Rolle des Scrum-Masters wird im Team rotierend „durchgereicht“. Statt eines Scrum Masters, der sich dediziert um ein (oder noch schlimmer mehrere) Teams kümmert, kümmert sich das Team um die Erfüllung der Rolle des Scrum Masters. In der Praxis kann man den „Scrum Master-Hut“ z.B. sprintweise, monatsweise, oder quartalsweise von Team-Mitglied zu Team-Mitglied weiterreichen.
So ist jeder einmal mit der „Verantwortung“ des Scrum Masters konfrontiert und lernt obendrein eine weitere, wichtige Perspektive des Prozesses kennen. Dadurch erschließt sich sukzessive dem ganzen Team eine tiefere Kenntnis der Vorgehensweise. Es ergibt sich eine induktive Selbstorganisation: Man lernt die Probleme und Aufgaben der Scrum Master Rolle kennen und hilft sich gegenseitig im Team, dass es nicht zu Problemen kommt oder diese schnell ausgeräumt werden.
Aus Sicht des Prozesses mündet das Rotationsprinzip in mehrere Vorteile. Zunächst wird einmal wird nicht nur die Selbstorganisation gefördert, sondern auch das Know-How effektiv verteilt. Der Bus-Faktor wird im Kontext des Prozesses und der Methodensicherheit massiv erhöht.
Refokussierung der Kommunikation
Für den Product Owner ist der wechselnde Scrum Master ein regelrechter Segen: Statt sich die ganze Zeit auf den Scrum Master zu konzentrieren, kann (und muss) er sich nun mit dem ganzen Team auseinandersetzen – so wie es am effektivsten ist und sich auch „gehört“. Darüber hinaus lernt der Product Owner, seine geschäftlichen Anforderungen und Interessen mit der „Masse Team“ zu koordinieren, statt mit dem „Ansprechpartner“ Scrum Master, wenn es mal wieder Abstimmungsprobleme oder Missverständnisse gibt.
Nicht nur der Prozess, sondern auch die umgebende Organisation – also das Unternehmen – profitiert von dieser Maßnahme. Statt wieder neue Stellen oder Stufen in die Organisation zu implementieren, wird durch die Rotation der Scrum Master von „allen“ getragen. Ergebnis: Keine neue „Position“ Scrum Master, keine Kompetenz- und Verantwortlichkeitskonflikte mit Teamleads (Gruppenleiter) oder Head-Of’s (Abteilungsleiter), keine Skalierungsprobleme. Die Führungsmöglichkeiten sind klar und bei einem partizipativen Führungsstil höchst effektiv.
Die Rückkopplung zum mittleren Management und der strategischen Führung wird greifbarer, denn jetzt kann sich das Management nicht mehr den „Scrum Master“ als Mittelsmann für Mitarbeiterführung herauspicken. Der Fokus für wird stattdessen zum Product Owner gelenkt. Der wiederum wird – wie auch das Management selbst – realisieren und anerkennen müssen, dass sich eine Selbstorganisation nicht kommandieren lässt, sondern sich nach Bedürfnissen orientiert.
Scrum Master: Kein Platz für Projektleiter
Das Unternehmen wird schlanker, weil der „klassische“ Projektmanager nun nicht mehr in die für ihn äußerst angenehme „Scrum Master“-Schiene flüchten kann, sondern sie entscheiden muss: Entweder Product Owner oder Team!
Ich selbst dachte vor ein paar Jahren noch, dass der klassische Projektmanager nur die Wahl zwischen Scrum Master und Product Owner hat. Falsch! Heute darf ich die Lehre ziehen, dass ich damals auf den Scrum Master als Rolle viel zu Stark fokussiert gewesen bin. Team und Product Owner sind die “Key Player”, der Scrum Master ist nur Mittel zum Zweck, und das – wenn möglich – nur soviel wie unbedingt notwendig.
Mein Fazit: Mit einem rotierenden Scrum Master schafft man viele inherente Hürden aus dem Weg. Das Team, der Product Owner und die umgebende Organisation fokussieren sich deutlicher auf die Aufgabe. Der Prozess Scrum wird dadurch im Software-Entwicklungs-Theater wieder mehr zum Bühnenbild, das Team zu den Schauspielern und der Product Owner zum Regisseur. Damit ist dann auch eine gute agile Vorstellung wesentlich einfacher und schmerzfreier umsetzbar. Vorhang auf!
Lieber Ilker
ja, auch ich gehöre zu den Lesern Deines Blogs, und ja auch ich gehöre zu Deinen Kritikern; zunächst einmal freut es mich aber mit diesem Post eine konstruktive Weiterentwicklung im Vergleich zu den letzten Posts zum Thema zu sehen; kurz und gut, diesmal ärgere ich mich nicht über das geschriebene Wort.
Da ich mich wenig mit den o.a. “Bibeln” auseinandersetze (vielleicht aufgrund des verallgemeirnden, bibelhaften Charakters, bzw. der Interpretation derselben als solche mancher Zeitgenossen) will ich aus der ersten Sektion nur Deine Aussage aufgreifen, dass es das Ziel des Scrum Masters sei, sich selbst überflüssig zu machen.
Diese – durchaus plakative – Aussage; die wie ich weiß auch von den – um bei Deiner Wortwahl zu bleiben – “Propheten” getroffen wird; hat einen wahren Kern.
Nichtsdestotrotz sehe ich diese und die Rolle des ScrumMasters durchaus differenzierter. Ich denke wir sind uns einig, dass der ScrumMaster im Konstrukt Scrum die, im klassischen Sinne gesprochen, “Methoden” (besser eigentlich im Kontext von Scrum: Rahmenwerks-) -kompetenz und verantwortung trägt. Zusätzlich dazu, bzw. impizit aus dieser Verantwortung ist er der “Begleiter” und “Unterstützer” des Teams, hilft bei der Auflösung von Blockaden und Hindernissen, die das gemeinsame Teamziel gefährden, und steht des weiteren den Stakeholdern und dem Management (Personenkreis außerhalb des Scrum Teams) zur kritischen Verfügung (Methodisch). Im Unterschied zum PO (Vertreter der oft mannigfaltigen “Kunden” und strategisch-taktisch sowie fachlich-inhaltlich Produktverantwortlicher), und zum weiteren Team (Umsetzer, operative und fachliche Umsetzungsverantwortung) besteht ergo eine klare “Division of Power”, mit klar umrissenen Aufgaben, Kompetenzen, Rechten und Pflichten der Rollen und Agierenden.
Die Frage, die Du Dir (und den Lesern) stellst, und deren Antwort Du mit dem Beispiel aus der SW-Entwicklung (Dependency Inversion / Inversion of Control) unterfütterst, kann ich jedoch nicht vollständig nachvollziehen. Die Fragestellung zu Ende gedacht, könnten wir letztlich auch die Position des PO einer ähnlichen Prüfung unterziehen und auch diese Aufgaben in Rotation auf das Team übertragen. Zu einem gewissen Grad wird dies ja bereits in Estimation und Planning Meetings (kritisches Auseinandersetzen mit Produktideen, “Sanity Check” und kreativer Austausch) praktiziert.
Jedoch zurück zum Kern Deiner Aussage. Sicherlich zeichnet einen guten ScrumMaster die Fähigkeit aus, ein Scrum Team zum eigenverantwortlichen und kreativen Arbeiten anzuleiten, und dies erfolgreich abzuschliessen. Ich glaube jedoch nicht, dass es zweckdienlich (und realistisch) ist, glauben zu wollen, dass der Zustand dieses Erfolges konservierbar ist. Zum einen unterliegen Teams in der Regel Veränderungen (neue Mitglieder kommen dazu, andere gehen), des weiteren ist es eine völlig natürliche Verhaltensweise, dass sich Kräfteverhältnisse innerhalb Teams bilden als auch verschieben, des weiteren wird ein Team, sowohl in der strategisch/taktischen als auch operativen thematischen Auseinandersetzung je länger es (auch erfolgreich und eigenverantwortlich) zusammenarbeitet Schritt für Schritt einen getrübten Aussenblick auf das Team, Framework, Methoden, die Zusammenarbeit etc entwicklen – kurz: die Betriebsblindheit wird sich einstellen.
Ich bin daher von folgenden Thesen überzeugt:
1) Je nach Reifegrad der Teams / der Organisation / der Etablierung des Frameworks verschiebt sich der Fokus der Rolle ScrumMaster (kurz: Unterstützung bei der Entdeckung und Etablierung von Eigenverantwortung VS Auflösen von commitbezogenen als auch organisatorischen Impediments VS Kritische “Schnittstelle” (doofes Wort, mir fällt aber kein besseres ein..) zu Stakeholdern und insbesondere Management VS …VS … VS)
Auch bei “reifen” Teams gibt es daher genügend Aufgaben für einen ScrumMaster, da ich bis dato noch kein Team erlebt habe, dass irgendwann “fertig” ist mit seiner Weiterentwicklung, denn jeder Einzelne innerhalb des Teams lernt ja jede Minute Neues, reift dadurch weiter, und es besteht der Bedarf diesen individuellen Reifungsprozess wiederum im Team abzugleichen. Hier ist es hilfreich wiederum eine Person / (Rolle) zu haben, die dies erkennt, sollte die tiefe inhaltliche und operative Auseinandersetzung innerhalb des Teams auf Basis deren Kompetenz dies nicht erlauben (Eintrübung der Sicht). Ob diese Rolle in einer reifen Organisation und einem reifen Team dann tatsächlich von einer Person zu 100% für ein Team wahrgenommen werden muss, stelle auch ich in Frage, ändert aber meines Erachtens nach nichts am Bedarf nach der Rolle mit der “Methoden”kompetenz.
2) Persönlich halte ich recht wenig (eventuell mangels fehlender positiver Erfahrung) vom Durchwechseln des ScrumMasters, da dies meines Erachtens die Gefahr des Verlusts des Fokus der Agierenden birgt, und zudem die Position des POs stark schwächen kann (alle gegen einen).
3) Sehe auch ich vordergründig sowohl PO als Rest des Teams als eindeutig die produktiven, direkt an der Wertschöpfung Beteiligten und für dieselbe verantwortlich Agierenden. Hintergründig und indirekt sehe ich dennoch auch den ScrumMaster als klaren Wetsteigerer, dessen Arbeit sicherlich nicht ähnlich vordergründig und direkt mit einem Produkt verbunden sichtbar ist. Letztlich ist, denke ich, uns allen klar, dass man auch ohne einen ScrumMastern Produkte herstellen kann, ich glaube aber nicht, dass die Produkte, als auch die Qualität der Zusammenarbeit besser werden indem man die Rolle des ScrumMasters ab Erreichung der Eigenverantwortung eliminiert, denn siehe 1) und 2) es gibt auch in etablierten, “funktionierenden” Teams wieterhin einen Haufen hinter den Kulissen zu tun, und ein Dritter, weder startegisch-taktisch, noch operativ direkt eingebundener Player sorgt für Entlastung, erhöhten Fokus, und eine ausgewogene “Balance of Powers”.
Ich denke, als Schlußworte ganz gut ;-)
lg
Joe
PS: Mit “den Stakeholdern und dem Management kritisch zur Verfügung zu stehen” meine ich natürlich nicht zB “Reporting nach Vorgabe zu machen, sondern kritisch die Anforderungen zu betrachten und dem Team dabei zu helfen diese umzusetzen, bzw. diese eben auch zu hinterfragen, ggf. deren Anpassung (falls kontraproduktiv oder nicht der Zielerreichung dienlich etc) zu verargumentieren, und gemeinsam mit PO und Team sicherzustellen, dass die Sprtinziele (die ja wiederum auf strategischen Vorgaben, dei vom Mgt etc vorgegeben) werden erreicht werden können – in der Rolle als Facilitator.
Es macht aus Erfahrung durchaus Sinn, dass diese Rolle von einer “neutralen” Instanz in der Rolle des ScrumMasters besetzt ist, da so eventuelle Zielkonflikte und/oder verfestigte Wahrnehmungspositionen vermieden werden können.
Beim Durchwechseln darfst du folgendes nicht vergessen: Nicht jeder WILL die Rolle des ScrumMasters einnehmen!
Joe,
vielen Dank für dieses regelrechte “Plädoyer”! Jedoch sehe ich in Deinen Ausführungen – außer der vortrefflichen Rollenbeschreibungen – keine stichhaltigen Argumente, die eine rotierende Implementierung der Scrum Master-Rolle ernsthaft in Frage stellen würden. Meines Erachtens ist genau das Gegenteil der Fall.
Du schreibst z.B. dass der Erfolg der Selbstorganisation nicht konservierbar ist bzw. nicht lange aufrecht erhalten werden kann. Ja, das ist auch richtig, denn ein wesentlicher Faktor der Selbstorganisation ist ja das stetige “Inspect & Adapt”. Aber dazu braucht es doch nicht eine Personifizierung des Scrum Masters. Oh nein. Dazu braucht man gemeinsame Methoden & Mittel, und die gibt Scrum mit der Retrospektive. Der Scrum Master hat da keine große Rolle, außer die Rahmenbedingungen aufrecht zu erhalten.
Den Vergleich der Rotation mit dem PO, den Du im Übrigen überspitzt formulierst, entkräftest Du selbst mit der validen Argumentation, dass Team und PO die “direkten Agierenden” in der produktiven Wertschöpfung sind. Team und PO kommunizieren miteinander, da ist Feedback und Austausch nicht weit ;-) Das hat m.E. mit Rotation für eine Rolle nichts zu tun.
Darüber hinaus erwähnst Du den stetigen Wandel innerhalb des Teams und diesen uns allen irgendwann über den Weg gelaufenen Zustand der “Betriebsblindheit”, dem der Scrum Master entgeen wirken soll. Ja, gut. Aber wieso muss das eine Person “außerhalb” des Teams sein? Oder besser gesagt: Wieso soll das immer die gleiche Person sein, die als Scrum Master diese Aufgabe übernimmt. Ich gebe die Antwort: Es gibt keinenh Grund. Vielmehr ist es für das verhindern einer “Betriebsblindheit” wesentlich fördender, dem gesamten Team die Möglichkeit der Perspektivänderung zu ermöglichen. Wenn jeder einmal die Situation aus der Verantwortungsposition des Scum Master betrachtet hat, kann er sind auch besser mit den Problemstellungen außerhalb der Rollen-Verantworung auseinandersetzen.
Nun noch schnell zu Deinen Argumenten:
zu 1) Genau das ist eine Schwachstelle! Nicht der Scrum Master *als Person* ist die Lichtfigur, nicht der Scrum Master *als Person* ist der Hirte, nicht der Scrum Master *als Person* ist der Ansprechpartner. Nein – es ist die Rolle. Wenn sich das Team nicht nur als agierende und operative Institution wahrnimmt, sondern durch die wechselnde “Scrum-Masterschaft” auch den strategischen und selbstreflektierenden Faktor deutlicher erkennt, dann ist das für die Selbstorganisation und die Kommunikation mit PO und Umwelt umso förderlicher. Also ein klares Plus für die Rotation und Scrum als *agile* Verfahrensweise.
zu 2) Mit Verlaub, mit so einer Grundhaltung des “alle gegen einen” (Team vs. PO) schießt man sich schon ein methodisches Eigentor. Es darf keinen Scrum Master geben, der als “Sekundant des PO” agiert. Das trägt der konstruktiven und produktiven Kommunikation zwischen Team und PO nicht bei, es schadet mehr. Schließlich geht es ja ums miteinander, und nicht ums gegeneinander. Der Scrum Master soll eben nicht neben dem Team oder neben dem PO oder genau dazwischen stehen. Wenn die Rolle “Scrum Master” von jedem Teammitglied geschultert wird, dann gibt es auch keine “wir gegen den PO” Situation. Das wäre schon ein Grund für den PO, die Dienstleistung des Teams in Frage zu stellen.
zu 3) Die Rolle des Scum Masters ist unbestritten notwendig und wichtig, denn die Aufgaben dieser Rolle sind für den Projekterfolg nicht zu unterschätzen. In diesem Punkt kann ich Dir nur vollkómmen beipflichten. Doch auch hier sehe ich keinen Beweggrund, die Erfüllung der Aufgaben stetig durch eine Person durchführen zu lassen. Ich habe im Vorfeld mir überlegt, wie man bei der Rotation z.B. “längerfristige Planungen & Maßnahmen” eines Scrum Masters durchführen würde. Ich selbst habe das z.B. als Schwierigkeit der Rotation betrachtet. Doch auch hier bin ich mittlerweile überzeugt, dass mittel- und langfristige Maßnahmen von dem Rotationsprinzip nicht sondernlich beeinträchtigt werden. Schließlich gilt das für das Team ja auch. Überdies gibt es mit dem Daily und der Retrospektive wunderbare Anker- und Kontrollpunkte.
Zusammenfassend: Ich erkenne keinen triftigen Grund, warum eine rotierende Scrum-Master-Rolle schlechter oder schwieriger sein sollte. Ganz im Gegenteil, die Vorteile und Vorzüge gegenüber der “personifizierten” Variante sind für mich deutlich gegeben.
Dirk,
ich verstehe was Du meinst. Klar *will* nicht jeder der Scrum Master sein. Aber ist das entscheidend? Ich meine, Scrum und Agilität sind nun mal keine Wunschkonzerte. In meinen Augen ist diese Aussage schon fast gleichzusetzen mit “Unit Tests ist etwas für Weicheier” oder “was soll dieses tägliche am Board rumstehen”. Heutzutage wird von einem Software-Entwickler eben nehr verlangt, als nur am Rechner irgendwelche Schleifen zu drehen. Gerade in der agilen Softwareentwicklung ist eine “breiteres Kompetenzspektrum” gefragt und notwendig. Überspitzt und ein wenig provokant: Scrum ist für Erwachsene! http://www.gmbsg.com/scrum-ist-fur-erwachsene-parental-advisory-explicit-engineering/
:-)
Lieber Ilker,
nur ganz kurz ein zwischenkommentar; sollte ich heute abend Zeit finden antworte ich gerne dedizierter auf Deine Antworten:
Selbstverständlich ist eine Grundhaltung des “Alle gegen Einen” kontraproduktiv, ich sehe dies jedoch als Gefahr wenn die Rolle des ScrumMasters durch eine Person besetzt wird, die im Konstrukt Scrum zusätzlich andere Rollen erfüllt. Je mehr Hüte (Rollen) eine Person sich – wenn auch temporär begrenzt – aufsetzen muss, desto schwieriger wird der Wechsel zwischen diesen (Lebensweisheit;-), es ist zwar nicht unmöglich, aber bedeutend schwerer, zumal wenn es sich um den Wechsel zwischen Produktiver Rolle und methodischer Rolle handelt (erfordert kontinuierlichen Wechsel der Wahrnehmnungspositionen, ist zwar machbar, aber eben schwierig). Auch die Langfristigkeit und startegische Ausrichtung wird erschwert.
Es ist meines Erachtens nach auch völlig falsch, den ScrumMaster als Sekundant der einen (PO) oder anderen (”Team”) oder sogar noch anderen (”Management”) Partei zu sehen, der ScrumMaster steht mittendrin, ist gleichermassen für alle da, ohne jedoch durch die Interessen einer der Parteien parteilich vorbelastet und mgl. beeinflusst zu sein, und genau hier macht die Personifizierung der Rolle Sinn, denn wenn PO=SM, dann besteht die Gefahr des Ungleichgewichts zu Ungunsten der Implementierung (Wie); wenn “Team” = SM, dann besteht die Gefahr des Ungleichgewichts zu Ungunsten des Business Value (Was, Warum), wenn Mgt = SM, dann besteht die Gefahr des Ungleichgewichts zu Gunsten von Kosten, organisatorischer Veränderungsunwilligkeit uvm.
Ich glaube weiterhin an die Rolle und Besetzung der Rolle durch eine dedizierte, neutrale, nicht parteilich vorbelastete und mit der erforderlichen Distanz ausgestattete Person :-)
Deine Antwort auf Dominik’s Reply ist meines Erachtens nach zu dogmatisch, da vermisse ich den Pragmatismus, der uns doch gerade in den agilen Prinzipien vorgedacht wird…
lg
El Joe :-)
Die vielen Worte spare ich mir. Ich mache kein Theater und ziehe einen anderen Vergleich. Das Team sind die Handwerker, der PO ist Bauherr (meinetwegen auch der Architekt), und der Bauleiter ist der … na, Scrum Master.
Hallo “Haus im Glück”,
schön, dass Du auch andere Vergleiche ziehen kannst. Ich respektiere Deine Ansicht – teile sie aber nicht. Denn Deinem Kommentar fehlt das Fundament der Argumentation. Mit so einer wackeligen Statik kannst Du ruhig weiter mit Deinem “Bauleiter” glücklich Häuser auf Treibsand bauen.
Joe,
Nun das mit den “zuviel Hüte auf” – also mehrfache Rollenwahrnehmung – mag vielleicht aus Deiner Perspektive als schwierig zu implementieren betrachtet werden. Für den modernen Software-Entwickler ist das heute schon gang und gäbe. Er nimmt im Alltag einige Verantwortlichkeiten und Rollen ein. Im konstruktiven Kontext z.B. als Architekt, Designer, Programmierer oder Tester. Im methodischen Kontext z.B. als Requirements Engineer, Business Analyst, Implementer oder Coach. Das alles machen heute Entwickler auch schon ohne Scrum – mit XP, FDD oder sogar mit VXT & RUP. Selbigen Trend kann man im Übrigen auch für andere Felder des Engineerings sehen. Wenn heute ein “Screen Designer” nicht die Verantwortlichkeiten eines “Information Architect”s oder “Usability Engieers” überblicken und grundlegend umsetzen kann, dann wird dieser sich meiner Meinung nach zunehmend schwer tun, den Erwartungen des Marktes (und damit des Arbeitgebers) gerecht zu werden. Vor diesem Hintergrund ist es geradezu profan, eine *temporäre* mehrfache Rollenverantwortung als “schwer umsetzbar” zu kategorisieren. Ich sage ja nicht, dass man mehrere Rollen gleichzeitig wahrnehmen soll. Das würde der Produktivität diametral entgegenstehen.
Außerdem möchte ich Dir für deine gute Scrum-Master-Beschreibung danken, denn bzgl. Neutralität und Gleichgewicht ich Dir wirklich Zustimmung entgegenbringen. Dennoch varanlasst die “Neutralität” des Scrum Masters mich in keinster Weise, die Rolle im Team wahrzunehmen. Die Neutralität und faktenorientiertes Handeln wird gerade durch das gemeinsame Schultern der SM-Rolle gestärkt. Im ersten Augenblick mag es so wirken, als sei der PO nun “alleine” oder es bestünde ein Unverhältnis. Aber das ist ein kapitaler Trugschluß! Denn genau das Gegenteil tritt ein: Der PO wird implizit zu mehr Kommunikation und Austausch “gedrängt” – nicht nur von sich selbst heraus, sondern auch vom Team heraus. Das wiederum bringt beide Akteure näher zusammen und dient letztendlich einer besseren Produktumsetzung.
Ein Wort erlaube ich mir noch zu der Anmerkung meiner angeblich “dogmatischen” Antwort an Dominik: Meine Antwort war mit Sicherheit nicht aus einer dogmatischen Haltung heraus motiviert. Solch eine Argumentation entkräftet sich ja schon durch meine hier dargelegte alternative Perspektive gegenüber der Scrum Master-Rolle. Selbiges ist auch zu Deinem haltlosen Pragmatismus-Statement entgegenzubrigen. Scrum ist nun mal für Erwachsene. Aber auch XP, FDD oder andere Methoden sind für Erwachesene. Eine zunehmend breitere Kompetenzabdeckung in der Software-Entwicklung ist Fakt, kein Märchen.
Alles in Allem finde ich unsere Diskussion zwar durchaus interessant, habe daraus aber keineswegs überzeugende Gegenargumente zu meinem vorgestellten Verbesserungsvorschlag entnehmen können. Vielmehr motivieren mich argumentationsarme Kommentare (siehe z.B. “Haus im Glück”) in meiner Annahme bestärkt, dass die hier geschilderte Rotation der Rolle Scrum Master ein gangbares Mittel für eine effektive & effiziente agile Produktentwicklung darstellt. Meine These wird durch aktiven Beispiele gestärkt, die ich in jüngster Zeit erleben durfte. Ergo: noch bin ich ziemlich überzeugt davon, dass ein “rotierender Scrum Master” besser ist :-)
Hallo allerseits,
Zu “Hans in Glück”-
Diese Worte hätten auch gespart werden können :-). Wo gibt es bitte einen Bauleiter, der keine disziplinarische Macht hat? In einem “agilen” Haus würde ich persönlich nicht wohnen wollen.
Zu dem Kommentar von Dominik:
Ich bin der gleichen Meinung- nicht jeder WILL es, auch nicht wirklich jeder KANN es. Es gibt sehr viele Menschen, die ungern organisieren aber super gut ihre Arbeit erledigen. Wie wäre es mit Rotation der Teammitglieder, die es WOLLEN! Dagegen spricht nichts, wenn man auch bedenkt, dass der “Vollzeit” Scrum Master kein MUSS ist. In sehr vielen Unternehmen, werden die methodologischen Aufgaben nebenbei erledigt. So viel Methodologie sollte es auch nicht geben- der Hauptmerkmal von Scrum ist genau diese Rollen, Artifacten und sonstige Dogmen auf einem Minimum zu reduzieren und pragmatisch vorzugehen.
Zu Joe:
Wenn die Teams “jede Minute” was Neues dazu lernen, kann es sich nicht um gute Teams handeln! SCRUM verspricht nur GUTE Teams zu EXZELENTEN Teams zu verhelfen. Lass uns einigen, dass es “jeden Tag Neues” sein darf ;-). Ausserdem unterstellst Du dem Team, dass es nicht selbst “diesen individuellen Reifungsprozess wiederum im Team abgleichen” kann. Ist das dann Selbstorganisation? Oder denkst Du vielleicht in dem alten Verhaltensmuster des supervisors? Sollte man eine Struktur durch eine andere mit neuen, chickeren Rollennamen, aber fast gleichem Verhalten ersätzen?
Weiterhin schreibst Du: wenn “Team” = SM, dann besteht die Gefahr des Ungleichgewichts zu Ungunsten des Business Value (Was, Warum). Das Was und Warum ist NICHT in der Zuständigkeit des SM, so dass wenn jemand aus dem Team diese Rolle wahrnimmt, keine negative Auswirkungen auf dem BV zu erwarten sind. Desweitern ist es eher erwünscht und ein Beweis für die Teamreife, wenn das Team auch die Produktgestaltung in seiner Verantwortung hat.
Zu Ilker:
Du schreibst “Darüber hinaus lernt der Product Owner, seine geschäftlichen Anforderungen und Interessen mit der „Masse Team“ zu koordinieren, statt mit dem „Ansprechpartner“ Scrum Master, wenn es mal wieder Abstimmungsprobleme oder Missverständnisse gibt.” Wie soll das gehen, wenn der PO nicht aus der Organisation kommt? Ich würde eine Schnittstelle für die tägliche Kommunikation bevorzugen, egal ob Teammitglied genannt oder SM!
Und wieder auf dem SCRUM zu kommen :-)- Ilkers Idee finde ich sehr interessant und würde sie ausprobieren. Wenn sie in dem Team funktioniert, dann ist sie nicht nur interessant, sondern GUT!
Lieber Ilker
da kommen wir dann wohl definitv nicht zusammen; das ist aber auch gut so, wäre ja auch schlimm wenn wir Schuster nicht bei unsren Leisten (und unsren Überzeugungen) bleiben würden.
Schade finde ich nur, dass meine Argumentationen von Dir nicht als solche angesehen werden, aber auch das liegt letztlich im Auge des Betrachters. Es gibt eben unterschiedliche Wahrnehmungspositionen, und das ist auch gut so; in diesem Sinne schließe ich meine Beiträge zu Deinem Post ab, und wünsche ein entspanntes Wochenende.
Es grüsst Schuster Joe ;-)
PS: in meinem letzten Urlaub hatte mir der Hotelbesitzer gesagt: “If you want us to fly a pink elephant, just ask, and we will do it” …
Ich hatte damals nicht danach gefragt, vielleicht hätte ich es tun sollen, dann wäre ich heute um eine Erfahrung reicher; wobei, wenn ich es mir recht überlege: eventuell auch etwas enttäuschter …
Anyway, jetzt is aber wirklich Schluss von mir ;-)
Also eines muss man dir lassen … schreiben kannst du :) Ich finde deine Ausführungen sehr interessant, vor allem weil du natürlich nicht mit provokanten Seitenhieben geizt. Ich frage mich zwar, ob dass mehr sein soll als Polemik gegen die “Propheten”, um sich selbst den Mantel des “Ach-So-Gescheiten” zu geben, aber sie ist sicherlich gut fürs Marketing.
Mal zum Inhalt: Selbst-Organisation ist kein Ideal, kein Ziel weswegen wir Scrum machen. Die Idealisierung der Selbst-Organisation führt meiner Meinung nach zu nichts. Mal davon abgesehen, dass man einen Rahmen braucht, mit klaren Regeln und Prinzipien, damit sich Teams selbst organisieren können. (Was etwas ganz anderes als Selbst-Organisation ist.)
Es geht immer darum Teams so produktiv wie irgend möglich zu machen. Das ist ein Handwerk, eine Aufgabe und meiner Meinung nach eine Mission. Ein Team hat einen Coach, einen Trainer, der nur ein Ziel hat, er will gewinnen.
Der ScrumMaster wurde von keinem meiner ScrumMaster “Propheten”-Kollegen je als Sprachrohr oder als Mittler zwischen dem PO und dem Team gesehen, sondern, wenn nötig, als Mittler, als Moderator der Kommunikation zwischen den beiden Positionen. Glaubst du wirklich, dass man diese “Vermittlung” für die man Draußen in der Wirtschaft, mittlerweile sogar “Mediatoren” ausbildet, durch einen rotierenden ScrumMaster durchführen lassen sollte.
Du wirfst u.a. mir bei der Darstellung des ScrumMasters und seiner Aufgaben vor, dass ich diese Position idealisieren würde. Das gleich könnte ich dir auch vorwerfen. Das Team, das Team und noch mal das Team.
Beides ist falsch. Es geht nicht um Idealisierung, sondern darum, dass jeder seinen Teil richtig macht.
@Boris,
es freut mich, dass Du in Deinem Kommentar Dich mehr um das Thema (”was?”) kümmerst als um meinen Schreibstil (”wie?”), deswegen komme ich gleich zum Thema, möchte aber nur voranstellen, dass meine Motivation weder Neunmalklug-Spielchen oder Marketing-Getue ist, sondern ich versuche, im Sinne meiner “agilen Werte” die Dinge in meinem Alltag zu betrachten, zu reflektieren und Verbesserungspotenzial zu suchen (ergo: Inspect & Adapt). Ich verdiene nichts mit Reden über Agilität, ich verdiene etwas mit Leben von Agilität.
Ich kann Deinem Kommentar ausser reflektiven Aussagen keine gewichtige Gegenargumentation zum rotierenden ScrumMaster erkennen. Du frägst mich, ob ich glaube, dass man für diese “Vermittlung der Kommunikation” (hier: zwischen Team und PO), in der draußen in der Wirtschaft Mediatoren ausbildet und einsetzt werden, wirklich der rotierende SM adequat ist. Antwort: JA. Und dann die Gegenfrage: Warum denn nicht bitte schön? Weil es draußen Mediatoren gibt? Würde das im Umkehrschluß heissen, dass es keine agile Software-Entwicklung ohne professionelle Mediatoren (der SM) geben würde? Nein, das kann es nicht sein. Moderation & “Facilitating” sind nur Teile der SM-Verantwortung – und diese sind nicht einmal auf den SM begrenzt. Ganz im Gegenteil: Jeder, der zur Produktivität beitragen möchte (also Team, PO & SM) sollte sich diese Eigenschaften grundlegend aneignen.
Zu der Idealisierung des Teams und der Selbst-Organisation, die Du mir “im Gegenzug vorwerfen könntest” kann ich nur eines sagen: Ich idealisiere garnichts. Ich würde auch nicht sehen, wo ich das in diesem Artikel tun würde. Natürlich ist Selbst-Organisation im wirtschaftlichen Kontext kein Selbstzweck. Meiner Meinung nach transportiere ich das auch. Denn ich poche nicht auf Selbst-Organisation, um die “Meuterei auf der Bounty” herbeizubeschwören, sondern aus einer relativ einfachen und pragmatiscchen Denkweise heraus: Die Emergenz und adaptive Flexibilität, denen viele Organisationen heutzutage hinterherlaufen, kann man nicht durch “halbherzige” Umstrukturierungen in “quasi” Netzwerkorganisationen erreichen. Auch die vielbeschorene flache Hierarchie ist meines Erwachtens nur ein Zwischenschritt. Scrum ist hier sicherlich nicht “das alleinige Mittel” – aber man kann mit Scrum viel erreichen. Meiner Meinung nach ist die Förderung der Selbst-Organisationsfähigkeit ein wichtiger Beitrag zur ökonomisch effizienten Wertewirkung von Scrum als agile Software-Management-Methode.
Es geht – wie Du richtig sagtest – um Produktivität und um Software-Entwicklung. Scrum ist nichts für einen Buchklub oder in eine esoterische Selbsthilfegruppe. Es geht um’s “kreative, produktive, agile” Software-Entwicklungs-Geschäft. Ich habe meine Argumente für die Rotation dargelegt – eine stichhaltige Gegenargumentation sehe ich bis Dato nicht, welches mich weiter für die hier dargelegten rotierenden SM-Rollen-Implementation motiviert.
Lieber Ilker
then try it, von uns hier in der Post-Runde wird Dich sicher niemand aufhalten; Die Scrum-Polizei gibt es meines Wissens nach nicht, und wo kein Ankläger, da keine Verurteilung :-)
Wenns funktioniert oder eben auch nicht, lässt Du es uns ja sicherlich wissen :-)
In diesem Sinne, GSD
Joe
Joe,
ich will es nicht probieren, sondern ich habe es schon erlebt! Ergo: Mein Rotationsvorschlag ist kein theoretisches Gedankenspiel, bei dem ich Verbesserungen vermute, sondern eine Methodik, die ich “am eigenen Leibe” erfahren und nachverfolgen konnte. Zwar habe ich schon seit längerer Zeit von anderen Teams gehört, dass sie mit der Rotation gut zurechtkommen, aber gerade meine jüngsten eigenen Erfahrungen haben mir das notwendige Quentchen an “empirischem Beleg” gegeben, dass ein rotierender ScrumMaster nicht nur funktionieren kann, sondern eben auch sehr gut funktionieren kann. Das mag ein subjektiver Eindruck sein. Aber Eindrücke sind nun mal subjektiv. Und: es ist ein sehr positiver subjektiver Eindruck. Damit habe ich wohl auch Deinen geforderten “Erfahrungsbericht” erfüllt. :-)
Danke für den Erfahrungsbericht :-)
Eine Frage hab ich noch ;-) Wenn Du schreibts dies ist Dein subjektiver Eindruck, wie sehen dies anderen Beteiligten (PO, weitere Teammitglieder); auch positiv? Und über welchen zeitraum konntest Du das beobachten *neugierig*
Danke
Joe,
in der mir bekannten Facilitator-Manier hast Du mir wieder weitergeholfen! Ich bin zwar jetzt nicht mehr in besagtem Team, aber ich muss auch gestehen, dass ich “Scheuklappen” auf hatte und mit diesem Blogpost alle nach einer Meinung gefragt habe, aber weder den PO noch (explizit) die Teammitglieder (*ups*) :/. Insofern zunächst ein dickes Danke für die “Kommunikationsförderung” und ein etwas verdutztes “sorry, auch ich lerne” meinerseits.
Zurück zum Thema. Wir waren ein kleines Team (4 Leute – alles Entwickler) mit 2-wöchigen Sprints. Ich durfte 2 Sprints “mit aushelfen”. Ich war nicht SM, sondern andere waren dran. Natürlich war ich überrascht und habe den SM gefragt, wie das so funktioniert. Er sagte nur “Super. Wir kennen das halt nich anders.”. BTW noch etwas “komisches”: die Dailies waren relativ spät – erst nachmittags. Den PO habe ich natürlich nicht gefragt – das wäre jedoch sehr interessant, deswegen werde ich versuchen, ihn noch zu fragen. Für mich war’s auf jeden Fall sehr “flüssig” und eingespielt, obwohl ich neu war.
HTH und danke für den Tipp…
*shame on me* :-)
Lieber Ilker
no need to be ashamed :-) Freut mich, dass unser Austausch auch online funktioniert ;-)
Auch ich kenne selbstverständlich die Situation des “den Wald vor lauter Bäumen nicht zu sehen”, und merke derzeit beinahe täglich wie wichtige Bestandteile doch Assoziation und Dissoziation in der täglichen Arbeit sind; und ich lerne, dass es wahnsinnig anstrengend ist, verdammt viel Disziplin erfordert, und auch echt weh tun kann eigene Überzeugungen kritisch zu hinterfragen und aus verschiedenen Positionen zu durchleuchten.
Gedanken-logbuch: Ich bin mir nicht sicher, ob ich es schaffen würde, wenn ich zusätzlich noch weitere “Hüte” aufhaben müsste, zB als “direkt produktives” Teammitglied, – andererseits, wenn ich es recht überlege, wo liegt der Unterschied sich zB als Disziplinarische Führungskraft, Coach und Operativer ScrumMaster in jeweils verschiedenen Teams zu bewegen *grübel*, so weit ist das nicht weg von der von Dir geschilderten Situation…
Muss mich dringend mal wieder mit Herrn De Bono und seinen sechs Denkhüten auseinandersetzen, is schon ein Weilchen her… Dank auch Dir für die Denkanstöße!
Schönen Abend
Joe
Ihre Meinung ist gefragt!
Archiv
Diskussionen
Meta
Auszeichnungen
Copyright Ilker Cetinkaya using CC BY-NC-SA 3.0 DE | Powered by WordPress | Log in | Artikel (RSS) | Kommentare (RSS) | Styled with gmblue v0.1 (the next arthemia)