Immer wieder kommt die Frage auf, wie viele Scrum-Teams ein guter ScrumMaster führen kann. Soll er nur ein Team haben? Kann er nicht zwei oder vielleicht sogar drei haben, wenn diese schon erfahren genug sind? Ich bin der Ansicht, dass Menschen, egal wie talentiert oder wie gut sie organisiert sind, immer nur eine Sache machen können, wenn sie diese fokussiert und mit Hingabe erledigen wollen. Ein Scrum-Team zu führen ist komplex und fordert dem jeweiligen ScrumMaster alles ab. Meine Empfehlung lautet daher: ein ScrumMaster, ein Scrum-Team.
Was für die Führung eines ScrumTeams zutrifft, das zählt für die Erfüllung der Rolle als ScrumMaster nicht minder. So dogmatisch es für viele immer wieder klingen mag, so sinnvoll und (erfahrungsgemäß) realistisch ist es: Ein ScrumMaster sollte seiner Verantwortung als ScrumMaster nachkommen und nicht mehr! Ein ScrumMaster sollte ebensowenig als Entwickler, wie in Zweitfunktion als Product Owner agieren: Interessenkonflikte und Überforderung sind quasi vorprogrammiert. Meine Empfehlung lautet daher: gute ScrumMaster wissen, dass sie nicht zwei Rollen belegen können.
In einigen Punkten gehen bor!sgloger consulting und die Scrum Alliance nicht immer konform. Aber in der Three-Hats-Challenge des ScrumMasters herrscht Einigkeit: „A good ScrumMaster will be a process facilitator, a servant leader to the team and a change agent within the organization.“ (3) Diese drei Hüte erfordern von einem ScrumMaster, drei Verantwortungen im Fokus zu behalten, um ein Scrum-Team produktiv(er) zu machen: Scrum (Prozess) einführen, das Scrum-Team schützen (nach innen und außen) und Hindernisse (Impediments) beseitigen. Die Three-Hats-Challenge unterstreicht das, was die Zahlen eins und zwei zum Ausdruck bringen. ScrumMaster sein ist ein Fulltime-Job.
Der ScrumMaster will „vier Prinzipien immer und immer wieder zur Anwendung bringen“ (Gloger, 2011, S. 23), weil diese Argumente enthalten, die es braucht, um Scrum mit Erfolg in einer Organisation zum Einsatz zu bringen: Selbstorganisation, das Pull-Prinzip und damit die Kontrolle von Input, Timebox und damit die Vorgaben von Grenzen (Rahmen) sowie Nutzbare Business-Funktionalität als Ergebnis jeder Iteration (Sprint). Boris Gloger (2011, S. 23) vertritt die klare Auffassung: Ist eines der Prinzipien verletzt, dann ist es kein Scrum!
Werte sind immer ein Fundament und ihre Intention ist es, nach ihnen zu streben. Es geht weniger darum, sie zu perfektionieren, als vielmehr sie als Fixstern, wie als Lichtstrahl in einem Leuchtturm, also als Orientierung anzuerkennen und „just do them now, as best you can. Good stuff happens immediately regardless of where and when you start.“ (4) Scrum kennt derer fünf Werte, die die Grundlage des Handelns bilden. Sie lauten: Respekt, Offenheit, Fokus, Commitment, Courage.
Der Erfolg von Scrum, des De-Facto-Standards in der Softwareentwicklung, ergibt sich unter anderem durch seinen Rahmen (Framework). Eine Rahmenbedingung stellen die sechs Rollen, die der Scrum-Prozess vorsieht: drei funktionale Rollen (= das ScrumTeam), nämlich Product Owner, ScrumMaster und Entwicklungsteam, drei organisationale Rollen, nämlich Manager, Customer und Enduser.
Mike Cohn nennt sechs „Eigenschaften eines guten ScrumMasters“ (1), durch die sich die seines Erachtens „besten ScrumMaster auszeichneten“ (1): Verantwortungsbewusstsein, Bescheidenheit, Förderung der Zusammenarbeit, Engagement, Einfluss und Wissen (vgl. Cohn, 2010, S. 146ff). Es ist eine großartige Zusammenstellung. Mir fehlt noch eine siebte Eigenschaft, eine, die in der heutigen Kommunikation von und mit Menschen oftmals vergessen wird beziehungsweise viel zu kurz kommt - nicht zuletzt, weil wir Menschen verlernt haben, uns diese Eigenschaft zu nutze zu machen: das Schweigen.
Die Zahl 8 steht für mich wie Felsen, wenn ein ScrumMaster ein Estimation Meeting leitet. Wenn die Teammitglieder die vom Product Owner priorisierten Userstories schätzen, dann steht für mich fest, dass ein guter ScrumMaster nur die vom Entwicklungsteam geschätzten Userstories ins Sprint Planning 1 zulässt, die kleiner gleich 8 Storypoints (entsprechend der Cohn`schen Reihe = unreine Fibonacci-Skala) geschätzt wurden (besser wäre natürlich, wenn sie einen noch kleineren Funktionsumfang haben). Sind sie größer und in der Priorität des POs so hoch, dass sie im nächsten Sprint geliefert werden, dann sollte der ScrumMaster darauf achten, dass der PO diese Stories noch mal schneidet oder dass sie zu einem weiteren Anlass für eine Konversation VOR dem SP 1 werden.
Ein Scrum-Team sollte aus nicht mehr als neun Teammitgliedern bestehen. Amazon spricht vom so genannten „Zwei-Pizza-Team“ (Cohn, 2010, S. 208). Das bedeutet, dass ein Team so klein sein sollte, damit eine Bestellung von zwei Pizzas kein Tohuwabohu wird, sondern leicht von der Hand geht. Vorteile kleiner Teams sind u.a. weniger Zeit für Koordination und Kooperation, weniger soziales Faulenzen, weniger Gefahr der Spezialisierung einzelner, höhere Produktivität, etc.
Boris Gloger vergleicht die Rolle eines erfolgreichen ScrumMasters mit der Romanfigur Robin Hood (vgl. Gloger, 2011, S. 24ff.). Als ich zehn Jahre alt war, war Robin Hood auch mein Held: Erol Flynn, unerschrockener Widerstandskämpfer gegen den bösen König John und den Sheriff von Nottingham. Der ScrumMaster hat stets die Rolle des Veränderers. Er ist Vorreiter und geht dorthin, wo es weh tun kann oder wo er anderen (z.B. Management) weh tun muss. Er stellt Fragen, die sich sonst keiner zu stellen traut. Er sucht und findet Lösungen, wo andere an Problemen, Stillstand und Routinen gescheitert sind. Er gibt seinem Team Hoffnung, hält ihm den Rücken frei und weitet die Kultur von „Scrum“ auf die Organisation aus. Die besondere Herausforderung hierbei ist, dass der ScrumMaster ohne Autorität führt. Seine Rolle und die damit verbundene Verantwortung ist es, die ihm erlaubt, sein Handeln darauf auszurichten, den bösen Mächten des Stillstands die Stirn zu bieten und dafür zu sorgen, dass der Prozess in den (Scrum-)Flow kommt.Literatur(1) Cohn, M. (2010). Agile Softwareentwicklung. Mit Scrum zum Erfolg. Addison-Wesley(2) Gloger, B. (2011). Scrum. Produkte zuverlässig und schnell entwickeln. Hanser(3) http://www.scrumalliance.org/courses/20093867-certified-scrummaster(4) http://newtechusa.net/agile/scrum-values/