Video: Der ScrumMaster II

Warum heißt der ScrumMaster eigentlich ScrumMaster? Ich habe dafür eine Erklärung mit einem Augenzwinkern und erkläre in diesem Video: Was macht den erfolgreichen ScrumMaster aus? Dass er die Regeln befolgt, die er in Scrum-Büchern findet? Oder dass er lange darüber nachdenkt, ob das Taskboard richtig aufgesetzt ist? Macht es ihn erfolgreich, dass er Scrum studiert hat, also ein Certified ScrumMaster ist, oder weil er unheimlich gut über Scrum reden kann?
In diesem Video findet ihr meine ganz persönlichen Antworten auf diese Fragen.
Viel Spaß beim Schauen – Boris

Übrigens: Ich bin gerade in Rio de Janeiro und mache das Studium zum GEMBA (Global Executive MBA) – bin dann also auch bald was 😃

Video: Der ScrumMaster

Der ScrumMaster ist eine Management-Rolle. Sie oder er hat eine Vielzahl von Funktionen zu erfüllen, um ein Scrum-Team produktiv zu machen. Aus meiner Sicht war der ScrumMaster die erste Verkörperung der modernen lateralen Führungskraft: Er war der erste agile Manager. Seine Aufgabe ist extrem wichtig und jedes Scrum-Team braucht diese Führungskraft. Woher der ScrumMaster kommt, ob er aus den Reihen des Entwicklungsteams stammt, ob er oder sie aus der Fachabteilung gestellt wird, ob es – wie bei unseren Implementierung – oft der externe Consultant ist, ist unerheblich. Wichtig ist, dass er die Verantwortung für das Gelingen der Arbeit des Teams übernimmt. Er macht Scrum-Teams erfolgreich.
In diesem Video erzähle ich euch mehr über meine Auffassung zur Rolle des ScrumMasters.
Viel Freude beim Anschauen! — Boris

The ScrumMaster's 6 duties in self-organisation

“The ScrumMaster role cannot fill a person’s working day!” Most managers and even most ScrumMasters believe this is true. However, it’s not even near the truth. The ScrumMaster has a very hard job to do. In my ScrumMaster Advanced Pro training I use Dieter Rösner’s framework “The glorious six of self-organisation” (see his postings on this blog here) to highlight and explain all the duties. In short, self-organisation is framed and supported by six elements which lateral leadership roles should take into account when doing their job: the common problem, structure, voluntariness, synchronisation, know-how and development.
boris_6
So let´s have a look at the ScrumMaster’s job from the position of Dieter’s framework:

  1. Leadership/common problem: A ScrumMaster leads people. He is not a “boss” or a “manager in a traditional sense, nevertheless he leads his people and gives them orientation by helping them to see the “the common or mutual problem”. Every organisation – and a team is an organisation – derives its purpose from the problem it is trying to solve. It´s the job of the ScrumMaster to make sure that there is a problem addressed and that he has established a team that wants to solve this problem. Usually, the problem is defined by the Product Owner but the ScrumMaster makes sure that everyone moves in that direction. In this regard, the ScrumMaster is a leader or shows leadership.
    a. His task is to lead people,
    b. therefore he has the responsibility to do so, and
    c. he needs to gain the skills to do so.
  2. Facilitation/structure: Dieter mentioned that self-organisation needs boundaries (structure). Scrum demands a certain structure and it is always a ScrumMaster’s job to create a structure which allows people to perform. ScrumMasters build this structure on different levels, e.g.:
    a. Team-level: Using Scrum as a framework for creating structure.
    b. Meeting-level: By facilitating meetings and all other communication processes he ensures a clear structure in which team members can perform their tasks.
  3. Voluntariness/change agent: For me, the most interesting aspect of agile leadership has always been voluntariness and its corresponding commitment. Acting as a change agent, I created a believe system and a culture of voluntariness within my own company. It is the ScrumMaster’s job to establish a culture that fosters contribution and the willingness to commit.
  4. Synchronisation/management: Teams, departments and our whole society functions because we are able to synchronise activities of individuals. Ensuring synchronisation has always been the management’s job. So, nothing changes for the ScrumMaster. He acts as a manager to establish communication processes so that everybody involved is able to contribute as productively as possible.
  5. Skills (know-how)/trainer: Someone needs to make sure that team members have all necessary skills for performing a task. In most cases team members take care about it themselves. However, from a meta position it is sometimes easier to assess if a team lacks certain skills (“you do not know that you do not know”). The job of a ScrumMaster is to ensure that a team becomes aware of its own limitations and consequently supports it in gaining new skills by offering/organising … training. As a “head trainer” the ScrumMaster might not be able to train others himself in every occasion, but he is responsible for coordinating all training activities.
  6. Development/coach of a team: It is one part of the ScrumMaster’s duties to provide skills and knowledge as a trainer. However, a team also needs a coach. Someone who works with the team on its development as a team. I am not talking about skills but about mindset, behavior and motivation – we can also call it personal growth. The ScrumMaster sets thought-out measures to let a team grow.

In this short blog post I tried to transfer Dieter’s framework onto the role of the ScrumMaster. Please note that I only focused on the “what” not on the “how”. If you want to know how to do all this … read our free book “Selforganisation needs Leadership” on Gitbook. It is a translation of my best selling book: “Selbstorganisation braucht Führung”.

A model for management helps to understand ScrumMaster duties

The Scrum world mostly focuses on leading agile teams. In this community we constantly discuss how to treat team members and whether the Product Owner is a part of the team or not. We question the role of management and are still not sure if the ScrumMaster is a leader. Several times the agile world tried to dismiss managers as not being useful anymore. In his famous article “First, let’s fire all the managers” Gary Hamel even treated the manager’s position as a tax rather than a value creating function (Hamel 2011). Most people on the operational level (primarily those who produce something) consider managers as not creating value. Management is something bad whereas no management is something good. Sometimes, agilists believe that only leadership is necessary and people are able to manage themselves.
I have never been sure whether this simplistic approach to distinction between management and leadership is really useful. And I am still struggling with the idea that large corporations like Daimler, General Motors, Apple or Google shall exist without having a “management”. Of course I know that Buurtzorg for example doesn’t have a distinctive management level, neither has Spotify. Being aware of that, I wanted to know more and went back to university. I enrolled in a Global Executive Master of Business Administration Program at St. Gallen University (HSG). Within the first week of the program I was shown that the professors thought like the protagonists of the agile world but they don’t try to simplify things in the same way as we sometimes tend to do within the agile community.
It might be useful for the agile community to understand the deep implications of seeing management as a “reflexive design praxis” as the St. Gallen Management Model (SGMM) suggests (I will talk about the SGMM in another article). One “translation” of the SGMM into practical terms is described by a model, that I do not claim having understood correctly in detail yet but I would like to share a piece with you which helped me understand the difference between the logical levels of vision and strategy. Looks pretty obvious when you see this model, but not having clear this distinction before had confused my thinking. We got this depiction from HSG Professor Dr. Wolfgang Jenewein who specializes in High Performance Teams (he has also written a book about it, see Jenewein and Heidbrink 2008). He coaches large organizations as well as football teams – and it seems to me that he is very successful in doing so.
jenewein2
You can see the model he introduced and which is used at HSG by many professors in the picture. Please note that this is not the St. Gallen Management Model itself (Rüegg-Stürm and Grand, 2015) which I will try to describe in another article. The model explained by Jenewein operates on three levels – normative, strategic and operational – and five different aspects of management (give a vision, create a strategy, build an organization, form a culture and lead your people) which comprise “Leadership” as one necessary function of management. Let’s have a look at the three levels:

  1. The normative level represents the settings put in place by managers or e.g. the board of directors. One function of the normative level is to determine the vision of the company or the team. A vision offers the “Why?” (see Sinek 2011). The normative level is located above the strategic level, so the strategy of a company or team is not part of the vision but it can influence the vision of course.
  2. Most of the time, the strategic level consists of a set of processes to determine and guide the actions of a company or team. On this level we need to answer all the questions which help guiding the company. We need to deliver:
    a. Focus
    b. The positioning of the company/team = the differentiation to other teams or companies
    c. Customer segments and the respective customer needs
    d. We need to consider potentials and risks of our strategy
    e. And it is all about the FUTURE!
  3. The operational level is the most important according to the agile community as the “real” work is done on this level:
    a. Set up of processes to organize the organization. That means also to set targets and goals for the organization.
    b. Working on and building the culture
    c. “Leadership” is a day to day activity which is shaped by the context you are working in. If you are the head of department, you will need to set up visions that are different from those visions you would set up if you were the ScrumMaster of a cross-functional development team.

I believe this model helps us to understand which aspects of management need to be taken care of in order to structure an organization, a department, a project and even a team. As the ScrumMaster is the one who works on raising the productivity of the organization, he is also in charge (on his level) of making this happen.
The ScrumMaster has to make sure that there is a vision, a strategy, a clear set of rules that guides the organization and he needs to build the culture. He or she does this by applying modern leadership tools as I described in “Selforganization needs Leadership”(available online here)
If you understand leadership as an activity then you can also learn it. You can learn how to help your team by working on all three levels using the appropriate “transfers”, f.e. the company vision becomes the product vision, the strategy might become your product roadmap and so on. Using an approach that lets team members grow in their personality, work attitude and ability of self organization.
 
Hamel, G. (2011). First, let’s fire all the managers. Harvard Business Review, 89(12), 48-60.
Jenewein, W., Heidbrink, M. (2008). High-Performance-Teams: Die fünf Erfolgsprinzipien für Führung und Zusammenarbeit. Stuttgart: Schäffer-Poeschel.
Rüegg-Stürm, J., Grand, S. (2015). The St. Gallen Management Model. English translation of the fourth generation of the German text. Bern: Haupt Verlag.

Real life tips: Do's and Don'ts for Scrum implementations – the ScrumMaster

Do

Have a full-time ScrumMaster for each of your teams. Why? Because, as the name suggests, if you are doing Scrum you need someone who masters all the aspects of it: Protecting the team from outside disturbances, making the team more productive, collecting data and defining KPIs on the team’s performance in order to define where the team stands and where it wants/needs to be next. Every team has a lot of contact points with stakeholders/other departments within a company – all of these contacts need to be managed and scheduled. Furthermore, the ScrumMaster is the change agent of your organization. If Marketing is still wondering, why they are getting invited to those “review meetings” every second week, you need someone to explain the Why, the How and the What.
For a ScrumMaster to be effective it has to be clear that she assumes a lateral leadership role. Protecting the team, removing impediments and constantly challenging the status quo can only be done if you stop treating the ScrumMaster role as an add-on but start treating it as a prerequisite for starting with Scrum. Here are 3 things you can do right now, to ensure the legitimacy of your ScrumMaster:

Scrum is about continuous learning and continuous improvement – if you want to take full advantage of it, the ScrumMaster is a full time job!

Auch ScrumMaster machen mal Urlaub

ScrumMaster zu sein ist eine ziemlich fordernde Sache. Neben den langfristigen Zielen, die man für sich selbst und gemeinsam mit dem Team verfolgt, tauchen jeden Tag Impediments auf, die mehr oder weniger sofort analysiert und gelöst werden wollen. Ja, hin und wieder ist dann auch der ScrumMaster urlaubsreif. Es ist nicht vorherzusehen, wann Impediments auftreten und wie sie sich entwickeln – und meistens lösen sie sich während des Urlaubs nicht in Luft auf. Wenn wir von unseren Projekten länger abwesend sind, lassen wir uns also gerne von Kollegen vertreten. Irgendwie logisch.

“Oh mein Gott, ein neuer ScrumMaster!”

Da wir als Team sehr gut vernetzt sind und das Übernehmen von Teams regelmäßiger Teil unserer Aufgabe ist, ist es für uns als Consultants – vom Einarbeitungsaufwand abgesehen – ein routinierter Prozess. Für die unmittelbar Beteiligten, also in erster Linie für das restliche Scrum-Team und das Management, bedeutet das aber, sich sehr schnell und nur für einen relativ kurzen Zeitraum auf ein neues Gesicht einstellen zu müssen. Der oder die Neue steigt flugs in hausinterne Prozesse ein und hat aufgrund einer sauberen Übergabe durch den urlaubenden Kollegen auch noch ziemlich schnell seinen Daumen in offenen Wunden. Das muss man erst einmal verdauen.
Die Reaktionen, die einem ScrumMaster dabei entgegenschlagen, können weitreichend sein. Veränderung erzeugt nun einmal Widerstand. Zugegeben, eine Projektübergabe bedeutet in unserem Kontext nicht, dass wir dem vertretenden Kollegen jeden Handgriff erklären müssen und es kann sein, dass gewisse, für das Team selbstverständliche Spezifika nochmals hinterfragt werden. Unterm Strich machen wir aber alle zusammen das Gleiche: Scrum. Und das im Rahmen eines standardisierten Frameworks.

Die Chance eines neuen Mindsets

Um personenbezogene Impediments zu lösen, sind kontinuierliche Zusammenarbeit und Vertrauen nötig. Als Change Agents sehen wir in dem frischen Wind zwischendurch aber in erster Linie eines: eine Chance! Jeder Consultant bringt eine andere Spezialisierung, andere Erfahrungen und persönliche Zugänge zur Problemlösung ein. Als T-shaped-Team nutzen wir unsere unterschiedlichen Fähigkeiten gerne, um Spezialisten in das Projekt zu holen. Stefan Willuda zum Beispiel ist unser Spezialist für agiles Monitoring und Reporting; Karl Bredemeyer hat unglaubliche Skills in der Visualisierung und ist Mastermind hinter unseren Visual Scrum Trainings. T-shaped heißt in unserem Verständnis, dass Karl genauso rechnen und Stefan zeichnen kann. Ebenso verhält es sich mit unserem gemeinsamen Verständnis von Scrum: Das Toolkit ist das gleiche, jeder von uns nutzt die Tools aber auf seine eigene Art.

Mehrwert durch ein zweites Augenpaar

Insgesamt verhält es sich dabei wie beim Mob Programming: Durch ein zweites Augenpaar, einen externen Blick und ein frisches Mindset können Synergien geschaffen werden. Ich sehe es als Urlaubsvertretung gerade selbst, habe diese Vorteile aber auch schon auf eigenen Projekten erleben können, wenn ein Kollege mit einem Sonderthema oder einem speziellen Workshop für ein paar Tage eine neue Sicht auf ein Thema eingebracht hat. Sehen Sie das als Chance! Wenn ihr ScrumMaster das nächste Mal auf Urlaub gehen möchte, fürchten Sie sich nicht – fragen Sie ihn lieber, ob er sich vertreten lassen will!

Das andere Ende der Leitung: Scrum in verteilten Teams

Verteilte Teams passieren nicht. Sie entstehen, weil das Management festgestellt hat, dass erforderliches KnowHow nicht an einem Ort versammelt ist oder an einem anderen Standort günstiger zu bekommen ist. Wir müssen unser Team also dezentral organisieren. Nachdem wir uns im ersten Schritt mit der Kommunikation in verteilten Teams befasst haben, können wir uns nun daran machen, das Projektmanagement zu organisieren.

Warum bietet sich Scrum für die Organisation verteilter Teams an?

Am Ende jedes erfolgreichen Teambuilding-Prozesses steht ein gemeinsam geteiltes und verinnerlichtes Ziel. Im Scrum-Umfeld verbinden wir dieses gemeinsame Ziel in erster Linie mit dem Artefakt der Vision und mit dem agilen Wert des Commitments. Die Vision sollte bereits auf strategischer Ebende schnell, klar und deutlich verbreitet und laufend erneuert werden. Auf Sprint-Ebene ist das Commitment zu einem gemeinsamen Ziel das erste integrative Element. Es hilft dem Team, sich auf die Aufgaben des kommenden Sprints zu konzentrieren.
Scrum setzt auch im Verlauf des Sprints auf mehrere integrative Effekte. Wie bereits erwähnt ist das Peer Working ein effektiver Weg der Zusammenarbeit. Hier geht es aber nicht nur um den angesprochenen Vertrauensaustausch. Wenn es den Teamspirit stärkt, Checklisten abzuhaken hilft es uns erst recht, dieses Erfolgserlebnis zu teilen. Apropos: (Miss-)Erfolg ist der abschließende integrative Teil unserer Arbeit. Das Erreichen eines gemeinsamen Ziels kann uns als Team bestärken, Lohn für unsere Mühen sein. Ebenso kann gemeinsamer Leidensdruck Auslöser für Veränderung und Verbesserung sein.

Be part of it!

Spätestens wenn Sie versuchen, Magic Estimation mit einem verteilten Team zu spielen, werden Sie herausfinden, dass die Integration von Menschen, die sich nicht in einem Raum befinden, recht kompliziert sein kann. Hier gibt es verschiedenste Lösungsansätze, die je nach Teamsetting umgesetzt werden können. Zum Beispiel

Spätestens, wenn Sie ein großteils verteiltes Team betreuen, müssen Sie sich als ScrumMaster über eine vollkommen digital spielbare Variante der Magic Estimation Gedanken machen. Egal, um welches Meeting oder welchen Arbeitsschritt es sich handelt, die zwei wichtigsten Anforderungen sind dabei, dass

Remote. Ein Problem, das wir letzten Endes alle kennen.

Ihr Scrum-Team ist an einem Standort zusammengefasst? Herzlichen Glückwunsch! Sie werden sich im Rahmen der Zusammenarbeit gewisse Abstimmungsarbeit sparen. Das bedeutet aber nicht, dass Sie die oben genannten Grundsätze nicht beachten sollten. Irgendwie ist nämlich jedes Team verteilt. Wenn wir von Scrum sprechen, meinen wir die kontrollierte Zusammenarbeit von verschiedenen (Interessen-)Gruppen, den Rollen. Ich habe schon verschiedenste Unternehmen und Teams gesehen: Eine Konstellation, in der der operative Kern, externe Zulieferer, Management, Kunden und User nicht verteilt waren, habe ich dabei noch nie beobachtet. Die zugrundeliegenden Probleme können dabei durchaus die gleichen sein wie bei einem verteilten Scrum-Team. Somit betrifft uns das Problem des verteilten Teams doch irgendwie alle. Machen wir uns das bewusst und agieren wir dementsprechend. So können wir uns wieder ein klein wenig verbessern.

Das andere Ende der Leitung: Kommunikation in verteilten Teams

Remote-Arbeit ist heute gang und gäbe – auch in Scrum-Umgebungen. Ich bin selbst Teil mehrerer Remote-Konstellationen: Aktuell betreue ich als Interim ScrumMaster im Rahmen eines Kundenprojekts ein verteiltes Team. Es gehört zu meiner Aufgabe, Remote-Kollegen bestmöglich in das Team zu integrieren. Darüber hinaus gehöre ich als Consultant zum verteilten Team von Boris Gloger Consulting und tausche mich regelmäßig mit meinen Kollegen zu aktuellen Fragen und Problemstellungen aus; ich erlebe also die andere Seite, jene des Teammitgliedes. Zwei unterschiedliche Perspektiven mit interessanten Erfahrungen, aus denen ich viele Schlüsse über die Arbeit in verteilten Teams ziehen kann. Ich will hier nicht auf die allgemeinen Rahmenbedingungen verteilter Teams eingehen. Ein Blick in die Praxis beweist, dass sie in vielen Fällen nicht vorhanden sind. Ich möchte nur die wichtigsten zwei Rahmenbedingungen kurz zusammenfassen:

Die Remote-Aufgaben des ScrumMasters

Wie kann ein ScrumMaster nun die Remote-Kollegen einbinden? Oft höre ich, dass die Position des ScrumMasters nicht remote besetzt werden darf. Für meinen beruflichen Schwerpunkt als Interim ScrumMaster, der meist in existierende Organisationen kommt, ist das grundsätzlich richtig; aber nicht bedingungslos. Als Remote-Einzelkämpfer ist man oft schlechter ins Team integriert. Sei es, weil es sich um externe Arbeitskräfte handelt, die später zum Team stoßen, weil die persönliche Anbindung anders ist als im unmittelbaren Kreis des Teams, oder weil es bei der technischen Verbindung hakt. Es gibt viele Gründe, wieso Remote-Kollegen sich scheuen, Verbindungsprobleme auszusprechen oder es schlichtweg aufgeben. Aus den Augen heißt in dem Fall aber nicht aus dem Sinn. Um sich ein eigenes Bild zu verschaffen, sollte man sich auch einmal an das andere Ende der Leitung setzen, sobald man Remote-Kollegen hat, die diesen Platz besetzen.
Wurden die Rahmenbedingungen für die Arbeit in einem verteilten Team durch die Organisation geschaffen, können wir damit beginnen, unser Team aufzusetzen. Auch verteilte Teams durchlaufen die klassischen Teambuilding-Phasen, es sind aber noch zusätzliche Erfolgsfaktoren zu beachten. Beginnen wir mit dem, was da sein muss, bevor es losgeht: das Vertrauen. Vertrauen wir in die Ehrlichkeit der Remote-Kollegen? Oder geht es uns in erster Linie um das Vertrauen in ihre fachliche Qualifikation? Ist Kontrolle nicht besser? Das eine gegen das andere aufzuwiegen, ist nicht nötig – aus zwei Gründen:

Beachten Sie als ScrumMaster vor allem auch die Kunst, aneinander vorbei zu reden. Man benötigt keinen Abschluss in Kommunikationswissenschaften, um zu erkennen, dass Menschen Sprache unterschiedlich nutzen und interpretieren. Das kann nicht zuletzt eine Frage des Kulturkreises oder der Generation sein, Stichwort „Digital Natives“. Remote-Kommunikation verliert an Gestik, Mimik, manchmal auch Tonalität. Achten Sie beim Forming eines Remote-Teams also noch stärker darauf, dass der Empfänger morgen noch weiß, wie es der Sender gemeint hat.
Hoch entwickelte Teams können davon ungeachtet auch komplett remote problemlos kommunizieren. Meine Erfahrung als Berater zeigt mir aber, dass persönlicher Austausch in unserem Kulturkreis immer noch ein Grundbedürfnis jedes Teams ist. Sorgen Sie also dafür, dass sich die Teammitglieder in regelmäßigen Abständen persönlich treffen!
Der erste wichtige Schritt zur Arbeit in verteilten Teams ist gesetzt: die Kommunikation funktioniert. In einem zweiten Schritt können wir nun überlegen, wie Scrum mit der Problematik umgeht.
 
Fortsetzung folgt

5 Punkte für ein effektives Daily

Scrum ist ein hocheffizientes Rahmenwerk für die Produktentwicklung, sofern es richtig gelebt wird. Leider erleben wir zu oft das Gegenteil. Die Scrum Meetings werden prozessual etabliert, aber es fehlt am qualitativen Mehrwert, der durch die Meetings entstehen sollte.
Immer wieder sehen wir Dailys, in denen der ScrumMaster vor dem Board steht, als gelte es sein Heiligtum zu bewachen. Das Team hat im weiten Bogen um ihn herum Aufstellung bezogen und jede Person sagt einen Satz, ohne dass sich die Kärtchen am Taskboard bewegen. Fast alle Storys hängen in der WIP-Spalte und die Tasks bekommen trotz Bewegungsfaulheit keinen Punkt dafür. Der Product Owner vergibt bei Gelegenheit noch Aufgaben an einzelne Teammitglieder und fährt anderen Teammitgliedern über den Mund.
Ein so oder so ähnlich durchgeführtes Daily ist leider ein sehr ineffizientes Daily. Gut, immerhin ist das Daily als Meeting etabliert. Es wäre weitaus schlimmer, wenn das Meeting überhaupt nicht stattfinden würde. Da es stattfindet und das auf eine transparente Art und Weise, können wir anfangen, es in eine effektive Richtung zu lenken.

1. Daily als Ort der Kommunikation

Das Daily ist KEIN Statusreport für den Product Owner und auch nicht für den ScrumMaster. Das Daily ist da, damit sich das Dev-Team austauschen und koordinieren kann. Die Mitglieder des Dev-Teams sprechen miteinander und erklären sich gegenseitig, was sie machen, wo sie bei der jeweiligen Story noch Hilfe brauchen bzw. wo es sinnvoll ist, im Pairing zu arbeiten. Der ScrumMaster achtet darauf, dass das Ganze im zeitlichen wie auch menschlichen Rahmen bleibt und ist hellhörig bezüglich Impediments. Der Product Owner steht für Rückfragen zu den Akzeptanzkriterien zur Verfügung oder kann sich einbringen, wenn er das Gefühl hat, dass das Dev-Team über das Ziel der Akzeptanzkriterien hinausschießt.
Umsetzung: Der SM fordert die Teammitglieder auf, vor dem Taskboard zu stehen und stellt sich selbst mit den Product Owner in den Hintergrund. Wenn der ScrumMaster oder der Product Owner in den Mittelpunkt der Kommunikation rutschen, erklärt der ScrumMaster wiederholt, dass das Daily nicht dazu da ist, um ihn oder den Product Owner auf den neuesten Stand zu bringen. Das Daily dient dem Informationsaustausch zwischen den Teammitgliedern. Der ScrumMaster hält bei Bedarf wiederholte Mini-Workshops ab, um den Sinn eines Dailys zu erläutern und coacht bei Bedarf den Product Owner in seiner Rolle.

2. Das Herz des Dailys – Aufbau des Tasksboards

Ein Taskboard besteht aus drei Spalten: To do, Work in Progress (WIP) und Done – nicht mehr und nicht weniger. Die horizontalen Zeilen ergeben sich aus den Storys, wo die Tasks zugeordnet sind.
Umsetzung: Der ScrumMaster baut ein Taskboard auf. Unsere beliebtesten Hilfsmittel sind: Pinnwände oder Metaplanwände, die mit Kreppband oder Garn und Stecknadeln in die Bereiche aufgeteilt werden. Moderationskarten sind optimal für die Spaltenüberschriften und die Storys, während verschiedenfarbige Post-its und Stifte das tägliche Aktionsmaterial sind.

3. Die Fragen für das Daily

Man orientiert sich an den 4 Fragen:

Diesbezüglich gibt es mehrere Optionen. Entweder man geht diese Fragen pro Teammitglied oder pro Story durch. Ich persönlich präferiere letzteres: Letztendlich geht es darum, zu sehen, ob die Storys fertiggestellt werden können und nicht darum, dass alle Teammitglieder ausgelastet sind. Wer etwas Neues ausprobieren will, geht einen Schritt weiter und lässt die Teammitglieder herzeigen, was Sie bereits produziert haben, sodass jedes Daily zum Mini-Review wird.
Umsetzung: Der ScrumMaster achtet darauf, dass zu jeder Story/Person die Fragen beantwortet werden. Wenn etwas vergessen wird, erinnert er daran. Die Fragen auf Moderationskarten neben dem Taskboard aufzuschreiben, ist eine einfache und gute Erinnerungsstütze. Beim Mini-Review sorgt der ScrumMaster dafür, dass die Teammitglieder zwischen den Präsentationen zum Taskboard zurückzugehen, um es auf den neuesten Stand zu bringen. Der ScrumMaster sorgt dafür, dass die Timebox von 15 Minuten eingehalten wird, indem er die Leute daran erinnert, sich kurz zu halten bzw. eine Uhr mitlaufen lässt, die alle daran erinnert, wie viel Zeit noch übrig ist. Tipp: Es gibt Timebox-Uhren mit kleiner werdendem Zeitbereich zu kaufen.

4. Das Team bewegt sich, nicht der ScrumMaster

Das Team bewegt die Tasks über das Taskboard. Wenn ein Task done ist, sollte er auch wirklich done sein und nicht mehr zurückkommen. Dabei hat jeder Task ein Namenskürzel. Auch wenn wir Consultants als ScrumMaster arbeiten, können wir uns nicht immer merken, wer von uns welchen Task erstellt hat – mit Namenskürzel auf dem Task hat man aber immer eine Anlaufstelle, wenn man sich über Sinn und Zweck eines Tasks im Unklaren ist. Sollte sich ein Task nicht in die nächste Spalte bewegen, bekommt er jeden Tag einen Punkt und zwar von den Teammitgliedern. Der ScrumMaster achtet auf diese Tasks und fragt während oder nach dem Daily, ob es ein bestimmtes Impediment gibt, das die Fertigstellung des Tasks behindert, oder ob der Task einfach nur zu groß ist.
Umsetzung: Der ScrumMaster bittet die Leute, selbst die Tasks zu schreiben und zu bewegen und reicht dabei auch gerne die Stifte. Auch wenn es sich am Anfang unangenehm anfühlt: Der ScrumMaster bittet die Leute wiederholt höflich (oder auch direkter), die Tasks selbst zu schreiben, zu bewegen und Punkte zu machen. Irgendwann wird er es nicht mehr tun müssen, weil es die Leute selbst tun werden.

5. Flow

Es wird immer daran gearbeitet, so wenige Storys wie möglich offen zu halten und so wenige Tasks wie möglich in progress zu haben. Im Allgemeinen gilt es, sich immer in die Richtung des Optimums einer offenen Story zu bewegen und eine Taskanzahl in progress zu haben, die geringer oder gleich der Anzahl der Teammitglieder ist. Wir wissen alle, dass Multitasking ineffizient ist und wir wollen einen schnellen Feedback-Loop mit dem Product Owner erzeugen. Sobald eine Story abgeschlossen ist, nimmt der Product Owner sie ab bzw. gibt Feedback, warum sie nicht abgenommen werden kann.
Umsetzung: Der Scrum Master vereinbart mit dem Team ein WIP-Limit auf Story-Ebene oder gibt eines vor. Er sorgt dafür, dass das WIP-Limit eingehalten wird, indem er es nicht zulässt, dass weitere Storys eröffnet werden. Sobald eine Story fertig ist, sorgt er oder sorgen die Teammitglieder dafür, dass der Product Owner davon erfährt. Der ScrumMaster sorgt dafür, dass es bald Feedback gibt, ob die Story abgenommen wird oder was die Abnahme verhindert.
 
Es gäbe noch viel mehr dazu zu sagen, aber diese fünf Punkte sind für mich die Basis für jede weitere Aktion – sie erschaffen im Kern eine gesunde Daily-Kultur. Dabei ist es wirklich schwierig, diese Punkte alle im Kopf zu behalten und kontinuierlich zu kontrollieren. Es ist ein Idealbild, dem man sich im im Laufe der Zeit annähern kann. Im Laufe der Entwicklung des Scrum-Prozesses wird der ScrumMaster immer mehr seiner Verantwortung an die Teammitglieder abgeben, sobald er sieht, dass sie das Konzept verinnerlicht haben. Am Anfang jedoch muss er durch Vorzeigen, Vorleben und häufiges Erklären die Grundlage und das Verständnis für die Vorgänge schaffen, die für langfristige Produktivität sorgen.

Was braucht eigentlich ein ScrumMaster?

Haben wir als ScrumMaster eigentlich Bedürfnisse? Im agilen Umfeld liegt der Fokus ja darauf, dass ein Scrum-Team liefert und allfällige Impediments beseitigt werden. Der Kunde steht dabei im Mittelpunkt der Aufmerksamkeit. Das Entwicklungsteam und der Product Owner versuchen stetig, seine Bedürfnisse zu erkennen und zu befriedigen. Wir ScrumMaster haben dabei die Aufgabe, Hürden oder Lücken in diesem Prozess jeden Tag aufs Neue zu erheben und zu beseitigen. Als Feuerlöscher oder Boje im Sturm stellen wir sicher, dass das Team ungestört neue Produkte entwickeln kann und wir haben ein offenes Ohr für alle, die an diesem Prozess beteiligt sind: für den Product Owner, das Entwicklungsteam, den Kunden, aber auch für das Management. Wir sind Seelsorger, Superhelden, Innovatoren, Beschützer, Sekretäre, Strategen, Anpacker, Künstler, Freunde, Sprachrohre, Motivatoren, Coaches und Clowns zugleich. Wir versuchen in unserer täglichen Arbeit, die Schmerzen und Blockaden zu lösen, damit ein reibungsloser Arbeitsflow entstehen kann, aber auch die Stärken und Freuden zu fassen und sie am Leben zu halten. Im Grunde dienen wir als Servant Leader unseren Teams und ihrem Umfeld und sind stets bemüht, ihre Bedürfnisse zu stillen. Aber wer stillt unsere Bedürfnisse? Wir selbst? Das Management? Oder im Gegenzug unser Team?
Und wir ScrumMaster? Sollten wir nicht Motivation und Freude aus unserer Arbeit ziehen, indem wir den Prozess am Laufen halten und den Menschen um uns herum die Verantwortung für die und Freude an der Arbeit schenken? Sollten wir nicht so bescheiden sein, dass wir Kraft und Anerkennung aus den kleinen Veränderungen schöpfen, die wir vollbringen? Sollten wir nicht unsere Befriedigung aus der Freude und Dankbarkeit unseres Teams ziehen?
Da liegt meiner Meinung nach der große Knackpunkt. Ein Prozess lässt sich nicht von heute auf morgen verändern, eine Denkweise nicht von jetzt auf gleich bereichern und schon gar nicht trägt eine Veränderung sofort Früchte. Also sind wir ScrumMaster erst einmal diejenigen, die alles aufreißen, kaputt machen und in Frage stellen, was allen Beteiligten Schmerzen bereitet, unangenehm ist und teilweise nicht verstanden wird. Die Freude unserer Teams und aller, die sie umgeben, fällt eher mager aus und damit auch die Befriedigung unserer Bedürfnisse als ScrumMaster. Jetzt könnten alle ScrumMaster aufspringen und sagen: “Ja! Revolution! Seht endlich ein, dass wir nicht eure Gegner sind, sondern eure Partner!” Aber nein, bescheiden wie wir sind, halten wir uns zurück, genießen im Stillen und hoffen auf den einen oder anderen guten Zuspruch in irgendeiner näheren oder fernen Zukunft. Ein paar Methoden helfen uns dabei, nicht den Mut und den Antrieb zu verlieren:
 

Was ist ein Change Agent ohne die Legitimation, einen Change auch durchführen und implementieren zu können? Was ist ein ScrumMaster ohne das Vertrauen des eigenen Teams? Und was können wir bewegen im Unternehmen, wenn das Management uns nicht hört und weiter die alten Wege geht? Nur wenn wir die Möglichkeit haben, Änderungen auch bis zum Schluss verfolgen und umsetzen zu können, haben wir die Möglichkeit, unsere Bedürfnisse zu stillen. Nur wenn wir die Erlaubnis aller im Team haben, mit ihnen gemeinsam den Weg gehen zu dürfen, können wir Arbeits- und Denkweisen verändern. Und somit ist das unser elementarstes Bedürfnis: die Freiheit und Legitimation, endlich unseren Job machen zu dürfen.