Selbstorganisation wächst durch konstruktives Feedback

Es sind viele Schritte notwendig, bis ein Team selbstorganisiert arbeiten kann. Wenn es dann endlich so weit ist, muss man Selbstorganisation zulassen und aushalten können. Was meine ich damit? Ein Beispiel aus der Praxis: In einem meiner Teams hat ein Teammitglied eine Aufgabe „gezogen“. Das heißt: Diese Person übernimmt die Verantwortung dafür, dass die Aufgabe end-to-end erledigt wird. Am Anfang gestaltet sich das oft schwieriger, als man denkt – besonders dann, wenn nicht in vollem Umfang klar ist, was mit Selbstorganisation alles einhergeht.

Feedback führt aus der Komfortzone

Die nun verantwortliche Person fragte nach jedem einzelnen Schritt beim Product Owner nach, ob es denn „so richtig“ sei und was im nächsten Schritt zu tun sei. Das Nachfragen war dabei nicht auf fehlende Informationen oder Kompetenzen zurückzuführen, sondern diente der Absicherung. Frei nach dem Motto: „Ich frage lieber einmal mehr nach, bevor ich eine auf den Deckel bekomme.“ Zwar war noch nie ein Teammitglied auf diese Weise zurechtgewiesen worden, allerdings war diese Denkweise scheinbar tief verankert und äußerte sich in diesem Absicherungsverhalten. Das restliche Team beobachtete das Verhalten des Kollegen eine Zeit lang, bis letztlich ein Teammitglied das Wort ergriff:
„Eine Aufgabe zu ziehen bedeutet, die Verantwortung dafür zu übernehmen. Du hast dir die Aufgabe gezogen und die End-to-End-Verantwortung dafür übernommen. Also bitte ich dich: Löse die Aufgabe, triff die nötigen Entscheidungen, nimm die damit einhergehenden Risiken in Kauf und leite die nächsten Schritte ein, ohne dich jederzeit absichern zu wollen. Wenn irgendetwas am Ergebnis nicht passt, werden wir im Review Zeit haben, das zu besprechen.“
Wow. Der ganze Raum war still. Diese Stille auszuhalten ist schwer, aber wichtig, um zu lernen, dass Feedback nichts Schlimmes ist. Niemand musste der angesprochenen Person zur Seite springen, um sie zu verteidigen. Genauso wenig musste sich jemand um seinen Job Sorgen machen. Das war ein klares Feedback auf inhaltlicher Ebene, ohne die Person auf persönlicher Ebene anzugehen. Ist es unangenehm zu hören, dass man nicht ständig nochmal nachfragen und sich absichern soll? Ja, ist es! Geht die Welt deswegen unter? Nein, geht sie nicht. Aber es passiert etwas: Man lernt, die Dinge anders zu machen und die Erwartung an die Selbstorganisation zu erfüllen. Außerdem macht es mehr Spaß, wenn man frei arbeiten kann und sich nicht immer absichern muss.

Konstruktives Feedback durch gewaltfreie Kommunikation

Um klares Feedback geben zu können, braucht es Vertrauen und Respekt in einer Gruppe. Zudem spielt es eine wichtige Rolle, wie man Feedback gibt. Marshall B. Rosenberg erklärt in seinem Buch „Gewaltfreie Kommunikation“, wie man die Dinge ansprechen kann, ohne den Gesprächspartner persönlich zu kränken. Rosenberg unterteilt die Kommunikation in vier Schritte:
  1. Beobachten
  2. Gefühl
  3. Bedürfnis
  4. Bitte
Der Autor fasst die Schritte in folgendem Merksatz zusammen: „Wenn ich a sehe, dann fühle ich b, weil ich c brauche. Deshalb möchte ich jetzt gerne d.“ Dieses Formulierungsmuster kann dabei helfen, dem Gegenüber Feedback wertschätzend und konstruktiv zu vermitteln. Natürlich handelt es sich dabei eher um eine Orientierungshilfe, aber dieses Feingefühl für konstruktives Feedback scheint auch unser Teammitglied zu besitzen, das seinen Kollegen auf die Situation hingewiesen hat.

Was wir daraus gelernt haben

Ich habe am Abend mit dem gesamten Team reflektiert und die Situation noch einmal aufgegriffen, um die Lernerfahrung für alle transparent zu machen. Klares Feedback hilft, ein Teammitglied verantwortlich zu halten. Ebenso hat es deutlich gemacht, dass mit Selbstorganisation nicht nur die Freiheit entsteht, zu entscheiden, woran ich als nächstes arbeiten möchte, sondern auch die Verantwortung einhergeht, diese Aufgabe sorgfältig abzuarbeiten. Selbstorganisation ist ein langer Weg und braucht immer wieder reflexive Phasen, um aus dem Geschehenen zu lernen. In meinem Beispiel hätte ohne die Reflexion leicht das Gefühl entstehen können, dass man für einen Fehler vor der ganzen Gruppe bloßgestellt würde. Das kann fatale Folgen haben, deshalb es ist wichtig, Feedback achtsam zu geben, um sicherzustellen, dass die Intention verstanden wird. Die Botschaft war in unserem Fall eine positive: „Wir lernen, was Selbstorganisation ist und was das für den Einzelnen bedeutet. Feedback im richtigen Ton und an der richtigen Stelle hilft, sich zu verbessern.“

In jedem steckt ein Genie. Man muss es nur wecken können.

Jeder ist ein Genie! Aber wenn du einen Fisch danach beurteilst, ob er auf einen Baum klettern kann, wird er sein ganzes Leben glauben, dass er dumm ist.“ – Albert Einstein

Mit diesem Bild des Fisches, der immer wieder vergeblich versucht, den Baum zu erklimmen, beschreibt Albert Einstein sehr bildlich ein Dilemma, dessen Auswirkungen wir tagtäglich zu spüren bekommen. Obwohl oder gerade weil wir uns in einer stark leistungsorientierten Gesellschaft befinden, fokussieren wir uns sowohl im beruflichen als auch im privaten Kontext viel zu häufig auf unsere Schwächen. Dasselbe gilt für den Umgang mit unseren Mitmenschen: Wir thematisieren tendenziell eher ihre Fehler anstatt ihrer Glanzleistungen.

Fragen Sie sich doch einmal selbst: Was sind Ihre Stärken und was Ihre Schwächen? Mir persönlich fallen sofort fünf Dinge ein, die mir nicht liegen oder die ich in Zukunft besser machen möchte. Bei der Formulierung einer Liste von fünf Stärken liegt mir der Stift schon deutlich schwerer in der Hand. Woran das liegt, ist schnell beantwortet: Von klein auf widmen wir einen Großteil unserer Zeit den fehlenden Kompetenzen. Egal ob Schulfächer, Tätigkeiten in der Ausbildung oder Aufgaben im Beruf – uns wird recht schnell klargemacht, worin wir noch besser werden müssen.

Was bringt uns wirklich weiter?

Müssen wir uns mit aller Kraft zu Dingen zwingen, die uns gar nicht liegen? Dass wir unsere Zeit viel besser in unsere Talente investieren können, verdeutlicht eine Studie, die bereits 1950 in Nebraska durchgeführt wurde. Diese verglich die Lesefähigkeit von normal begabten StudentInnen mit der von anderen StudentInnen, die sich durch eine besondere Lesebegabung auszeichneten. Es zeigte sich, dass normal begabte StudentInnen durch Übung von ursprünglich 100 gelesenen Wörtern auf bis zu 250 Wörter pro Minute kommen können. Aber: Die begabten KollegInnen konnten ihre Lesefähigkeit von anfangs 250 auf bis zu 2.900 Wörter pro Minute steigern. Sie erreichten somit ein fast 12 Mal besseres Ergebnis und hatten dabei auch noch Spaß.

Mir ist dieses Thema gerade im Bereich der Team-Facilitation so wichtig, weil ich davon überzeugt bin, dass Teams nur optimal funktionieren, wenn jeder seine individuellen Stärken einbringen kann. Ich selbst habe den Anspruch, in meinen agilen Teams ein Arbeitsumfeld zu schaffen, in dem man Spaß an seinen Aufgaben hat und die Teammitglieder jeden Tag mit guter Laune und voller Tatendrang zur Arbeit kommen. Eine wichtige Rahmenbedingung ist deshalb für mich, dass jede Kollegin und jeder Kollege die individuellen Talente nutzen kann. Denn nur so hat man das Gefühl, etwas erreichen zu können und Tag für Tag seinen Teil dazu beizutragen, dass das Team immer ein Stückchen besser wird. Und nur so kann man die erstrebten Ziele umsetzen und vielleicht sogar übererfüllen.

Durch einen Kompetenzworkshop das Bewusstsein für die individuellen Fähigkeiten stärken

Um die Stärken eines jeden Einzelnen gezielt einsetzen zu können, muss man sich diese jedoch erst einmal bewusstmachen. Ich unterstütze meine Teams gerne durch einen gemeinsamen „Kompetenzworkshop“ dabei, sich auf ihre individuellen Fähigkeiten zu fokussieren. In diesem Workshop darf jeder innerhalb von 15 Minuten seine eigenen Kompetenzen in Form eines „Kompetenzbaums“ visualisieren.

In den fest verankerten Wurzeln werden die Kernkompetenzen und das erlernte Wissen dargestellt. Der stetig wachsende und kräftiger werdende Stamm, der von Baum zu Baum ganz spezifische Strukturen haben kann, zeigt die Erfolgsfaktoren jedes Einzelnen. Dort ist Platz für die USPs (unique selling points = Alleinstellungsmerkmale), die jedes Teammitglied einzigartig und unabdingbar machen. Die Krone des Baums bildet eine prächtige, immer wieder nachwachsende Laubpracht, in der sich der persönliche Mehrwert wiederfindet, den das Teammitglied für das Team oder den Kunden generiert.
Nach Ablauf der 15 Minuten stellen alle ihren eigenen Kompetenzbaum kurz vor und hängen ihn gut sichtbar im Raum auf.

Dann beginnt mein Lieblingsteil der Übung: Jeder darf nun in einem Gallery-Walk die Kompetenzbäume der anderen vervollständigen. Hierbei ist es immer wieder erstaunlich, welche USPs und bereichernden Fähigkeiten man an sich selbst gerne übersieht. Indem die Kolleginnen und Kollegen diese offenlegen, geht man auf einmal viel bewusster mit ihnen um. Man nimmt sie nicht nur wahr, sondern erkennt auch Situationen, in denen man diese einsetzen kann, oder man entdeckt, wie die eigenen Fähigkeiten die der anderen Teammitglieder ergänzen können.

Kompetenzbaum

Nutzen Sie die Talente der einzelnen Teammitglieder und profitieren Sie als Team davon

Mit dieser recht simplen Übung stelle ich das Bewusstsein über die Unterschiede im Team her und sensibilisiere den Blick für die jeweils starken Seiten und Begabungen eines jeden Einzelnen. Gleichzeitig haben der Gallery-Walk und die Vervollständigung der Kompetenzbäume durch die Kolleginnen und Kollegen einen tollen wertschätzenden Nebeneffekt.

Natürlich ist mir klar, dass sich unsere Schwächen nicht in Luft auflösen, indem wir uns allein auf unsere Stärken fokussieren. Und selbstverständlich werden in bestimmten Berufsfeldern gewisse Grundanforderungen vorausgesetzt. Spiegeln sich diese nicht in den Fähigkeiten eines Bewerbers oder einer Bewerberin wider, wird es in diesem Arbeitsumfeld immer schwer sein. Wir sollten den Fokus unserer Aufmerksamkeit jedoch weg von den Fehlleistungen hin zu den Begabungen eines jeden Einzelnen lenken. Denn nur so können wir die individuellen Eigenschaften und das Genie, das in jedem von uns schlummert, optimal nutzen und in unser Team und die Arbeit einfließen lassen.

The Pull of the Retro

The Retrospective is perhaps the most challenging part of the Scrum process for a ScrumMaster. Although there are several ways to run a retro, the basic idea is very simple. You want to find out what went well and what could be improved, to gather information that will help you to improve the team’s performance. The Retro essentially gives the ScrumMaster ‘material’ to work with; as the change agent, you need to know what the team wants to have changed. Engaging in discussions with the team to understand what the problems are and how they can be addressed are key parts of the process.

Getting a ‘feel’ for the team

For me, the Retro is primarily a barometer for a team’s mood. You can focus your attention on the tone in which the team members speak, how they express their opinions and what the contents are. Their openness and engagement are what you want to see, but maybe you realize that they are holding back a bit. In that case, the team members might lack a clear understanding of the main point of the Retro; or they might not feel comfortable enough to speak out and raise difficult (and potentially controversial) issues. Consequently, you have to ask yourself: What is preventing the team from being open, and therefore fulfilling the purpose of the meeting? What is required to give them more confidence? One of my teams had already gone through several Retro cycles. Nevertheless, there was this feeling that we are going around in circles. The Product Owner was always present, and the team would not really speak about problems at the team level. Even after organizing categories to specify whether problems (and successes) are at team, sector or organization-wide levels, the problems at team-level remained underrepresented and would often boil-down to difficulties that actually lay in cooperation with other teams.

Individuals becoming a Team

Although the team had been performing very well, the Product Owner did not want to take the further steps recommended by the SM to improve the team’s performance further. Instead, the PO turned up for the Backlog Refinement and questioned the concept of the meeting; and what is more, he had no proper Backlog for the team to refine. Similar problems have been encountered in other meetings, including Dailys where the PO was openly dismissive of the pull principle by actively staring at a person whom he believed should take a particular User Story during the Sprint Planning 1. Of course, there are many ways to address this. However, in order to ‘empower’ the team it is important to keep a cool head and not to argue during joint meetings, but rather explain the roles, the aim of the particular meeting and the principles of Scrum – day in, day out, if required. The team got the ideas and had a pretty clear picture of how things should run in an agile environment. After one particularly poor showing at the Backlog Refinement, I decided to communicate more openly and strongly what the team needs, and what the role of the PO consists of. At first glance, it seemed that this didn’t work out very well. The meeting ended without anything resembling a half-decent Backlog, with the PO throwing User Stories on the table in the shape of tasks, and a team visibly annoyed.

The Grassroots Retro

It was not entirely surprising to receive an update several hours later. The team held a spontaneous ‘crisis meeting’ and wanted to make these issues a subject in the next Retro. I welcomed this news with arms wide open, particularly because the team had developed a pull principle to Scrum itself. Although the PO used to join those meetings, I offered to exclude him this time. The team agreed. We started the Retro with two boards. One symbolized the United Nations. All the topics on this wall would be directly discussed with the PO. The other one was Las Vegas. What happens in Vegas stays in Vegas. The logic behind it was to encourage the team members to show commitment and also become aware when they are not courageous. To my positive surprise, everything ended up at the UN, while the themes were almost entirely focused on the dynamics within the team. After 1 hour we realized that we need more time, so we organized a second part to go through the themes and find potential solutions. The vast majority of the themes challenged the PO, how he is fulfilling the obligations towards the team, and produced concrete steps forward. The next steps were to formulate the points, prioritize them and for me to present them to the PO who needs to commit to them.

Discovering Openness

Overall, and irrespective of the possible outcome of the meeting between the PO and the SM, the team has succeeded in formulating and openly speaking about problems. Initially, they were not able to challenge the PO directly. By now, the team members have committed themselves to use Retros to raise essential questions to improve their ability to work effectively. I’ve realized that feeling the pulse of the team and reading between the lines are important, and I’ve also learned that it is crucial to invest time in change and provide clarity on roles and responsibilities. The results speak for themselves. In the next sprint, the team nearly completed the entire committed Sprint Backlog, and the members have also begun sparring to learn new skills from one another. When culture change is in focus, openness does go a long way.

Der Blick hinter die Fassade: die Retrospektive

Das tägliche Lernen und Reflektieren gehört zum Wissensarbeiter wie das tägliche Schleifen der Werkzeuge zum Waldarbeiter. In den immer wiederkehrenden Lernschleifen kann altes Wissen vertieft, neues Wissen integriert, beides miteinander verknüpft und hinterfragt werden. Sich bewusst die Zeit zu nehmen, um zu reflektieren und das Reflektierte zu dokumentieren, sollte ein fixer Bestandteil des Arbeitsalltags sein und zu einer Praxis werden, die selbstverständlich ist.

Reflexion im Team

Nach einem Sprint ist es üblich, einen Rückblick zu wagen und die Geschehnisse im Sprint noch einmal Revue passieren zu lassen. Hier ist es z. B. möglich, mit Fragen zu arbeiten:

  1. Welche signifikanten Ereignisse sind im jeweiligen Zeitraum passiert?
  2. Wie ist das Stimmungsbild?
  3. Was ist uns gelungen?
  4. Was können wir verbessern?

In diesem Scrum-Workshop geht es vor allem darum, Beziehungspflege im Team zu betreiben. Dadurch soll einerseits ein Gemeinschaftsgefühl entstehen und andererseits ein Raum geöffnet werden, um Dinge anzusprechen, die gut oder eben nicht so gut gelaufen sind – und das möglichst wertfrei. Dieses Treffen muss auch keinen Output generieren. In der Praxis erlebe ich häufig, dass ScrumMaster den Fokus auf das Ableiten von „Maßnahmen“ aus dem Gesagten legen, damit man im nächsten Sprint gewisse Regeln oder Verhaltensweisen befolgen kann. Und das ist großartig, wenn das Gesagte den nötigen Raum findet, um von allen gehört zu werden, und man daraus Verhaltensweisen definiert, die einem Orientierung geben. Doch das übergeordnete Ziel dieses Treffens ist es, die Zusammenarbeit im Team zu verbessern. Nicht mehr und nicht weniger. So stellt sich mir die Frage: Wie kann ich als ScrumMaster den Fokus auf die Zusammenarbeit legen?

Offene Retrospektiven gestalten

Für Teams, die sich kennen und miteinander frei über ihre Themen sprechen können, wäre es vielleicht angenehmer, wenn man das aus Büchern bekannte Retro-Format aufweicht. Hier kann man auch durchaus experimentieren. Was passiert eigentlich, wenn man mal den Meeting-Raum verlässt? Wenn man die gewohnte Retro mal ganz anders gestaltet? Vielleicht in einer zwangloseren Atmosphäre? Wie wäre es, den Druck rauszunehmen und die Retro als eine offene Stunde für das Team zu gestalten? Ohne Agenda. Ohne Fragen. Einfach mal darüber zu sprechen, was gerade ansteht und die Menschen im Team beschäftigt. Und die Teammitglieder entscheiden zu lassen, worüber sie sprechen oder wie sie diese offene Stunde gestalten wollen.

Darum ist ein offener Raum wichtig

Um einen offenen Raum ohne Rahmen zu gestalten, braucht es einen gewissen Reifegrad als Team. Doch genau in diesen Momenten passiert oft etwas ganz Wunderbares. Ohne Ablenkungen von Social Media oder anderen Verführungen. Genau in diesem Moment kann man Kontakt zu sich selbst herstellen und sich die Frage aller Fragen stellen: Wie fühle ich mich gerade? Natürlich kann sich in diesem offenen Raum auch Langeweile einstellen. Aber das ist der Punkt, an dem Kreativität aufkommt. Neue Denkwege können ergründet werden, Ideen entstehen.

Auf den Punkt gebracht

Meiner Erfahrung nach sollte man die Retro nicht unnötig verkomplizieren und stattdessen so einfach und klar wie möglich gestalten. Vielleicht hilft ja eine Frage, die den Ausblick in die Zukunft wagt: Was würde uns beim nächsten Sprint glücklicher machen? Im nächsten Meeting? Am nächsten Tag?

You want to use Scrum? Watch Lord of the Rings first.

Disclaimer: This post will be most enjoyable to you if you have read the books or at least watched the movies of the Lord of the Rings. If you are that guy/girl, who has no clue, I invite you to read the plot first. Needless to say; this blog post contains a heavy load of spoilers.

J. R. R. Tolkien started working on the books in the 1930s, so no way he plagiarized Jeff Sutherland’s or Ken Schwaber’s ideas, but agility has been around since the 1930s in Bell Labs too, so maybe he got a little inspiration there?!

The whole storyline of the Lord of the Rings (LotR) follows the same pattern like building up an agile team. To show you what you can learn from LotR for your work in an agile environment, I’ll guide you through the plot and show you seven steps that make agile teams successful.

In the first chapters of the LotR Gandalf visits an old friend of his, the Hobbit Bilbo, who is the owner of the “One Ring”; a powerful artifact that could destroy the world when held in the wrong person’s hands. The dreaded, evil wizard Sauron seeks the power of this ring to expand his territorial dominion over Middle-earth. In order to prevent this tragic fate, the ring needs to be destroyed and thus becomes the Product Vision of the book plot. However, who delivers this Product Vision?

Step 1: You need someone who commits to a vision.

In the agile world, this someone is called Product Owner. In LotR, this is the subject area of Gandalf the Wizard. He has the greater vision of defeating the greatest evil in the world, Sauron. He is also responsible for stakeholder management; for instance getting in touch with Saruman with the aim to build an alliance with him, convincing the Riders of Rohan or rallying the troops of Gondor. Further, he knows what needs to be delivered and how the tasks have to be prioritized to reach the goal. Speaking in agile you could say, he is responsible for keeping the product backlog in shape.

All in all, one can observe that he is strongly committed to his vision of defeating the evil at all costs. However, he can not execute it alone and needs a team, which takes us to the next step.

Step 2: Recruit a badass team.

The first team members of the agile team are Frodo, who in the meantime inherited the Ring from his uncle Bilbo, and Sam, his gardener. These two are Hobbits or halflings and therefore well versed with two skills: luck and stealth – skills, which come in handy for the first part of their mission, getting to the human city of Bree to find a guardian for their journey. In the first part, they get support from Merry and Pippin to navigate through the lands where they already encounter the evil forces of Sauron, only able to flee from the danger partially through wit and sheer luck. They reach Bree and meet their guardian.

Let’s recap this section in agile jargon: The Product Owner recruits a team that will bring his vision to life and makes sure that the team members have the required competences to deliver the first product increment. But he needs support for that, which brings us to the role of the guardian the four Hobbits meet in the city of Bree.

Step 3: Find a person willing to defend and unite the team.

In LotR the guardian’s name is Aragorn. In the agile world, Aragorn would be the ScrumMaster of the team. He protects the team from impediments and leads them as a servant leader. For example, after the expanded team leaves Bree, Aragorn hunts food, protects the team from the evil forces of Sauron and leads the Hobbits to Rivendell so that they can focus on their mission “to protect the ring.” In the subsequent sections of the book, the servant leadership traits of Aragorn become clearer as he recruits the Dead Men of Dunharrow to ensure that the team protects Gondor in one of the big fights at the end of the book.

Aragorn embodies the ScrumMaster throughout the book, he demonstrates servant leadership, ensures solutions to impediments and practices a retrospective meeting with the team after the “death” of Gandalf in the Mines of Moria. In short, he meets all expectations of a good ScrumMaster and supports the team’s path towards success.

Step 4: Upgrade your team “T-shaped style”.

After getting to Rivendell, Aragorn and the Hobbits take part in the circle of Elrond where the overall goal of the team becomes even clearer; through further deliberations and a lecture by Elrond. They have to destroy the ring in the fires of Mount Doom, a project that needs more and broader resources than only getting the ring in a safe haven like Rivendell. So, during the discussion the team around Gandalf, the Hobbits and Aragorn joins forces with

Together, they form a T-shaped team, each one having a rough understanding of the skills of the other team members but specialized in one specific skill. For example, in the Mines of Moria, the small Hobbits widen their skillset by engaging in fights. Although they are much less effective than the other combat-approved team members, they were able to learn from them.

It also seems to be no coincidence that they are nine team members, holding their needed communication and coordination at a manageable level; a size for a team that is also highly recommended in the agile world. So, in this form of an agile team, T-shaped and small, they start from Rivendell to realize the team’s vision.

Step 5: Embrace self-organization.

The team that sets off at Rivendell to put the “One Ring” into the fires of Mount Doom is certainly a non-hierarchical team. Each member of the team is at eye level with the other members, even the small Hobbits. Helping each other when needed, e.g., when the team opens the gates to the Mines of Moria. Nobody is forced to stay in the team and is free to leave at any time. The team members are bound by the vision and their commitment to accomplishing the goal. This cohesion gives the team the strength to overcome danger and reevaluate their strategy. In two instances this becomes crystal clear. The first is the “killing” of Gandalf in the fight against the Balrog: Every member of the team knows what to do bearing in mind the overall vision. Even in the face of the death of their Product Owner, they are still able to execute the plan. The second is the voluntary splitting of Frodo and Sam from the rest of the team after the battle on the hill of Amon Hen. The other part of the team recognizes the benefits of this drastic action for their mission’s success and chooses to embrace actions more suited for them, like pursuing or fighting the enemy troops.

Step 6: Iterate in small increments and get rid of impediments.

Our heroes deliver increments of their overall mission along their way. Every major fight in LotR is their way to deliver an end-to-end increment of their battle against the evil forces. They analyze the enemy’s weaknesses and adapt their fighting strategies before each fight but react to small changes during the fight. In short: They use an iterative approach to deliver their “fights” and simultaneously get rid of impediments during their mission, mainly led by Aragorn, their ScrumMaster. The concept of iteration is also unfolded in other scenes throughout the book. For example, when they use the passage through the Mines of Moria because Saruman blocks the Redhorn pass through the mountains. Or when Sam takes the ring from Frodo in dire need of protecting it. Every team member is truly committed to continuous improvement throughout the whole book.

Step 7: “Put a ring on it” a.k.a. hold on to your vision.

If there is no need from a market perspective to overhaul your vision – don’t do it. The vision of LotR grants the team a bigger picture, which gives them strength in distress and enables them to stand fast against the forces of Sauron. Especially the last part of the journey of Frodo and Sam makes this apparent. Only with the destruction of the ring, they can accomplish their vision, and the people of Middle-earth are free to live their lives peacefully. The vision of the team helps them to deliver a great product – the liberation of the world from all evil.

Reaching your goal is a unique experience. Agile frameworks like Scrum provide you with effective tools to iteratively achieve your set goals. Of course, your vision does not have to be the liberation of the world from all evil, although it is a great one. As the comparison with LotR shows, reaching your vision is a journey of hardship and struggle but also great joy and friendship. Keep that in mind if you are working in your teams the next time and try to support one another like the fellowship of the Ring.

Selbstorganisation der Teams fördern: Ask the team!

Die Wahrscheinlichkeit ist sehr hoch, dass Sie während Ihrer Ausbildung zur agilen Expertin, zum agilen Experten oder beim Durchwälzen der Fachliteratur auf den Ausspruch “Ask the team!” gestoßen sind. Was genau steckt dahinter?

Die Grundannahme hinter diesem Prinzip ist, dass die Teammitglieder alle Fähigkeiten besitzen, um selbst zu einer Lösung zu kommen. Oder man formuliert es noch stärker: Als crossfunktionales Expertenteam können nur sie zur besten Lösung für ihre fachspezifische Fragestellung kommen. Wenn sich die Teammitglieder ihres Wissens und ihrer eigenen Handlungsfähigkeit bewusst sind, steht der Selbstorganisation nichts mehr im Weg. Aber wie schafft man es, das Team in diese Richtung weiterzuentwickeln?

Ein Beispiel, das viele aus der Praxis kennen

Stellen Sie sich vor, Sie haben mit Ihren Teams als agile Begleiterin oder agiler Begleiter ein Arbeitsmodell erstellt, das iteratives Arbeiten inkl. Reflexionsschleifen ermöglicht. Wohlwollend stellen Sie Terminserien ein, moderieren die Meetings wie bspw. die Retro oder Dailys und beinahe automatisch verbringen Sie sehr viel Zeit mit einer Hand am Flipchart und frontal vor dem Team. Sie erklären vieles, schaffen Transparenz über Themen und Zusammenhänge etc.

Nun frieren Sie diese Szene ein, zoomen aus der Situation heraus und betrachten diese mit einiger Entfernung. Was können Sie aus der Metaperspektive beobachten?

Vielleicht erkennen Sie Folgendes:

  1. Ein Team, das eine Kultur des „Command & Control“ gewohnt ist und Selbstverantwortung nur aus dem Duden kennt.
  2. Eine ehemalige Teamleitung / Teilprojektleitung, welche die alte Rolle noch nicht ganz loslassen konnte und wie gewohnt Aufgaben zuweist und Ansagen macht.
  3. Einen Agile Coach, der die Selbstorganisation des Teams stärken möchte und das dem Team sogar offenlegt, der aber gleichzeitig stark steuert und die Entwicklung der Autonomie im Team unbewusst zurückhält – durch das frontale Stehen und seinen hohen Redeanteil. Alles in der guten Absicht, das Meeting bestmöglich zu gestalten und das Team zu unterstützen.
  4. Ein Team, das alles abnickt und Anweisungen einfach befolgt – den Blick stets brav auf die moderierende Person oder die ehemalige Teamleitung gerichtet.

Wege zur Selbstorganisation

Wie können Sie die Selbstorganisation in Ihrer Rolle als agile Begleiterin oder agiler Begleiter fördern? Oder anders formuliert: Wie können Sie dem Team eine gewichtige Stimme zuteilwerden lassen? Folgende Maßnahmen haben sich in der Praxis als hilfreich erwiesen:

  1. Stellen Sie sich nicht direkt an das Flipchart! Meetings sind die Bühne der Teams, in denen Sie eine Nebenrolle spielen: Sie achten auf die Akustik, die Beleuchtung, das Bühnenbild und vieles mehr, damit die Hauptdarsteller ungehindert auf der Bühne performen können. Mit einer Ausnahme: Sie machen die Einführung und den Abschluss eines Meetings. Experimentieren Sie ruhig ein wenig, welche Position im Raum sich für Sie und das Team gut anfühlt.
  2. Achten Sie darauf, dass Ihr Redeanteil hauptsächlich aus Fragen besteht. Fragen Sie interessiert nach. Fragen Sie, wen das Team noch involvieren könnte, ob es noch etwas zu ergänzen gibt. Und fragen Sie, ob das Team noch weitere Lösungsansätze kennt. Was passiert durch das Fragen? Es regt die Synapsen der Teammitglieder an, die Systemlandschaft, in der sie sich bewegen, gedanklich nach Handlungsmöglichkeiten abzufahren. Was vermeiden Sie dadurch? Die Teammitglieder bekommen keine Lösungen auf dem Servierteller präsentiert und sind aktive Gestalter statt nur Befehlsempfänger.
  3. Setzen Sie sich anfangs ein Ziel, wie viele Fragen Sie an einem Tag stellen wollen, um das Fragenstellen zu trainieren. Es mag Ihnen eingangs etwas roboterartig vorkommen. Bald werden Sie das als Selbstverständlichkeit betrachten.
  4. Und ein zusätzlicher Tipp: Widerstehen Sie dem Drang, einfach drauflos zu sprechen, wenn Sie das Gefühl haben, das Team stockt. Nehmen Sie sich ruhig gelegentlich Zeit, das Team einfach zu beobachten. Diese Beobachterrolle ermöglicht Ihnen, bewusster wahrzunehmen, was im Meeting geschieht. Achten Sie darauf, wer eine führende Rolle einnimmt, wer sich zurückhält und welche Dynamiken entstehen. Erkennen Sie immer wiederkehrende Muster? Wandert der Blick Hilfe suchend zu Ihnen? Spielen Sie den Ball zurück ans Team, auch wenn es manchmal zwei bis drei Anläufe braucht. Die Teams kommen selbst auf Lösungen.

Was Sie dadurch bewirken

Wenn Sie die Teams fleißig mit Fragen gefüttert und die Teammitglieder erlebt haben, dass dadurch wertvolle Informationen offengelegt werden, beginnen diese selbst, mehr Fragen zu stellen. Sie werden sehen, dass sie sich zu Beginn an Ihren häufig gestellten Fragen orientieren. Parallel dazu beginnen die Teammitglieder automatisch, mehr Informationen zu liefern, weil sie

  1. lernen, dass sie wertvoll sind und
  2. erkennen, dass eine Frage ohnehin gestellt wird, wenn sie diese nicht schon von sich aus im Vorhinein beantworten.

Fazit

Besonders zu Beginn, wenn die Rolle als ScrumMaster oder Agile Coach aufgenommen wird, ist es eine große Herausforderung, die Teams nicht zu stark durch die Meetings zu steuern und zu viel Präsenz in altbekannten Mustern zu zeigen. Erinnern Sie sich an die Weisheit, die man aus vielen Managementseminaren kennt: „Wer fragt, der führt.“ Oder übertragen auf den agilen Kontext: Ask the team!

Warum die Rollenfindung Teamsache sein sollte

„Wir wollen agil werden“ – so oder so ähnlich lautet die Maßgabe in vielen Unternehmen. Bei der Einführung von Scrum braucht es dazu unterschiedliche Rollen wie den ScrumMaster und Product Owner. Den Führungskräften ist oft schon im Vorfeld klar, wer diese Rollen im späteren Verlauf ausführen soll. Dabei vergisst man aber häufig, auch das Team zu fragen, wen es in dieser Rolle sieht. Aufgrund hierarchischer Machtverhältnisse und Weisungsbefugnissen werden neue Rollen einfach zugewiesen, ohne auf die Anforderungen und Befähigung der Erwählten einzugehen. Auch wie die Bedingungen innerhalb des Teams aufgestellt sind, spielt tendenziell eine eher untergeordnete Rolle.

Aber wie kann man das besser machen? Meiner Meinung nach ist zunächst die Unterscheidung von Macht und Status essenziell für die Etablierung und Akzeptanz der neu geschaffenen Rollen. Denn Macht bekommt man manchmal geschenkt, Status muss man sich erarbeiten.

Status vs. Macht

Sozialer Status zeichnet sich durch Respekt und Wertschätzung aus, die einer Person von anderen entgegengebracht werden. Er entsteht somit durch die Beurteilung von Außenstehenden und bezieht sich auf den Wert, den sich eine Person in einem sozialen System erarbeitet hat. In weiterer Folge heißt das, dass man sich Status nicht selbst verleihen kann, sondern das soziale Umfeld diesen zuschreibt.

Genau darin unterscheidet sich der Status auch im Wesentlichen von der Macht. Sie kennzeichnet sich vor allem durch die Fähigkeit, eigene Interessen durchzusetzen, auch wenn das Umfeld anderer Meinung ist. Die Art und Weise, wie Macht schließlich ausgeübt wird, kann dabei völlig unterschiedlich sein – sei es durch den alleinigen Zugang zu Wissen oder durch eine höhere soziale Stellung.

Aus diesen unterschiedlichen Konzepten von Status und Macht lassen sich allgemein drei mögliche Szenarien ableiten:

  1. Macht ohne Status
    Fehlt der Status, so kann Macht alleine immer noch ausreichen, um seine eigenen Vorstellungen auch gegen den Willen oder die Interessen anderer durchzusetzen. Allerdings macht man sich dabei oft keine Freunde, da man zwar Autorität besitzt, die anderen aber nur kontrolliert.
  2. Status ohne Macht
    Auch ohne Macht kann man als Führungsperson fungieren, wenn der Status, also der Respekt und das Ansehen im sozialen Umfeld stimmen.
  3. Macht gepaart mit Status
    Wer sowohl über Macht als auch über Status verfügt, kann beide nutzen, um seinen Einfluss geltend zu machen. Entweder kann man sich auf seine Macht berufen und seine Ansichten durchsetzen oder seinen Status einbringen, um andere zu überzeugen.

Was bedeutet das beispielhaft für die ScrumMaster-Rolle?

Übertragen auf die Besetzung eines ScrumMasters können sich folgende Szenarien ergeben:

  1. Klassisch besetzt der Teamleiter die Rolle des ScrumMasters im neu etablierten Scrum-Team. Dadurch besitzt die Rolle zwar die notwendige Rückendeckung, um Entscheidungen im Sinne des Teams zu treffen (technische Voraussetzungen, Anschaffungen, Entwicklungsmaßnahmen für Teammitglieder etc.). Jedoch fehlt die notwendige Akzeptanz der Rolle im Team, wodurch die Entscheidungen nicht immer auch vom Team mitgetragen werden.
  2. Der ScrumMaster wird als Teil des Teams akzeptiert und ist in der Lage zu wirken, kann aber in der Beseitigung von Impediments durch organisationale Hürden ausgebremst werden.
  3. Der ScrumMaster wurde gemeinsam im Team gewählt, akzeptiert und genießt die Rückendeckung seines hierarchisch Vorgesetzten bei der Lösung von Impediments.

Um in dieser Rolle im agilen Umfeld tatsächlich wirksam werden zu können, braucht es sowohl Macht wie auch Status. Szenario 3 stellt für mich daher die optimale Ausprägung dar.

Das Team weiß, was es braucht

Zur Förderung dieser Entscheidung aus dem Team heraus hat sich folgende Herangehensweise als praktikabel erwiesen:

  1. Klare Darstellung der Rollenanforderung und Erwartung
  2. Selbstwahrnehmung der beteiligten Personen zur dargelegten Rolle
  3. Fremdwahrnehmung der einzelnen Gruppenmitglieder: Wen kann ich mir in der dargestellten Rolle vorstellen?
  4. Reflexion in der Gruppe zur Teamaufstellung
  5. Gemeinsames Commitment

Festzuhalten bleibt: An vielen Stellen bedarf es keiner klassischen Rollenbesetzung, da die Teammitglieder durchaus in der Lage sind, eine objektive Aussage darüber zu treffen, wer die beste Rollenpassung aufweist. Und wem ich das Vertrauen schenke, die Rolle auszufüllen. In der Praxis sieht das oft aber leider noch ganz anders aus. Beim Entscheidungsverhalten wie auch bei der Rollenfindung hält man noch stark am klassischen Verständnis fest und schreibt die Verantwortung für diese Bereiche einer hierarchisch vorgesetzten Person zu. Meiner Meinung nach sollte sich das Verständnis wandeln, um mit der sich verändernden Arbeitswelt Schritt halten zu können.

Pfläging¹ zeigte auf, dass man viel schneller auf die Marktbedürfnisse reagieren kann, wenn die Entscheidungsmacht aus dem Zentrum in die Peripherie, also an die marktnächste Instanz gegeben wird, wo die entsprechenden Informationen vorhanden sind. Äquivalent dazu sollte es sich mit der Rollenfindung verhalten – nur eben in die andere Richtung. Die Information bzw. das Wissen liegen hierbei im Kern, also im Team. Dementsprechend sinnvoller ist es, dass auch das Team die Rollenfindung innehat.

 


Literaturhinweis:

¹Nils Pfläging: Komplexithoden: Clevere Wege zur (Wieder)Belebung von Unternehmen und Arbeit in Komplexität. Redline Verlag 2015.

Mysterium Motivation – so motiviere ich mein Scrum-Team

Kürzlich stellte einer unserer Trainingsteilnehmer am Ende des Trainings folgende Frage: „Wie schaffe ich es als ScrumMaster, alle Leute in meinem Team für Scrum zu begeistern oder überhaupt zu motivieren, Teil dieses Teams zu sein?“ Mit dieser Frage ist er nicht alleine. In fast jedem Team begegnen wir der Problematik, dass nicht alle von Anfang an mitziehen und die agile Transformation unterstützen. Was tun?

Das Motivations-Tagebuch

Als ScrumMaster sollten Sie auch Widerstände als Chancen betrachten, weil darin Optimierungspotential sichtbar wird. Ich empfehle ScrumMastern, ein Motivations-Tagebuch zu führen, in dem konkrete, motivierende und kurzfristig umsetzbare Maßnahmen aus den Beobachtungen des Tages abgeleitet werden. Welche Einträge ins Tagebuch kommen und wie diese aussehen können, schauen wir uns in diesem Blog-Artikel gemeinsam an. Begleiten Sie unseren fiktiven ScrumMaster durch seinen Sprint. Er macht sich zu jeder Situation Notizen und hält konkrete To-dos zur Motivation und Weiterentwicklung seines Teams fest.

Montag, 09:00 Uhr – Verantwortung übertragen

Der ScrumMaster steht mit seinem neuen Team vor dem Taskboard. Er ist seit zwei Wochen im neuen Projekt unterwegs, es gibt viel zu tun. Jeder nimmt sich reihum Tasks und schreibt sein Kürzel auf die einzelnen Aufgaben. Es sind immer die gleichen Personen, die sich die gleichen Tasks ziehen. Und es gibt ein Teammitglied, das scheinbar an derselben Aufgabe arbeitet wie in der Woche zuvor. Das Worst-Case-Szenario: Am Ende werden die User Storys bis zum Review am Freitag nicht fertig. Es gibt kein Feedback vom User und der Product Owner sieht die abgeschlossenen User Storys im Review zum ersten Mal. Eine Konsequenz, wenn nicht geliefert wird? Fehlanzeige.

Hier braucht es dringend einen aktiven ScrumMaster. Das Team muss lernen, Verantwortung für die Qualität der Lieferungen zu übernehmen, und braucht echtes Feedback von einem Endanwender sowie ausreichend Support vom Product Owner.

Der ScrumMaster erstellt eine Liste mit konkreten To-dos für den Tag und versucht, diese direkt umzusetzen: 

Dienstag, 10:00 Uhr – Wertschätzung fördern

Eine sehr knifflige User Story ist endlich fertig geworden. Zwei Teammitglieder bekommen kräftigen Applaus vom gesamten Team. Der ScrumMaster klatscht am Anfang noch am lautesten. Zur Abnahme der Story bringt der Product Owner zwei seiner selbstgebackenen Muffins vorbei. Ein Teammitglied steht halb abgewandt zum Taskboard und betrachtet diese Zeremonie skeptisch: „Mit so einer billigen Nummer kriegt ihr mich nicht“, denkt er sich. Es waren seine Lieblingsmuffins.

Die Scrum-Master-Notiz am Dienstag: 

Mittwoch, 14:00 Uhr – Fokus setzen

Der ScrumMaster hat drei neue Teammitglieder. Einer der drei Kollegen scheint sich mit Scrum auszukennen. Er hält sich sehr bedeckt. Der ScrumMaster ist nun nicht mehr der einzige Verfechter der Methode und sieht die Chance, etwas zu verändern. Er bittet den Kollegen, mit ihm gemeinsam einen Workshop zum Thema „User Storys schreiben“ durchzuführen. Im gemeinsamen Austausch berichtet der Mitarbeiter, dass ihm einige Dinge aufgefallen sind, die er gerne ändern würde – z. B. könnte man das Taskboard anpassen. Es sprudelt nur so aus ihm heraus. Er hat bereits in zwei erfolgreichen Teams gearbeitet und möchte sein Wissen weitergeben.

Der ScrumMaster notiert in seiner Liste:

Donnerstag, 12:30 Uhr – Wissen vermitteln

Der ScrumMaster hat ein gemeinsames Mittagessen organisiert. Einen Teamraum gibt es nicht, daher sieht sich das junge Team bis auf die Meetings nicht so häufig. Im gemeinsamen Austausch kommen unterschiedlichste Themen auf, welche die Teammitglieder noch nicht verstanden haben. Scrum sei doch sehr kompliziert. Ein Kollege erzählt, dass er gerade gemeinsam mit dem ScrumMaster einen User-Story-Workshop plant. Die anderen Teammitglieder machen Vorschläge, welche Themen sich noch eignen würden.

Weitere Vermerke kommen auf die Liste:

Freitag, 15:00 Uhr – mit Begeisterung anstecken

Das Review beginnt. Sechs von sieben Storys sind fertig geworden. Nur sechs Storys werden gezeigt. Hier gibt es Verbesserungspotential, aber für die nächsten 90 Minuten widmet sich der ScrumMaster vor allem dem Erfolg des Teams. Ein neues Gesicht ist in der Runde. Eine Mitarbeiterin aus dem Vertrieb ist vorbeigekommen, um sich anzusehen, was das Team entwickelt hat. Sie hat einen Tipp bekommen und wollte sich das nicht entgehen lassen. Sie kann die Endanwender zwar nicht ersetzen, ist aber ziemlich nahe dran. Der PO hält sich zurück und das gesamte Team präsentiert. Die Mitarbeiterin ist begeistert. Sie hat zwar ein paar Anmerkungen, ist aber sonst sehr zufrieden. Das nächste Mal bringt sie einen weiteren Kollegen mit. Vielleicht kann sie sogar mal einen richtigen User organisieren. Den Applaus erhalten am Ende alle. Auch der eine Kollege, der etwas abseits von der Gruppe steht. Überzeugt ist er (noch) nicht, aber ein Lächeln konnten wir ihm abgewinnen.

Der letzte Eintrag diese Woche: 

Sie kennen alle Tipps und Tricks zum Thema Motivation von Scrum-Teams und lassen nichts unversucht, um Ihre Teams zu motivieren? Dann sind wir gespannt auf Ihre Erfolgsgeschichte.

 

Feedback oder die Kunst der Anerkennung

Wir Menschen streben nach Anerkennung. Unsere Motivation steigt, wenn unsere Arbeit „erkannt“ und wertgeschätzt wird. Diese Wertschätzung können wir durch unser Umfeld, also Kollegen, Freunde oder Familie erhalten, aber auch durch uns selbst. Und doch passiert beides immer noch viel zu selten.

Konstruktives und wertschätzendes Feedback kann das Bedürfnis nach Anerkennung der eigenen Arbeit bedienen. Es kann dabei helfen, die eigenen Ressourcen besser einzusetzen, produktiver zu werden und Erfolgspotentiale weiterzuentwickeln. Nicht zuletzt bietet es die Chance, aus Fehlern zu lernen und blinde Flecken aufzudecken. Halten wir uns bei der Arbeit mit Feedback zurück, bringen wir uns selbst und vielleicht auch unser Team oder ein ganzes Unternehmen um den Erfolg.

Die Devise heißt also: Schwächen abbauen und Stärken aufbauen. Doch leider ist Feedback oft eine Mogelpackung, wenn es falsch formuliert ist und dadurch verletzend wird. Wissenschaftliche Erkenntnisse beweisen, dass es entscheidend ist, wie man etwas sagt.

Wie formuliert und gibt man Feedback?

Die Kunst ist also, Feedback wertschätzend zu formulieren. Es sollte beschreibend sein und nicht bewertend. Es sollte sich auf eine erlebte Situation und ein konkretes Beispiel beziehen und am besten sofort im Anschluss gegeben werden. So, dass man über veränderbares Verhalten spricht – konkret und nicht allgemein gehalten, mit klar formulierten Aussagen. Besonders positive Wahrnehmungen und Gefühle können und sollen mitgeteilt werden. Wichtig ist dabei, stets aus eigener Perspektive für sich zu sprechen. Gut wäre es, eine Gesprächsatmosphäre so zu kreieren, die nicht unter Zeitdruck und in der Öffentlichkeit geschieht, sodass der Feedbacknehmer auch die Zeit hat, das Feedback in Ruhe zu verarbeiten.

Um das Feedback zu entschärfen und nicht als verletzende Waffe einzusetzen, sollten Sie sich im Voraus über die folgenden Punkte klar werden:

Feedback geben in drei Schritten

Wenn Sie diese grundlegenden Fragen geklärt haben, hilft es, das Feedback in drei Schritte zu gliedern:

  1. Klären Sie zunächst den Sachverhalt und stellen Sie sich die Frage: „Was ist geschehen?“
  2. Danach folgt eine Offenbarung bzw. Beschreibung der Gefühle: „Wie geht es mir damit?“
  3. Die konstruktive Komponente ist schließlich entscheidend für die Umsetzung: „Wie kann für die Zukunft eine Verbesserung herbeigeführt werden?“ Wichtig dabei ist, dass Sie realistische Maßnahmen vorschlagen, die auch umgesetzt werden können.

Fakt ist, dass Selbst- und Fremdeinschätzung meistens voneinander abweichen. Des Weiteren ist jedes abgegebene Feedback zu einer Person anders, weil jedes Individuum andere Dinge an der beobachteten Person wahrnimmt. Die Gefahr ist daher groß, missverstanden oder überhaupt nicht verstanden zu werden. Deshalb seien Sie offen, hören Sie beim Feedback nehmen aktiv zu und fragen Sie bei Unklarheiten beim Gesprächspartner nach. Nur so können beide Seiten sichergehen, dass Ihre Botschaften auch ankommen.

Auf den Punkt gebracht

Feedback erlaubt uns, das eigene Verhalten aus der Perspektive des Gegenübers zu betrachten und es damit auf den Prüfstand zu stellen. Somit haben wir die Chance uns weiterzuentwickeln und in dem was wir tun noch besser zu werden. Für den Feedbackgeber ist die Kunst, die konstruktive Kritik wertschätzend zu formulieren, damit der Empfänger das Feedback auch annehmen kann und nicht in eine abwehrende Haltung gezwungen wird. Fragen Sie den Empfänger ruhig vorher, ob Sie Feedback geben dürfen. Als Empfänger lohnt es sich bei Unklarheiten oder nicht nachvollziehbaren Beispielen nachzufragen, was gemeint ist und in den Dialog zu treten. Denn nur so profitieren Sie und damit Ihr Unternehmen davon.

Von Löwen und dem Mut, sich auf Scrum einzulassen

Verschränkte Arme, kritischer Blick und einen spöttischen Zug um den Mund – so steht er mal wieder in unserem Sprint Planning 2. Manchmal lauert er auch wie ein Löwe, lauert auf die nächste Gelegenheit zum Angriff. Er ist schon sehr lange dabei. Er weiß, wie der Laden läuft und er ist Experte auf seinem Gebiet. Stolz wie ein Löwe nutzt er nur zu gerne jede Gelegenheit, um zu präsentieren, wie bisher alles gemacht wurde und welche Erfolge er dabei verzeichnen konnte. Wozu er jetzt mich – diesen sogenannten ScrumMaster – brauchen sollte, der ihm sagt, wie er noch effizienter arbeiten kann, versteht er nicht. Warum er ständig an diesen Meetings teilnehmen muss und transparent machen soll, woran er gerade arbeitet, versteht er noch weniger. Und was ist eigentlich dieses Scrum? Wer hat sich das schon wieder ausgedacht? Er beobachtet argwöhnisch jeden meiner Schritte und gibt mir zu verstehen, dass ich ein Eindringling in seinem Herrschaftsgebiet bin.
Jeder kennt sie, diese Art von Kollegen. Veränderung fällt ihnen schwer. Sie können sich nicht so leicht wie die anderen darauf einlassen. Eine neue Methode wie Scrum in den Arbeitsalltag zu integrieren, ist eine solche Veränderung. Manche Menschen können damit umgehen, manche nicht. Was man dabei immer im Hinterkopf behalten sollte: Jede Veränderung bringt auch einen größeren oder kleineren Verlust mit sich. Und jeder Mensch begegnet diesem Verlust unterschiedlich.

Verlust verstehen mit den fünf Phasen der Trauer

Mir hat die Beschreibung der fünf Phasen der Trauer von Elisabeth Kübler-Ross – Verleugnung, Verärgerung, Verhandlung, Depression und Akzeptanz – dabei geholfen, die möglichen Reaktionen auf Verlust und damit die unterschiedlichen Reaktionen von Menschen auf Veränderungen besser zu verstehen. [vgl. Kübler-Ross, Kessler 2005, S. 7-24] Das Leugnen der Veränderung hilft uns durch den ersten Schockzustand, indem wir uns nur so weit auf die Realität einlassen, wie wir es im Moment aushalten können. Der Ärger, den wir fühlen, sobald wir das gesamte Ausmaß der Veränderung realisieren, kann auf ganz unterschiedliche Ziele gerichtet sein: Kollegen, Management oder auch die Familie. Manchmal versuchen wir, über die Folgen der Veränderung zu verhandeln, um einen Ausweg aus der Situation zu finden. Eine typische Frage, die für mich die Unsicherheit in der Depressionsphase deutlich macht, lautet: „Warum soll ich mich denn überhaupt noch anstrengen, ergibt das noch Sinn?“ Und irgendwann gelangen wir an den Punkt, an dem wir die Veränderung Stück für Stück akzeptieren können und lernen, mit ihr zu leben.
Anzunehmen, dass jede einzelne Phase linear durchlaufen wird und Wochen ja vielleicht sogar Monate fortwährt, ist falsch. Wir reagieren in diesen Phasen auf Gefühle, die Stunden oder auch nur Minuten andauern und sich an keine vorgeschriebene, rationale Abfolge halten!

Wie ScrumMaster durch den Verlust führen können

Doch zurück zu unserem Löwen. Wie helfe ich ihm als guter ScrumMaster jetzt durch diese Situation? Mein erster Impuls bei einer solchen ablehnenden Haltung ist immer, den Kollegen darauf anzusprechen. Ich möchte verstehen, was das Problem ist, es aus der Welt schaffen und ihn dazu befähigen, sich auf diese Reise in die Agilität einzulassen. Doch genau das ist es, worauf der Löwe wartet: Wertschätzung im Sinne von Aufmerksamkeit zu erhalten und dadurch in seiner ablehnenden Haltung bestärkt zu werden.
Wieso also sollte ich ihm genau das geben, was er möchte und ihn wertschätzen, wo er sich doch dem ganzen Team gegenüber respektlos benimmt? Deshalb konzentriere ich mich auf die Teammitglieder, deren motiviertes und offenes Verhalten zum Erfolg des Projekts beiträgt. Getreu dem Motto: Ich konzentriere mich auf die Einstellung, von der ich mehr möchte. Ich ignoriere den Löwen auf der anderen Seite des Raums und schenke dem restlichen Team meine Aufmerksamkeit. Ich bestärke die Haltung des Löwen nicht und signalisiere ihm, dass er die Phasen der Trauer weiter durchlaufen muss. Dadurch versuche ich, ihn dazu zu bringen, über sein Verhalten zu reflektieren und er lernt, dass nur jene Teammitglieder eine Belohnung in Form von Aufmerksamkeit bekommen, die mir und der Methode offen begegnen und respektvoll miteinander umgehen. Jedoch achte ich wachsam darauf, wann er sich der Methode und dem Team gegenüber öffnet. Dann bin ich da, um ihm dabei zu helfen, wieder zum Team aufzuschließen – inhaltlich, aber auch emotional. Ich beantworte seine Frage und nehme ihn mit auf unsere Reise. Und dabei ist mir stets bewusst, dass man einen wilden Löwen nie ganz zähmen kann.

[Kübler-Ross, Kessler 2005]
Kübler-Ross, Elisabeth; Kessler, David: On Grief and Grieving: Finding the Meaning of Grief Through the Five Stages of Loss. Simon and Schuster 2005.
Foto: CC0 Creative Commons – pixabay, IanZA

Regeln und Prozesse im agilen Umfeld? Nein! Doch! Oh!

In vielen selbstorganisierten Umfeldern gibt es zwei böse Wörter: das R-Wort und das P-Wort. Benutzt man diese Worte, kann man sich auf einen wilden Mob und viel Widerstand einstellen. Wild ist der Mob vielleicht nicht, aber er ist bereit, sich mit allen Mitteln gegen die Regeln und Prozesse zu wehren. Denn die vielen Freigeister fühlen sich durch das R-Wort auf einmal eingeengt und ihrer Freiheit beraubt. Meiner Meinung nach brauchen wir aber Regeln und Prozesse. Ein selbstorganisiertes System endet schnell im Chaos, wenn es keine Regeln und Prozesse gibt. Die Effizienz sinkt und die Produktivität geht in den Keller. Aus unternehmerischer Sicht ein Desaster.
Vorweg sei also gesagt: Auch in der agilen Welt brauchen wir Regeln und Prozesse. Es kommt aber darauf an, um welche Regeln und Prozesse es sich handelt und wie viele es davon gibt. Hier greift ein bekannter Satz: So wenig wie möglich, aber so viel wie nötig! Der Inhalt ist wichtiger als die Menge. Jede Organisation sollte daher ihre eigenen Regeln und Prozesse genau analysieren und auf folgende vier Aspekte untersuchen:

  1. Nutzen: Eine Regel, die keinen Nutzen stiftet, ist eine schlechte Regel. Beschützt die Regel etwas, was beschützt werden muss? Ja – super, diese Regel behalten wir! Nein – diese Regel kann weg. So einfach können Sie Ihre Regeln aussortieren.
  2. Nachvollziehbar: Eine Regel muss nachvollziehbar sein. Was bringt mir eine Regel, die von den Mitarbeitern nicht verstanden wird? Sie bringt Widerstand. Besonders in selbstorganisierten Organisationen kann dieser groß werden. Die Kollegen werden die Regel hinterfragen und sich zur Wehr setzen, also gestalten Sie die Regel transparent und kommunizieren sie den Nutzen (s.o.), damit der Angestellte sie verstehen und vor allem akzeptieren kann.
  3. Effizienz: Eine Regel oder ein Prozess muss effizienzsteigernd sein. Was bringt mir ein Nutzengewinn durch einen Prozess, wenn ich diesen wesentlich schlanker gestalten könnte und somit effizienter arbeiten könnte? Genau, er bringt Opportunitätskosten mit sich und einen Effizienzverlust! Übrigens: Ist ein Prozess nicht effizient, wird er in der Regel nicht akzeptiert, weil er nur bedingt nachvollziehbar ist!
  4. Flexibel: Eine Regel oder ein Prozess muss agil sein. Ist diese(-r) nicht anpassbar, werden alle drei Punkte zuvor nicht erfüllt. In einem dynamischen Umfeld ist es also unabdingbar, sich regelmäßig mit seinen Regeln und Prozessen auseinanderzusetzen.

Das Wichtigste, was Sie über Regeln wissen müssen, ist die folgende Regel: Reden Sie im Unternehmen regelmäßig über Ihre Regeln. Sorgen sie für Verständnis, stellen Sie den Effizienzgewinn dar und passen Sie dann bei Bedarf ihre Regeln an. Kommunizieren Sie ständig und immer weiter Ihre Regeln. Es muss deutlich werden, dass diese Regeln nicht da sind, um den Freigeistern Ihre Freiheit wegzunehmen, sondern um sie zu schützen oder um ihre Produktivität zu erhöhen. Nur durch Kommunikation kann ein harmonisches und effizientes Miteinander in einer Selbstorganisation mit Regeln und Prozessen garantiert werden.
Ein relevantes und aktuelles Beispiel gefällig? Bitte sehr: Auch wir bei borisgloger consulting haben Regeln und Prozesse, an die sich meine Kollegen und ich halten müssen. Gerade aber neue Kollegen verstehen die Regeln nicht immer und wollen sie in Frage stellen. Was passierte also speziell bei uns? Einige Kollegen versuchten eine Regel zu umgehen, weil sie sich um Teile ihrer Freiheit beraubt fühlten. Sie sahen in dieser Regel vor allem eine Hürde, bedachten aber gleichzeitig nicht, dass die Regel einen tieferen Grund hatte. Dieses Nichtwissen kann man ihnen gewiss nicht vorwerfen, denn der Grund der Regel wurde ihnen nie wirklich nahegebracht. Was dann aber passierte, ist unserer lebendigen Diskussionskultur zu verdanken. Regelaverse und regelfreudige Kollegen diskutierten miteinander. Das Ergebnis: eine Anpassung der Regel und vor allem eine klare Kommunikation der Regel. Gut, dass wir darüber gesprochen haben!

Foto: CC0 Creative Commons – pixabay, taniadimas

Viele Produkte, ein Team – Stiefkind der Skalierung

Wenn sich ein Unternehmen mit dem Thema Scrum auseinandersetzt, kommt früher oder später die Frage auf, wie es denn mit der Skalierung aussieht. Häufig wird jedoch recht undifferenziert von Skalierung gesprochen und nur wenige wissen genau, was sie eigentlich meinen. Es gibt aber eine einfache Übersicht, die Christoph auch in einem unserer letzten Meetups zum Thema „SKALIERUNG! SKALIERUNG! SKALIERUNG!“ gezeigt hat. Diese macht klar, in welchem Kontext man sich bewegt und was sinnvollerweise zu tun ist.

Skalierung

(c) Christoph Schmiedinger, Matthias Wolf-Dietrich

Für die Übersicht ziehe ich einen Graphen mit zwei Achsen auf. Die vertikale Achse zeigt die Anzahl der Produkte in einem Unternehmen oder einer Abteilung, auf die horizontale Achse trage ich Anzahl der Teams auf, die zur Verfügung stehen bzw. welche die Arbeit erledigen. Für den 1. Quadranten gilt es, ein Hochleistungsteam zu formen, dass liefert und regelmäßig reflektiert – zum Beispiel mit Scrum. In den Quadranten 2 und 4 müssen sich viele Teams um ein oder mehrere Produkte kümmern. Diese Situationen haben die meisten Menschen im Kopf, wenn sie über Skalierung sprechen. Ich konzentriere mich hier nun auf den linken oberen Quadraten 3: viele Produkte – ein Team. Das ist eine Situation, die bei der Skalierung gerne vergessen wird und dementsprechend bekommen solche Teams wenig Aufmerksamkeit von Führungskräften und/oder Coaches.

Das Problem des fehlenden Fokus

Eine typische Ausprägung davon sind Entwicklungsteams, die neue Varianten bestehender Produkte entwickeln. Auch in etablierten Produktbereichen mit relativ langlebigen Produkten, die sich um Seriensupport kümmern oder Verantwortung für das Lifecycle Management haben, ist diese Situation ganz alltäglich. Meist sind auch die berüchtigten „Cash Cows“ betroffen. Aber mit welchen Schwierigkeiten muss ein Team in dieser Konstellation kämpfen? Das größte Problem ist der fehlende Fokus und die damit verbundenen langen Bearbeitungszeiten. Ein großer Effizienzkiller ist, dass die Aufmerksamkeit häufig von einem Produkt zum anderen wechselt und die Wahrscheinlichkeit höher ist, unterbrochen oder gestört zu werden. Das zwingt die Teammitglieder dazu, sich immer und immer wieder neu in die unterschiedlichen Themen reinzudenken. Kaum hat es sich in eine Aufgabe eingefunden, muss sich das Teammitglied aus verschiedenen Gründen auf das nächste Thema stürzen.
Sicher kennen Sie auch die schier erdrückende Last einer langen und stetig wachsenden To-Do-Liste. Wie gelähmt sitzt man vor der Menge an Aufgaben und weiß gar nicht, wo man anfangen soll. Das Resultat: Das Team ist überlastet, die Wahrscheinlichkeit von Fehlern steigt und die Bearbeitungszeiten steigen noch weiter an. Ein häufiges Symptom ist das ständige Arbeiten im Feuerwehrmodus. Kaum hat das Team ein Feuer gelöscht, flammt gleich das nächste Glutnest auf. Was soll man hier tun? Die folgenden fünf Schritte verhelfen zu mehr Klarheit.

  1. Priorisierung nach der Cost of Delay. Der mögliche Durchsatz des Teams, also die Menge der möglichen Lieferungen, ist die einschränkende Größe. Da es üblicherweise deutlich mehr Opportunitäten als vorhandene freie Zeit gibt, gilt es hier mehr noch als sonst, nur an den wichtigsten, sprich wirtschaftlich wertvollsten Themen zu arbeiten. Die Bewertung kann nach den Verzögerungskosten oder „Cost of Delay“ erfolgen: Wie hoch sind die Kosten bzw. der entgangene Gewinn, wenn ein Thema später – oder gar nicht – durchgeführt wird. Je höher diese Verzögerungskosten sind, desto eher sollte das Team an diesem Produkt arbeiten. Eine weitere Bewertungsmöglichkeit ist der Return on Investment, bei dem aber häufig die zeitliche Komponente ignoriert wird.
  2. Nein sagen. Da der Durchsatz des Teams durch den Engpass im Team bestimmt wird, muss dieser identifiziert und möglichst gut ausgenutzt werden, gleichzeitig aber auch möglichst gut beschützt werden. Er soll also nicht von anderen Teammitgliedern, anderen Teams oder Abteilungen mit neuen Aufgaben verstopft werden (https://blog.borisgloger.com/2017/01/19/the-malicious-behavior-of-non-constraints/). Um sicherzustellen, dass das Team möglichst zielgerichtet am wertvollsten arbeiten kann, müssen Kontextwechsel so gut es geht vermieden werden. Für den Product Owner heißt das: Nein sagen. Konsequent und immer wieder. Ideen für neue tolle Produkte, die unbedingt JETZT umgesetzt werden müssen, gibt es wie Sand am Meer. Die Herausforderung ist, keine Produkte oder Aufgaben mit geringerem Wert zuzulassen.
  3. Fehler sofort beheben. Es ist extrem wichtig, keine halbfertigen Produkte oder Aufgaben zuzulassen. Der fast schon fanatische Fokus auf Qualität stellt sicher, dass einen die Fehler später nicht einholen. Das erschwert das Jonglieren mit vielen Themen oder macht es sogar unmöglich. Das Schlimmste was passieren kann: Ein Thema, das eigentlich schon erledigt war, kommt wieder und muss gelöst werden. Schnell ertrinkt man in Nacharbeit und Fehlerbehebungen. Wenn man ohnehin schon Dutzende Themen in der Luft halten muss, ist das nicht angenehm und bricht einem Team schnell das Genick.
  4. Definition of Done. In diesem Umfeld bietet es sich an, mit sehr kurzen Sprints oder flussbasierten Systemen wie Kanban zu arbeiten. Um die Qualität möglichst hoch zu halten, braucht es eine gemeinsame Definition of Done (DoD), die auch durch das gesamte Team eingehalten und eingefordert wird. Das beinhaltet auch den ScrumMaster und den Product Owner. Regelmäßige Refinements und grundsätzlich moderne Arbeitspraktiken wie Mob Working unterstützen hier noch weiter.
  5. Portfoliomanagement. Um sicherzustellen, dass die zahlreichen Themen nicht das Team überschwemmen, ist eine Form von Portfoliomanagement sinnvoll. Der einfachste Weg ist es, das Portfolio zu visualisieren und damit zum regelmäßigen Gegenstand der Gespräche von Product Owner, Entwicklungsteam und der anderen Stakeholder zu machen. Wichtig ist weiter, dass regelmäßig und zeitnah Entscheidungen getroffen werden.

In den nächsten Artikeln dieser kurzen Serie werde ich die restlichen Quadranten und das empfohlene Vorgehen beschreiben.

Foto: CC0 Creative Commons – pixabay, pexels

Magic System Mapping oder "How to make toast"

Ein und dasselbe Thema – viele Sichtweisen und Wissensstände. So sieht es oft in einem Team aus, bevor es an die Entwicklung eines Produkts geht oder ein bestimmtes Problem gelöst werden soll. Mit „Magic System Mapping“ lassen sich individuelle Sichtweisen und Standpunkte, die es innerhalb einer Gruppe zu einem Thema oder Problem gibt, zu einem Gesamtbild zusammenführen.
Magic System Mapping beruht auf ähnlichen Prinzipien wie Magic Estimation: non-verbale Kommunikation wird visualisiert. Ich habe diese Methode schon für unterschiedliche Zwecke verwendet:

Wie funktioniert Magic System Mapping?

Um die Methode zu erklären, beginnt man mit einer einfachen Design-Übung, die je nach Gruppengröße 10 bis 15 Minuten dauert. Ausgedacht hat sich das ganze Tom Wujec, Businesss-Visualisierungs-Pionier und Mitgründer der Singularity University, der die Hintergründe fabelhaft in einem TED-Talk vorstellt.

Was man dafür braucht
Anmoderation der Aufgabe

Die Teilnehmer werden begrüßt, anschließend kündigt ihr an, dass ihr mit ihnen jetzt eine viertelstündige Design-Aufgabe mit anschließender Reflexion durchführt. Dazu bittet ihr die Anwesenden, in den nächsten fünf Minuten auf Post-its aufzuzeichnen, wie sie Toast machen. Dazu gibt es drei Regeln:

  1. Jeder macht die Aufgabe im ersten Schritt für sich.
  2. Nur ein „Toastmachschritt“ auf je einem Post-it.
  3. Das Ganze ist kein Kunstwettbewerb.

Optional könnt ihr noch erwähnen, dass zehn Post-its pro Person ein guter Anhaltspunkt für die Granularität der einzelnen Schritte sind. Falls noch nicht geschehen, könnt ihr jetzt die Post-its austeilen.

Review der Toast-Modelle

Nach Ablauf der drei Minuten bittet ihr einen Kollegen damit anzufangen, seine Toastmachschritte auf der freien Wandfläche von links nach rechts aufzuhängen. Dann geht es weiter mit der nächsten Person, er oder sie hängt sein Toastmodell darüber oder darunter. Falls er oder sie ähnliche Schritte hat, können sie unter bzw. übereinander angeordnet werden. Das Ganze wiederholt ihr, bis jeder sein Toastmodell geteilt hat.
Nachdem alle ihre Modelle aufgehängt haben, könnt ihr die Teilnehmenden fragen, was ihnen an den unterschiedlichen Modellen auffällt. Zum Beispiel: Wie komplex oder simpel sind die jeweiligen Modelle, werden dabei Personen oder keine Personen gezeigt? Diese Phase könnt ihr kurz halten. Zwei bis drei Wortmeldungen aus der Gruppe genügen.

Magic System Mapping

6 verschiedene Toast-Modelle im Vergleich

Zusammenführen der Toast-Modelle

Im letzten Schritt geht es darum, eine Synthese zwischen allen Toastmodellen herzustellen. Hier ist als Anforderung: Im finalen Bild darf es keine Duplikate mehr geben und es muss eine Reihenfolge erkennbar sein – und das Ganze soll ohne verbale Kommunikation gelöst werden. Im normalen Arbeitskontext kommt Letzteres auch häufig vor: Beispielsweise bei der Priorisierung von Anforderungen oder dem Treffen von Entscheidungen, ohne dass das Team mit den Stakeholdern sprechen kann.
In diesem Prozess werden sehr schnell unterschiedliche Sichtweisen und auch Konflikte in der Gruppe deutlich. Ziel ist es, eine Einigung zu finden und das im Gesamtmodell abzubilden. Schweigen ist hierbei Gold Wert. Interessanterweise funktioniert das ohne verbale Kommunikation deutlich schneller als mit.
Als Zeitvorgabe bieten sich für diesen Schritt fünf Minuten an.

Magic System Mapping

Das zusammengeführte Toastmodell ohne Duplikate in einer Reihenfolge

 

Reflexion

Nachdem die Gruppe ein Gesamtbild erarbeitet hat, gibt es erst einmal eine Runde Applaus. Den Reflexionsprozess kann man mit den folgenden zwei Fragen an die Gruppe starten:

Häufig berichten die Teilnehmenden, dass ihnen die Übung gezeigt hat, wie eingeschränkt ihre eigene Sichtweise auf ein Problem ist und wie unterschiedlich die Denkweisen von verschiedenen Personen sein können. Dieser Punkt wird häufig mit unterschiedlichen Expertisen und Spezialisierung in Verbindung gebracht. Einige Personen sind Spezialisten für einzelne Teilbereiche des Prozesses, die sie besonders stark ausdetaillieren – beispielsweise wie ein Toaster funktioniert – und andere beginnen den Toastprozess beim Weizenkorn, das gesät und bewässert wird. Nur durch die Synthese entsteht ein gesamtes System.
Als weiterer Punkt kommt in der Reflexion oft auf, dass unterschiedliche Perspektiven im System sichtbar gemacht und berücksichtigt werden können. Etwa die Tatsache, dass manche Menschen ihren Toast mit Butter essen und andere das niemals tun würden. Im Toastmodell werden die unterschiedlichen Belegungspräferenzen häufig durch übereinander hängende Post-its dargestellt.
Eine weitere Erkenntnis der Übung ist: Abgebildete Systeme bestehen immer aus Knoten und Verbindungen, die eine Logik herstellen. Die Übersetzung in BPMN-Sprache wäre: flow-basierte Objekte wie Ereignisse oder Aktivitäten und verbindend strukturierende Elemente wie Kanten/Assoziationen oder Gateways.

Anwendung im realen Kontext

Nach der Trockenübung mit dem Toastbeispiel könnt ihr euch eurem tatsächlichen Thema oder Problem zuwenden. Der Ablauf ist am Anfang analog zum Toastbeispiel:

  1. Startet mit eurer Fragestellung – falls sie noch zu grob ist, nehmt euch etwas Zeit, um sie in der Gruppe genauer zu spezifizieren
  2. Sammelt in der Gesamtgruppe die Knotenpunkte
  3. Entwickelt ein Gesamtbild/System in der Gruppe und stellt die Verbindungen her
  4. Verfeinert das System in der Gruppe
  5. Verfeinert das System weiter …
  6. … und weiter

Je mehr Runden ihr in die Verfeinerung des Systems steckt, umso klarer wird das System für die Beteiligten. Im Zuge dessen werdet ihr auf immer feingranularere Probleme oder Abhängigkeiten stoßen, für die es Lösungen zu finden gilt.
Mein Tipp für diese Phase: Teilt euch in Kleingruppen auf und arbeitet einzelne Teile eurer Systems genauer aus. Nehmt euch dafür je nach Größe und Komplexität des Themas 30 bis 60 Minuten Zeit. Danach stellt jede Kleingruppe ihre Ergebnisse vor, sie werden diskutiert und anschließend in das System eingebaut.
Wie viel Zeit ihr für diesen Prozess benötigt, hängt von der Komplexität eurer Fragestellung ab. Ich beginne meistens mit einer dreistündigen Session, in der am Anfang Zeit für die „How to make Toast“ Übung ist. Am Ende wird besprochen, wie an den Ergebnissen weitergearbeitet wird. Ich habe aber auch schon mehrtätige Off-Sites in diesem Stil organisiert.

Eine abschließende Bemerkung

Das Feedback der Teilnehmenden war bisher immer positiv. Die Methode hat nur einen Haken: Das erarbeite System ist eine Momentaufnahme – abhängig von den Beteiligten, und es hat nur Gültigkeit, solange man in der Gruppe zusammenbleibt. Durch den iterativen Ausarbeitungsprozess hat eine Verständigung auf Begrifflichkeiten und Regeln für das System stattgefunden. Ein Außenstehender kann das Abgebildete nur mit Hilfe von guter Dokumentation verstehen.
Das ist aber auch für die Teilnehmenden wichtig: Ab dem Moment, an dem sie den Raum verlassen, machen sie neue Erfahrungen, führen Diskussionen mit Kollegen oder haben Ideen, die Auswirkungen auf das System haben. Was kann man dagegen machen? Man muss den Prozess regelmäßig wiederholen, um ein längerfristiges Alignment herzustellen und das System an die aktuellen Gegebenheiten anzupassen. Am Ende ist es die Auseinandersetzung mit dem richtigen Personenkreis zu einem Thema, was uns am Ende erfolgreich macht. Die Visualisierung ist dabei nur ein Hilfsmittel. In diesem Sinne wünsche ich euch viel Erfolg und Spaß beim kollaborativen Visualisieren.

Ressourcen

Templates zu verschiedenen Themen:
DrawToast
Mural – ein gutes Tool für kollaboratives Visualisieren
Originalartikel erschienen im ProjektMagazin – verwendet mit freundlicher Genehmigung.
Foto: CC0 Creative Commons – pixabay, pexels

ScrumMaster in Aktion: Das Feiern von Erfolgen

Es ist 9.00 Uhr. Wir haben uns vor dem Taskboard versammelt. Es ist alles noch ganz frisch, wir lernen noch, ein Hauch Unsicherheit liegt in der Luft. Der erste Kollege beginnt und hängt seine Tasks um. Die Kollegin folgt. Der erste Task wird auf „Done“ gesetzt. Die erste Aufgabe ist geschafft. Ich lade zum Feiern ein, strahle die Kollegin an. Ich empfinde die erste erledigte Aufgabe als große Genugtuung. Grund genug, um kurz innezuhalten und den Moment wirken zu lassen. Einziger Haken daran: um mich herum nur verdutzte Gesichter, die Kollegin ist verunsichert. Lob für eine solche „Kleinigkeit“ ist sie nicht gewohnt. Sie mache doch nur ihren Job. Auch der Product Owner ist verwirrt: Sollte das hier nicht selbstverständlich sein? Warum also ist der ScrumMaster so begeistert?
Ich merke schnell: Das Problem liegt tiefer. Lob und positive Rückmeldungen gehen hier allen schwer von den Lippen. Aus der Psychologie ist bekannt, dass Belohnung der positiven Verstärkung dient. Damit soll die Wahrscheinlichkeit erhöht werden, dass sich ein gewünschtes Verhalten wiederholt. Situationsgebundene Belohnung kann also durch Loben erfolgen. Dies sollte allerdings nicht zu freigiebig eingesetzt werden, da es sonst unverdient erscheint. Bewiesenermaßen wird das Belohnungssystem jedoch gezielt durch die Wertschätzung unserer Mitmenschen angesprochen – das steigert die Ausschüttung des Glückshormons Dopamin.

Den kleinen Dingen Aufmerksamkeit schenken

Meistens sind es ja die kleinen Dinge, die als selbstverständlich hingenommen werden, und es erscheint uns deshalb nicht nötig, diese wertzuschätzen. Es liegt uns fern, die kleinen Dinge zu sehen, die in Summe zum Gesamterfolg beitragen. Gerade im Prozess der Veränderung ist es jedoch sehr wichtig, diese kleinen positiven Fortschritte zu erkennen und hervorzuheben. Dopamin ist dafür verantwortlich, dass wir Erfahrungen als wohltuend empfinden, in Zukunft werden wir uns an dieses Gefühl erinnern können. So werden diese aktiv unterstützt und in Zukunft höchstwahrscheinlich wiederholt werden. Noch wichtiger als das Lob durch den ScrumMaster und den Product Owner ist das Lob untereinander. Kollegen, die sich gegenseitig zu ihren einzelnen Leistungen wertschätzend äußern, steigern die produktive Zusammenarbeit und den Zusammenhalt im Team.

Das Team mit Freiheiten belohnen

Das Team kann neben diesen kleinen Wertschätzungen auch durch Freiheiten belohnt werden. Vertrauen, das dem Team beispielsweise vom Product Owner entgegengebracht wird, ist eine wertschätzende Handlung, die dazu führen kann, dass das Team bemüht ist, beim nächsten Mal die Erwartungen des Product Owners zu übertreffen. Es wird dadurch selbstbewusster und beginnt, sich selbst mehr zuzutrauen. Damit ist die Grundlage für innovativere und kreativere Lösungen gelegt und das Team wächst noch mehr zusammen. Zugestandene Freiheit wirkt durch ihren wertschätzenden Charakter also ebenfalls als positive Verstärkung und steigert die Produktivität im Scrum-Team.

Gold Cards

Die gleiche Wirkung haben sogenannte Gold Cards, die der Product Owner an die Teammitglieder vergibt. Mit diesen Cards können Mitarbeiter innerhalb eines gewissen Zeitraums einen Teil ihrer Arbeitszeit in etwas investieren, das sie interessiert. Dies kann eine Fortbildung, persönliche Weiterbildung oder Zeit sein, um an eigenen Ideen zu arbeiten. Der Vorteil an dieser Variante ist, dass dem einzelnen Mitarbeiter gegenüber Interesse ausgedrückt wird, nicht nur an der Leistung des Teams.

Eine Release-Party schmeißen

Im skalierten Umfeld gibt es eine weitere mächtige Möglichkeit, das gesamte Team oder sogar mehrere Teams für ihre erbrachten Leistungen zu belohnen. Wie wäre es beispielsweise mit einer Release-Party? Die Teams haben durchgehalten, gekämpft und geliefert. Warum also nicht den Release gebührend mit allen Beteiligten feiern? So kann sogar das Angenehme mit dem Nützlichen verbunden werden: Die Teams können ihre Leistungen bei einer Präsentation von den Stakeholdern und dem gesamten Umfeld anerkennen lassen und anschließend kann sich das Team gebührend selbst feiern.
Zurück zum Geschehen: Ich wiederhole meine Aufforderung, den ersten Task auf „Done“ zu feiern. Peinlich berührt versucht sich die Kollegin aus dem Mittelpunkt zu stehlen. Wir haben noch einen langen Weg vor uns, aber ich werde nicht aufgeben, denn: Gerade am Anfang sind es die kleinen Erfolge, die aus einer Gruppe von Menschen ein Team machen.

Foto: CC0 Creative Commons – pixabay, pexels

Agil trotz Überlastung: Wie man die Freiwilligkeit rettet

Die folgende Situation kommt Ihnen eventuell bekannt vor: Der Product Owner oder das Management haben das Prinzip der Agilität noch nicht vollständig verinnerlicht und überladen die Teams mit Aufgaben, die ihre Kapazität um das Doppelte übersteigen. Die Folge sind unzählige Meetings, lange Abende und wenig Motivation für alles, was den ständig wachsenden Stapel auf dem Schreibtisch nicht direkt verkleinert. Dazu gehören auch die morgendlichen Dailys, lange Sprint Plannings und ganz beliebt: die vermeintlich überflüssige Retrospektive. Gerade Letztere erzeugt selten einen sofort messbaren Mehrwert, weswegen sie gerne einmal gekippt wird, wenn ein Team zu ausgelastet ist. Was also tun, um dem Team zu helfen, Agilität zu verstehen, seine eigene Effizienz zu steigern und Zeit dafür zu finden? Und wie kann man den Weg dorthin auch noch auf dem Prinzip der Freiwilligkeit beruhen lassen?

  1. Freiwilligkeit betonen. Ich handhabe dies gerne, indem ich das Gesetz der zwei Füße anbringe und zum Standard in allen Meetings erhebe. Freiwilligkeit zu betonen und vor allem zu leben, ist von enormer Bedeutung, da das Team lernen soll, selbstbestimmt zu arbeiten. Langfristig wird es eine intrinsische Motivation für Agilität aufbauen, wenn es den Mehrwert darin erkennt.
  2. Mehrwert schaffen. Nichts überzeugt mehr als Mehrwert. Wenn jedes Teammitglied nach einem Meeting das Gefühl hat, dass die Zeit gut investiert war, fällt es leichter, auch am nächsten Meeting teilzunehmen und sich langfristig auf Agilität einzulassen. Mehrwert zu schaffen, liegt in der Verantwortung des ScrumMasters.
  3. Meetings koppeln. Was aber, wenn die Teammitglieder aufgrund ihrer Auslastung zum Beispiel nicht einmal zur ersten Retrospektive zu bewegen sind? Hier hat es sich für mich bewährt, Kombinationsmeetings anzubieten. Statt zu einer Stunde Backlog Refinement und einer Stunde Retrospektive einzuladen, lade ich einfach zu zwei Stunden Refinement und Retro in einem Termin ein. Klingt simpel? Ist es auch. Sind die Teammitglieder erst einmal an einem Ort und gestaltet der ScrumMaster einen guten Übergang, hat die Retro schon voll begonnen, bevor das Team merkt, dass es bereits die Axt schärft. Tipp: Zu Beginn kann das Kombinationsmeeting auf eineinhalb Stunden angesetzt werden, um die Hemmschwelle zu senken.
  4. Brokkolimethode einsetzen. Als Kind mochte ich, heute unverständlicherweise, keinen Brokkoli. Meine Oma fragte mich dann am Mittagstisch, mit der Kelle Brokkoli bereits in der Hand, ob ich denn zwei oder drei Stücke Brokkoli möchte. Ich nahm natürlich zwei Stück und aß sie brav auf, da ich das Gefühl hatte, die Entscheidung selbst getroffen zu haben. Wie wohl meine Antwort ausgefallen wäre, wenn meine Oma gefragt hätte: „Möchtest du Brokkoli? Ja oder nein?“ Übertragen wir die Methode meiner Oma auf ein Meeting: „Wollt ihr die Retrospektive lieber um 14.00 Uhr oder um 16.00 Uhr machen?“ Ask the team. Danke Oma!
  5. Jedes Zweiglein greifen. Ein guter ScrumMaster hört zu. Jederzeit und mitdenkend. So fallen ihm auch Zweiglein auf, die das Team fallen lässt und die er aufheben muss, um die Arbeit des Teams zu verbessern. Beispielsweise ließ in einem Sprint Planning ein Tester den Kommentar fallen, wie schade es sei, dass niemand im Team Wissen zu einer bestimmten Datenbank hatte. Nach fünfminütiger Diskussion war klar, dass drei Teammitglieder dieses Wissen sehr wohl hatten und der besagte Tester dies erst jetzt, sechs Wochen nach Projektstart und unzähligen Abstimmungsschwierigkeiten, erfahren hatte. Das Zweiglein greifend, stellte sich heraus, dass es alle gut fänden zu wissen, welche Fertigkeiten und Wissen die anderen Teammitglieder hatten (welch Überraschung). Einmal zu dieser Erkenntnis gekommen, fiel es nicht schwer, einen Skills-Workshop auf die Beine zu stellen: Einerseits wurden die Skills der Teammitglieder samt selbstorganisierter Fortbildungsmaßnahmen entwickelt und andererseits wurde mein Arbeitsmodell für das Projekt gefüllt. Also mein Tipp: Hört genau zu, fragt nach und nutzt die mäeutische Methode von Sokrates.

Zusammenfassend gibt es aus meiner Sicht mehrere Möglichkeiten, die Effizienz eines Teams zu steigern und das Prinzip der Freiwilligkeit zu leben und zu fördern, auch wenn das Team stark ausgelastet ist. Das bedeutet zu Beginn viel Aufwand, Motivationsarbeit und den einen oder anderen Kniff. Dabei sollte nie vergessen werden, das Prinzip der Freiwilligkeit zwar explizit zu erwähnen, es jedoch ab und zu durch aktives Nachdenken direkt erkennbar werden zu lassen.

Die Kalinić-Lektion – Grundwerte sind unverhandelbar

Scrum kennt mit Mut, Offenheit, Transparenz, Respekt und Commitment fünf grundlegende Werte. In Unternehmen, die sich auf den agilen Weg machen, kommen diese Werte im Allgemeinen ganz gut an. Ja, es gibt den ein oder anderen Konjunktiv oder rhetorischen Weichmacher. Manchem entkommt auch ein mildes, wohlwollendes Lächeln. Werte, na klar, sind jedenfalls schon mal super und wenn es hart auf hart kommt, findet sich immer irgendwie eine Lösung. Haben Sie den rhetorischen Weichmacher, die opportunistische Öffnung des Handlungsspielraums im vorherigen Satz entdeckt?

Mit unverhandelbaren Werten schafft man es ins Finale

Wie weit man es bringen kann, wenn Werte unverhandelbar sind, hat in diesen Wochen die kroatische Nationalmannschaft bei der Weltmeisterschaft in Russland mit dem Einzug ins Finale gegen Frankreich gezeigt. Nikola Kalinić hat im ersten Gruppenspiel der Kroaten gegen Nigeria in der 85. Minute beim Stand von 2:0 für Kroatien seine Einwechslung verweigert. Er habe Rückenschmerzen, ähnlich wie schon Tage zuvor im Freundschaftsspiel gegen Brasilien. Kurz nach dem Spiel gegen Nigeria sprach der kroatische Trainer Zlatko Dalic davon, dass es keine Verletzung, sondern nur ein Problem gäbe. Zwei Tage später war Kalinić nicht mehr Teil des kroatischen Kaders. Es heißt, er sei enttäuscht darüber gewesen, dass Mario Mandzukic den Vorzug im Sturmzentrum erhalten habe.
Nikola Kalinić war ein wichtiger Spieler im Kader der kroatischen Nationalmannschaft. Ein international erfahrener Stürmer, der erst diesen Sommer für eine zweistellige Millionensumme zum AC Mailand gewechselt war und einst als eines der größten Talente des Landes galt. Ein Land, das gerade etwas mehr als vier Millionen Einwohner zählt, ein Land, dessen größter fußballerischer Erfolg mit dem dritten Platz bei einer Weltmeisterschaft bereits 20 Jahre zurückliegt und ein Land, das im Finale in Moskau die Möglichkeit hatte, den größten Triumph im Fußball zu erringen – den Weltmeistertitel.
Zlatko Dalic hat das alles erreicht, obwohl er die Mannschaft im ersten Moment geschwächt hat, indem er einen Spieler nach Hause geschickt und sich selbst einer wichtigen Option im weiteren Turnierverlauf beraubt hat. Er hat sich gegen die vermeintliche Angst vor mangelnden Alternativen in der späteren Phase entschieden. Er hat konsequent seine Grundwerte verteidigt – gerade dann, als es hart auf hart kam. Zu Beginn des wichtigsten Turniers einer goldenen Generation.

An erster Stelle steht das Wohl des Teams

Das zeigt, wie wichtig Grundwerte sind. Es belegt, dass ein funktionierendes Team bei jedem Zusammenwirken von Menschen die oberste Priorität hat – ob auf dem Platz oder in Unternehmen und erst recht im agilen Kontext. Das gilt es zu verteidigen, auch wenn es im ersten Moment wie eine Schwächung aussieht und Konsequenz auch mal als Kälte interpretierbar ist. Es zeigt sich erneut, dass ein funktionierendes Team mit starken, gelebten Grundwerten in der Lage ist, auch bei suboptimalen Rahmenbedingungen Erfolge zu feiern und das Maximum aus sich herauszuholen.
Auf der anderen Seite sehe ich auch den Menschen Nikola Kalinić. Ich möchte mir gar nicht vorstellen, wie es aktuell in ihm aussieht, die Gedanken, die ihm in den Sinn kommen, das Stigma, „der Eine“ gewesen zu sein. Wenn man aus dieser Tragik noch etwas Positives ziehen möchte, dann ist es diese Lektion, die uns Nikola Kalinić mitgibt: Es lohnt sich einfach nicht, sich für unverzichtbar zu halten. Weder im Moment, noch in der Vita. Die Welt dreht sich weiter. Ein funktionierendes Team geht seinen Weg.
Persönlich wünsche ich Nikola Kalinić, dass er sich von diesem persönlichen Tiefschlag erholt. Ich hoffe, dass er den Mut findet, seine Geschichte zu erzählen und dass es sein Triumph wird, Menschen dazu zu inspirieren, in jenen Augenblicken reflektiert zu handeln, in denen das Leben von jetzt auf gleich eine Wende nimmt.

Foto: CC0 Creative Commons – pixabay, comfreak

3 Argumente gegen User Stories und wie ihr ihnen begegnen könnt

In unseren Trainings oder in der Arbeit mit Teams begegnen wir einer Vielfalt von Gründen, warum eine bestimmte agile Praktik in diesem Team nicht angewendet werden kann. Dabei sind die Begründungen nur auf den ersten Blick spezifisch für das jeweilige Team und vor allem sind es in den seltensten Fällen tatsächlich sachliche Gründe, warum etwas nicht geht. Menschen stehen Veränderungen prinzipiell erst einmal kritisch gegenüber. Deshalb werden neue agile Praktiken nicht einfach ausprobiert, sondern meist erst einmal gründlich geprüft.
Daran ist prinzipiell nichts Falsches – unser Gehirn spart viel Energie, wenn es gelernte Praktiken abspielt und nicht immer Neues ausprobiert. Gleichzeitig kann es ganz schön frustrierend sein, wenn man einem Team etwas zeigen möchte und nur Widerstand erntet. Manchmal verbirgt sich hinter der vorgeschobenen rationalen Begründung auch ein Gefühl der Unsicherheit. Ehrlich wäre es, einfach zu sagen: „Ich will es nicht machen! Den alten Prozess kenne ich, der neue macht mir Angst, weil ich noch nicht weiß, was genau passiert.“ Im beruflichen Kontext sind aber wenige so reflektiert und ehrlich und deshalb lohnt es sich, sich als Scrum Master oder Agile Coach schon einmal auf die typischen Widerstände einzustellen, die einem bei der Einführung eines neuen Meetings, Artefakts oder einfach nur einer kleinen Prozessänderung begegnen werden.
In den nächsten Wochen wollen wir euch einige jener Argumente nennen, die uns immer wieder begegnen, damit ihr dagegen gewappnet seid und euren Teams helfen könnt, sich auf das Abenteuer des Ausprobierens einzulassen. Im ersten Teil widmen wir uns dem Thema User Stories.

„So ein simpler Satz ist mir viel zu wenig!“

Ganz klar, die User Story in ihrer klassischen Syntax ist einfach – und das soll sie auch sein! Eine gute User Story ist nämlich nichts anderes als eine „Einladung zur nachgelagerten Konversation“. Das bedeutet: In ihrer offenen Formulierung ist sie dazu gedacht, dass der Product Owner mit dem Team über die User Story spricht, sie auf den Prüfstand stellt und dadurch die Details immer klarer werden – bis die Story „ready for sprint“ ist.

„Aber eine User Story kann doch nicht mindestens zwei Mal im Refinement gewesen sein!“

Gerade weil User Stories anhand der INVEST-Kriterien formuliert werden, sollen sie unter anderem verhandelbar und klein sein. Das bedeutet, dass es viele Gespräche und einige Durchläufe braucht, um mehr Klarheit über die Anforderung zu bekommen, die sich in der User Story versteckt. Je vager die Formulierung und je näher die User Story noch an ihrer Ideenphase ist, desto klarer wird, dass es mehr Details braucht, bis alle Teammitglieder das gleiche Verständnis über den Inhalt der User Story haben. Das Backlog Refinement ist dafür der geeignete Termin. Sprecht als Team über den Inhalt, verschafft euch Klarheit und ergänzt, was das Zeug hält: Akzeptanzkriterien, Testfälle, Abhängigkeiten, Risiken und alle Details, die euch einfallen. User Stories werden dann auch oft kleiner geschnitten, wenn sie sich für einen Sprint als zu groß herausstellen.

„User Stories, okay, aber Personas? Brauch ich wirklich nicht!“

Simon Sinek sagt immer wieder, dass das „Why“, also das Warum, das einen antreibt, klar sein muss. Daher sollte die dahinterliegende Antwort etwas elaborierter sein als ein lapidares „Isso“. Auch wenn dem Team der Mehrwert klar ist, ist es unglaublich hilfreich, sich die Anforderungen mit der Brille bestimmter Zielgruppen anzusehen: Warum tickt meine Zielgruppe so wie sie tickt? Und was bedeutet das für mein Produkt? Gibt es widersprüchliche Anforderungen meiner User-Gruppen? Worauf will ich als Product Owner mein Augenmerk legen und für wen priorisiere ich? Personas helfen dabei, sich als Team in die jeweilige Zielgruppe hineinzuversetzen. Je mehr Daten und Fakten in die Persona fließen, desto besser – und dennoch: Entwerft eure Personas so, als wären sie reale Wesen mit Charakter, Lebenslauf, Vorlieben und gebt eurem Produkt damit so viel Kontext, dass ihr euch der Frage nach dem „Why“ leichter nähern könnt.
Sind euch in eurer Arbeit noch andere Argumente gegen User Stories begegnet? Lasst uns wissen, wie ihr darauf reagiert.

Dieser Beitrag ist im Pair Writing mit Sandra Wittmann entstanden.
Foto: CC0 Creative Commons, pixabay – aitoff

Was die Position des Scrum-Teams vor dem Taskboard über das Team aussagt

„Leistet mein Team gute Arbeit?“ Eine Frage, die viele Führungskräfte in Unternehmen umtreibt, wie zahlreiche Anfragen nach Projektbesuchen und Assessments beweisen. Doch braucht es Fragebögen, Interviews oder stundenlange Post-Mortems, um eine Antwort zu finden? Die Frage lässt sich häufig mit einer scheinbar einfachen Methode beantworten: durchs Beobachten.
Wenn ich zum ersten Mal ein Team besuche, das bereits agile Arbeitsweisen wie Scrum oder Kanban nutzt, achte ich bewusst und unbewusst auf viele kleine Hinweise, um eine Hypothese über den Teamerfolg und das Verhalten des Teams und des Unternehmens zu bilden. Ich versuche bewusst, nicht in Aktionismus zu verfallen und sofort alles auf links zu drehen. Denn es gibt Gründe, warum die Menschen so arbeiten, wie sie es gerade tun. Es geht also nicht darum, nach wenigen Tagen einen detaillierten 12-Punkte-Aktionsplan zu haben, sondern ein tiefes Verständnis für die Arbeitsweise der Menschen im Unternehmen zu entwickeln.
Erfahrungsgemäß ist die Stehung, das Catch Up, Stand Up oder Heads Up, oder wie auch immer Sie das tägliche kurze gegenseitige Update im Team, also das Daily Scrum, bezeichnen, eine tolle erste Möglichkeit, um diese Beobachtung durchzuführen. Neben dem üblichen Teilnehmerkreis, der Dauer und der Häufigkeit des Dailys sagt die Position der Teammitglieder vor dem Taskboard sehr viel über die Kultur und den Teamspirit aus.
In den zahlreichen Unternehmen und Projekten, die ich gesehen habe, zeichneten sich einige Muster immer wieder ab. 12 davon zeige ich Ihnen hier. Zur Erklärung: Der orange Kreis ist der ScrumMaster, Gelb symbolisiert die Teammitglieder, in Grün sehen sie den Product Owner und blau ist der Manager.

Muster 1 – das einsame Taskboard


Niemand kommt zum Daily. Man hat sich zwar die Mühe gemacht, die Arbeit sichtbar zu machen, doch das Hilfsmittel wird nicht genutzt. Wahrscheinlich wird das Taskboard nicht als hilfreich erachtet. Offensichtlich sind Zusammenarbeit und Koordination in diesem Team nicht notwendig.

Muster 2 – die Leere


Kein Taskboard, keine Gespräche, kein Treffen. Ob das besser oder schlechter ist, als das „einsame Taskboard“ sei mal dahingestellt.

 

Muster 3 – kein Taskboard


Das Team unterhält sich mehr oder weniger strukturiert. Das ist ein guter Anfang. Der Hauptzweck des Meetings – die kurze, zielgerichtete Unterhaltung zwischen den Teammitgliedern funktioniert. Ein Taskboard kann helfen, diesen Austausch zu fokussieren und zu strukturieren.

Muster 4 – das Zentrum

Die Teammitglieder berichten an den ScrumMaster. Der ScrumMaster steht viel zu sehr im Fokus und verhindert, dass sich die Teammitglieder offen und ehrlich austauschen. Das Team hat den Nutzen des Dailys für sich selbst wahrscheinlich noch nicht erkannt. In besonders schlimmen Fällen fragt der ScrumMaster die Teammitglieder einzeln ab und verlangt eine Rechtfertigung, wenn etwas nicht klappt. Selbstorganisation muss hier noch beigebracht werden.

Muster 5 – das alternative Zentrum


Die Teammitglieder berichten an den Product Owner. Ein Wort – Micromanagement. Anscheinend vertraut der Product Owner dem Team nicht ausreichend. Der ScrumMaster scheint auch schwach zu sein.

Muster 6 – die spanische Inquisition


Product Owner und ScrumMaster sitzen hinter einem Schreibtisch vor dem Taskboard und erwarten den Bericht der Teammitglieder. So ziemlich das Schlimmste, was einem Team passieren kann. Noch schlimmer wäre es nur mehr, wenn die Teammitglieder mit verbundenen Augen vor einer Wand stünden.

Muster 7 – das Meeting


Offensichtlich ist die alte Meetingkultur noch tief verankert. Die Teammitglieder sitzen an den Tischen. Im „Idealfall“ klappt jeder noch seinen Laptop vor sich auch und tippt wild vor sich hin. Es geht um Anwesenheit, nicht um Ergebnisse. Langeweile ist vorprogrammiert, Leidenschaft werden wir in so einem Meeting vergeblich suchen. Kann noch gesteigert werden durch das nächste Muster.

Muster 8 – das Klassenzimmer


Ähnlich wie „Das Meeting“, zusätzlich können sich die Teammitglieder jetzt nicht mehr in die Augen schauen. Auch hier arbeiten eher Fachexperten in einer Arbeitsgruppe. Zusammenarbeit gibt es hier wahrscheinlich nicht.

Muster 9 – der Experte


Das Daily findet ausschließlich mit dem ScrumMaster und dem „einzigen Teammitglied, das sich wirklich auskennt“ statt. Ab und zu gibt es auch mehrere Experten, die jedoch getrennt voneinander befragt werden. Die restlichen Teammitglieder werden ignoriert. Teamzusammenarbeit und Austausch wird man in diesem Team vergeblich suchen.

Muster 10 – noch ein alternatives Zentrum


Die Teammitglieder berichten an den Manager – Micromanagement in Vollendung. Der Product Owner ist entweder entmachtet oder nicht da.

 Muster 11 – der Lonesome Rider


Der ScrumMaster macht das Daily mit sich alleine, weil er das Team nicht braucht, um Transparenz zu stiften. Er weiß Bescheid (oder meint Bescheid zu wissen), was im Team gerade läuft. Hat den Sinn des Dailys komplett verfehlt. Offensichtlich hat der ScrumMaster auch wenig Respekt vor den Fähigkeiten der Teammitglieder. Eine alternative Interpretation ist, dass keines der Teammitglieder zum Daily kommt, weil sie den Mehrwert und Sinn nicht sehen. Vergleichbar mit Muster 1 und 2.

Muster 12 – der Reporter


Der ScrumMaster berichtet direkt an den Manager. Teammitglieder werden komplett außen vor gelassen – entweder, weil der ScrumMaster die Teammitglieder als nicht fähig genug einstuft oder diese keine Lust auf das Meeting haben. Vertrauen und Identifikation mit dem Produkt, das entwickelt wird, wird man hier vergeblich suchen.

Die Kraft des Taskboards nutzen: Wie macht man es besser?

Idealerweise stehen alle Scrum-Teammitglieder – also Entwicklungsteam, Product Owner und ScrumMaster – gleichberechtigt vor dem Board. Die Teammitglieder erzählen sich gegenseitig von ihrem Fortschritt, der ScrumMaster moderiert, achtet in den Ausführungen des Teams auf Hindernisse und erzählt auch selbst von den Themen, an denen er arbeitet. Der Product Owner interessiert sich auch für den Fortschritt des Teams und berichtet von den Themen, die bei ihm passiert sind. So gefällt mir das.

Starten Sie an dieser Stelle ein kleines Experiment. Beobachten Sie bei nächster Gelegenheit das Verhalten Ihres Teams. Überprüfen Sie, ob sich der aus der Beobachtung ableitbare Zweck mit der Funktion deckt, die das Team erfüllen soll. Passt das Gesagte mit dem sichtbaren Verhalten zusammen? Damit wird die Beobachtung auch zur Strategiearbeit: Was haben wir uns vorgenommen zu tun und was tun wir tatsächlich? Beobachtung als bewusste Führungsaufgabe benötigt etwas Zeit und Kontakt ins Team, kann aber zur Rekalibrierung des Veränderungsbedarfs führen und zur Steuerung genutzt werden. Konkret könnte das bedeuten, die Beobachtung zu teilen und zusammen mit dem Team in Bezug auf den angestrebten Zweck zu reflektieren.
Kennt ihr noch weitere Muster? Ich freue mich über eure Kommentare.

Collaboration Hacks for Distributed Teams

Last month I have been invited to join an event for the PMA young crew organization in Austria, an organization that has the aim to foster project management knowledge for young professionals. The organizer asked if I do have experiences with distributed teams and if I can share them with interested young professionals from all over Europe. Therefore, I prepared a workshop to elaborate on success factors for distributed teams, no matter if they are distributed around the world or in the same city sitting in different offices. Although I’m primarily working with agile teams, the experiences shared could be used for any work setting. This is also the reason I named the workshop “Agile flavored Collaboration Hacks for Distributed Teams”.
In my opinion, there are two major categories of enablers for high performing distributed teams:

From my perspective the most important success factor is that the project leader can decide autonomously on how to structure the process of collaborating and which tools are used. If everything is predefined and there is no freedom in adapting to challenges, chances are pretty low that the team will fully unleash its potential. Therefore, be self-confident and define your space of autonomy with your sponsors so that you can decide on important adaptions improving your team performance!
You can find more experiences in my slide deck:
Agile Flavoured Collaboration Hacks for Distributed Teams

Foto: CC0 Creative Commons, pixabay -Free-Photos

"Ja, aber …" oder woran ich erkenne, dass ich agil bin

Wie bei jeder Reise, die wir unternehmen, wollen wir auch in Veränderungsprozessen wissen, ob wir Fortschritte machen. Wenn wir wissen, wie weit wir schon gekommen sind, können wir eine Prognose darüber anstellen, wie viel mehr Energie wir einsetzen müssen, bis wir unser Ziel erreicht, unsere Vision erfüllt haben. Gehen wir daran, agile Arbeitsmethoden, wie zum Beispiel Scrum, zu implementieren, ist die Einhaltung des Rahmenwerks ein konkreter Indikator dafür, wie vollständig, wie gut ich schon agil „mache“:

In der Praxis hat sich allerdings gezeigt, dass man nur vollständig agil „machen“ kann, wenn man auch agil ist, d.h. wenn das dahinterliegende Mindset, die Kultur im Unternehmen etabliert ist. Es gibt eine Wechselwirkung zwischen machen und sein. Nun lässt sich das agile Machen – wie oben beschrieben – recht einfach messen: Ich zähle einfach die Häkchen, die ich hinter die verschiedenen Elemente des Rahmenwerks machen kann. Falls ich nicht auf die volle Zahl Häkchen komme, lässt sich interessanterweise mutmaßen, dass es beim Mindset hapert. Anders ausgedrückt: Tatsächlich sind die Hard Facts ein Indikator dafür, ob es bei der Etablierung eines agilen Mindsets in eurem Unternehmen noch Verbesserungspotenzial gibt. Und wie beschrieben, lassen sich die Hard Facts recht leicht messen. Wer sich mit Objectives und Key Results auseinandergesetzt hat, weiß wahrscheinlich, dass Ergebnisziele und Fortschrittsziele zwei verschiedene Dinge sind. Auf unser Anliegen übertragen heißt das: Ich messe den Erfolg der Einführung agiler Methoden anhand der „Treue“ zum Scrum-Framework.

Ja, aber wie messe ich nun die Soft Facts?

Nur wie lässt sich messen, wie weit meine Bemühungen zur Etablierung des Mindsets gediehen sind? Wie messe ich meine Fortschritte auf dem Weg zum Ziel? Wie messe ich Kultur? Für den Start reicht es einmal genau zuzuhören. Zählt einmal, wie oft ihr „Ja, aber …“ in eurem Team und Unternehmen hört – und wie oft ihr selbst „Ja, aber …“ sagt. „Ja, aber“ heißt in Klardeutsch „Nein“. Alles, was hinter dem Aber kommt, negiert die erste Satzhälfte. lehnt damit die Position des anderen ab. Erst wenn ein Team in der Lage ist, verschiedene Standpunkte nebeneinander in der Schwebe zu halten, können dem Spannungsfeld der verschiedenen Sichtweisen neue und kreative Lösungen entspringen. Dann hat das Team dialogische Kompetenz entwickelt – eine wichtige Kulturtechnik für ein agiles Unternehmen. Im praktizierten Pluralismus liegt die Chance zur Schaffung eines neues Ganzen, das größer ist als die Summe seiner Teile.

Was könnt ihr für die Entwicklung dieser Kompetenzen tun? Was sind eure Fortschrittsziele?

In multifunktionalen Teams treffen häufiger Menschen mit unterschiedlichen Persönlichkeitstypen aufeinander als in Silo-Teams, deren Teammitglieder meist denselben Beruf gewählt haben. Analysen von Persönlichkeitstypen, wie beispielsweise disc oder der Myers-Briggs-Typenindikator helfen den Teammitgliedern zu verstehen, wie ihre Kollegen ticken. Das erhöht auch die Bereitschaft, Andersartigkeit zu tolerieren und den genannten Pluralismus zunehmend wertzuschätzen. Der ScrumMaster spielt in der Förderung dieser Entwicklung eine wichtige Rolle. Er erklärt den Teammitgliedern die Bedeutung von „ja, aber …“ und spiegelt ihnen, wie sich Kommunikation gestaltet, wenn es verwendet wird oder wenn es ausbleibt.

Video: Digital Avengers – So stellen Sie Ihr schlagkräftiges Superhelden-Team zusammen

Im Call for Papers der „Agile Digital Transformation“ inspirierte mich die Frage nach dem geeigneten Team, mit dem man die Herausforderungen der Digitalisierung meistern kann. Ich machte mich auf die Suche nach einem passenden Hollywood-Teams als Metapher und stieß schließlich auf die Superhelden-Truppe der Avengers. Nicht nur konnte ich sofort einige Parallelen zu performenden Teams entdecken, die Verknüpfung passte auch zum Start des neuen Avengers-Streifen im Kino. Also, Welt aus, Film an und beide Teile der Avengers-Streifen geguckt, um nach den Parallelen und Mustern zwischen den Superhelden und Hochleistungsteams zu suchen. Herausgekommen ist ein unterhaltsamer Vortrag, der sich einerseits damit beschäftigt,

Die Slides zu diesem Vortrag findet ihr unter diesem Link
Viel Spaß beim Nachschauen!

Scrum and multi-disciplinary teams

In this edition of my video series, I explain the need to use multidisciplinary teams in Scrum, rather than cross-functional. Teams should consist of members from all business areas to develop a fully functional solution.  
Join me in my video to find out why using multi-disciplinary teams is critical. 

Manager, entscheidet euch oder entscheidet euch!

Das häufigste Impediment, das uns in Großunternehmen am Weiterkommen hindert, ist die nicht getroffene Entscheidung. Teams stoßen regelmäßig an den Rand ihrer Entscheidungsfähigkeit, da es geschriebene und ungeschriebene Regeln im Unternehmen gibt: Bestimmte Entscheidungen sind vom Vorstand oder zumindest einer bestimmten Hierarchieebene zu treffen.
Eine nicht getroffene Entscheidung hat zwei Effekte:

Nichtentscheiden kostet Geld

Das Arbeiten mit Hypothesen führt zu einem hohen Grad an Unsicherheit und demotiviert die Mitarbeiter: Sie müssen nämlich befürchten, dass ihre Arbeit bei einer gegensätzlichen Entscheidung überflüssig wird. Hierbei ist noch nicht der finanzielle Schaden bedacht, der einem Unternehmen durch verzögerte Entscheidungen und dem daraus resultierenden Hantieren mit Hypothesen entstehen kann.
Ein Beispiel: Ein Team besteht aus neun Mitgliedern, jedes davon verdient im Schnitt 80.000 €/Jahr. Das Team wartet auf eine Entscheidung und beginnt, vorläufig mit einer Hypothese zu arbeiten. Nach sechs Wochen fällt der Vorstand eine gegensätzliche Entscheidung. Durch die verzögerte Entscheidung entstehen also folgende Kosten: 9 Mitarbeiter * 80.000 €/Jahr: 52 Wochen * 6 Wochen = 83.077 €. Innerhalb von sechs Wochen wurde somit das Jahresgehalt eines Mitarbeiters verbrannt und ein motiviertes Team erfolgreich in die Demotivation geführt.
Dieser finanzielle Schaden für das Unternehmen wird in Kauf genommen, weil im Hintergrund das Machtdenken dominiert. Entscheidungsgewalt abzugeben, führt beim Management zunächst zum Gefühl einer gewissen Ohnmacht, da Entscheidungsgewalt doch immer mit Macht gleichgesetzt wird.
Tatsächlich führt das Abgeben von Entscheidungsbefugnissen aber zu motivierten Teams und besseren Performances. Eine Win-Win-Situation: Der Manager darf sich schnellerer und performanterer Teams rühmen, während die Teams die Lust und Motivation am Arbeiten zurückgewinnen. Zudem kann sich der Manager als Führungskraft wieder auf seine eigentliche Aufgabe konzentrieren: auf das Führen!
Möchte man also demotivierte Teams vermeiden, Selbstorganisation fördern und Ressourcen nicht verbrennen, folgen daraus zwei logische Konsequenzen: Entweder trifft der Manager (besser daher der Entscheider) schnelle Entscheidungen, oder er entscheidet sich dazu, Entscheidungsgewalt ab- und dafür in die Teams zu geben. Einfacher lässt sich Motivation nicht erzeugen und Kostenverschwendung vermeiden! Also Manager, entscheidet euch, euch zu entscheiden!

Foto; CC0 Creative Commons – congerdesign, pixabay

Pair und Mob Programming – der kleine, aber feine Unterschied

Wissenstransfer, die Ideen und Kompetenzen von vielen nutzen, Einarbeiten neuer Kollegen – Mob und Pair Programming sind wirklich sinnvolle Arten der Zusammenarbeit. Aber wann eignet sich welche der beiden Arbeitsmethoden am besten?

Vier Augen sehen mehr

Beim Pair Programming sitzen zwei Entwickler gleichzeitig vor einem Bildschirm und bilden somit ein „Pair”. Einer der beiden programmiert, der Zweite liest die Codezeilen mit. Nach dem Motto “vier Augen sind besser als zwei” wird so der Code von beiden Entwicklern gleichzeitig geschrieben. Besonderen Charme hat dieses Vorgehen deshalb, weil die beiden Entwickler einerseits besseren und sauberen Code schreiben und sich andererseits gegenseitig zu innovativem Denken motivieren. Der Austausch zwischen den Entwicklern zum geschriebenen Code führt dazu, dass sie voneinander lernen und ihr Wissen erweitern.
Tipp: Nach einer zuvor vereinbarten Zeit sollten Coder und Mitleser sich abwechseln, um Ermüdungserscheinungen (nachlassende Konzentrationsfähigkeit) vorzubeugen.

Komplexe Themen im Team bearbeiten

Beim Mob Programming sitzt das gesamte Team vor einem großen Bildschirm und nur einer aus dem Team programmiert. Die Besonderheit ist hierbei, dass das programmierende Teammitglied nicht seine eigenen Gedanken in Code verwandelt, sondern das restliche Team über den nächsten Codeabschnitt diskutiert. Der Entwickler an der Tastatur muss aus der Diskussion heraushören, wie die nächsten Codezeilen aussehen werden bzw. lässt er sich diese teilweise sogar diktieren (je nach Erfahrungsgrad). Durch die Diskussion wächst nicht nur bei jedem Teammitglied die Erfahrung im Umgang mit komplexen Problemstellungen, sondern gleichzeitig auch das Wissen über den Code. Jeder im Team ist in der Lage, den Code zu verstehen, weiß worum es geht und kann schnell Code Refactoring betreiben.
Tipp: Diese Art des Programmierens ist für denjenigen, der gerade tippt, sehr anstrengend. Daher sollte der codende Entwickler nach ca. 10-15 Minuten von einem anderen Teammitglied abgelöst werden. Bei einer Teammitgliederanzahl von mehr als vier ist es besser, mit einem Beamer zu arbeiten, statt auf einen Bildschirm zu starren. So kann jeder einfach folgen und niemand versperrt einem anderen Teamkollegen die Sicht.

Best Practice

Meine persönliche Erfahrung mit beiden Methoden hat gezeigt, dass es bei neuen Thematiken sinnvoller ist, erstmal gemeinsam zu starten, um eine gemeinsame Laufrichtung zu finden. Im nächsten Schritt sollte man das Team in kleine Pairs aufbrechen, um sich die geschnittenen Themen zu erarbeiten. Nach einiger Zeit trifft man sich wieder als Team im Mob, fügt die Codefragmente zu einem gemeinsamen Code zusammen, testet gemeinsam und bleibt für die weitere Entwicklung im Mob. Oder: Das Team einigt sich auf die nächsten Einzelthemen, die wieder im Pair erarbeitet werden. So entsteht ein angenehmer Arbeitsflow, bei dem das Wissen aller Teammitglieder stark wächst und das Produkt dadurch schnell, effizient, effektiv und erfolgreich geliefert werden kann.

Foto: (c) rawpixel

Die User Story als Einladung zu einer Diskussion

Viele meiner Kunden fragen, wie viele Anforderungen eine User Story beinhalten sollte und wo denn die „anderen“ Anforderungen abgespeichert werden sollen.
Diese Frage ist meiner Meinung nach ein Widerspruch in sich. Denn eine User Story besteht ja nicht nur aus dem berühmten Satz „Als <Rolle> möchte ich <Funktion>, um <Nutzen> zu haben“, sondern enthält einiges mehr an Informationen.
Zunächst mal: Was braucht man, um ein Produkt zu entwickeln? Natürlich das Wissen darüber, wie dieses Produkt am Ende aussehen soll. Was *braucht* der User? Was *will* der User? Was sind die Rahmenbedingungen (Budget/Ressourcen, Gesetze etc.)?
Um all diese Fragen zu beantworten, sollte also eine User Story diese Informationen beinhalten:

Wie umfassend soll diese „Dokumentation“ sein? Ich beobachte, wie lange mein Team beim Refinement darüber geredet hat – das ist mein Richtwert. Denn das ist genau das, was in diesem Meeting passieren soll: darüber reden. So lange bis jeder weiß, was diese Funktionalität können muss.
Jetzt werden viele sagen: „Wir arbeiten ja nur mit Kärtchen, da passt das alles nicht drauf.“ Das ist schon richtig. Es spricht allerdings nichts dagegen, zusätzlich zum Kärtchen auch andere Medien zu verwenden, die separat geführt werden. Ein Flipchart reicht oft völlig aus.
Wie sieht bei Ihnen eine User Story aus?

Scrum – eigentlich so einfach wie kochen

Einzelne Teams, inzwischen aber auch ganze Unternehmen stellen sich die Frage: Wie können wir uns angesichts sich ständig verändernder Marktbedingungen so aufstellen, dass wir unsere Anpassungsfähigkeit erhöhen und gleichzeitig schneller in der Umsetzung werden? Sicher: Auf diese Frage gibt es viele mögliche Antworten und ganz sicher gibt es nicht das eine Rezept. Eine Antwort ist, die Haltung und Methoden von Scrum für sich zu entdecken und anzuwenden.
Oft erleben wir viele Hemmungen, wenn Menschen zum ersten Mal von Scrum hören und es für sich und ihren Kontext anwenden sollen. Deshalb wollen wir das Thema einmal aus einer anderen Perspektive betrachten und es mit dem Kochen vergleichen. Stellt euch vor, ein Familienmitglied hat Geburtstag. Ihr wollt diesen Geburtstag bei euch Zuhause feiern und ein Festmahl zubereiten. So ähnlich ist es, wenn man den Scrum Flow für sich entdeckt und seinen Projekt-/Arbeitsalltag mit Leben füllt.

Mit Offenheit kocht es sich leichter

Eine wichtige Voraussetzung ist aus unserer Sicht die Haltung, beispielsweise die Offenheit für Experimente. Bezogen auf unser Menü bedeutet das, nicht zu lange zu überlegen, sondern bereit zu sein, einfach loszulegen. Sich darauf einzulassen, dass das Menü während des Kochens weiter Form annimmt. Natürlich kann man beliebig viel Zeit investieren, ein besonders kreatives Menü zusammenzustellen, doch lasst uns einfach mal damit beginnen!
Auf den Kontext der Organisation übertragen, bedeutet das eine neue Haltung in der Führung: sich beispielsweise gemeinsam mit den Mitköchen zu überlegen, was traue ich mir und meinen Mitköchen zu, die Aufgaben aufzuteilen und dann loszulassen. Es bedeutet, in die Selbstorganisationsfähigkeit des Teams zu vertrauen, in die Kollaboration über horizontale und vertikale Grenzen hinweg, damit das Essen gemeinsam gelingt. Welche Zutaten tragen wesentlich zum Gelingen bei?

Die Vision: Pasta oder Schweinshaxe?

Um den Geburtstag gebührend zu feiern, wollen wir unsere liebe Familie und die Freunde bekochen. Natürlich soll es etwas Besonderes geben. Wir haben es geradezu vor Augen: Das größte Festmahl aller Zeiten soll es werden! Ein rauschendes Fest, wie es die Welt noch nicht gesehen hat. Mit einem Leuchten in den Augen erzählen wir bei der Einladung von unserem Plan und sehen, wie geradezu der Funke überspringt. Alle freuen sich auf das anstehende Fest und bieten ihre Unterstützung an. Im Scrum-Kontext ist es der Product Owner, der diese Vision in ein Produkt verwandelt und emotional kommuniziert und dadurch das Team motiviert, voller Energie an der Umsetzung mitzuwirken.

Die Constraints: der Blick in den Kühlschrank

Wir stehen also in der Küche und haben die Vision eines opulenten Festmahls vor Augen. Ein Blick in den Kühlschrank holt uns zurück auf den Boden der Tatsachen. Er ist ziemlich leer. Es ist Monatsende und das Konto zeigt überdeutlich, dass ein Großeinkauf heute nicht mehr drin ist. Es gibt aber noch ein paar Dosen geschälte Tomaten und in der Vorratskammer findet sich eine Packung Nudeln. Etwas Knoblauch ist auch noch da, frische Chili-Schoten und Olivenöl. Leider ist der Backofen seit Wochen defekt, aber immerhin funktionieren die Herdplatten, im Schrank finden sich ein Topf und eine Pfanne. Mit diesen Rahmenbedingungen lässt sich zwar kein 10-Gänge-Menü zaubern, für eine große Portion Penne Arrabbiata dürfte es aber reichen. Zusammen mit der letzten Flasche von dem guten Rotwein ergibt es das bestmöglichste Gericht.
So ambitioniert eine Vision auch sein mag, kein Produkt und kein noch so leckeres Gericht ist frei von Einschränkungen und Rahmenbedingungen, eben den sogenannten „Constraints“. Im Kontext einer Produktentwicklung geben diese Rahmenbedingungen vor, wie die Vision umgesetzt werden kann. Wie groß ist das Budget? Wie viele Mitarbeiter können an einem Projekt arbeiten? Welche gesetzlichen Vorschriften müssen eingehalten werden? Was ist technisch überhaupt machbar?

Die Rollen: Verantwortung teilen – kochen im Team

Wie auch im Scrum Flow gibt es beim gemeinsamen Kochen zugewiesene Rollen. Diese Rollen sind klar voneinander abgegrenzt: Jeder der mitkocht, übernimmt eine bestimmte Arbeit. Im Scrum Flow gibt es die drei Kernrollen Scrum Master, Product Owner und Entwicklungsteam. In drei weiteren Rollen kommen noch Kunde, User und Management ins Spiel. Auch hier sind die Rollen klar voneinander abgegrenzt: Der Product Owner weiß genau, was er oder sie am Schluss vor sich stehen haben möchte. Er organisiert das Menü und ist dafür verantwortlich, dass jeder Koch im Team die benötigten Fähigkeiten hat, um das beste Menü auf den Tisch zu zaubern. Seine „Vision“ gibt er an die Mitköche weiter, die das Entwicklungsteam bilden. Sie kochen das Menü „tatsächlich“ und bringen es in eine Form. Ohne sie würde der Product Owner das Gericht nicht rechtzeitig zur Feier fertigbekommen.
Die Rolle des Scrum Masters kann in der Küche mit jemandem verglichen werden, der sich darum kümmert, dass jeder die Zutaten hat, um seine Arbeit schnellstmöglich auszuführen. Der Scrum Master sorgt auch dafür, dass das Team ohne Probleme und Einschränkungen kochen kann, indem zum Beispiel Geschirr abgewaschen oder Abfälle entsorgt werden. Um den Scrum Flow zu vollenden, benötigen wir noch Kunde, User und Management. Im unserem Fall ist das Geburtstagskind Kunde und User. Es gibt im Vorfeld an, welche Wünsche es hat (oder das Kochteam weiß das aus vergangenen Beobachtungen), und genießt das Mahl im Anschluss an die Zubereitung. Der Manager finanziert das Geburtstagsessen, er hat nichts mit der Küche und dem Kochen zu tun. In unserem Fall könnte das der Vater des Geburtstagskindes sein.

Kochen und abschmecken: Selbstreflexion und Feedback-Loops

Lasst uns nun kochen. Um das Rezept bestmöglich umzusetzen, bietet sich ein gewisses Vorgehen an. Die taktische Ebene des Scrum Flow umfasst alle Meetings und ist mit den Anleitungen in einem Rezept vergleichbar. In diesen Anleitungen steht genau beschrieben, welche Schritte und welche Zutaten wann eingesetzt werden.
Starten wir mit dem Sprint Planning 1: In diesem Meeting überlegen wir uns, was das Festmahl beinhalten soll. Eventuell möchten wir mehrere Gänge zubereiten und entscheiden uns dafür, dass Kartoffelsuppe das Beste für den ersten Gang sei. Nachdem alle zugestimmt haben, überlegen wir uns, wie wir unseren ersten Gang umsetzen werden – vergleichbar mit dem Sprint Planning 2. Jeder Koch hat seine Aufgabe zugeteilt bekommen: Der eine wäscht die Kartoffeln, der andere schält die Kartoffeln, der Dritte schneidet sie klein und so weiter.
Nun ist das Vorgehen klar und alle Köche kommen ins Tun. Während der Zubereitung kann es Rücksprachen geben – im Scrum Flow spiegelt sich das in den Dailys wider. In diesem täglichen, rund 15 Minuten dauernden Standup-Meeting halten alle Köche kurze Rücksprachen zu den einzelnen Aufgaben. Ist die Suppe fertig, wird der Product Owner in die Küche gerufen, um zu probieren. Gefällt ihm die Kartoffelsuppe, wird sie an den Tisch gebracht und kann vom Geburtstagskind und den Gästen probiert und bewertet werden. Sind die Gäste und vor allem das Geburtstagskind zufrieden, hat die Kartoffelsuppe bestanden. Sollte es jemandem nicht schmecken, wird zum Beispiel mit weiteren Gewürzen nachgebessert – das geschieht im Rahmen des Scrum Flow mit Produkten nach dem Review. Nachdem die Kartoffelsuppe von den Genießern „abgenommen“ wurde, trifft sich das Team in der Küche und reflektiert die Zusammenarbeit, wie in einer Retrospektive.
Die Prinzipien und Vorgehensweisen von Scrum sind also eigentlich nichts Neues – sie werden in anderen Kontexten täglich praktiziert. Was vielleicht ungewohnt ist, ist die Anwendung dieser Prinzipien auf die Wissensarbeit. Fangen Sie doch einfach genau so an, wie wir es hier beschrieben haben: Legen Sie einfach los, machen Sie sich den Spaß und bereiten Sie mit Freunden ein Essen nach dem Ablauf des Scrum Flow zu. Guten Appetit!

Diesen Artikel haben Mara Ambs, Michael Gissler und Miruna Sachse im Mob-Writing gemeinsam verfasst.

Agiles Arbeiten: Fokus entsteht durch Vertrauen

Bei einem Product Owner Training haben mich drei Teilnehmer auf das Thema Fokus gebracht. Nicht zuletzt ist “Fokus” einer der fünf Werte von Scrum. Doch wozu brauchen wir ihn, wie wirkt er und überhaupt: Wie entsteht Fokus? In einer angeleiteten Freewriting Session hatte ich dann die Chance, dieses Thema von Grund auf für mich zu beschreiben. Und naja, was soll ich sagen: Dabei fiel mir zunächst einmal Basketball ein. Ich habe selbst früher Basketball gespielt und wirklich geliebt. Man kämpft gemeinsam als Team und spielt alle nötigen Spielzüge aus, um einen Korb gegen seinen Gegner zu werfen.
Der Moment aber, in dem ich absolute Fokussierung wirklich spüren konnte, war während einer Freiwurfsituation. Sie ist hart erkämpft, und sichtlich aus der Puste steht man an der Freiwurflinie und soll zum angezeigten Zeitpunkt den Ball im Korb versenken. Alles andere als eine leichte Übung, wenn man das in einer realen Wettkampfsituation machen muss.
Fürs Gelingen braucht es Fokus und eine einstudierte Routine, durch die man im Moment der höchsten Anspannung die Umwelt vollkommen ausblenden kann. Der Fokus beschränkt sich nur noch auf den Ball, den Korb und den eigenen Herzschlag. Noch einmal tief durchatmen: und Wurf!

Wodurch entsteht Fokus?

Wie kann ich mich dazu bringen, die Umwelt für eine gewisse Zeit auszublenden, um im übergreifenden Sinne auch in der Unternehmenswelt zu „punkten“? Man könnte meinen, Meditation wäre ein möglicher Weg, um in einer Stresssituation cool bleiben zu können. Ja, sicher. Ich denke aber, dass der eigene Fokus nur ein Teil der gesamten Lösung ist. Denn was es in einer Freiwurfsituation braucht, ist nicht nur die eigene Ruhe, sondern die Ruhe des gesamten Teams, in dem man spielt.
Der Kern liegt also im Vertrauen zu seinem Umfeld.
Ich muss mich auf meine Leute verlassen können, egal was passiert. Selbst wenn ich den Ball nicht versenke, braucht es das Team, um den Ball wieder einzufangen, um im Spielverlauf durch weitere Versuche Punkte zu machen. Nur wenn ich es schaffe, dem Team vollkommen zu vertrauen, kann ich mich selbst auf das Wesentliche konzentrieren.

pixabay.com, Skitterphoto, CC0 Creative Commons

Wie funktioniert Fokus in der Unternehmenswelt?

In der freien Marktwirtschaft sind wir einer viel höheren Dynamik und Komplexität ausgesetzt. Wir haben oft mehrere Bälle im Spiel und jonglieren diese viel schneller als wir es eigentlich möchten. Doch der Fokus auf das Wesentliche macht ein Unternehmen wirtschaftlich. Würde ein Unternehmen auf jeden Reiz reagieren, würde es nicht mehr wertschöpfend sein.
Folglich scheint der wertschöpfende Fokus essentiell für den Erfolg in unserer Marktwirtschaft zu sein. Durch Vertrauen sowie eine passende Rollen- und Aufgabenverteilung behält ein Team die umliegenden Geschehnisse im Blick und reagiert nur auf die wichtigen Ereignisse. Denn wer den eigenen Fokus auf die wenigen, wirklich wichtigen Dinge legt, hat eine gute Chance, sein Vorhaben zu meistern. Durch den Fokus kann man sich jede beliebige Situation zu eigen machen, das Beste aus ihr herausholen und sie zu einem guten Abschluss bringen! Wohl wissend, dass das Team hinter mir steht und bei Problemen meinen Rücken stärken wird.

Wider die unsinnige Teamisierung von Leistung

Teamisierung? Gibt es nicht. Ein Kunstbegriff. Für mich beschreibt er ein Phänomen, das seit längerem in Zusammenhang mit der Einführung von agilen Methoden in Unternehmen beobachtbar ist. Ich meine hier nicht die „Sozialisierung“ – darunter versteht man das Vergemeinschaften und Teilen etwa von Belastungen, Gewinnen oder Lernerfahrungen unter den an einer Gesellschaft Beteiligten. Mit „Teamisierung“ meine ich eine leichtfertige Pauschalisierung und Verallgemeinerung von Individuen, die an einem Objekt oder in einer Leistung zusammenwirken. Sie passiert meist unmerklich zunächst auf der sprachlichen Ebene und wirkt sich in weiterer Folge auf die Struktur aus.
Plötzlich gibt es nur noch „das Team“ in seiner äußeren Hülle und Pauschalität – ähnlich indifferent wie „die Gesellschaft“, „die Wirtschaft“ oder „die Wissenschaft“ in politischen oder religiösen Polemiken. Als Hinweis auf eine innere Differenziertheit bleibt maximal das Attribut übrig, dass „das Team“ möglichst „crossfunktional“ besetzt sein soll. Dem Team stehen spezifische Rollen gegenüber: der ScrumMaster, der Product Owner, der Manager, der User, der Kunde. Das Team aber – jedenfalls in der ihm entgegenschlagenden Erwartungshaltung – als amorphe Masse angesprochen und sprachlich behandelt, trägt und erfüllt den hehren Anspruch, im Sinne aller beteiligten Anspruchsgruppen zu handeln, alle Bedürfnisse in sich zu absorbieren und zu verarbeiten. Mit intrinsischer Motivation und methodischer Kompetenz werden alle diese Bedürfnisse in Produktinkrementen iterativ aufgelöst und erfolgreich integriert. „Ask the team“ ist zur Weltformel geworden.
Einst war es eine Aufforderung, die Entscheidungen dorthin zu legen, wo die Information ist. Heute ist es mitunter eine Plattitüde, die einem ungelenken Management in ohnmächtiger Laissez-faire-Manier eine zeitgeistig erscheinende Beschreibung des eigenen – jetzt agilen – Mindsets und Führungsstils ermöglicht. Früher lästerte man vielleicht: „TEAM – toll, ein anderer macht’s.“ Das war wenigstens noch auf die dysfunktionalen internen Teamdynamiken gemünzt und mit einem Augenzwinkern eine freundliche Anmahnung für Zusammenspiel und Teamplay. Ganz nach der Idee des Mannschaftssports.

Leistung ist ein Zusammenspiel von Einzelnen

Aufgaben werden heute teamisiert – in ein Team geworfen – und dort durch das wundersame, unerklärliche Wirken des Teams auf höchstem Niveau bearbeitet und gelöst. Entsprechend wird auch Leistung teamisiert: Also keiner war’s – nicht nur im Negativen (wir erinnern uns an den ahnungslosen Blick kleiner Kinder, die mit dem Fußball eine Scheibe eingeschossen haben. Da war’s auch keiner). Schlimmer noch: Auch im Erfolgsfall war´s keiner. Weil es eben nur das Team gibt. Leistung aber, kommt im Zusammenspiel einzelner Teamplayer zustande. Wir sind kein Schwarm (was für ein grausamer Begriff im Kontext von Agilität), der instinktiv einen Formationsflug oder das Formationsschwimmen meistert. In der Regel sind wir doch höchst spezielle und spezialisierte Wesen mit einem hohen Maße an Differenzierungsmöglichkeiten und Bedürfnissen, die diese Diversität in den Dienst eines gemeinsamen Objekts (vielleicht des Teamworks) stellen. Für den Erfolg ist es noch nicht einmal notwendig, dass wir denselben Benefit aus diesem Zusammenwirken erhalten. Was uns eint, ist der Moment des Erfolgs, in dem wir uns in unseren Anstrengungen, Entbehrungen und Wirken bestätigt sehen.

Agiles Management führt Individuen

Lange Zeit hatte ich nicht verstanden, warum einige (vor allem Software-) Entwicklungsteams sich Namen wie „Defenders“ (entlehnt von Marvel-Figuren) gaben. Heute verstehe ich das als einen Hinweis auf die Unterschiedlichkeit im Team, als Hinweis darauf, die spezifischen Einzelleistungen und -beiträge im Team zu sehen, sichtbar zu machen und anzuerkennen, statt eine amorphe Masse namens „Team“ zu kreieren. Das ist ein wichtiger Schritt agilen Managements und somit einer agilen Führung und Steuerung: Es geht uns im Team um eine handverlesene Truppe von Charakteren und Profilen – ausgerichtet auf eine Sache. Eine Sache, die in ihrer Art und Natur ein komplexes und hochgradig soziales System der Bearbeitung, Beantwortung und Veränderung erfordert. Als agile Manager sind wir dafür verantwortlich, dieses komplexe, hochgradig soziale System zu etablieren und in eine Kultur der Selbsterhaltung und Selbstorganisation zu führen, um eben jener Sache (Aufgabe) gerecht zu werden.

Team ist Beziehung

Allzu schnell lösen wir den Einzelnen wie eine Brausetablette im Teamwasser auf (was nicht anzuraten ist). Jeder im Team bleibt aber wegen seiner menschlichen Natur immer nur er/sie selbst und wird nicht zu Team. Vielmehr vernetzt er sich in wiederholender, erweiternder und laufender Kommunikation mit anderen, die sie selbst bleiben. Erst diese Kommunikation lässt die Idee des Teams entstehen. Und diese Idee nährt sich aus den Beziehungsleistungen einzelner, die sich selbst in Bezug zueinander und zum ko-konstruierten Ganzen – dem Team – setzen. Entweder positiv inspirierend – dann nehmen wir die anderen Teammitglieder und das Teamkonstrukt positiv erweiternd zu unserem individuellen Wirkraum wahr – als Möglichkeit, über uns hinauszuwachsen. Oder wir erleben es eben als Gegenteil: Als Begrenztsein innerhalb der uns ohnehin schon schmerzlich bewussten Limitationen aus unserem Alleinsein. Durch das Teamkonstrukt erlebe ich mich also noch ohnmächtiger, als ich mich durch meine menschlichen Grenzen ohnehin schon erlebe. Sozialisierung der Limitationen statt Erweiterung der Möglichkeitsräume.

Team ist ein Konstruktionsprozess

Das bedeutet: Team ist immer ein Konstruktionsprozess, ein Work in Progress, der sich im Einzelnen positiv oder negativ nährt. Er wirkt selbstverstärkend dort, wo Konsens in der Beurteilung erlebt wird; energetisierend, wenn die Selbsterhöhung durch andere bestätigt wird; zerstörerisch dort, wo diese Konstruktion als behindernd, verhindernd oder gar lebensbedrohlich empfunden wirkt. Team ist also immer auch eine Einzelleistung, so verrückt das klingen mag. Auch wenn diese Einzelleistung zuallererst in der Konstruktionsbereitschaft des Wirklichkeitskonstrukts Team bestehen mag.Das bedeutet aber, sich nach dem Setup auch der Bedeutung der Einzelnen im Gesamtsystem Team bewusst zu bleiben. Damit kann sich die Schlagkraft, Bearbeitungs-, Beantwortungs- und Veränderungskompetenz und -fähigkeit weiterentwickeln und damit das System Team am Leben erhalten werden.
Konkret heißt das: 

Ich wäre nicht Berater, hätte ich nicht einen Begriff, der einem Executive Summary gleichkäme: Coopetition. Die Verbindung aus Cooperation und Competition. Das „sowohl als auch und und“ – auf Unternehmens-, Bereichs- und eben auch Teamebene. Weil wir eben sind, was wir sind: Individuen, die durch Sozialisierung überlebensfähig werden.

Video: Dev Team

Dev-Teams sollen liefern. Sie sollen crossfunktional sein, die Teammitglieder sollen sich gegenseitig unterstützen und sie sollen ständig besser werden. In diesem kurzen Video erkläre ich das Prinzip eines autarken Teams und die zwei wesentlichen Möglichkeiten, um eure Teams zur Zusammenarbeit zu bewegen.
Viel Spaß beim Anschauen — Boris
 

Ein Product Owner für zwei Teams, oder?

Mein Kunde hatte sich innerhalb eines großen Entwicklungsprojekts vorgenommen, nicht nur die verschiedensten Applikationen den neuen Anforderungen des Marktes anzupassen, sondern gleichzeitig die Software-Architektur zu modernisieren, um Continuous Delivery zu ermöglichen. Gestartet wurde mit mehreren parallel laufenden Scrum-Teams an vier verschiedenen Standorten. Wir hatten einen Kollegen aus dem Fachbereich, der neben der Rolle des Kunden auch zwei Scrum-Teams als Product Owner betreuen sollte. Auf welche Herausforderungen stößt dieser nun in der Rolle als Product Owner mit seinen beiden Scrum-Teams?

Was der Product Owner eigentlich tun sollte

Im Allgemeinen ist der Product Owner für das entstehende Produkt und den dazugehörigen Business Value verantwortlich, den das Produkt für das Unternehmen erzeugen soll. Gemeinsam mit dem Team arbeitet er an der Vision, pflegt das Backlog (Schreiben von User Storys und deren Priorisierung im Backlog) und er ist im ständigen Kontakt mit den Stakeholdern.
In meinen Augen ist der Product Owner ein betriebswirtschaftlicher Allrounder mit Liebe zur eingesetzten Technologie, der verschiedene Funktionen in einer Person vereint und dafür sorgt, dass das Richtige entwickelt wird. Zusätzlich bringt er die unterschiedlichen Positionen von Team und Stakeholdern zum größtmöglichen wirtschaftlichen Nutzen für das Unternehmen auf einen Nenner. In diesem Fall sah es aber anders aus.
Bild_ella_1

Der Product Owner hat keine Zeit

Bereits in den ersten Sprints stellten beide Scrum-Teams unabhängig voneinander fest, dass ihr Product Owner für sie kaum zeitlich verfügbar war. Das Backlog war weder vorbereitet noch priorisiert und daher liefen die Meetings sehr unstrukturiert und nicht konstruktiv ab. Nur sehr schwer konnten die Teams in Erfahrung bringen, welche User Storys im kommenden Sprint bearbeitet werden sollten. Für Fragen während des Sprints stand der Product Owner nur sehr eingeschränkt zur Verfügung, da er in seiner Rolle als Hauptansprechpartner im Fachbereich viele Aufgaben wahrnehmen musste und häufig unterwegs war. Letztendlich war auch der Product Owner mit der Situation unzufrieden, weil er den Anforderungen der beiden Teams nicht gerecht wurde und zunehmend überfordert war.

Der dreigeteilte Product Owner

Während einer Coachingsitzung mit diesem Product Owner entstand folgendes Bild:
Bild_ella_2
Es zeigt, dass schlichtweg die Fokussierung fehlte. Der Verantwortliche konnte sich weder seiner bisherigen Tätigkeit als Kunde noch seinen beiden Scrum-Teams widmen.
Mit dem Fokus auf nur ein Team könnte er sich besser in die Rolle des Product Owners einfinden. So sollte ein Product Owner Vertrauen in die Fähigkeiten seines Teams haben und es selbstständig entscheiden lassen, wie es seine Anforderungen umsetzen will. Dieses Vertrauen kann er jedoch nur erlangen, wenn er sich auf eine Sache, hier ein Scrum-Team, konzentrieren und sich mit dem Team und dessen Fähigkeiten auseinandersetzen kann. Zusätzlich ermöglicht die Fokussierung, auch ausreichend Zeit in die eigene Vorbereitung zu investieren. Mit einem vorbereiteten Product Owner laufen die Meetings strukturiert und effizient ab, sodass alle motiviert in den neuen Sprint starten können.
Ein Product Owner ist zudem Teil des Scrum-Teams. Er teilt sich im Idealfall mit dem Dev-Team und dem ScrumMaster einen eigenen Teamraum, verwaltet dort seine Artefakte (Story Map, Product Backlog etc.) und ist als Ansprechpartner verfügbar: für das Team und für die Stakeholder. So kann er sich voll und ganz auf das Team und deren Anfragen konzentrieren und wird nicht ständig unterbrochen. Auf allen Seiten ist dadurch ein Produktivitätsschub zu erwarten.

Ein Product Owner für zwei Teams, oder?

Im Laufe der ersten Sprints erkannten wir, dass die Konstellation nicht zielführend war. Selbst nachdem der Product Owner ein Scrum-Team abgegeben hatte, spürten wir keine wesentliche Verbesserung. Und so wurde schlussendlich entschieden, dass sich der Vertreter des Fachbereichs nun auf diese Rolle konzentrieren sollte – sie beanspruchte seine volle Aufmerksamkeit.
Ich bin der Meinung: Grundsätzlich ist es nicht sinnvoll, einen Product Owner für zwei Scrum-Teams einzusetzen, geschweige denn einen Kollegen, der mit zusätzlichen Aufgaben betraut wird. Die beschriebene Situation zeigt gut, auf welche Schwierigkeiten alle Beteiligten stoßen und dass diese sich nicht immer beseitigen lassen. Die Kunde-Product Owner-Konstellation führte außerdem dazu, dass zwei Teams nicht ausreichend gut und schnell entwickeln konnten und das wiederum verlangsamte das Projekt. Um einer solchen Situation künftig vorzubeugen, sollten alle Projektinvolvierten vor dem Start in den Aufgaben und Rollen innerhalb von Scrum trainiert werden. Zusätzlich sollten die Ausgestaltung der Scrum-Rollen und die Erwartungshaltung innerhalb der Organisation besprochen werden. So können bereits im Vorfeld mögliche Bottlenecks identifiziert und gelöst werden, bevor sie innerhalb des Projekts zu realen Schwierigkeiten führen. Und schließlich bin ich davon überzeugt, dass ein Product Owner seine Rolle nur so effektiv wie möglich ausführen und alles Nötige für sein Team geben kann, wenn er fokussiert arbeitet und sich nicht um mehrere Teams oder Projekte innerhalb der Organisation kümmern muss.
Übrigens ist es durchaus möglich, in Scrum einen Product Owner für zwei Teams einzusetzen. Allerdings setzt das unbedingt voraus, dass die Teams bereits seit mehreren Jahren mit Scrum gearbeitet haben und dass es die Produkt-Business-Beziehung vollständig durchdrungen hat. Der Grad der Selbstorganisation innerhalb der Teams ist dann bereits so hoch, dass es ausreicht, die große Vision des Product Owners zu kennen, um das Richtige zu liefern.
Bild_ella_3
 
Weitere Informationen zu Scrum 3.0 finden Sie hier: “Von Scrum 1.0 zu Scrum 3.0” oder “Boris Gloger and Scrum 3.0: Is the Future of Scrum Really No Backlogs or Standups??”

Warum sitzt David Alaba auf der Bank?

Als Österreicher freue ich mich auf diesen Sommer besonders. Seit Langem hat es unsere Fußball-Nationalmannschaft wieder einmal geschafft, sich für ein Großereignis zu qualifizieren. Wir fahren nach Frankreich und ein ganzes Land ist im Fußballfieber: Fanartikel verkaufen sich wie warme Semmeln, Spiel-Städte wie Bordeaux entdecken den österreichischen Fußballfan als gänzlich neue Touristengruppe und Testspiele gegen Fußballzwerge werden mit Interesse verfolgt. Und so lese ich eines Abends nach dem Testspiel gegen Malta den Spielbericht und wundere mich, dass unser Superstar, David Alaba, bereits zum zweiten Mal das halbe Spiel über auf der Bank sitzt. Müssen wir uns Sorgen machen?
Nein. Ganz im Gegenteil. Teamchef Marcel Koller sieht sich Alternativen an. Richtig gehört. Der Fußball-Zwerg Österreich sucht Alternativen für den besten Linksverteidiger der Welt. Zu Recht. Schließlich kann es sein, dass David Alaba ausfällt, geschont werden muss oder – vielseitig wie er ist – an einer anderen Stelle eingesetzt wird. Um das Team darauf vorzubereiten, lässt er gegen Malta einen anderen Spieler links außen auflaufen. Der Trainer investiert also Testspielzeit.

Fußball ist wie Softwareentwicklung – ein Teamsport

Genauso wie beim Toreschießen (Siehe: Mats Hummels darf keine Tore schießen) zeigt sich in diesem Fall eine Parallele zwischen Fußball und der Softwareentwicklung. Sehen wir uns den Zusammenhang anhand eines – nicht ganz – fiktiven Beispiels an:
Stellen wir uns vor, wir haben einen Spezialisten in unserer Mannschaft, der in seinem Bereich (sei das nun die linke Außenbahn oder die Datenbankverwaltung) eine Koryphäe ist. Aus welchem Grund auch immer ist er zur Zeit jedoch nicht verfügbar. Als Teamsportler wissen wir, dass Ausfälle im Laufe der Saison vorkommen und entsprechende Alternativen aufgebaut werden müssen. Ähnlich sollten auch Entwicklungsteams aufgestellt sein:
Selbstverständlich hat jedes Teammitglied individuelle, unterschiedlich ausgeprägte Stärken. Dennoch müssen wir auf einer Position agieren können, falls es hier zu einem Ausfall kommt. Trainer investieren an dieser Stelle Testspielzeit. Manager können diesem Vorbild folgen und in Wissenstransfer investieren. Dabei verlangt natürlich niemand, dass die Alternative so gut ist wie der Stammspieler, das Team darf nur zu keinem Zeitpunkt auf einer Flanke komplett offen sein.
Im Fußball wie auch in der Softwareentwicklung gibt es die Möglichkeit, Schwächen in der Mannschaft kurzfristig zu kompensieren. Während Fußball-Vereine Spieler ausleihen, können Unternehmen externe Berater oder Entwickler zukaufen. In beiden Fällen gelten dabei zwei Grundsätze:

Doppelspitzen lohnen sich

Im Fußball wie auch in der Softwareentwicklung lohnt es sich, Teams so aufzusetzen, dass jede Position bzw. Funktion mit mehr als einer Person besetzt ist. Während es im Fußball darum geht, gegenüber einem Gegner keine Schwachstelle zu offenbaren, hilft uns die Absicherung innerhalb der Teams dabei, Engpässe in der laufenden Entwicklung zu verhindern. Treten Probleme auf, kann durch die Mehrfachbesetzung außerdem gewährleistet werden, dass jemand da ist, der sich des Problems annehmen kann. Im Sport wie auch in der Softwareentwicklung können Sie sich kurzfristig behelfen, achten Sie dabei allerdings darauf, sich nicht in Abhängigkeiten zu begeben, die Sie nicht steuern können.

Mats Hummels darf keine Tore schießen

Auf dem Fußballplatz hat jeder Spieler eine wesentliche Verantwortung. Die Stürmer sollen Tore schießen, die Mittelfeldspieler die Bälle nach vorne bringen, die Verteidiger sollen verhindern, dass die gegnerische Mannschaft trifft und der Torwart versucht, Schüsse aufs Tor abzuwehren und Elfmeter zu halten. Das bedeutet aber nicht, dass die Spieler nur genau und ausschließlich das machen. Wenn sich die Chance ergibt, darf auch mal ein Abwehrspieler ein Tor schießen oder ein Stürmer in der Abwehr aushelfen. Stellen Sie sich vor, Tore, die nicht von einem Stürmer geschossen werden, zählten nicht. Hummels trifft? Das entspricht nicht seiner Verantwortung als Verteidiger. Marko Arnautovic verhindert auf der Linie ein Tor des Gegners? Die Abwehr des Stürmers gilt nicht, die gegnerische Mannschaft bekommt ein Tor zuerkannt.

Und in der Entwicklung?

Was am Fußballplatz absolut undenkbar ist, scheint in der Entwicklung von neuen Produkten gang und gäbe. Dort gibt es oft einen Hardwareentwickler, der ausschließlich Hardware entwickelt, eine Konstrukteurin, die ausschließlich konstruiert, einen Technischen Zeichner, der ausschließlich Zeichnungen erstellt, eine Einkäuferin, die ausschließlich Teile einkauft, einen Softwareentwickler, der nichts anderes macht, als Software zu schreiben. Jeder hat seinen Bereich, für den er verantwortlich ist. Nur er kann die dort anfallenden Aufgaben übernehmen und nur in seinem Verantwortungsbereich kann er arbeiten.
Wenn wir in Unternehmen neue agile Teams aufsetzen, lautet einer der ersten Einwände, die wir hören oft: „Ich bin Konstrukteur, ich darf nur konstruieren.“ oder „Ich teste nicht, dafür haben wir Versuchsmitarbeiter.“ Die Möglichkeit, außerhalb des eigenen Bereichs zu arbeiten oder zu helfen wird gar nicht in Betracht gezogen. Fehlt es zum Beispiel akut an freien Zeichnern oder ist der Teamkollege überlastet, kommt es selten bis gar nicht vor, dass der andere Kollege, der vielleicht die nötigen Fähigkeiten hätte, dem ersten hilft und somit das Projekt nach vorne bringt.
Was ist der Grund dafür? Hier sind einige Hypothesen:

Würden die Teammitglieder ein bisschen nach links und rechts neben ihrem eigenen Verantwortungsbereich schauen (dürfen), würden sie merken, dass sie sehr wohl helfen können.

T-shaped Professionals in der Produktentwicklung

Auch wenn der Verteidiger seine große Stärke in der Abwehr ausspielen kann, sind seine Fähigkeiten als Stürmer trotzdem gut genug, um auch mal ein Tor zu machen. Der Verteidiger reagiert situativ und flexibel auf die aktuellen Anforderungen, anstatt sich zurückzuziehen und darauf zu warten, dass der Gegner den nächsten Angriff startet. Auch wenn der Stürmer im Mittelfeld aushilft, ist er nach wie vor Experte im Schießen von Toren. Oftmals braucht es nicht DEN Topspieler mit den besten Fähigkeiten, sondern nur jemanden, der zur richtigen Zeit am richtigen Ort das Richtige tut, um den Teamerfolg zu gewährleisten. Genau so verhält es sich auch in der Entwicklung. Der Konstrukteur konstruiert, doch wenn er Zeit hat, darf er ruhig auch mal testen oder in der Fertigungs- oder Prozessplanung unterstützen. Das macht ihn nicht weniger zu einem Experten. In der agilen Community nennt man Mitarbeiter, die fachliche Expertise in ein paar speziellen Bereichen haben und darüber hinaus über Basiswissen in angrenzenden Bereichen verfügen „T-shaped Professionals“. Sie werden erstaunt sein, in wie vielen Bereichen außerhalb der eigenen Verantwortung man durchaus sinnvoll helfen kann.
Ein sehr positives Beispiel für diese Hilfsbereitschaft liefert eine niederländische Firma für Belüftungssysteme, in der ich einige Projekte begleiten durfte. Dort hat in einem Projektteam ein Mitarbeiter aus der Fertigungsprozessplanung in einer Phase, in der er eigentlich noch nicht so viel zu tun hatte, gerne und wie selbstverständlich den restlichen Teammitgliedern seine Hilfe angeboten. Die Designer im Team, die sonst regelmäßig mit neuen Aufgaben zugemüllt wurden, konnte er unterstützen und entlasten, obwohl er nicht in seinem Fachgebiet gearbeitet hat. Das hat dem Projekt und allen Mitgliedern gut getan und Ruhe ins Team gebracht. Das war die Theory of Constraints in Reinkultur: Der größte Engpass wurde aufgelöst, der Durchfluss an der richtigen Stelle erhöht.

Designated Teams fördern nachhaltige Zusammenarbeit

Die Voraussetzung dafür: Offenheit und eine nachhaltige Teamzusammensetzung. Nur wenn die Teammitglieder das Gefühl haben, sagen zu dürfen, dass sie Zeit frei haben, ohne vom eigenen Chef und Abteilungskollegen dafür mit einem Maulkorb bestraft zu werden, werden sie das auch tun. Da Fairness nach dem SCARF-Modell von David Rock ein menschliches Grundbedürfnis ist, muss außerdem absehbar sein, dass der Gefallen, der da geleistet wird, später auch wieder zurückgezahlt werden kann. Werden die Designer später aus dem Team genommen, ohne dass sie sich revanchieren konnten, wird der Prozessplaner einmal und nie wieder geholfen haben. Aus diesem Grund ist die Konsistenz im Team so wichtig. Das Stichwort hier lautet „designated teams“.
Fußball ist eine Teamangelegenheit, genau wie die Entwicklung neuer Systeme oder Software und nur wenn alle zusammenarbeiten, wird man das Spiel am Ende auch gewinnen. Da zählen Tore vom Verteidiger genauso viel, wie Tore der Stürmer. Lassen Sie Ihr Team also auch wirklich als Team arbeiten. Und trauen Sie sich, auch mal über Ihren Schatten zu springen. Sie und Ihr Team werden daran wachsen und davon profitieren.

Product teams for hardware products

Already in 1986 Ikujiro Nonaka und Hirotaka Takeuchi identified cross functional teams as a success factor for the development of new products. In their HBR article „The New New Product Development Game” they described six characteristics of successfully designing products:

  1. Built-in instability
  2. Self-organizing project teams
  3. Overlapping development phases
  4. “Multilearning”
  5. Subtle control
  6. Organizational transfer of learning

Not only simple teams but cross functional ones are a key factor for successful development.

What is a cross functional team exactly?

Cross functional teams are a way of working together more cohesively, across the silos of the organizational chart, reducing hand-overs and achieving a smoother and more efficient workflow. For our clients, we usually build autonomous teams with all or the maximum of competencies needed to develop solutions valuable to the customer. It shows that it is a key success factor. Scrum is a team-based management framework. It fosters interdisciplinary and collaborative work within the organization. It’s no coincidence that the first of the four statements of the agile manifesto says: “Individuals and interactions over processes and tools.“
crossfunctional_teams
Some companies starting with Scrum in hardware development are not willing to build cross-functional teams across organizational silos right from the beginning. Within a short time one can observe the following consequences:

We recommend to be especially careful as far as the team setup is concerned. To be able to deliver value the team’s setup and responsibility should ideally mirror your product architecture based on independent modules. Means each team should be responsible for a functional module. In this case you have one team for each module of your product and you can deliver value on the entire product level at the end of each iteration.

What are the main challenges of interdisciplinary work in a cross functional team?

Responsibility and decision making
Give the team the authority it needs to get things done and move forward. Progress will slow down if the teams have to ask the management for approval at every step. As head of mechanical engineering, system engineering or electrical engineering you have to let down taking single decisions. Instead, support the team in understanding or defining transparent decision criteria. As such a stakeholder you can still challenge the team at least at the end of every sprint! If your project is not doing as well as you desire, try to figure out how you can strengthen the team. Look for solutions within the team before you start looking for solutions outside the team, without the team!
Find a common language
Teamwork is an individual skill, interdisciplinary work is another one. Team members have to learn respecting each single competence and input. As a Product Owner you encourage the team to deliver valuable results and features together. Never define single delivery where only one competence is requested. It will help the team to know each other, understand the single contribution to the whole product development. As a ScrumMaster you can support the team finding a common language by using visualization and encouraging pairing.

Team decision versus level of influence

Depending on the company’s culture or history, different functional silos might have different levels of influence. The ScrumMaster and the manager have to be careful not to transfer these power biases into scrum teams. Be careful that decisions are not a „mechanical decision“ or a „science“ decision but a team decision regarding to the product vision.
Status

Collocation

The best way to lower barriers to team communication is collocation. Without sending the whole team in the desert for the duration of the project like engineering legend Kelly Johnson of Lockheed Martin did in 1943 (see Skunk Works) you should support a maximum of collocated time. It has to be simple for the team members to meet if they want/need it.
Use a War Room or project room (Obeya in lean equivalent) to make the project visible in one place. A place for collecting all the Information and project artifacts will create a magnet for team members as well as for supporting resources and stakeholders. This place can be seen as a working room as well as a show room. Choose a room spacious enough to host your prototype or which is very close to your laboratory or prototyping facilities. In all our projects, we have at least a dedicated team room for scheduled meetings (Planning, Review, Workshops) where we gather all the main Artifacts (Vision, Backlog, Workshop results, etc.). Especially for design, architecture and interface specification invest colocated time instead of other kinds of communication. Like Donald Reinertsen said: „Never place an organization or a geographic boundary on top of a poorly characterized architectural interface.“ (Don Reinertsen: Managing the Design Factory. A Product Developers Tool Kit. Free Press, 1997)

Focus

You wish your team members to be committed, to share a sense of ownership, taking responsibility and making decisions? Strive for dedicated team members! 1 Person= 1 Team = 100%
Even with best intentions, bystanders trying to “help” the team often just create more work for it. Those who are doing the work should be making most of the decisions.  Although you probably cannot afford to have every member assigned to only one team each, the more often you can do this, the better your project is likely to perform. Be sure you have people almost temporarily (some Sprints ) in the team if their field of competence and their decision are strongly needed in this phase. Invite people to join at least the Scrum Meetings, especially the Dailys or Review Meetings. For example when you are in a phase in which you have to negotiate with suppliers and submit orders, ask the colleague of the purchasing department to join the team for a few sprints.
I made the experience how dedicated staffing greatly improved accountability and commitment because:

Although you cannot afford to have every member assigned to only one team, the more you can do this, the better your scrum team is likely to perform.
I am deeply convinced that cross-functional teams are the key to delivering value faster by reducing transaction costs, accelerating decision processes and fostering a real sense of ownership for the entire product: before losing yourself in coordination and integration activities, give it a chance from the beginning!

Scrum Spaces oder Agilität braucht Raum

Ich habe ein neues Team, ein neues Projekt, eine neue Herausforderung. Einige der Tätigkeiten scheinen jedoch auf den ersten Blick nur wenig mit den Aufgaben eines ScrumMasters, wie man ihn aus den Lehrbüchern kennt, zu tun zu haben. Ich möchte, dass mein Team sich wohlfühlt, schließlich wird es hier, im Teamraum, die meiste Arbeitszeit verbringen. Mein Ziel: Ein Raum, in dem alle Lust haben zu arbeiten.
Scrum muss gelebt werden und um etwas zu leben, muss man es spüren – jeden Tag aufs Neue. Es ist ein aufregendes Gefühl, Teil von etwas Neuem zu sein. Scrum heißt, gemeinsam an einem Ziel zu arbeiten. Dieses Wir-Gefühl soll sich auch im Arbeitsraum widerspiegeln. Eine gute Stube. Hier sitzen ALLE Entwickler zusammen. Idealerweise finden auch ScrumMaster und Product Owner in der guten Stube ein Plätzchen zum Arbeiten. An diesem Punkt kommt oftmals die Frage: „Warum denn alle zusammen? Ich habe doch mein Büro …“ Eine einfache Antwort: Face-to-face- Kommunikation. Eine Frage oder ein Problem ist im direkten Gespräch viel schneller geklärt. Ohne Telefon, ohne E-Mail, ohne Chat. Ein Problem? Wir kreieren gemeinsam die Lösung! Tasks können in einem Teamraum einfach leichter und schneller gemeinsam bearbeitet werden. Durch das gemeinsame Arbeiten werden Wissen und Erfahrung direkt ausgetauscht und die Qualität des Arbeitsergebnis steigt dadurch erheblich.
Im Agile Manifesto liest man:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Doch wie schaffe ich es als Scrum Master, diese Prinzipien in das tägliche Arbeitsumfeld meines Teams zu implementieren? Bei der Frage nach dem perfekten Teamraum für agile Teams gibt es kein Schwarz oder Weiß. Alles, was sich gut anfühlt, ist erlaubt. Teams sitzen gerne zusammen, ob in Arbeitsinseln oder in einer U-Form. Fühlt sich das Team wohl, ist es die richtige Form. Und wenn nicht? Dann nutzen wir doch einfach zehn Minuten nach dem Daily, um ein wenig zu experimentieren … agil sein … anpacken und testen.

Wie sieht unser Teamraum nun aus?

Als ich die Teammitglieder gefragt habe, was für sie wichtig ist, stand an erster Stelle das Taskboard. Das Team wünscht sich, immer einen guten Blick auf seine Aufgaben zu haben. Wichtig ist den Teammitgliedern auch, die Sitzplätze je nach Zusammenarbeit wechseln zu können.
Wir wissen, wie wichtig die gemeinsame Arbeit an einer Tätigkeit und der disziplinenübergreifende Austausch sind. Also haben wir die Trennwände zwischen den Arbeitsplätzen abgebaut und Raumteiler entfernt. Nichts, abgesehen von den Bildschirmen, steht nun den Entwicklern und ihrem täglichen Austausch im Weg. Jeder kann so mit jedem kommunizieren und arbeiten, aufstehen, Sitzplatz wechseln, alles ist erlaubt. Feste Sitzplätze schränken das agile Arbeiten für gewöhnlich ein. Daher kann die tägliche Teamaufteilung (Pairs oder MiniMobs) je nach Bedarf wechseln. Das bedeutet auch, dass sich die Sitzordnung mit jeder Anforderung ändert. Platzwechsel als ein kleiner Ausdruck von Agilität – den Blickwinkel auch auf den Teamraum einmal ändern.
Viele Teams zeichnen und teilen gerne ihre Ideen, sie wollen die Strukturen oder Abhängigkeiten ihrer Storys und Tasks sehen. Am besten funktioniert das auf Whiteboards oder Flipcharts. Hier können neue Ideen ergänzt, Optimierungen direkt eingearbeitet und am Ende alles auf einem Foto festgehalten werden. Die zu Beginn noch weißen und leeren Wände füllen sich dann im Laufe der Zeit mit zahlreichen Visualisierungen, Zeichnungen und Artefakten. So bekommt der Raum einen teamindividuellen Ausdruck (oder Anstrich). Wichtig ist dabei, auch darauf zu achten, dass kein Information-Overflow entsteht, sondern dass nur Informationen vorhanden sind, die das Team wirklich braucht.
Wenn der Teamraum groß genug ist, würde ich als ScrumMaster noch eine Time-out-Zone einführen. Bequeme Sessel, ein Sofa – Open Areas. Dieser Bereich ist ideal für ad-hoc-Meetings, so muss nicht extra ein Meetingraum gebucht werden. Auch kann dieser Open-Space-Bereich einfach für 10 Minuten kreative Pause genutzt werden. Diese kurzen Auszeiten können für die Produktivität wahre Wunder wirken.
Agile Räume sind in meinen Augen genauso wie ihre Teams: individuell und anpassungsfähig.

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

Kümmern Sie sich um Ihr Team?

Wenn ich wieder mal meinen Fokus auf die Effizienz von Teams gerichtet habe und mich darauf konzentriere, Aufgaben fertig zu bekommen, dann passiert es – so wie vor Kurzem. Eine weitaus erfahrenere Kollegin fragte mich beim Kaffee, wie es denn um den Spirit meines Teams bestellt sei? Ob es denn genug gelobt werde? Und ich komme ins Grübeln.
Nachdem ich nun schon mit sehr vielen Menschen aus vielen Bereichen gearbeitet habe, glaube ich nicht mehr an die maximale Effizienz durch das korrekte Abarbeiten eines Taskboards. Ja, ich habe eine sehr genaue Vorstellung davon, wie das Meeting ablaufen sollte, aber auch die passt sich im Laufe der Zeit an neue Varianten an, die besser funktionieren. Was wir heute noch für das absolut Richtige halten, mag uns morgen schon vollkommen überholt erscheinen. Was sich jedoch meines Erachtens nicht ändert: Das Team muss das Gefühl haben, dass ein Consultant, ein Manager oder/und ein ScrumMaster im Grunde seines Herzens das Beste für das Team will. Am Ende des Tages ist das vermutlich einer unserer am besten ausgeprägten Instinkte, die wir im Laufe unserer Evolution ausgebildet haben: Können wir dem, der neben uns steht, auch wirklich vertrauen?

Verbundenheit – die wirksamste Führung

Noch viel mehr gilt das für jene Personen, die gewollt oder ungewollt auf einem Sockel stehen – und als laterale Führungskräfte tun wir das immer, egal wie sehr wir uns zurücknehmen. Selbst die neueste Managementlehre sagt, dass es immer noch eine einzige Person braucht, die vorlebt, was zu tun ist, selbst wenn alle Hierarchien abgeschafft werden. Das Vorleben kann durchaus darin bestehen, einen Großteil der Entscheidungen vom Team treffen zu lassen.
Die Anforderungen an laterale Führungskräfte sind somit durchaus nicht ohne. Vorleben kann man nur, was man wirklich verinnerlicht hat – alles andere funktioniert nicht, denn wir Menschen sind gut darin, Lügner zu erkennen. Daher muss man sehr genau prüfen, ob man diesen Weg auch wirklich gehen will. Wenn ja, ist noch ein weiterer Aspekt zu berücksichtigen: Menschen brauchen Aufmerksamkeit und Verbundenheit. In selbstorganisierten Bereichen ist der Stresspegel am Anfang hoch. Wenn man damit anfängt, ein Miteinander zu leben, müssen alte Strukturen aufgegeben und neue erlernt werden. Vieles ist im Umbruch: Man muss zeigen, dass auf die neue Art und Weise die erhofften Ergebnisse erreicht werden können, die vorher nicht erreicht wurden. Dabei ist die Verbundenheit mit den Teammitgliedern ein zentrales Element. Hier eine kleine Checkliste für Sie, damit Sie feststellen können, ob Sie Ihren Teammitgliedern mal wieder Wertschätzung zeigen sollten:
 
Haben Sie sich heute/gestern schon bei jemandem bedankt?
In arbeitsintensiven Zeiten können wir schon mal vergessen, wirklich Danke zu sagen. Es geht nicht um ein schnelles Danke und dann ab durch die Mitte, sondern um ein ehrliches Danke, verbunden mit einem „warum“ des Danks. Das gibt uns auch Zeit, über uns selbst zu reflektieren und dabei zu erkennen, wie viele Menschen uns täglich unterstützen.
 
Haben Sie gestern/heute bereits jemandem zu seinem Erfolg gratuliert?
Es ist seltsam: Ich stelle immer wieder fest, dass es Menschen schwer fällt, diese Art von Komplimenten anzunehmen. Aber lassen Sie sich davon nicht irritieren. Sie tun jemandem etwas Gutes und zeigen, dass Sie ihn sehen und anerkennen. Im Team wird signalisiert, dass auf die jeweilige Leistung auch ehrlich gemeintes Lob folgt.
 
Haben Sie gestern/heute bereits jemandem gesagt, dass Sie seine Arbeit schätzen?
Vor Kurzem war ich spätabends gerade am Nachhauseweg und sah noch einen Kollegen am Rechner sitzen. Ich nahm mir die Zeit und sprach noch einige Worte mit ihm. Dabei sagte ich ihm, dass ich seine Arbeit wirklich schätze und er sie gut macht. Da wurde dieser Mensch, dem ich es nie zugetraut hätte, plötzlich sehr emotional und wir hatten eines der besten Gespräche überhaupt. Es war wertvoll für uns beide und hat dafür gesorgt, dass wir uns gegenseitig noch mehr schätzen. Glauben Sie mir: Solche Gespräche lassen sich nicht mit Gold aufwiegen. Die Verbundenheit, die dabei aufgebaut wird, bleibt auch in schwierigen Zeiten bestehen.
 
Haben Sie Ihrem Team in letzter Zeit Süßigkeiten mitgebracht oder Kaffee gekocht?
Ich stelle immer wieder fest, dass es die Kleinigkeiten sind, die für ein gutes Miteinander sorgen. Süßigkeiten zur freien Entnahme, Kaffee kochen, wenn kein anderer Zeit dafür hat oder am Abend gemeinsam essen gehen. Ein Taskboard kann abbrennen, Festplatten können gelöscht und Post-its vom Winde verweht werden – ein guter Team-Spirit wird auch dann noch erhalten bleiben.
 
Haben Sie zu Ihrem Team kontinuierlich Kontakt?
Das wichtigste Gut eines Menschen ist seine Zeit. Es stimmt, wir haben nur eine bestimmte Menge davon zur Verfügung und wenn wir unsere Lebenszeit mit unseren Teammitgliedern verbringen, ist es die einfachste und klarste Aussage der Welt: Es gibt nichts Wichtigeres als euch, deswegen bin ich hier mit euch. Gerade am Anfang, wenn sich ein Team formiert, ist es wichtig, dass Sie dabei sind und den Teammitgliedern helfen, Schwierigkeiten aus der Welt zu schaffen oder Feedback zu geben. Das verschafft Sicherheit und gibt den Menschen Orientierung, wo es langgehen soll und was von ihnen erwartet wird.
 
Zeigen Sie sich selbst als authentischer Mensch?
Als ich letztens am Morgen vor einem Managementworkshop aufwachte, wurde mir klar, dass wir am Tag zuvor alles Mögliche besprochen hatten: Rahmenbedingungen, Organisatorisches, Räumlichkeiten, Ziele. Nur eines nicht, und das wurde mir an diesem Morgen klar: Warum wollten wir dieses Projekt machen? Was waren unsere tiefsten inneren Überzeugungen? Ich stellte fest, dass ich wohl der Erste sein musste, der seine Überzeugungen ehrlich kundtat und wollte, dass alle zumindest darüber nachdachten (von „den anderen mitteilen“ sprach ich gar nicht). Es fiel mir nicht so leicht, in diesem Workshop, in dem es um harte Zahlen und Fakten ging, über diese weichen Faktoren zu sprechen. Aber letztendlich passierte dabei etwas, das dafür sorgte, dass eine zerwürfelte Gruppe plötzlich gemeinsam in den Tag startete und zu einem gemeinsamen Verständnis kam. Wir Menschen haben die Fähigkeit wahrzunehmen, was oder wer authentisch ist. Das macht es uns wesentlich leichter, jemandem zu vertrauen und mit ihm neue Wege zu gehen, auch wenn wir uns dabei unsicher sind.
 
Diese Checkliste ist sicher nicht vollständig und schon gar nicht so klar definiert wie ein Taskboard oder ein Burndown-Chart. Es sind aber einige Anhaltspunkte dafür, wie Sie den Kontakt zu Ihren Teammitgliedern stärken. Ich bin heute der Überzeugung, dass dieser Kontakt zu einem großen Teil maßgeblich dafür ist, ob man mit einem Team Erfolg hat.

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.

Der Testmanager in Scrum

Auf den Software Foren Leipzig im April hatten wir das Vergnügen, Kay Grebenstein, Testmanager bei unserem Partner Saxonia Systems, über den Testmanager in Scrum sprechen zu hören. Sein Vortrag war für mich deshalb so interessant, weil er uns ein Mapping der Aufgaben des Testmanagers auf die Aufgaben des Development-Teams zeigte und begründen konnte, dass Scrum-Teams tatsächlich alle Aufgaben des Testmanagers erfüllen (können). Nach den Standards des International Software Testing Boards (ISTQB) hat ein Testmanager folgende Aufgaben:

(c) Kay Grebenstein

Dabei wird zwischen strategischer Ebene – der des Qualitätsmanagers – und der operativen Ebene (Testmanager) unterschieden. Laut Grebenstein müssen wir also schauen, dass sich Scrum-Teams mit beide Ebenen befassen. Auf den ersten Blick sagt Scrum nichts darüber aus, wie getestet wird und wer dafür die Verantwortung übernehmen sollte. Sicher, es wird immer gesagt, dass in Scrum das Team testet. Aber wer trägt die Verantwortung?
Sieht man sich die Standards des ISTQB an, hat ein Testmanager Aufgaben wie
• den Aufbau eines Testteams,
• das Erstellen eines Testkonzepts,
• Erstellen der Testfälle durch die Tester,
• Erstellen und Durchführen der Testfälle durch das Testteam,
• u.v.m. (siehe unten)

(c) Kay Grebenstein

Wie passt dazu nun ein agiler Testprozess, der all das ja nicht vorschreibt? Grebenstein  zeigte uns dazu zunächst, wie in einem Scrum-Team getestet wird. Und richtig, alle von der ISTQB beschriebenen Aufgaben werden vom Team tatsächlich erfüllt.

(c) Kay Grebenstein

Die Tester im Team – oder besser das Entwicklungsteam selbst – wird nun mit diesen Dingen konfrontiert und die Kompetenz der Tester wächst, weil sie die gesamte Testpyramide abdecken müssen. Das bedeutet, dass die Tester nun sowohl für Unit-, Service- und Systemtest zuständig sind und das Testen, die Domain und das Codieren beherrschen müssen, da sie alle Tests auch automatisieren sollten, wenn nicht sogar müssen.

(c) Kay Grebenstein

Schaut man sich die Aufgaben (siehe erste Abbildung) noch einmal an, ist nun die wichtige Frage, wann diese Aufgaben durchgeführt werden. Dabei werde auf der obersten Ebene – bei agilen Transitionen – die Aufgaben der strategischen als auch der operativen Ebene von den Scrum-Teams durchgeführt. Und hier das dazugehörige Mapping:

(c) Kay Grebenstein

 

(c) Kay Grebenstein

(c) Kay Grebenstein

Genau betrachtet ist nicht viel nötig, um alle Aufgaben gemäß ISTQB durchzuführen. Dazu müssen wir nur geeignete Meetings oder Artefakte bereitstellen oder bestimmte Verfahren wie exploratives Testen tatsächlich durchführen. Dabei hilft es, die drei Stadien Testkonzeption, Umsetzung und Koordination auseinanderzuhalten und getrennt voneinander anzuschauen.
Alles in allem war der Vortrag von Kay Grebenstein ein Gewinn für die agile Community, weil er es dem ScrumMaster ermöglicht, den Qualitätssicherungsabteilungen fundiert entgegenzutreten und in skalierten Umfeldern (Scaled Agile) zu zeigen, dass Scrum alle notwendigen Anforderungen der ISTQB erfüllt.
Der Vortrag war natürlich ausführlicher, als ich es hier nacherzählen kann. Ich bin sicher, Saxonia Systems hilft bei Fragen mit Rat und Tat. Oder schickt mir eine Mail, ich kümmere mich dann drum.
Noch ein wenig Werbung in eigener Sache: Das nächste Treffen der User Group “Agilität in der IT” der Softwareforen Leipzig findet im November 2015 statt und beschäftigt sich mit der Frage: Braucht Agilität Führung? Nähere Informationen findet ihr Softwareforen Leipzig

Hilfe, die Koffer sind weg oder ein tolles Beispiel zum Thema Commitment

Müde, aber gut gelaunt landet die Boris-Gloger-Marathonstaffel nach einem 2-Tages-Retreat in Baden-Baden am Flughafen Wien. In Gedanken sind wir schon bei unserem nächsten Abenteuer: dem Vienna City Marathon. Wir warten und warten und warten. Aber unsere Koffer tauchen einfach nicht auf. Alle 11 Trolleys (kaum zu übersehen, weil orange), Taschen und Koffer sind weg. Es kommt, was kommen muss: Auch Samstag Morgen sind sie noch immer nicht da. Um 11:00 dann die Nachricht der Airline: “Wir haben keine Ahnung, wo die Koffer sind.” Natürlich liegt die gesamte Ausrüstung in den Koffern: Fünf von uns stehen jetzt ohne Laufschuhe und ohne Laufdress da. Mal abgesehen davon, dass sie auch sonst nur mehr das dabei haben, was sie gerade am Körper tragen. Alles weg!
Jammern hilft nicht, wir wollen trotzdem am Sonntag gemeinsam die Staffel laufen. Also nichts wie los auf die Mariahilfer Straße, um den Umsatz sämtlicher Sportgeschäfte kräftig anzukurbeln. Wir stellen einen neuen Rekord im Speedshopping auf, einige fliegen am Sonntag nach dem Marathon schließlich auch gleich an ihren Einsatzort weiter. Abends ist der Ärger zwar nicht ganz vergessen, aber bei einem gemeinsamen Bier doch wieder etwas weniger geworden. Alle sind so weit mit Schuhen und Laufklamotten ausgestattet, Zahnbürsten haben sich auch gefunden – leider muss Sabrina aber auf den Start verzichten. Ohne Spezialschuheinlagen kann sie nicht laufen und die Einlagen liegen im Koffer, der … ja.
Sonntag um 8.00 treffen wir uns, Hélène und Sabrina übernehmen den Support. Gemeinsam geht es zum Start. Karl und ich sind die Startläufer, gespannt wartet das ganze Team mit uns. Die Übergabe an Kristina K. läuft tadellos, Cathleen sprintet später und verblüfft uns alle. Als Wilfried an Stefan übergibt, versucht Stefan, Kristina B. noch einzuholen, aber unsere Staffel 2 gewinnt überlegen mit 5 Minuten Vorsprung auf unsere Staffel 1. Aber das war uns allen völlig egal. Wir haben als Team, die Läufer mit unseren Betreuern bewiesen, was Commitment ist: Gemeinsam als Team durch die Ziellinie zu gehen, auch wenn es rundherum gerade nicht ideal läuft. Jeder ist an diesem Wochenende an seine körperlichen und nervlichen Grenzen gegangen. Nächstes Jahr sind wir wieder dabei beim Vienna City Marathon 2016!
Marathon_2015

Der alles entscheidende Unterschied im Commitment

Was ist besser für ein Team? Wenn es 9 von 11 Stories oder 9 von 7 Stories schafft?
Richtig gelesen: Ich rede über die gleiche Anzahl abgearbeiteter Stories. Der einzige Unterschied ist, dass ein Team einmal 2 Stories mehr absolviert als es committet hat, während es im gegensätzlichen Fall 2 Stories weniger geschafft als committet hat. Angenommen, dass die Storypoints dieselben sind, wäre das Ergebnis doch eigentlich das Gleiche, oder? Nur ist das leider nicht so. Warum, ist recht einfach erklärt.

Übercommitment und seine Folgen

Haben Sie schon einmal ein Team erlebt, das beim Review vor versammelter Mannschaft sagen musste: “Hey Leute, es tut uns leid, aber wir konnten unser Commitment nicht erfüllen.” Für mich war es bisher meistens ein deprimierender Anblick. Hebt dann noch ein Manager mit Inbrunst die fehlerhafte Leistung hervor, fällt das Team geradewegs in das Motivationsloch des Jahres. Dann schnappen Sie sich am besten die Angeprangerten und gehen mit ihnen irgendwo hin, wo sie ihren Frust rauslassen und alles vergessen können – damit vielleicht, so halbwegs und eventuell wieder ein Start möglich wird. So oder so: der Schaden ist passiert, die Scherben können so gut wie möglich aufgesammelt werden, aber im Großen und Ganzen wars das für die nächsten Tage mit der maximal möglichen Leistungsfähigkeit.

Untercommitment und seine Folgen

Ganz im Gegensatz dazu steht das Team, das mit stolzgeblähter Brust verkünden kann: “Hey Leute, wir haben nicht nur unser Commitment erfüllt, wir haben Euch sogar noch mehr geliefert. Es war uns ein Volksfest.” Abgang von der Bühne unter donnerndem Applaus. Wie geht wohl dieses Team in den nächsten Sprint? Es ist stolz auf das, was es geschafft hat. Die Teammitglieder haben ihr Baby (das Produkt) weitergebracht und durften dem Management zeigen, was sie können. Wenn ich von etwas überzeugt bin, dann davon, dass dieses Team sein Bestes geben wird, um im nächsten Sprint noch besser zu sein und mehr zu können.
Der Grund dafür ist relativ einfach: Bekannterweise funktioniert positive Motivation wesentlich besser als Bestrafung. Falls Sie das für ein Gerücht halten, rufen Sie beim nächsten Casino an und fragen Sie nach, warum so viele Menschen weiterspielen, obwohl sie selten gewinnen, aber ganz oft verlieren. Die positive Motivation durch einen Gewinn – egal wie klein er ausfallen mag – hebt den Bestrafungseffekt des Verlierens (ebenfalls egal, wie viel Geld man schon verspielt hat) wieder auf. Dieses Prinzip funktioniert so gut, dass Casinos hervorragend davon leben können. Höchste Zeit also, diesen Effekt dafür zu nutzen, um etwas Positives für unsere Unternehmen und die Menschen darin zu tun. Denn es kann doch jeder nur gewinnen, wenn ein Team motiviert ist, gerne zur Arbeit kommt und das Management mehr bekommt, als es erwartet hat, oder?
Was bedeutet das praktisch? Versuchen Sie also nicht, Ihr Team dazu zu bewegen mehr zu committen, wenn Sie den Eindruck haben, dass es untercommittet hat. Lassen Sie dem Team stattdessen die Freude, mehr Arbeit dazunehmen zu können, sein Commitment damit zu übertreffen und das auch kommunizieren zu können. Das Team wird sich mit mehr Leistung bedanken, denn es will zeigen, was es kann – und das nützt auf Dauer der Organisation als Ganzes.

Mit Tests die Kostenkurve kriegen

Bei einem Gespräch unter Kollegen kam wieder einmal das Thema „Qualität der Software“ zur Sprache. Jeder von uns hatte seine eigene Geschichte aus seinem Projekt mitgenommen und mit den anderen geteilt. Wir waren verblüfft, wie schwer es Software-Teams noch immer fällt, Software regelmäßig und funktionstüchtig zu liefern. Um mit gutem Beispiel voranzugehen, entschieden wir daher, diesen Beitrag im sogenannten “Pair Blogging” entstehen zu lassen. Was bedeutet das? Zwei Kollegen arbeiten nebeneinander auf ihren Notebooks in einem Google-Dokument und schreiben was das Zeug hält. Und damit zum eigentlichen Thema.
Wir haben das Gefühl, dass auch heute noch viele Unternehmen bzw. das Management die anfänglichen Investitionskosten für einen guten Softwareauslieferungs-Prozess scheuen. Bei Legacy-Systemen ist die Angst vor einem langen und teuren Migrationsprojekt oft noch viel größer. Die Verlockung, schnell Software ohne wirkliche Achtung der Qualitätsgrundsätze zu entwickeln, rächt sich spätestens bei den ersten Anforderungsänderungen der Kunden. Denn zu diesem Zeitpunkt kippt das Verhältnis der anfänglichen Investitionskosten gegenüber den immer stärker steigenden Kosten für jede einzelne Änderung. Das folgende Diagramm, das die “Cost of Change”-Kurven von Berry Boehm, Alistar Cockburn, Scott Ambler und Kent Beck abbildet, macht dieses Phänomen deutlich sichtbar.
Screenshot 2014-11-28 10.03.18
Dabei ist es weder notwendig noch sinnvoll, für die Einführung von Testautomatisierung oder Continuous Delivery ein großes Projekt zu starten. Ein erfolgsversprechendes iteratives Vorgehen zeichnet sich durch einen schnellen Return on Investment und geringe Risiken aus. In kleinen Schritten immer genau jenen Teil verbessern, in dem die Schmerzen am größten sind. Welche Komponente sorgt für die meisten Fehler im Test? Diese sollte mit automatisierten Tests überprüft werden, und erstmal nur diese. Wo läuft das Deployment immer wieder schief? Für genau dieses System sollte das Deployment automatisiert werden. Solche Investitionen zahlen sich sofort aus, und wir lernen gleichzeitig für den Umgang mit dem nächsten Problem. Indem man immer das akut größte Problem löst, entsteht Stück für Stück ein Rahmen für agile Softwareentwicklung.
Teams benötigen dafür folgende drei Rahmenbedingungen:

  1. Verantwortungsbewusstsein für Qualität und Lieferung
  2. Die Freiheit und die Freiräume, sich selbstorganisiert darum kümmern zu dürfen
  3. Das nötige Können und Wissen

Das Management ist gefragt, diese Rahmenbedingungen zu schaffen. Die Experten für die Etablierung agiler Entwicklungsmethoden seid jedoch ihr in den Teams – fangt einfach mit dem ersten kleinen Schritt an und erfreut euch am Ergebnis eures Schaffens.
Der Beitrag entstand im Pair Blogging mit Frank Janisch.

Die Sache mit der Freiwilligkeit

Ich war diesen Sommer in London auf Urlaub. Und ja so wie es sich für das Londoner Wetter gehört, gab es auch im Sommer viel Regen. Nun gut, was tun im Regen? Am besten in eines der tollen Museen gehen. Die große Überraschung: Man kann die einige Stockwerke umfassenden Standard-Ausstellungen gratis besuchen! Am Ausgang ist es jedem selbst überlassen, ob er an das Museum Geld spenden möchte. Alle Mitarbeiter betonen immer wieder, dass man völlig freiwillig spenden kann und keinerlei Zwang herrscht.
Für mich als Wienerin war das tatsächlich etwas ungewohnt. Drei Museen später leuchtete es mir aber immer mehr ein: Ich hatte in den letzten drei Museen viel mehr gespendet als den Richtwert, den die Museen vorgeschlagen hatten. Ich wusste nicht so richtig warum, aber ich genoss jede Ausstellung viel leichter und ungezwungener (ich hatte ja auch keine Unmengen für den Eintritt gezahlt). Beim Rausgehen spendete ich wegen der guten Erfahrung und der mir zugestandenen Freiwilligkeit also viel mehr.
Das Thema der Freiwilligkeit taucht immer wieder in vielen Scrum-Teams auf. Soll es eine Anwesenheitspflicht geben für die Dailys, Sprint Plannings, Reviews und Retrospektiven? Viele sagen, es herrsche absolute Anwesenheitspflicht, jeder habe zu erscheinen, da sich das Team sonst nicht selbst organisieren könne. In vielen Teams werden Einladungen für alle Meetings versendet und es wird erwartet, dass man teilnimmt. Da ist von Freiwilligkeit keine Rede.
Vor einigen Wochen habe ich einen Kollegen getroffen, der mir von einem Team erzählte, mit dem er anfangs als ScrumMaster Schwierigkeiten hatte. Das war für mich nichts Überraschendes, bis er erwähnte, er hätte den Teammitgliedern von Anfang an gesagt, sie müssten nicht in die Meetings kommen. Sie würden zu 100 % auf Freiwilligkeit beruhen. In der Runde herrschte Verwunderung: Wie sollten denn die Meetings funktionieren, wenn die Leute keine Lust hätten und dann auch noch alles auf ihrer Freiwilligkeit beruhte?
Der Kollege meinte nur, dass innerhalb eines Sprints alle Teammitglieder zu den Dailys dazugestoßen seien. Sie wären pünktlich gewesen und hätten alle Scrum gemacht – bis auf einen. Dieses eine Teammitglied nahm auch nach zwei Sprints nicht an den Dailys teil, sah sich das Taskboard an und beendete seine Storys zeitgerecht. Er nahm aber nur an den Meetings teil, an denen er teilnehmen wollte. Im dritten Sprint nahm er am Daily teil, in dem er bisher nur zugesehen hatte. Im vierten Sprint schrieb er bereits eigene Tasks. Im fünften Sprint half er dem PO mit komplexeren Storys, die in seinem Fachgebiet lagen. Inzwischen sind fast sechs Monate vergangen, das komplette Team nimmt an allen Meetings teil und organisiert sich selbst ganz freiwillig.
Man muss Menschen manchmal etwas mehr Vertrauen schenken, als man vermutlich möchte, aber es zahlt sich aus. Alle Museen in London können sich durch die freiwilligen Spenden ihrer Besucher erhalten.
Jeder spendet so viel wie er kann oder will – und siehe da, es ist möglich.

Skalierung aus der falschen Richtung

Wer darüber nachdenkt, wie man Scrum in großen Projekten macht, fängt meistens mit dem klassischen Bild an: Der Product Owner erstellt das Backlog und dann wird es priorisiert … bla, bla, bla – das ist euch allen mittlerweile klar. Wenn ich aber darüber nachdenke, wo die meisten Features herkommen, wer die Fehler findet, wer sich im Review mit dem Kunden auseinandersetzt, dann wird schnell klar, dass die meisten Backlog Items von den Entwicklungsteams geschrieben werden. Sie müssen sowieso von ihnen entwickelt werden. Schaut man in den Design Thinking Prozess von IDEO, dann wird auch dort sehr deutlich, dass das Entwicklungsteam sich selbst überlegt, was der Kunde am Ende benötigt.

Die Entwicklungsteams selbst erstellen die Backlog-Einträge und priorisieren sie auch selbst. Obwohl ich mir das Video über IDEOs Shopping Cart bestimmt 100 Mal angeschaut habe, hat es nicht wirklich Click gemacht. Mir fällt sogar auf, dass ich in jedem Training immer wieder sage, dass das Team die eigentlichen Backlog Items schreibt, aber – wie gesagt – das Klick, das Heureka, fehlte. Dabei lag es schon seit Jahren auf der Hand. Der Product Owner war in den meisten Projekten damit überfordert, wissen zu müssen, was das richtige Feature ist. Er weigerte sich auch oft, das Backlog zu priorisieren und wusste häufig nicht, ob die Kunden das Feature wirklich wollen. Er brauchte immer das Entwicklungsteam, damit er die richtigen Entscheidungen treffen konnte. So weit so schön, wir haben dann immer tolle Erklärungen gefunden, warum der Product Owner, obwohl er keine Ahnung von der Materie hat, dem Entwicklungsteam sagen müsste, was es zu entwickeln hätte.

Dieses Bild hat ausgedient – Skalierung funktioniert so nicht!

Das geht nur so lange gut, wie man nicht skalieren muss. Dann fällt das ganze Kartenhaus zusammen – in einem solchen Fall mit Product Ownern zu arbeiten, die sich inhaltlich nicht auskennen und daher keine Entscheidungen treffen können, führt zu den gleichen Effekten wie im klassischen Projektmanagement: niemand will Entscheidungen treffen. Der Klick kam bei mir, als mich ein Kunde etwas fragte. Dafür bin ich ihm wirklich dankbar.
In diesem Projekt hatten wir es mit 150 Beteiligten – Wissenschaftlern, Entwicklern, Programmierern, Managern – zu tun. Wir rangen mit tausenden kleinerer und größerer Probleme, und wir machten das durch das Aufstellen von Backlogs transparent. Weil das Management die Sicht auf das Ganze haben wollte (was verständlich und nachvollziehbar ist), tauchte die Frage auf, ob man denn so etwas wie ein Master Backlog habe und ob nicht mit entsprechenden Filter-Funktionen in JIRA sichergestellt werden könne, dass alles wirklich abgearbeitet wird? Die gängige Erklärung ist: Sicher, das geht! Das findet sich auch in allen vorhandenen Bildern zur Skalierung von Scrum. „Aber wieso eigentlich?“, fragte ich meinen Kunden. Das Master Backlog sei doch keine Input Queue, sondern bilde nur die Realität ab. Wir müssten unbedingt vermeiden, dass der Product Owner des Master Backlogs dieses priorisiert. Die Verwunderung war groß, denn jedes Bild in Scrum suggeriert, dass die Macht beim Product Owner liegt. Er füllt den Sprint. Der Product Owner kann dieses Backlog aber gar nicht in eine korrekte Reihenfolge bringen. Es sind zu viele Einträge. Der Product Owner müsste bei einem großen Projekt gottgleich alles beantworten können. Solche Typen gibt es, sie sind aber sehr selten und ihr Gewicht wird in Gold aufgewogen.
Gleichzeitig gibt es dennoch – ob der Product Owner es kann oder nicht – zwei Fragen zu lösen:

In großen Projekten ist darüber hinaus drittens auch noch die Frage entscheidend, ob man überhaupt alle Abhängigkeiten zwischen den Teams berücksichtigt hat.
Können die Product Owner diese Fragen nicht selbst lösen, dann müssen sie wohl oder übel die Teams selbst fragen. Doch was, wenn die Product Owner es ihren Teams nicht zutrauen, diese Fragen zu beantworten? Sehr oft haben die Product Owner damit auch recht. Häufig gibt es externe Kollegen in den Teams und die wissen gar nicht all das, was die Product Owner wissen. Sie können es noch gar nicht wissen. Dann bleibt nur, die wenigen Experten in den Teams zu fragen, und schon hat man einen Infinite Loop geschaffen.

Mit Selbstorganisation hat das gar nichts zu tun – nur mit noch mehr Kontrolle

Der Wahn, alles müsste transparent und rückverfolgbar sein, auch nach Monaten oder Jahren müsste noch klar sein, welche Zeile Code von welchem Entwickler geschrieben wurde – dieser Wahn ist heute von vielen Entwicklern umgesetzt worden. Dank JIRA, Bamboo, Team Foundation Server und anderen Tools lässt sich ja alles rückverfolgen. All das hat zu noch mehr Kontrolle und noch weniger Selbstverantwortung der Kollegen geführt. Das Schreiben eines JIRA-Tickets ist einfach – da kann ich als Teammitglied schnell das Denken abschalten, denn es wird ja von einem anderen entschieden, ob ich dann daran arbeiten soll. Wieder wird die Verantwortung nach oben delegiert. Die Entscheidung liegt erneut beim Product Owner, der aber nicht für jede Kleinigkeit geradestehen kann. Wo kommt dieser Anspruch eigentlich her? Denn das sollte er in Scrum gar nie können. Nonaka und Takeuchi hätten nicht beschrieben, wie man einen interdisziplinären, cross-funktionalen Management-Prozess entwickeln kann (den Jeff Sutherland zu Scrum ausgebaut hat), wenn sie dabei gleichzeitig an volle Kontrolle gedacht hätten.
In vielen Scrum-Skalierungsansätzen wird aber genau das Gegenteil propagiert. Was mich dabei erstaunt: In Deutschland sind die Modelle, die das Top-Down-Prinzip in der Skalierung von Scrum erklären (SAF) beliebter als in den USA. Hier werden mehr Bücher dazu gekauft, als in den USA (sagt mein Verlag). Da ist was faul. Übrigens funktioniert es auch nicht. Was gut funktioniert: Skaliert wird durch Abgeben der Verantwortung bei gleichzeitiger Standardisierung, und die Berater verdienen damit viel Geld.
Wenn die Backlogs nicht vom Product Owner und seinen Product-Owner-Kollegen aufgestellt und in die „richtige“ Reihenfolge gebracht werden, wer macht es dann? Genau, die Entwicklungsteams! Skalierung ist dann ganz einfach, denn diese Kollegen wissen sehr gut, was als Nächstes getan werden muss. Sie wissen, ob es heute sinnvoller ist, den Defect zu fixen, oder das nächste Feature anzufangen. Sie haben den Kontakt zu den Usern und können viel besser verstehen, was dort gebraucht wird. Können wir aber den Teams trauen? Wie verhindern wird dann Wildwuchs? Wie verhindern wir, dass Dinge gemacht werden, die niemand braucht? Wie verhindern wir, dass die Entwickler nicht businessgetrieben arbeiten, sich in Lösungen verfangen, einer interessanten Idee nach der anderen nachgehen?
Meine provokante These: Lassen wir doch einfach zu, dass es Schwund und Fehlentwicklungen gibt. Es ist viel billiger, als alles überwachen zu wollen. Die teuren Management-Runden, in denen sich Product Owner erklären lassen, was das Richtige ist, ergeben wenig Sinn. Scrum selbst ist das Korrektiv. Wenn eine Entwicklungsmannschaft nicht liefert, keine Lösungen, keine Ergebnisse, keine neuen Erkenntnisse, wenn sich die Entwicklungsteams ums sich selbst drehen, dann wird das doch im Review sichtbar. Dann kann das Management doch eingreifen. Aber es in die Teams hinein zu kontrollieren, das funktioniert nur bedingt. Dabei wäre das sogar möglich: Wer Qualitätsmanagement als Lernprozess versteht und gefundene Fehler nicht als Versagen von Menschen, sondern als gegebene Realität sieht, wer vergossene Milch als Verlust abschreibt und nach vorne schaut, der kommt auch damit klar, dass Nicht-Liefern eine Information ist. Eine Information ans Management, dass gehandelt werden muss.
Aber das erklärt noch nicht, wie Firmen nun selbstorganisiert skalieren können, oder doch? Ich denke schon! Der Trick besteht darin, sich selbst steuernde, cross-funktionale Teams zu etablieren, die innerhalb eines Kontexts nur auf eine einziges Ziel hinarbeiten können. Dieses Ziel wird durch die Vision geschaffen, doch der Weg dahin bleibt den Teams überlassen. Die Teams müssen sich standardisierte Schnittstellen überlegen. So wie das in der Bauindustrie und in der Elektroindustrie doch auch funktioniert. Diese Übergaben werden trainiert, geschult und zertifiziert. Diese Standards zu verändern ist mühsam, aber so können funktionierende, vielleicht nicht immer perfekte Lösungen gefunden werden. Die Rahmenbedingungen werden von der Organisation gesteckt und die Teams so lange darauf geschult, bis sie die Rahmenbedingungen verstanden haben. Teams, die liefern, werden belohnt und die anderen werden lernen, was erfolgreich ist und werden es kopieren. Gleichzeitig überlässt man mehr und mehr Verantwortung den kleineren Funktionseinheiten, den Teams. Ist das perfekt? Ich weiß es nicht, aber Amazon und Google, Facebook und 3M fahren mit diesem Ansatz ziemlich gut.

Multikulti – vom Umgang mit Internationalität in Projekten

Wir reden immer davon, dass es bei verteilten, global verstreuten Teams um das Verständnis geht, dass Amerikaner eine andere Kultur als die indischen Kollegen haben (Stichwort Skalierung). Es geht also immer darum, die unterschiedlichen Nationalitäten im Blick zu haben und deren Kultur zu verstehen. Bei meiner Arbeit mit internationalen Teams bin ich zu einer anderen Schlussfolgerung gelangt: Internationale Firmen haben selbst eine Kultur. Sicher, es gibt Einflüsse – Lokalkolorit. Aber die Kultur eines Unternehmens ist viel stärker als die des Landes.
Schaut man genau hin, dann sind die auftretenden Probleme oft nicht der unterschiedlichen Landeskultur zuzusprechen, sondern der Tatsache, dass sich zugekaufte Firmen nicht in den internationalen Konzern eingliedern lassen. Klar, Amerikaner ticken ein wenig anders als Deutsche – aber dass die Firma zugekauft wurde, eine andere Firma war, eine andere Art des Umgangs miteinander hatte, ist viel wichtiger und hat größeren Einfluss auf das Selbstverständnis des Einzelnen in einem Unternehmen als seine Nationalität.
Besonders deutlich wird das, wenn man Scrum in Hardware- oder Medizintechnik-Projekten einführt und cross-funktionale, multidisziplinäre Teams aufbauen will: Da bemerkt man plötzlich, dass nicht nur Tester und Entwickler in einer Abteilung unterschiedlich funktionieren, sondern dass es vollkommen andere Weisen gibt, die Welt wahrzunehmen. Wenn Ingenieure auf Biologen oder Chemiker treffen, wenn Metallfacharbeiter sich mit Elektrikern unterhalten sollen, wenn Grafiker sich mit Softwareentwicklern unterhalten, dann treffen die verschiedensten Weltbilder aufeinander.
Das wäre ja nicht weiter tragisch, wenn sich alle darüber im Klaren wären, entsprechend viel Zeit für den gemeinsamen Abgleich einplanen würden und das Management verstehen würde, dass es hier zu Konflikten kommen muss. Doch auch das Management hat natürlich seine blinden Flecken. Einige von ihnen waren vielleicht Ingenieure und sehen die Welt von ihrer Warte, andere sind Soziologen, Biologen oder Chemiker. Da wird oftmals gar nicht verstanden, was der andere meint oder warum er diesen und nicht jenen Zugang wählt.
Das alles sind lösbare Probleme und genau das ist die Aufgabe von ScrumMastern. Doch was passiert jetzt: Diese Teams sollen sich nicht nur aus unterschiedlichen Disziplinen, sondern auch noch aus unterschiedlichen Nationen an unterschiedlichen Standorten zusammensetzen. Vielleicht aus der Not heraus, weil es gar nicht anders geht. Nun wirken oft die Kräfte des Separatismus: Die Vertreter jeder Disziplin verstehen sich untereinander besser als mit den anderen. Sind diese auch noch verteilt, entsteht schnell ein Abwehrhaltung gegen die Kollegen am eigenen Standort, wenn dieser von einer anderen Disziplin ist und in der Minderheit. Oft nimmt man sich nicht die Zeit, sich wirklich kennenzulernen. Die ScrumMaster haben oft gar keine Chance – denn sie sind nicht vor Ort, sie steuern ihre Teams mit Hilfe von Tools und einem Video Conference Call. All das sind wirklich harte Bedingungen. Es wird noch schwerer werden, garantiert. Es wird immer öfter zu Konstellationen dieser Art kommen.
Doch eines wird sich durchsetzen: der Wille zu liefern. Der Druck auf Unternehmen, die so arbeiten (müssen), wird so hoch werden, dass sie sich etwas einfallen lassen werden. Sie werden Teams temporär zusammenziehen, sie werden wieder Menschen nahe zusammenbringen. Wenn Firmen wie Google und Facebook das können, wenn Apple in Cupertino ein Gebäude genau aus diesem Grund heraus baut, damit alle zusammen sind, dann sind diese Firmen schon längst wieder auf dem Weg, die Internationalisierung zugunsten der Produktivität zu reduzieren.
Die Voraussetzung dafür, dass dies gelingen kann: Eine gute Führung. Separatismus, das Auseinanderbrechen von Teams, kann sehr einfach verhindert werden – durch gute Führung. Durch eine Führung, die innerhalb des Teams, innerhalb der Abteilung und innerhalb der Firma die „gleiche“ Kultur schafft. Die gemeinsame Firmenkultur ist in der Lage, die Menschen zum Zusammenarbeiten zu bringen und Ungleichheiten vergessen zu machen. Die Aufgabe von Führungskräften wird schwerer werden. Scrum kann die Themen schneller ans Licht bringen. Lösen müssen es die Beteiligten zusammen.

Scrum in der Medizintechnik: Wie stelle ich ein erfolgreiches Team zusammen?

Auch in stark regulierten Branchen wie der Medizintechnik ist es möglich, Produkte mit Scrum zu entwickeln – das hat sich mittlerweile von den IT-Abteilungen deutscher Dienstleistungsunternehmen über den innovativen Mittelstand bis in die großen Konzerne durchgesprochen*. Aber wo anfangen, wenn die Entscheidung für Scrum einmal gefällt wurde? Der Erfolg Ihres Projekts steht und fällt mit dem Team.
Scrum, richtig gelebt, bietet Ihnen die Möglichkeit, sämtliches Know-how, das Sie für die Entwicklung Ihres Produkts benötigen, in einem Team zu bündeln. Auf diese Weise lassen sich zusätzliche Aufwände und Redundanzen an Übergabepositionen minimieren und gleichzeitig dringend benötigtes Wissen beinahe automatisch auf mehrere Köpfe verteilen.
baseball-74003_640

Herausforderungen für die Medizintechnik

Für die Hersteller medizintechnischer Geräte bedeutet das allerdings nicht nur, Anwendungsentwickler und Tester zusammenzusetzen. Zu der ohnehin schon komplexen Aufgabe, Hardware und Software miteinander zu kombinieren, kommt hinzu, dass konstruierte Teile bestellt, Risikomanagement-Checklisten abgearbeitet und vor allem regulatorische Anforderungen erfüllt werden müssen. Neben Hard- und Softwareentwicklern sowie Konstrukteuren brauchen Sie in Ihrem Team also auch noch einen Einkäufer, jemanden aus der Produktdokumentation und eine Person, die sich mit den regulatorischen Anforderungen auskennt.

Pilotteams nicht als Wetterfrösche missbrauchen!

Viele Unternehmen treffen die Entscheidung, Scrum zunächst in Pilotprojekten auszuprobieren, um die Organisation nicht zu überfordern und ein Gefühl dafür zu bekommen, ob das funktionieren kann, oder nicht. Der Gedanke, die Organisation nicht zu überrumpeln, ist nachvollziehbar, und das Aufsetzen einer Pilotgruppe auch empfehlenswert.
Aber: Jedes Pilot-Team wird früher oder später an strukturelle Grenzen stoßen, vor allem wenn die Abteilungen, die den Teams zuarbeiten, nicht entsprechend geschult sind. Insbesondere wenn es um Anforderungen „aus dem Feld“ oder seitens der Regulierungsbehörden geht, kann die Integration entsprechender Know-how-Träger in ein Scrum-Team sehr viel Zeit sparen. Heißt das, mein QM – Mitarbeiter ist jetzt 100% der Zeit im Scrum-Team? Nicht unbedingt.

Verantwortungsbewusstsein schaffen

Allein das Commitment „entwicklungsfernerer“ Kollegen, regelmäßig zu Meetings wie Sprint Planning, Daily oder Review zu erscheinen, wird einen großen Beitrag zu mehr Effizienz Ihrer Scrum-Teams leisten.
Bei einem unserer Kunden in der Laborautomatisierung gibt es beispielsweise einen Projekteinkäufer, der regelmäßig die Dailies mehrerer Scrum Teams besucht und somit für das Team stets zu verlässlichen Zeitpunkten als Ansprechpartner zur Verfügung steht, sollte es beispielsweise Rückfragen zu Lieferzeiten geben. Und auch für die Arbeit des Projekteinkäufers ergeben sich durch die Unmittelbarkeit viele Vorteile. So bekommt er schnell ein Gefühl für die Dringlichkeit sowie über mögliche Zusammenhänge einzelner Bestellungen.
Auch bei der Erstellung von Bedienungs- oder Servicehandbüchern lassen sich eine Vielzahl von Verzögerungen und doppelten Arbeitsschritten durch die rechtzeitige Einbindung entsprechender Kollegen vermeiden. Schaffen Sie ein Bewusstsein dafür, dass Ihr Projekt nur durch das Zusammenwirken aller Parteien erfolgreich werden kann und das Scrum hierfür den notwendigen Rahmen bietet. Haben Sie die Rahmenbedingungen einmal abgesteckt und kommuniziert, werden sich Ihre Teams so aufstellen, wie sie es für eine anwenderfreundliche und normgerechte Produktentwicklung brauchen.
*Sowohl der Technical Information Report TIR 45:2012 der AAMI (Association for the Advancement of Medical Instrumentation ) als auch die Prozess-Norm IEC 62304 geben Herstellern explizit die Freiheit, ihre Produkte so zu entwickeln, wie sie es für richtig halten – solange die Produktsicherheit und -qualität gewährleistet bleiben.

Cross-funktionales Arbeiten – wie geht das?

Über Apple ist in den letzten Jahren so viel geschrieben worden, dass in der Flut an Informationen nur noch wenige wirklich neue Erkenntnisse aufwarten. Und doch: Auf der Webseite Co.Design ist kürzlich ein aufschlussreiches Kurzportrait über Apples Designkultur erschienen. Der Bericht stützt sich auf Mark Kawano, der sieben Jahre lang als Designer für Apple arbeitete.
Die Kernaussage ist: Apples Designkultur ist nicht auf die Herrschaft besonders begabter Designer zurückzuführen. Sie beruht vielmehr auf einer Ausrichtung des gesamten Unternehmens auf gutes Produktdesign. Bei der Entwicklung neuer Produkte sind Designer und Entwickler so in der Lage, am gleichen Strang zu ziehen:
“For the most part, Apple didn’t employ specialist designers. Every designer could hold their own in both creating icons and new interfaces, for instance. And thanks to the fact that Apple hires design-centric engineers, the relatively skeleton design team could rely on engineers to begin the build process on a new app interface, rather than having to initiate their own mock-up first.”
In Scrum sprechen wir in diesem Zusammenhang von cross-funktionalem Arbeiten: Wie in einem Operationssaal arbeiten Spezialisten Hand in Hand. Jeder hat andere Aufgaben und auch Ziele – und trotzdem weiß jeder zu jedem Zeitpunkt, was der andere gerade macht und wo er welche Unterstützung braucht.
In der Produktentwicklung gibt es diese Spezialisierung ebenfalls: Disziplinen wie Design, Konstruktion, Qualitätsmanagement, Einkauf, Marketing und Vertrieb sind normalerweise in verschiedenen Abteilungen untergebracht. Innerhalb von Produktentwicklungsprojekten kommen die Abteilungen zwar punktuell zusammen (etwa beim Erreichen von Meilensteinen), doch findet keine intensive Zusammenarbeit wie im OP-Saal statt. Das führt häufig dazu, dass jede Disziplin ihren eigenen Zielen folgt und sich nicht genügend austauscht:

Dass jede Disziplin ihren eigenen Zielen folgt, ist völlig normal. Doch führt ein Mangel an Zusammenarbeit dazu, dass aus Unkenntnis über die Ziele der anderen kein gemeinsamer Grund entstehen kann. So haben wir die berüchtigten Silos, in denen nur noch lokal optimiert wird.

Das Team als Keimzelle der cross-funktionalen Zusammenarbeit

Mit der Schaffung von Scrum-Entwicklungsteams ist formal eine Instanz geschaffen, in der die verschiedenen Spezialisten zusammen kommen. Und es gibt auch einen gemeinsamen Grund: Die Verantwortung des Entwicklungsteams ist die erfolgreiche (Aus-)lieferung des Produkts. Doch der erfolgreichen Zusammenarbeit stehen häufig Hindernisse im Weg. Die typischen Hindernisse sind:

Organisationsveränderung will gelernt sein

Keines der drei Hindernisse ist prinzipieller Natur – alle sind sie überwindbar. Sie erfordern allerdings mutige Entscheidungen, die altbewährte Denkweisen und Paradigmen wie z.B. das der maximalen Auslastung und Effizienz in Frage stellen.
Machen wir uns nichts vor: Der Weg zum cross-funktionalen Arbeiten ist für die meisten Unternehmen ein starker Veränderungsprozess, der zu Widerstand und tiefer Verunsicherung führen kann. Umso wichtiger ist das Design des Prozesses: Veränderungen, die von wenigen konzipiert und dann ausgerollt werden, haben meistens mit erheblichen Akzeptanzproblemen zu kämpfen. Man spart sich viele Grabenkämpfe und Umwege, wenn die Betroffenen von Anfang an zusammen kommen, damit sie selbst einen Lösungsvorschlag erarbeiten.
Hierzu bietet sich das Format der Pilotgruppe an, die aus einem repräsentativen Querschnitt des Unternehmens besteht und damit beauftragt wird, Antworten auf die relevanten Fragestellungen zu finden. Wichtig ist, dass eben diese Fragestellungen und die dazu gehörigen Rahmenbedingungen im Vorfeld vom Management festgelegt werden. Wir haben am Beispiel Apple gesehen, wie ein Unternehmen seine Kernbotschaft (bei Apple ist es das Design) über einige wenige Spezialisten hinaus in der gesamte Unternehmenskultur verankern konnte.
Was auch immer Ihre Kernbotschaft ist: Erlauben Sie nicht, dass sie von den Zwängen der Unternehmensprozesse und -strukturen verwässert wird.

Egal, was es ist: Ich war's nicht!

Scrum ist großartig. Entscheidungen werden dort getroffen, wo die größte Kompetenz liegt. Nur was, wenn mein Team das gar nicht so großartig findet? Wenn die Teammitglieder lieber tun, was man ihnen sagt? Dann sind sie hinterher, falls etwas schief geht, wenigstens nicht schuld. Schuldkultur führt zu Pflichterfüllung statt Verantwortungsübernahme. Wenn ich das als ScrumMaster erkannt habe, wie kann ich dann damit umgehen? Wie schaffe ich es, meinem Team Mut zu machen, selbst Entscheidungen zu treffen?

1. Rahmen schaffen Sicherheit

Je größer das Sicherheitsbedürfnis, desto enger sollte der Rahmen sein, um kleine Entscheidungen mit geringfügigen Konsequenzen treffen zu können. Mit der Erfahrung kommt das Vertrauen. Das Vertrauen liegt übrigens auf beiden Seiten: Bei demjenigen, der Verantwortung übernimmt ebenso wie bei dem, der Kontrolle abgibt.
Jeder ScrumMaster kennt die Situation am Anfang einer Scrum-Einführung: Im Daily stehen alle Teammitglieder in einem großen Sicherheitsabstand zum Board, niemand will etwas sagen müssen.
Durch die 4 Fragen

geben wir dem Daily einen engen Rahmen. Die Teammitglieder haben nicht viel eigenen Gestaltungsspielraum. Es entsteht umso mehr Vertrauen, je häufiger Dailies gemacht werden. Der ScrumMaster macht die Erfahrung, dass das Team die 15 Minuten nutzt, um sich auszutauschen. Beim Team entsteht das Vertrauen, dass der Termin nicht dazu gedacht ist, sie zu kontrollieren. Ebenso wie im Beispiel ‘Daily’ funktioniert das mit dem Scrum-Framework als Ganzes. Der feste Rahmen gibt den benötigten Freiraum.

2. Schulddiskussionen rigoros unterbinden

Es ist wichtig herauszustellen, dass die Frage, wer schuld ist, gänzlich uninteressant ist. Jedwede Diskussion der Schuldfrage muss vom ScrumMaster sofort unterbrochen werden. Für eine konstruktive Analyse der Ursachen bieten sich die 5-Warums und die Fischgräten-Analyse an. Die Erfahrung, nicht vorgeführt zu werden, wenn etwas nicht wie erwartet funktioniert hat, schafft Vertrauen.
Mein persönlicher Erfolg war, als eines Tages ein Kollege sagte: „Da standen drei Leute aus drei verschiedenen Abteilungen vor dem Gerät zusammen, und statt wie früher drei Tage lang darum zu streiten, wer schuld ist, haben wir innerhalb von ein paar Stunden eine Lösung erarbeitet.”
Lächeln auf den Gesichtern. Stille Freude und Stolz, dass sie es geschafft haben, die lästige Schuldfrage hinter sich zu lassen.

Die vier Spielfelder der Teamkommunikation

Agile Teams organisieren ihre Prozesse, Strukturen und ihre Performance über ein hohes Maß an Kommunikation. Kurz gesagt, Selbstorganisation ist gleich Kommunikation. Für die Führung agiler Teams, ob disziplinarisch oder lateral, gehört das Initiieren und Gestalten von funktionalem, aber auch sozialem Austausch zu den zentralen Aufgaben. Die verschiedenen “Spielfelder”, die für die interne Teamkommunikation relevant sind, müssen im Auge behalten und bei Bedarf aktiv entwickelt und gesteuert werden.
Teamkommunikation findet grundsätzlich auf zwei Ebenen statt. Zum einen auf der sachlich-fachlichen und zum anderen auf der emotional-sozialen Ebene. Beide können natürlich nicht wirklich unabhängig voneinander betrachtet werden, sie wirken in der Praxis permanent aufeinander ein. Es zeigt sich jedoch in den Teamprozessen, dass im Alltag situativ unterschiedliche Schwerpunkte zu erkennen sind und die vier Spielfelder durchaus unterschiedlich gut funktionieren können. Folgendes Modell kann für Teamentwickler und Führung eine Folie zur Analyse und Intervention bezogen auf die komplexe Teamkommunikation sein.
Spielfeld_Teamkommunikation
Im Mittelpunkt von selbstorganisierter Teamarbeit steht naturgemäß das Feld Fachinformation und Austausch – im Sinne von fachlichen und organisatorischen Absprachen, gegenseitigem Lernen. Kommunikation in diesem Feld entscheidet wesentlich über die Performance des Teams. Probleme können dann entstehen, wenn es im Team Wissensmonopole gibt, wenn nicht genügend Zeit für den Austausch zur Verfügung steht oder sich genommen wird, unklare Botschaften gesendet werden, z.B. zu viel E-Mail statt direkter Austausch, etc.
Entwicklungsfragen zu diesem Feld sind u.a.:

Das Feld Auseinandersetzung ist gekennzeichnet von hoher, z.T. unkontrollierter,
Emotionalität. Es steht in der Regel für ungelöste, eskalierende Konflikte und deren
Dominanz über die sachliche Kommunikation. Die eigentliche Arbeit wird partiell aus den
Augen verloren, es droht Schwächung der Leistung. Es kommt zu Koalitionen, die intensiv
miteinander kommunizieren und sozialem und kommunikativem Ausschluss von
einzelnen oder Teilgruppen usw. Es kann aber auch sein, dass Auseinandersetzungen
zu stark vermieden werden, Harmonie über alles gestellt wird. Das bedeutet oft
Stagnation und Mittelmaß, bzw. die Gefahr unvermittelter Eskalationen.
Entwicklungsfragen zu diesem Feld sind u.a.:

Das Feld Small Talk definiert die entspannte, beziehungsorientierte Kommunikation im Team. Hier wird über Privates und Alltägliches gesprochen und soziales Miteinander gepflegt. Small Talk ist wichtig für den Abbau von Stress und das persönliche Kennenlernen auf einer nicht leistungsbezogenen Ebene. Und ein oft unterschätztes Element von Teamgeist und Wir- Gefühl. Probleme können hier eigentlich kaum auftreten, höchstens wenn zu viel oder zu wenig Small Talk läuft.
Entwicklungsfragen zu diesem Feld sind u.a.:

Spannend ist das Feld des Dialogs. Hier kommuniziert das Team im kooperativen Dialog und bearbeitet gemeinsam vor allem komplexe fachliche Probleme und innovative Themen. Dieses Spielfeld heißt, in unterschiedlichen Meeting- und Workshop-Formaten zu kommunizieren und sich mit positiver Emotionalität, Engagement für das Ganze und hoher Fachkompetenz einzubringen. Dialog heißt Austausch auf höchstem Niveau und immer mit dem Fokus auf der Sache. Probleme können hier mangelnde Dialogbereitschaft, “Kopfmonopole”, schlampige Meetings, fehlende Methoden, zu wenig Beteiligung u.a. sein.
Entwicklungsfragen zu diesem Feld sind u.a.:

Diese vier Felder kennzeichnen die komplexe und anspruchsvolle Vielfalt der Kommunikationsprozesse in selbstorganisierten Teams. Weit mehr als in konventioneller Teamarbeit sind alle im Team aufgefordert, diese vier Felder optimal mitzugestalten und zu entwickeln. Führung als funktionales Mitglied des Teams sollte sich hier schwerpunktmäßig als Moderator, Impulsgeber und konstruktiv-kritischer Beobachter verstehen und sich entsprechend einbringen. Das heißt, Feedback geben, ggf. Trainer sein, Rahmenbedingungen schaffen, Impediments aus dem Weg räumen.
Wie im Fußballspiel: Auf dem Platz spielt dasTeam, in der Kabine agiert der Coach.
Wie geht das – die Kommunikation im Team fördern und gestalten? Antworten darauf gibt es im Training “Team Bo
oster” mit Dieter Rösner – alle Infos hier

Team-Heterogenität als Chance

Es ist anscheinend eine ganz selbstverständliche Annahme, dass Teams leistungsfähiger sind, wenn sie möglichst heterogen aufgestellt sind. Und tatsächlich findet man in einschlägigen Publikationen eine Vielzahl von Beispielen und Nachweisen. Aus eigener langjähriger Erfahrung im Umgang mit Teams und Teamarbeit kann ich dieser Annahme durchaus zustimmen. Heterogene Teams sind zwar meist anspruchsvoll (gerade auch in punkto Führung), aber in ihrer Performance tatsächlich vielversprechend.
Heterogenität kann als die Uneinheitlichkeit und Vielschichtigkeit der Elemente einer definierten Menge, oder der Bestandteile eines (sozialen) Systems bezeichnet werden. Als heterogen wird das übergeordnete Ganze, das System als solches (also in unserem Fall das Team) bezeichnet, nicht seine einzelnen Teile.
In der Teamarbeit kann man verschiedene Ebenen von Heterogenität konstatieren, z.B. bezüglich Alter, Geschlecht, Persönlichkeitsmerkmalen, fachlichen Kompetenzen, formalen und informellen Rollen und Funktionen usw. Ich will hier speziell auf Heterogenität in Bezug auf sogenannte individuelle Typologien der Teammitglieder eingehen – also ihre typischen individuellen Rollen- und Verhaltensmuster.

Die Nützlichkeit von Typologien

Typologien sind schlicht ziemlich nützlich. Menschen brauchen vereinfachende Strukturen, in die sie unterschiedlichste Umweltfaktoren einordnen können, um mit Komplexität fertig zu werden und handlungsfähig zu sein. Auch menschliche Typologien sind als eine solche Vereinfachung zu sehen, und werden von jeder Person automatisch und meist unbewusst entwickelt. Erst über diese Schubladen registrieren und definieren wir Unterschiede in den persönlichen Mustern unserer Mitmenschen und im Bezug zu uns selbst. Die Auseinandersetzung mit einem strukturierten Typologiemodell bietet die Möglichkeit, sich diese Unterschiede bewusst, transparent und nutzbar zu machen. Dies kann zum einen helfen, sich selbst besser kennenzulernen und zum anderen ein differenziertes Verständnis für andere und ihre Eigenarten im Team zu entwickeln. Gerade in der Teamarbeit, in der direkte Kontakte, enge Beziehungen und eine gewisse Abhängigkeit voneinander herrschen, kann die Reflexion der persönlichen Typologien Verständnis für einander schaffen und so die Heterogenität bewusst einzusetzen und zu fördern.

Die LIFO®-Methode

Aus der Vielzahl der auf dem Markt angebotenen Modelle wie z.B. MBTI™-Typenindikator, DISG-Persönlichkeits-Profil, Enneagramm, Team-Management-System™ (TMS™), möchte ich mich hier auf das Modell der LIFO®-Methode beziehen. Ursprünglich als Selbstmanagement-Tool gedacht, eignet sich LIFO auch hervorragend für die Teamentwicklung. Die LIFO®-Methode wurde 1963 von Stuart Atkins und Allan Katcher in den USA auf der Basis der Theorie von Erich Fromm entwickelt, und wird inzwischen weltweit auch in vielen großen Unternehmen in der Personalentwicklung eingesetzt. Sie verwendet, wie viele andere Modelle auch, einen detaillierten Fragebogen zur Analyse der persönlichen Verhaltensstile. Daraus ergibt sich ein konkretes Verhaltensprofil im Sinne einer je individuellen Typologie.
Die LIFO®-Methode geht von der Annahme aus, dass unsere individuellen Verhaltensmuster im Wesentlichen das Ergebnis von Erziehung und Erfahrungen, d.h. biographischen Lernens sind. Wir haben gelernt, uns anderen gegenüber so zu verhalten, dass unsere unterschiedlichen psychischen und physischen Wünsche möglichst befriedigt werden. Daraus resultiert die individuelle Kombination unserer komplexen Verhaltensstile. Diese Kombination ist die Quelle unserer Stärken und unserer Ressourcen.
Dieses Typologie-Modell streicht als Besonderheiten heraus, dass

Die vier LIFO Verhaltensstile sind:

  1. Unterstützend / hergebend (hilfsbereit, leistungsorientiert, lebt Werte und Ideale, anspruchsvoll u.a.)
  2. Bewahrend / festhaltend (analytisch, methodisch, detailorientiert, vorsichtig, pragmatisch u.a.)
  3. Anpassend / harmonisierend (emphatisch, kooperativ, ausgleichend, harmonieorientiert u.a.)
  4. Bestimmend / übernehmend (Führung, einflussnehmend, innovativ, risikobereit u.a.)

Die Ergebnisse des Fragebogens ergeben das individuelle Verhaltensprofil einer Person mit der jeweiligen Ausprägung der vier Stile. Im persönlichen Stilprofil zeigen sich ein eher bevorzugter und ein eher vernachlässigter Stil. Der bevorzugte Verhaltensstil wird häufiger, ja in der Regel standardmäßig, eingesetzt, während auf den vernachlässigten Stil eher weniger zugegriffen wird. Weitere Detailinformation sind unter www.lifoproducts.de oder dieter.roesner@borisgloger.com zu erfahren.
Vergleicht man in der Teamentwicklung die individuellen LIFO-Profile der einzelnen Teammitglieder, ergeben sich in der Regel differenzierte und unterschiedliche Verhaltensschwerpunkte, die im Sinn der Heterogenität gezielt analysiert und eingesetzt werden können. Gerade in Teamkonstellationen, in denen Selbstorganisation einen zentralen Stellenwert hat, braucht es eine gezielt gestaltete Teamstruktur.
In der Teamzusammenstellung oder Rekrutierung einzelner Mitarbeiter kann die LIFO®-Methode als Unterstützung zur Personalauswahl für Teams genutzt werden. Welche Ressourcen sind aktuell gut vertreten? Welche Stärken ergänzen das Team? Wieviel Homogenität / Heterogenität ist für das Team und die Aufgabe hilfreich? In der Zusammenarbeit in Teams müssen immer wieder Aufgaben und Situationen analysiert und effektive Lösungen gefunden werden. Durch die unterschiedlichen Stilausprägungen geht jeder Mitarbeiter unterschiedlich an die Problemlösung heran. Sind die unterschiedlichen Verhaltensmuster untereinander transparent, ausgetauscht und akzeptiert, können sich die Synergien des Teams optimal entfalten.
Fazit: Typologiemodelle sind in ihrer Funktion durchaus nicht unumstritten. Sie können zu Vereinfachungen, ja zu Stigmatisierungen einzelner Personen führen. Andererseits können sie, wie oben beschrieben, durchaus einen konstruktiven Beitrag zur selbstorganisierten Teamentwicklung leisten. Ganz gleich welches Modell gewählt wird, kommt es darauf an, es funktional einzusetzen, höchstmögliche Transparenz herzustellen und die Teammitglieder nicht nur auf die Ergebnisse der Fragebogenergebnisse zu reduzieren. Hoch lebe die Heterogenität als wesentliches Element guter Teamarbeit!

Teamcooking – ein funktionaler Event zur Teamentwicklung

Teamarbeit und kochen haben eine Gemeinsamkeit: Beide sind in der öffentlichen Wahrnehmung hoch aktuell. Ein agiles Modell wie Scrum stellt selbstorganisierte Teamarbeit ins Zentrum und die TV-Sender liefern täglich eine bunte Vielzahl von Kochshows ab. Da liegt es nahe, über den Einsatz von Kochevents in der Teamentwicklung nachzudenken. Und tatsächlich bietet gemeinsames Kochen im Team beste Möglichkeiten, Teamentwicklungsprozesse und kreativ-kulinarisches Erleben zu verknüpfen.
Für ein Teamcooking bieten sich verschiedene Optionen in der Umsetzung an:

  1. Der Einsatz professioneller Event-Veranstalter, die alle Vorarbeiten und den Ablauf gestalten und den Schwerpunkt auf den Kochprozess setzen. (Profikoch, Profi-Location, bei Bedarf Hilfskräfte und einen Moderator zur Auswertung, wenn gewünscht.)
  2. Einsatz eines koch- und teamentwicklungserfahrenen Moderators (z.B. ScrumMaster).
    1. Vorbereitung, Durchführung und Auswertung durch den Moderator (Menü erstellen, einkaufen, Location, Ablaufplanung). Das Team konzentriert sich auf den Kochprozess.
    2. Einsatz eines Moderators (z.B. ScrumMaster), der ein hohes Maß an Selbstorganisation durch das Team steuert und von Anfang an eher als Prozessbegleiter fungiert.
  3. Denkbar sind auch Mischformen aus allen drei Varianten.

Als Teamentwickler habe ich alle Varianten mehrfach moderiert und bevorzuge je nach Ausgangslage Variante 2a oder eine Mischform aus 2a und 2b.
Zielsetzungen im Teamcooking


Kriterien für einen erfolgreichen Ablauf von Teamcooking-Maßnahmen

Hinweise zur Auswertung von Teamcooking-Prozessen
Teamcooking ist als ein ausgesprochen ressourcenorientiertes Modell der Teamentwicklung zu verstehen, d.h. der Blick liegt nicht auf Defiziten, sondern auf Stärken. Die Auswertung sollte daher niemals den Spaß verderben und die Leistung, die das Team erbracht hat, grundsätzlich in Frage stellen und abwerten.
Kritische Situationen, die sich durchaus ergeben können (aber eher selten sind, wenn: siehe Kriterien) sind im Sinne von Entwicklungsmöglichkeiten ressourcenorientiert aufzugreifen und zu steuern. Es bieten sich unterschiedlichste Methoden und Techniken zu Auswertung an, z.B. Gruppendiskussionen, Kleingruppenreflexion mit Austausch, Einzelarbeit mit Moderationskarten und anschließender Präsentation und Reflexion, Malen der Erfahrungen usw. Vereinbarungen und Maßnahmen für einen Praxistransfer sind empfehlenswert
Zusammenfassung
Teamcooking bietet eine echte Chance, funktionale Teamentwicklung und Kreativität, Lebendigkeit und Spaß optimal zu verbinden. Es bietet sich für Teams im Anfangsstadium (Teambuilding) an, aber auch für erfahrene Teams, die sich in einer nicht alltäglichen Situation erleben wollen. Teamcooking bietet viele kreative Variationsmöglichkeiten, z.B. als Grill-Event, in Verbindung mit Rollenspielen (Rittermahl), als Wettbewerb usw. Ein Beispiel aus meiner Teamentwicklungspraxis zeigt ein Menü für ein Führungsteam mit 14 Personen, die sehr wenig Kocherfahrung mitgebracht hatten. Das Menü und die Zutatenliste wurden von mir als Moderator erstellt. Suche nach der Location, Einkauf, Zusammenstellung der Kochteams für die 5 Gänge lagen in der Selbstorganisation des Teams.

Teamcooking-Menü für 14 Personen

Einkaufsliste

Amuse Geule
Lachsröllchen mit Wasabi-Frischkäsefüllung Zutaten:

  • 3 Packungen milder Räucherlachs à 150g 
  • 3 Teelöffel Wasabi Creme 
  • 2 Becher Frischkäse (Philadelphia o.ä.) à 200 g 
  • Salz, Pfeffer

  • Lachsscheiben knapp übereinanderlegen, sodass 3 Rouladen entstehen. 
  • Wasabi-Creme mit Frischkäse gut verrühren, mit Salz/Pfeffer abschmecken und auf die Lachsflächen streichen.
  • Lachs nun vorsichtig, aber fest aufrollen und in Klarsichtfolie verpacken, kurz in den Kühlschrank legen. 
  • Zum Servieren Lachsrollen auswickeln und in gleichmäßige Scheiben schneiden. Zu Toastbrot-Dreiecken servieren.

 

Vorspeise
Kürbissuppe mit Kokosmilch Zutaten:

  • 1,5 kg Muskatkürbis ungeputzt (evtl. Hokkaido) 
  • 2 l Hühnerbrühe (Instant) 
  • 800 ml süße Sahne
  • 100 g eiskalte Butter 
  • Salz, Pfeffer, Zucker
  • 1 EL mildes Currypulver 
  • Ein Bund Petersilie (wenn möglich Koriander) 
  • Eine Dose Kokosmilch (400 ml) ungesüßt
  • Kürbis putzen und in Würfel schneiden. 
  • Hühnerbrühe zubereiten und in einen Topf geben, aufkochen lassen. 
  • Kürbis dazugeben und bei mittlerer Hitze weichkochen (ca. 15 min). 
  • Suppe pürieren und Sahne zugießen, aufkochen lassen. 
  • Die heiße Suppe nun mit der eiskalten Butter stückchenweise aufkochen und mit Salz, Pfeffer, Zucker und Curry abschmecken. 
  • Kleingeschnittene Petersilie (oder Koriander) zugeben. 
  • Je Teller 2-3 Esslöffel Kokosmilch vorsichtig darüberträufeln (wenn Zeit und Material vorhanden, evtl. Zimtcroutons dazugeben).
Hauptgang
Hähnchenbrüste mit Fetakruste Zutaten:

  • 3 kg aromatische große Tomaten 
  • Salz, Pfeffer
  • 4 TL getrockneter Oregano 
  • Olivenöl 
  • Pro Person eine Hähnchenbrust ohne Haut und Knochen 
  • 400g Schafskäse (Feta) 
  • 6 Schalottenzwiebeln, 2 Bund Basilikum 
  • 1 Glas schwarze Oliven entsteint zur Deko, Ciabattabrot o.ä.
  • Backofen auf 200 Grad vorheizen. 
  • Tomaten in kochendes Wasser tauchen, abschrecken, häuten, halbieren, entkernen und grob würfeln. 
  • Tomaten in einer großen feuerfesten Form verteilen. 
  • Salzen, pfeffern, mit 8 Esslöffel Olivenöl beträufeln. 
  • Im heißen Backofen, mittlere Schiene, unter dem Grill 15 Minuten garen. 
  • Hähnchenfleisch waschen, trocknen, salzen und pfeffern. 
  • In heißem Olivenöl von jeder Seite 4 Minuten braten. 
  • Schafkäse reiben und mit Oregano und klein gehackten Schalotten mischen.
  • Hähnchenbrüste nun auf die Tomaten legen, Fetamischung darauf verteilen und ca. 5 Min übergrillen, bis der Feta leicht geschmolzen ist.
  • Zum Servieren mit gehacktem Basilikum bestreuen. Einige Oliven dazugeben und mit Ciabattabrot reichen.
Dessert
Weißer Schoko-Himbeer-Schaum Zutaten:

  • 400g weiße Schokolade 
  • 800 g süße Sahne 
  • 750g Himbeeren (kann auch Tiefkühlobst sein) 
  • 8 EL Himbeergeist 
  • 4 EL Puderzucker
  • Schoko in kleine Teile zerbröckeln. 
  • Sahne in einem Topf erhitzen. 
  • Schoko zufügen und bei milder Hitze schmelzen lassen. 
  • Sahnemischung 1 Stunde kalt stehen lassen. 
  • Himbeeren abbrausen, abtropfen und mit Himbeergeist und Puderzucker mischen.
  • Sahne-Schokomischung mit dem Handrührer zu einer schaumigen Creme aufschlagen.
  • Die Himbeeren auf die Dessertgläser aufteilen und servieren.

TIPP: Noch mehr Ideen für besseres Teamwork gibt es bei den Scrum Supplements mit Dieter Rösner.

Wann ist ein ScrumMaster erfolgreich?

Woran erkennt man einen erfolgreichen ScrumMaster bzw. welche Kriterien könnten herangezogen werden, um einen ScrumMaster als erfolgreich zu bezeichnen
Ich selbst bezeichne mich als erfolgreichen ScrumMaster, wenn ich

In der Realität ist es etwas schwieriger, diese Vorhaben umzusetzen und somit als ScrumMaster erfolgreich zu sein. Es gibt immer wieder Teams, denen die Umstellung auf Scrum sehr schwer fällt und die neue Arbeitsweisen anfangs ablehnen.
In diesen Teams ist es umso wichtiger, einen ScrumMaster zu haben, der das Team an Scrum heranführt und den Sinn sowie den Zweck der Meetings, Artefakte und Rollen in Scrum dem Team näher bringt. Während sich dieses Vorgehen in der Theorie sehr einfach anhört, gibt es in der Realität Teams, die zu Meetings kommen und angeben, sie seien nur anwesend, “weil sie dazu ja gezwungen werden“. Diese Meetings verlaufen dann in etwa so: Die Teammitglieder sind demotiviert und geben dem ScrumMaster das Gefühl, dass sie dieses Meeting über sich ergehen lassen. Sie meckern bei jedem einzelnen Punkt gefühlte 20 Minuten, damit man auch ja weiß, dass sie keine Lust haben. In dem ganzen Unmut bin ich der ScrumMaster. Ich bin motiviert, ich glaube an mein Team und an mein Ziel. Ich weiß, dass ich es schaffe, das Team zu motivieren und anzuleiten um mitzumachen. Ich schaffe es, sie von den Vorteilen in Scrum zu überzeugen. Das sind mal Ambitionen. Leider vergehen diese, zwar nicht sofort, aber mit der Zeit, und das Team gibt einem auch noch das Gefühl, es hätte seine Sache doch gut gemacht. Das Team hat es schlussendlich doch geschafft, den ambitionierten ScrumMaster zu frustrieren.
In einem dieser Teams, bei dem ich glaubte, dass mein Tun einfach nichts weitergebracht hatte und nichts von dem angekommen war, was ich gesagt oder getan hatte, passierte etwas.
Ja, es passierte tatsächlich: Ich, der ScrumMaster, war erfolgreich. Nicht in dem Sinne wie ich mich persönlich als erfolgreich bezeichnet hätte, aber ich war es. In einer Diskussion zwischen dem Product Owner und der Geschäftsführung sagte der PO: “Ja, der ScrumMaster hat gesagt, wir sollen das so machen …“ Daraufhin mischte sich ein Teammitglied ein und sagte: “Der ScrumMaster hat so etwas nicht gesagt.“ Es war auch so gewesen: Ich, der ScrumMaster, hatte niemandem gesagt, wie er oder sie etwas zu tun hat – und das Team hat mich in Schutz genommen, vor dem Manager und dem PO. Ich hatte es geschafft! Es hatte sich etwas bewegt, ich war erfolgreich.
Wir ScrumMaster dürfen einfach nicht außer Acht lassen, was wirklich ein Erfolg ist und dieses unwillige und demotivierte Team hat mir gezeigt, was es heißt, erfolgreich zu sein. Ein ScrumMaster darf sich als sehr erfolgreich bezeichnen, wenn er es geschafft hat, dass sein Team hinter ihm steht. Ich habe es geschafft, mein Team steht hinter mir und es fühlt sich wirklich wirklich gut an.

In kleinen Schritten Feedback fördern

Wie kann es sein, dass ich immer wieder aufs Neue erlebe, dass in Unternehmen keine Feedback-Kultur gefördert wird? Die Richtlinien des lösungsorientierten Feedbacks sind zwar meist auf dem Unternehmenslaufwerk zu finden, aber dort verstauben sie in ihrer virtuellen Existenz, statt real angewendet werden. Das ist wirklich schade. Feedback ist unwahrscheinlich wichtig, um das Verständnis rund um die kontinuierliche Verbesserung zu fördern. Gegenseitiges Feedback im beruflichen Kontext zu geben und zu nehmen ist elementar, um eine lernende Organisation aufzubauen.
Aus diesem Grund habe ich es mir zur Gewohnheit gemacht, (fast) nach jedem Meeting, Training bzw. Workshop das Feedback meiner Teilnehmer einzuholen und – wichtig – auch Feedback an meine Teilnehmer zu geben. Hier meine drei Lieblingsmethoden.

Feedback-Tür

Einfach 4 Post-its an die Tür kleben (++, +, -, –) und die Teilnehmer bitten, beim Verlassen des Raumes einen Punkt auf das zutreffende Post-It zu zeichnen. Das geht schnell, ermöglicht Anonymität, und ist wenig disruptiv. Ich wende das häufig bei „Feedback-Neulingen“ an, obgleich die Methode eigentlich immer passt. Man kann bei dieser Feedbacktür den Schwerpunkt auch konkret auf „Return On Time Invested“ (kurz: ROTI) legen, um herauszufinden, wie viel Mehrwert der Termin den Teilnehmern gefühlt gebracht hat. (Achtung: Bei einem überwiegend negativen Resultat sollte jedoch unbedingt eine Nachbesprechung mit den Teilnehmern erfolgen.)

Blitzlicht-Gewitter

Beginnend bei mir selbst, sagt jeder reihum einen Satz. Wie geht es mir jetzt nach dem Termin, wie empfand ich das Meeting, was fand ich gut, was hat mir gefehlt – all das sind Elemente, die hier erwähnt werden dürfen. Kleiner Tipp: Es hilft, einen „talking stick“ herumzureichen (Stift, Ball, Spielzeug o.ä.), um sowohl die Disziplin als auch den Fokus zu fördern. Und wer eine sehr redselige Truppe an Teilnehmern hat, kann ruhig zur Packung Streichhölzer greifen. Wer länger redet, als ein Streichholz abbrennt, der verbrennt sich wortwörtlich die Finger 😉

Wie war der Termin?

Bei einer kleinen Gruppe, die sich ohnedies öfter sieht (z.B. Dev.Team), lohnt es sich, nach Abschluss des Termins die ganze Runde bzw. einzelne Personen zu fragen: Wie war der Termin? Was war gut? Was sollten wir das nächste Mal anders machen? So bekommt man Feedback und der nächste Termin kann nur noch besser werden.
Habt ihr auch das Gefühl, dass eine tatsächliche Feedbackkultur im beruflichen Kontext sehr selten zu finden ist? Wie geht ihr damit um?

Der ScrumMaster – zwischen Stühlen und Fronten

Ort: Meetingraum
Zeit: 08:47
Zweck des Meetings: Sprint Planning 1
Die Beteiligten meiden Augenkontakt. Hochrote Köpfe, betretene Stille. Es geht nicht mehr weiter. Soeben haben sich zwei erfahrene Entwickler des Teams mit dem Product Owner angelegt.
Streiten. Der Product Owner fordert eine sehr große Story für den zu planenden Sprint, weigert sich jedoch, sie zu splitten. Sie in zwei zu teilen. Die Gründe dafür verstehen die Entwickler nicht. Sie verweigern das Commitment. Als ScrumMaster kann ich der Diskussion aus fachlicher Sicht schon lange nicht mehr folgen. Ich fühle mich gelähmt, frustriert, fast unfähig, zum Ziel des Meetings, dem Commitment zu führen. Klar ist mir nur eines: Die Gründe für diese Bewegungslosigkeit liegen im Verborgenen. Weit unter der Oberfläche, denn die Entwickler überzeugen sachlich und argumentatorisch auf ganzer Linie.
Als klar wird, dass es nicht mehr weitergeht, wird das Commitment um einen verträglichen Zeitraum verschoben, um eine Klärung herbeizuführen und die Gemüter zu beruhigen.
Nach ca. einer Stunde kommt der Product Owner zum Team, lenkt ein und stimmt sichtlich erbost zu, die Story doch noch anzupassen. Die Situation scheint gelöst.
Weit gefehlt.
Nach ein bis zwei Stunden taucht die Story im Computersystem wieder auf und … ist unformuliert, aber nicht gesplittet. Die Verärgerung ist den Entwicklern am ganzen Körper und vor allem an ihrer Gesichtsfarbe anzusehen. Die Entwickler bitten mich mit meinen „politischen Fähigkeiten“ – so die Entwickler – um Hilfe und darum, zum Product Owner zu gehen und letztlich zu erbitten, was er doch zugesagt hatte: Die Story in zwei kleinere zu splitten. Ich stimme zu und mache mich sofort auf den Weg.
Ich, als Fachfremder, sehe meine Chance, mir weiteres Standing beim Team zu verdienen. Nun bin ich gefordert und kann meine Fähigkeiten unter Beweis stellen. “Hoffentlich”, denke ich. Es fühlt sich wie ein bewegender Schlüsselmoment für mich und die weitere Zusammenarbeit mit meinem Team an. Ist doch sonst so schwer spürbar, was man an einem langen Tag geleistet hat.
Reden. Ich betrete das Büro des Product Owners. Leider sitzt er noch nicht beim Team. Änderung ist jedoch in Sicht. Ich begebe mich freundlich zum Product Owner und frage ihn mit einem einladenden Lächeln, ob er mir drei Minuten seiner Zeit schenken kann. Ich setze mich zu ihm und danke für die Bereitschaft, über die Story zu sprechen. Ich nehme eine ähnliche Körperhaltung ein wie er, um eine positive Stimmung zu erzeugen und bitte ihn erneut, die Story zu teilen. Es braucht drei Minuten freundliche Worte und ein wenig Small Talk. Der Product Owner stimmt zu, die Story gemeinsam mit mir so umzuformulieren, dass das Entwicklerteam umgehend bereit ist, sein Commitment abzugeben.
„Wie leicht war das denn?“, frage ich mich, kehre voller Stolz zum Team zurück und verbreite die gute Nachricht. Das Team kann nun die neu entstandene und kleinere Story committen.
Verbinden. Ich spüre Freude, Stolz und Erfolg auf ganzer Linie. Mir wird bewusst, was es heißt, ScrumMaster zu sein. Wir ScrumMaster sind das Sprachrohr zwischen den Gemütern, die Mittler zwischen den Parteien, die Mediatoren und Psychologen. Die mit den geheimnisvollen Soft Skills, die Impediments jedweder Art aus dem Weg räumen. Es wird klar, wozu es uns ScrumMaster braucht. In vielen Fällen blockieren die Dinge aufgrund von Befindlichkeiten, Ängsten, Politik oder zwischenmenschlichen Themen.
In meinem Fallbeispiel wird sehr deutlich, dass es oft nur der richtigen Ansprache oder dem Schaffen einer positiven Stimmung braucht, um ein gemeinsames Ziel zu erreichen.
Erschöpft und zufrieden zugleich sinke ich in meinen Bürostuhl und kann kurz darauf das Sprint Planning 1 mit einem einstimmigen Commitment des Teams beenden.
Was habe ich aus meinem Erlebnis mitgenommen? Zum einen wird mir klar, wie wichtig regelmäßige und qualitativ wertige Estimation-Meetings sind, an denen immer alle Teammitglieder teilnehmen. Zum anderen sehe ich die Vorteile, als externer ScrumMaster tätig sein zu können. Frei von Ängsten oder gar Abhängigkeiten kann ich mit verschiedensten Vertretern eines Unternehmens kommunizieren.

Der ScrumMaster als Identitätsstifter

ScrumMaster sind dazu da, die Produktivität ihrer Teams zu erhöhen. Gerade in Projekten mit hohem Erfolgsdruck ist diese Erwartung deutlich zu spüren. Vorbei die rosaroten Zeiten, als der ScrumMaster sein Team von den wirtschaftlichen Zwängen der Wirklichkeit zu befreien suchte. Das ist eine gute Entwicklung, denn sie gehört zum Erwachsenwerden dazu. Damit Scrum auch von Vorständen und Geschäfsführern ernst genommen wird, müssen ScrumMaster zur Führungsinstanz werden, auf die sich Top-Manager verlassen können.

Nötig: ein eigener Führungsstil

Macht dieses Bild aus ScrumMastern bloße Erfüllungsgehilfen des Top-Managements? Verkümmert der ScrumMaster zum verlängerten Arm der Geschäftsleitung? Die Gefahr besteht immer dann, wenn der ScrumMaster zu schwach ist, um einen eigenen Führungsstil zu entwickeln. Dann ist er schlimmstenfalls das Sprachrohr anderer Leute – und dazu noch ohne disziplinarische Führungskompetenz.
Aktuelles Beispiel: Ein strategisch wichtiges Projekt, in das viele Ressourcen gesteckt wurden, steht auf der Kippe. Das Top-Management steht unter Druck und gibt diesen Druck an die Scrum-Teams weiter. Begründung: Allen beteiligten Akteuren soll klar werden, wie wichtig dieses Projekt und die Einhaltung von Lieferterminen ist.
In einer solchen Situation kann der ScrumMaster zwei Dinge tun: Entweder stellt er sich entschieden gegen das Management und versucht, das Team von dieser Drohkulisse so gut wie möglich fern zu halten. Oder er gibt nach und erhöht selbst den Druck auf das Team. Beide Optionen sind für die Legitimität des ScrumMasters fatal, denn er riskiert den Vertrauensbruch mit der einen oder der anderen Seite.
Gibt es aber eine dritte Möglichkeit – eine, die weder auf Gehorsam noch auf Rebellion basiert? Kann ein ScrumMaster die Erwartungen des Managements mit den Erwartungen des Teams zusammenbringen, ja vielleicht sogar versöhnen? Damit das gelingen kann, müssen ScrumMaster sich auf ihre ureigene Stärke zurück besinnen: Die soziale Bindung an ihr Team. Ein ScrumMaster ist nur in zweiter Linie Facilitator, Servant Leader und Change Agent. Primär ist er Teil des Scrum-Teams und sitzt damit mit dem DevTeam und dem Product Owner im gleichen sozialen System.

Unbezahlbar: die großen und kleinen Gesten

Das eröffnet ihm ganz eigene Möglichkeiten, die nicht auf den klassischen Einflussfaktoren Macht und Geld beruhen. Die vielen kleinen und großen Gesten eines guten ScrumMasters – vom Bereitstellen einer wohligen Arbeitsatmosphäre bis hin zur intensiven Auseinandersetzung mit jedem Teammitglied – sie dienen allesamt dazu, eine Form der Transaktion innerhalb des Scrum-Teams zu schaffen, die nicht auf den Normen des Marktes, sondern auf sozialen Normen basiert.
Und hier liegt auch die Chance des ScrumMasters. Er kann sein Team mit genügend Selbstbewusstsein und Ehrgeiz impfen, dass es auch stürmische Zeiten erfolgreich meistert. Er schafft das, indem er die Identität seines Teams stärkt. Mit “Identität” meine ich ein Selbstbild, das eigentümlich genug ist, um das Team von anderen Gruppe abzugrenzen. Man kann in diesem Zusammenhang auch von Idiosynkrasie sprechen.
Ein Beispiel: Ich fragte neulich ein Teammitglied, warum er und seine Teamkollegen die Einladung eines (neuen) Kollegen ausgeschlagen haben, als dieser sie zu sich nach Hause zum Abendessen einladen wollte. Die Antwort war verblüffend: “Wir sind im Unternehmen die Außenseiter – wir versuchen erst gar nicht, uns beliebt zu machen.” Dazu muss man wissen: Das Team war in einem Projekt unterwegs, das allseits unbeliebt und von ständig wechselnden Anforderungen sowie Stillständen gebeutelt war. Das für dieses Projekt eingesetzte Scrum-Team hat den Lärm von außen ignoriert und ist seinen eigenen, oftmals rauen Weg gegangen. Dabei hat es offenbar eine eigene Identität – die des rebellischen Außenseiters – entwickelt. Damit war es erfolgreich: In nur sechs Monaten gelang es ihnen, gegen alle Erwartungen die Entwicklung zu einem glücklichen Ende zu bringen.
Als ScrumMaster habe ich vielfache Möglichkeiten, auf die Identität des Teams Einfluss zu nehmen: Das Review, die Retrospektive, die Dailies… das sind alles Happenings, in denen das Team Bilder von sich selbst produziert und dabei seine eigene Identität konstruiert. Als ScrumMaster kann ich im Sinne eines Stifters oder Förderers bestimmte Entwicklungen gezielt unterstützen und andere hinterfragen. Das hier genannte Team war zum Beispiel stets der Gefahr ausgesetzt, in Selbstgerechtigkeit und -mitleid zu verfallen. Hier konnte ich etwa durch paradoxe Interventionen dafür sorgen, dass mein Team die Bodenhaftung nicht völlig verlor. Auf der anderen Seite gab ich unserem Team reichlich Raum, um erfolgreiche Sprints zu feiern und jeden Tag den eigenen Weg zu bestärken. Hierzu ist es essenziell, dass das Team den gleichen Raum teilt und somit tatsächlich zusammenarbeiten kann.
Der Jahresbeginn eignet sich übrigens hervorragend dafür, um das Selbstverständis eines Teams zu reflektieren. Eine Frage könnte sein:
Was hat uns in 2013 stark gemacht? Und: Was davon brauchen wir in 2014? Was noch?
Siehe dazu auch:
http://blogs.hbr.org/2012/09/stop-wasting-money-on-motivati/
 

Enttäuschte Erwartungen

Wie kann man die Bildungsqualität im subsaharischen Afrika erhöhen? Indem man Schulbücher umsonst verteilt. Die Hypothese klingt einfach und plausibel. So dachte auch die Weltbank in den frühen neunziger Jahren und startete eine entsprechende Kampagne.
Michael Kremer, einem Wirtschaftsprofessor vom Massachusetts Institute of Technology, war das zu einfach. Er machte sich auf die Suche nach Möglichkeiten, diese Hypothese auf ihre Validität zu überprüfen. Er nahm sich die Kampagne der Weltbank vor und tat das, was u.a. in pharmazeutischen Studien längst üblich ist: Er schuf Vergleichbarkeit. So verdoppelte er die Anzahl an teilnehmenden Schulen, um mit zwei Gruppen arbeiten zu können: Die eine Gruppe an Schulen bekam freie Schulbücher zur Verfügung gestellt, die andere nicht.
Nach vier Jahren und jeder Menge Feldarbeit unter schwierigsten Bedingungen hatte er ein Ergebnis: Die mit kostenlosen Schulbüchern ausgestatteten Schulen wiesen im getesteten Vergleich keine Verbesserung der Bildungsqualität auf. Die so plausible Hypothese, dass freie Schulbücher das Bildungsniveau erhöhen, war widerlegt.
In einem späteren Experiment, diesmal im westlichen Kenia, testete Kremer weitere Maßnahmen zur Erhöhung der Bildungsqualität: Vergünstigste Mahlzeiten, kostenlose Schuluniformen, Bildungsstipendien. Doch es war schließlich eine ganz andere Maßnahme, die mit 3.50 Dollar pro Person die günstigste und zugleich erfolgreichste war: Die Behandlung von Darmparasiten. Dadurch sank die Abwesenheit an den Schulen um 25% und trug damit erheblich zu einem besseren Bildungsniveau bei.

Hypothesen auf ihre Validität überprüfen. Wie oft machen wir das in unserer Arbeit?

Ich arbeite viel mit Gruppen zusammen und zerbreche mir einen guten Teil meiner Zeit den Kopf darüber, wie ich mein Team weiterentwickeln kann. Aus meiner Erfahrung habe ich mittlerweile ein recht gutes Gespür für funktionierende Gruppen. Ich merke schnell, ob die Chemie stimmt. Zugleich habe ich eine Menge an Rezepten, Tipps und Tricks parat, die ich jederzeit hervorzaubern kann. Dumm nur, wenn sie nicht sofort zum erwünschten Erfolg führen. Damit die Arbeit nicht zur ständigen Frustrationsquelle wird (warum macht das Team bloß nicht so, wie ich will?), versuche ich, ein paar einfache Grundsätze zu beherzen:

Literatur


Jessica Benko: The Hyper-Efficient, Highly Scientific Scheme to Help the World’s Poor (Wired, Dezember 2013):
Maren Fischer-Epe (2011): Coaching – Miteinander Ziele erreichen. 2. Auflage. rororo

Die Kraft der Unzufriedenheit

Auf dem Weg zur Agilität haben wir glücklicherweise immer wieder mit den Widrigkeiten eingekrusteter Strukturen, langen, scope-fixen Releases, dem magischen Dreieck etc. zu tun. Releaseplanungen und Backlog Groomings unter diesen Bedingungen durchzuführen, macht besonders viel Spaß. Man muss nämlich das Beste draus machen und gleichzeitig versuchen, den nächsten Schritt Richtung Produktorientierung zu gehen.
Was es für einen Sinn macht, Backlog Groomings, Releaseplanungs-Meetings zu veranstalten und ein gemeinsames Releaseboard zu pflegen?
Im besten Fall halten die Teilnehmer der Meetings diese irgendwann für so sinnlos und nervig, dass sie selbst anfangen, sich Gedanken darüber zu machen, wie man die Zeit sinnvoller gestalten kann. Wichtig dabei ist aber, dass man sie nicht aus der Pflicht entlässt, dass sie die Zeit gemeinsam gestalten müssen.
Bei einem unserer Kunden haben wir damit angefangen, dass alle Teams im skalierten Umfeld ihre Backlogs teamweise für die nächsten drei Sprints auf Story-Ebene auf einem riesigen Board plakatierten. Alle zwei Wochen veranstalteten wir Meetings, in denen die jeweiligen POs die Stories vorstellten, an denen ihr Team in den nächsten drei Sprints arbeiten würde. So weit im Voraus sollte das Backlog ja einen recht stabilen Stand haben. Um diese Planung machen zu können, hatten die POs aber im Vorfeld die Aufträge schon in mehr oder weniger technische Arbeitspakete geschnitten und auf die Teams/Komponenten aufgeteilt. Im Meeting selbst wurden also keine Abhängigkeiten mehr entdeckt und bei der Vorstellung der User Stories für die nächsten drei Sprints schliefen die POs entweder aus Höflichkeit oder weil wir vor dem Board standen nicht ein.
Zuerst wurde viel über das Meeting gemeckert. Es würde nichts bringen, man würde ja eh auf die anderen POs zugehen, wenn man etwas von ihnen bräuchte. Außerdem sei es zu aufwendig, die Stories auszudrucken und aufzuhängen… Als klar wurde, dass wir das Meeting trotzdem beibehalten würden, wählten sie eine andere Strategie. Statt meckern: besser machen.
Anstatt schon vorab alles zu klären und auf die Teams zuzuordnen, will man nun versuchen, die unterschiedlichen Themen mit initialen User Stories in der Priorität des Company Backlogs abzubilden. Das Meeting kann dann dazu dienen sich bewusst zu machen, welche Aktivitäten nötig sind, um das Thema abzuschließen. Außerdem kann sofort gesehen werden, ob an den richtigen Prozessen gearbeitet wird bzw. ob sich ausreichend Teams aus den oberen Themen Stories ziehen. Die Endlichkeit der Wand führt außerdem automatisch zu einer Fokussierung. Es finden vielleicht gar nicht alle Themen Platz. Die wichtigsten können aber aufgehängt werden. Merkt man, dass die kleinen Stories für die Top-Themen ausgehen, kann man in kleineren Gruppen die Detaillierung durchführen. Burndown-Charts auf Themen-Ebene werden möglich. Die nächste Stufe könnte sein, nicht mehr Themen abzubilden, sondern vielleicht die Kernprozesse im Backlog zu haben, an denen Änderungen gemacht werden. Die Priorität richtet sich dann evtl. danach, welcher Prozess am wichtigsten für das Business ist, oder wo die größten Einsparungen realisiert werden können.
Sind das Meetings und Artefakte wie sie im Buche stehen? Sicher nicht, aber es sind Mittel, die dem PO-Team helfen, den Überblick zu behalten und anderen zu geben.
Welche Möglichkeiten habt ihr durch Unzufriedenheit mit dem Status quo gefunden?

Wieso stehen Sie eigentlich auf der Lohnliste Ihrer Firma?

Der Abschluss des Projekts steht kurz bevor. Der Projektleiter übt Druck aus: Schon mindestens drei Mal wurde das Projekt nach hinten verschoben. Wir haben nur noch 4 Tage bis zum Entwicklungsstopp. Die Entwickler sind genervt, der Kunde ist genervt, es herrscht schlechte Stimmung. Wenn wir ehrlich sind, werden wir es diesmal auch nicht schaffen. Nichtsdestotrotz versuchen wir, unser Versprechen so gut wie es nun mal geht zu halten. Wir haben nur zwei Entwickler im Team, die die Software in- und auswendig kennen. Andere Kollegen innerhalb des Projektes haben entweder gekündigt, wurden befördert oder auf andere Projekte versetzt. Die Hinterbliebenen sind entweder neu im Unternehmen und somit unerfahren in der Software, Juniors, die eingearbeitet werden müssen oder Kollegen, die in einer anderen Niederlassung sitzen und von dort aus zuarbeiten. Unterm Strich haben wir also genau zwei Leute, die wissen, wie der Hase läuft und der Rest hilft mit, wo er nur kann. In dieser Hektik treffen zwei Urlaubsmeldungen und eine Krankmeldung ein. Mein erster Gedanke: “Ok, jetzt können wir die Produktivsetzung zum vereinbarten Termin vergessen.” Die Ereignisse überschlagen sich, dann auf einmal eine knallharte Meldung aus den höheren Etagen: Urlaubssperre!
Große Empörung unter den Kollegen! Man versteht die Welt nicht mehr. Was denkt sich das Management nur dabei, solche Methoden einzusetzen? Man schüttelt den Kopf und hat absolut keinen Bock mehr zu arbeiten. Nicht für die!
Rückblende: Ein ganz normaler Montag, ein Jahr zuvor. Die ersten Kollegen treffen so gegen 9 im Büro ein, einige sogar erst zwischen 10 und 11 Uhr. Der erste Druck, der am “frühen” Morgen ausgeübt wird, ist der auf den Knopf der Kaffeemaschine. Dann schlendert man gemächlich ins Büro und unterhält sich ausgiebig mit den Kollegen. Kann ja sein, dass man seit gestern Nachmittag was verpasst hat. Die Welt hat sich weitergedreht, deshalb sollte man unbedingt einen Blick auf bild.de werfen. Nachdem klargestellt wurde, dass alles noch im Lot ist, kommen wir auf die tatsächliche Arbeit zurück. Aber hey, kein Stress! Das Projekt läuft ja noch ne halbe Ewigkeit …
Back to reality … wir sind wieder im Hier und Jetzt und haben große Probleme. Beziehungsweise, ich korrigiere: das Management hat große Probleme. Es wird nämlich klar, dass der zahlende Kunde sehr unzufrieden ist. Genauer gesagt ist er außer sich. Versprechungen wurden nicht eingehalten, viel Geld wurde in den Sand gesetzt und trotzdem muss man sich jetzt mit den Mindestanforderungen zufrieden geben. Mehr ist nicht drin. Die paar Kollegen, die nicht auf Urlaub gehen dürfen, sind sauer. Richtig sauer! Um 16:30 Uhr lassen sie alles stehen und liegen und machen Feierabend. Von Verantwortung gegenüber dem Kunden und dem gesamten Projekt keine Spur.
Fredmund Malik, führender Management-Experte Europas, behauptet in seinem Buch “Führen, Leisten, Leben”, dass in der heutigen Zeit Lusterfüllung und Wehleidigkeit an die Stelle von Pflichterfüllung und Pflichtbewusstsein getreten sind. Wir fordern, dass Arbeit Spaß machen muss und idealerweise noch gut bezahlt ist! Ich stelle mir einen Chirurgen bei einer Operation vor: Mittendrin hört er einfach auf. Er hat genug operiert, jetzt will er Urlaub machen. Wahrscheinlich wären wir empört – erst recht der Patient (wenn er es denn überlebt). Egal, ob der Chirurg gerade Bock hat oder nicht: Fertig ist er erst dann, wenn der Patient behandelt und ordentlich zugemacht wurde. Den Jungs von der Müllentsorgung wird die tägliche Arbeit auch nicht immer Spaß machen, sie muss allerdings getan werden, da ansonsten die Konsequenzen für uns alle unangenehm wären. Sozialarbeiter, Flüchtlingshelfer, Lehrer und Krankenschwestern: Sie alle haben Berufe, die bestimmt nicht lustvoll und spaßig sind – aber notwendig!
“Pflichterfüllung” gehört immer seltener zum Wortschatz unserer Führungskräfte. Man möchte die Mitarbeiter binden, ihnen Möglichkeiten zur Weiterentwicklung aufzeigen. Der Job soll ja Spaß machen! Spaß bezahlt allerdings nicht die offenen Rechnungen. Die Kunden zahlen nicht für Spaß an der Arbeit. Der zahlende Kunde möchte das, was ihm versprochen wurde, zum vereinbarten Zeitpunkt. Lahme Ausreden sind fehl am Platz. Deshalb ist es für unsere Gesellschaft und Wirtschaft wichtig, dass Führungskräfte den Mut haben, Pflichterfüllung zu fordern, auch wenn es nicht populär ist!
Wenn es also das nächste Mal stressig und anstrengend wird, und die Arbeit so richtig keinen Spaß macht und ihre Mitarbeiter klagen, dann fragen Sie doch mal ganz provokant: “Wieso stehen Sie eigentlich auf der Lohnliste dieser Firma?”

Scrum – wider die Methodenfixierung

Je öfter ich agile Implementationen begleite, desto deutlicher wird für mich: Es geht nicht um Scrum. Oder anders gesagt: Das Reden über Scrum lenkt die Aufmerksamkeit von den eigentlichen Themen ab.
In meinem ersten Job war ich ScrumMaster eines neu geformten Scrum-Teams. Ich weiß noch genau, wie viel Zeit ich damals darauf verwandt habe, von Anfang an alles richtig zu machen. Vom Storywriting über das Schätzen bis hin zum Commitment – mein Team hinterfragte beinahe alles – und ich setzte meine gesamte Energie ein, um ihnen zu erklären, warum man das “mit Scrum” nun so machen muss. Auf diese Weise haben wir es geschafft, die ersten Sprints über nichts anderes als Scrum zu diskutieren. Gibt es eine bessere Form, unproduktiv zu sein?
Viele behaupten immer noch, Scrum sei eine Methode oder ein Prozess. Typischerweise geht damit die Forderung einher, man müsse, gerade am Anfang, Scrum “by the book” machen, um erfolgreich zu sein. Zugegeben: Das Befolgen von eng gesteckten Regeln schafft Sicherheit, indem es unerfahrenen Teams einen Rahmen gibt. So diskutieren wir nicht lange, ob fünfzehn Minuten Daily oder eine Sprint-Retrospektive Sinn machen –  wir tun es einfach.
Problematisch wird dieser Ansatz dann, wenn Scrum zum Zweck an sich verkehrt und dadurch zum unhinterfragbaren Dogma erhoben wird. Kritik des Teams wird dann mit der Begründung abgeschmettert, Scrum erlaube das nicht. Was dann passiert, ist leicht auszumalen: Das Team beginnt, Scrum in Frage zu stellen und es als Grund ihrer Unzufriedenheit zu betrachten.
Anstatt mit Scrum wie mit einem roten Tuch vor den Augen unserer Teams hin und her zu wedeln, sollten wir uns viel intensiver mit ihren Problemen auseinander setzen. Woran krankt die Produktentwicklung gerade? Was kann mein Team schon richtig gut? Und wo braucht es jetzt Hilfe? Wenn wir bei solchen Fragen starten, werden wir Scrum einsetzen können, ohne wirklich über Scrum reden zu müssen.
Ich habe kürzlich mit meinem neuen Team ein Backlog Grooming durchgeführt, ohne davon zu erzählen. Es hat einfach gerade gepasst. Mein Team wollte die nächsten Schritte besprechen und wäre – ganz klassisch – eine Excel-Tabelle mit dem Projektleiter durchgegangen. Im Backlog Grooming geht es darum, das Product Backlog so zu überarbeiten und zu pflegen, dass es aussagekräftig und handlungsweisend bleibt. Doch anstatt das zu erklären, habe ich die Teammitglieder gebeten, die aktuellen Themen auf einem Flipchart in ihren eigenen Worten zu formulieren, sie dann gemeinsam zu besprechen und schließlich zu priorisieren.
Meine Hypothese: Wenn es uns gelingt, Scrum besser mit dem Bedarf der Teams zu verknüpfen, dann erschließt sich der Sinn der Artefakte, Meetings und Rolle von selbst. Scrum wird dann nicht mehr als vorgeschriebener Overhead, sondern als Stärkung, als passendes Mittel zur passenden Zeit wahrgenommen. Wenn uns das gelingt, dann können Teams Scrum dafür nutzen, wofür es eigentlich gedacht ist: Als Rahmenwerk, mit dessen Hilfe Ballast abgeworfen und die regelmäßige Weiterentwicklung von Produkten endlich in Mittelpunkt allen Tuns steht.
Ein Tipp zum Schluss: Skizziere auf einem Blatt Papier, wo dein Team gerade steht und welches eine Ziel du mit deinem Team nächste Woche erreichen möchtest. Achtung: Deine Ziele dürfen nicht astronomisch sein, sondern müssen den Möglichkeiten deines Systems entsprechen. Ich kann 100 Meter in 11 Sekunden laufen – 10 Sekunden sind für mich außer Reichweite. Unter dem Stichwort SMART verbergen sich fünf Eigenschaften guter Ziele: Spezifisch, messbar, erreichbar, relevant, zeitlich terminiert.
Wie sieht dein Ziel aus? Vielleicht geht es um eine bessere Einbindung von Teammitgliedern, vielleicht geht es um mehr Zuverlässigkeit in der Lieferung oder um mehr Qualitätsbewusstsein. Egal, was es ist: Überlege dir dann in einem zweiten Schritt, wie du dieses Ziel gemeinsam mit deinem Team erreichen kannst, ohne ein Wort über Scrum zu verlieren. Überlege dir nach Bedarf auch ein Alternativszenario, einen Plan B: Was mache ich, falls mein ursprünglicher Plan nicht funktioniert?
Lass Scrum ruhig im Hintergrund, als Prinzip, vom dem du überzeugt bist, wirken. Nutze Scrum, um dir bei deinen Entscheidungen zu helfen. Ziehe die Inspiration für dein Tun aus Scrum. Aber belästige dein Team nicht damit. Es hat vermutlich andere Sorgen. Setz dich statt dessen mit deinem Team zusammen, sag ihnen offen und ehrlich, wo genau du momentan Handlungsbedarf siehst, was du mit ihnen erreichen möchtest, und arbeiten dann mit ihnen, so lange es nötig ist, an der Erreichung des Ziels. Du wirst dich wundern, wie schnell das Arbeiten nach Scrum zu einer Banalität wird, die keiner mehr hinterfragt.

Commitment und Verbindlichkeit

In einem aktuellen Projekt beschäftigt uns ScrumMaster die Frage, wie wir dem Commitment des Teams im Sprint Planning 1 mehr Verbindlichkeit im positiven Sinne verleihen können. Was bringt uns zu dieser Fragestellung?
Wir befinden uns glücklicherweise in einem Unternehmen, dem es wirtschaftlich gut geht. Zumindest so gut, dass kein Leidensdruck herrscht. Das bedeutet für unser Beispiel, dass es keine Konsequenzen hat, wenn mal die eine oder andere Timeline nicht gehalten wird. Heruntergebrochen auf unsere User Stories heißt das, dass es nicht so schlimm ist, wenn eine Funktionalität bis zum Sprintende nicht geliefert wird. „Dann beenden wir sie eben im nächsten Sprint“, so die Stimmen einiger Entwickler.
Dass es in Scrum jedoch auch darum geht, mit jedem Sprint FERTIGE Funktionalität zu liefern, die dem Kunden als solche im Idealfall auch berechnet werden kann, gerät schnell in den Hintergrund. Was also als ScrumMaster tun, um dem Team den nötigen Schwung zu verleihen, dass Versprochene auch aus eigenem Willen zu liefern? Es gibt mehrere Ansätze, die in geballter Form ihre Wirkung entfalten sollten.
Formuliere Ziele
Als ScrumMaster können wir das Commitment des Teams mit dem Sprintstart noch einmal als Ziel nach SMART (spezifisch, angemessen, relevant, terminiert) formulieren und visualisieren. Hierzu empfehle ich den Beitrag von Bernd Krehoff: „Warum wir Ziele brauchen“.
Dieses Ziel, das sich das Team mit dem Commitment selbst gesteckt hat, noch einmal auszuformulieren und zu visualisieren, so dass es jedem Mitglied täglich vor Augen geführt wird, hilft in der Praxis sehr.
Ziele visualisieren
Wenn man erfolgreiche Menschen fragt, warum und wie sie ihre Ziele erreichen, so fällt immer wieder das Wort „Visualisierung“. Erfolgreiche Menschen sind also in der Lage sich vor Augen zu führen, wie ihr Ziel aussieht, ja sogar wie es sich anfühlt. Im Skirennsport kann man beispielsweise immer wieder Rennfahrer beobachten, die vor ihrem Start das Rennen mit geschlossenen Augen in Gedanken abfahren. Eine Ausnahme war dabei stets die Skilegende zu Lebzeiten, Hermann Maier. Auch dieser fuhr vor seinen Starts die Strecke im Geiste ab, beendete diese gedankliche Fahrt aber nicht mit der Zieleinfahrt, sondern mit dem Jubel über den Sieg. Wie kein Zweiter verstand er es also, sein Ziel und sogar den Jubel zu visualisieren.
Was kann das für unsere Performance in einem Sprint bedeuten?
Ähnlich einem Sportler können wir unsere gesetzten Ziele visualisieren, indem wir unsere User Stories wie oben als abgeschlossenes Ziel formulieren und dieses in schriftlicher oder sogar bildlicher Form in den Teamraum hängen. Die Tatsache, von nun an täglich mehrfach an diesem Ziel vorbeizulaufen, wird die Zielstrebigkeit erhöhen. Ebenso kann man im Team eine Liste führen, in der neu angenommene Tasks vom jeweiligen Teammitglied mit einem selbstgewählten Zieldatum eingetragen werden. Der Umstand, sich ein frei gewähltes Ziel für einen Task zu setzen, wird den Wunsch wecken, dieses auch zu erreichen. Wichtig ist, die Ziele offen einsehbar an einem geeigneten Ort zu platzieren.
Schaffe Bezug
Ähnlich wie bei einer gut geschriebenen User Story sollte es das Team motivieren, wenn es sich unter dem Sprintziel auch etwas möglichst Greifbares vorstellen kann. Beispiel: „Als Facebooknutzer möchte ich bis zum 30.10.2013 den Dislike-Button nutzen können, um auch mein Nichtgefallen eines Beitrages zeigen zu können.“
Belohne den Erfolg
Hier ist Kreativität gefragt. Statt mit Konsequenzen zu drohen, wenn etwas nicht fertig wird, sollten wir eine erstrebenswerte Belohnung für den Sprinterfolg in Aussicht stellen. Welche das ist, sollte jeder individuell für sein Team entscheiden.
Beispiele könnten Grillabende oder andere Dinge sein. Aus Erfahrung möchte ich sagen, dass eine von Herzen ausgesprochene Anerkennung einer Leistung oft mehr Wert hat, als materielle Anerkennungen. Das Leuchten in den Augen desjenigen, der diese Anerkennung bekommt, ist auch für den Aussprechenden ein schöner Moment im beruflichen Alltag.
In der Vergangenheit hat sich gezeigt, dass das Setzen eigener sportlicher, aber angemessener Ziele nach SMART in Verbindung mit Visualisierung und echter Anerkennung stets zum Erfolg führt. Natürlich ist nicht alles rosarot und die Realität zeigt, dass es immer wieder Situationen gibt, in denen das Team am Ende des Sprints nicht wie versprochen liefert. Für diesen Fall ist es empfehlenswert, dass das Team zum Sprintbeginn gemeinsam entscheidet, was die dann folgende Konsequenz ist. Ein Team könnte beispielsweise eine Mannschaftskasse führen, um einen gängigen Vergleich zum Mannschaftssport zu ziehen. Aus dieser werden dann die Team Events finanziert.
Viel Erfolg!

Das Review als Nicht-Meeting

Der Sprint ist zu Ende. Das Team legt die Arbeit nieder und geht in das Review. Und schon ist sie wieder da: Die steife Meeting-Atmosphäre, in der die erlegten Stories nacheinander vorgeführt werden, ScrumMaster und Product Owner im Mittelpunkt stehen, und Anwesende ungeduldig auf den Stühlen rutschen. Wenn es ganz schlecht läuft, muss das Team sich auch noch gegenüber Product Owner und Management rechtfertigen, warum etwas so und nicht anders umgesetzt wurde.
Ein gutes Review ist wie eine gute Retrospektive: In dem einen geht es um die Auseinandersetzung mit dem Prozess, in dem anderen um die Auseinandersetzung mit dem Produkt. Alles andere sollte im Review im Hintergrund verschwinden. So ist es für das Review zum Beispiel irrelevant, wie viele Stories das Team geschafft hat. Ebensowenig sollte das Team im Review irgend etwas vorführen müssen, das keinen Nutzer interessiert. Deshalb macht der Product Owner die Abnahme der fertigen Stories bereits im Sprint und nicht erst im Review.
Für ein erfolgreiches, spannendes und wirklich kommunikatives Review kommt es auf die richtige Perspektive an:

Wie gestaltet ihr Eure Reviews? Was hat funktioniert, was nicht?

Communities of Practice

Scrum tritt an, um Menschen mit unterschiedlichem Wissen, unterschiedlichen Interessen und Erfahrungen zusammen zu bringen, damit sie gemeinsam an der gleichen Werkbank arbeiten. Dafür haben wir cross-funktionale Scrum-Teams. Klassische Rollenunterschiede, etwa die zwischen Tester und Entwickler, werden im Scrum-Team aufgeweicht. Jeder, auch der absolute Spezialist, hat den einen Auftrag, an der erfolgreichen Lieferung in seinem Team mitzuwirken (selbst wenn sein Spezialwissen gerade nicht gefragt ist). Das ist ein deutlicher Unterschied zum klassischen Projektmanamagent, wo unter der Maxime größtmöglicher Auslastung Spezialisten auf verschiedenen Projekten gleichzeitig unterwegs sind.
Um Menschen mit ähnlichem Wissen, Interessen und Erfahrungen zusammen zu bringen, gibt es in Scrum sogenannte Communities of Practice (CoP). Eine CoP ist zunächst eine Gruppe, die freiwillig zusammenkommt, und sich ein Thema zu eigen gemacht. So kann es beispielweise CoPs für Architektur, Testen, UX oder Scrum geben. Anders als Task Forces verfolgen CoPs nicht den Zweck, ein eng gestecktes Ziel zu erreichen. Ebensowenig haben sie die Erzeugung von Statusberichten zum Zweck. Sie sind vielmehr dazu da, Ideen zu generieren und dafür zu sorgen, dass – teamübergreifend – ein gemeinsames Bild entstehen kann. So kann sich zum Beispiel eine CoP zum Thema Testen damit beschäftigen, die Automatisierung von Testfällen in den Scrum-Teams zu platzieren und die Hindernisse auf dem Weg dorthin zu identifizieren. Mike Cohn schreibt, es sei Aufgabe von CoPs, einen gewissen Grad an Konsistenz über die Teams hinweg zu sichern.
Communities of Practice sind als zusätzliche Ebene in Scrum gedacht, jedes Mitglied einer Community of Practice ist in der Regel auch Mitglied eines Scrum-Teams. Wichtig ist, dass CoPs in keinem Konkurrenz- oder Hierarchieverhältnis zu den Scrum-Teams stehen. Das, was in einer CoP anvisiert wird, sollte von den Mitgliedern in ihre jeweiligen Scrum-Teams getragen und dort umgesetzt werden.
Damit heben wir die Dualität auf, die klassischerweise durch vor- oder nachgeschaltete Instanzen auftritt: Ein Team, dessen Mitglieder beispielsweise für die Qualitätssicherung verantwortlich sind, wird immer daran leiden, dass es seine Wirkungsstätte außerhalb der Scrum-Teams hat. Die Scrum-Teams werden dazu geneigt sein, das Thema Qualität an das QS-Team abgehen – und das QS-Team wird am Versuch verzweifeln, die Scrum-Teams zu mehr Qualitätsbewusstsein zu “erziehen”. Selbstorganisation sieht anders aus.
Etienne Wenger unterscheidet zwischen fünf Ausprägungen einer Community of Practice:

Welche CoPs gibt es in deinem Unternehmen? Wie stark sind sie ausgesprägt? Werden sie vom Rest des Unternehmens wahrgenommen? Falls nein: Was kannst du tun, um sie handlungsfähiger zu machen?
CoPs brauchen zwar keinen dedizierten ScrumMaster, aber eine regelmäßige, engagierte Unterstützung (etwa zur Formulierung der gemeinsamen Mission oder zur Moderation der Arbeitstreffen) kann entscheidend sein.
Literatur
http://www.mountaingoatsoftware.com/blog/cultivate-communities-of-practice
https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.PDF

Die KITA-Bewohner spielen wieder!

Sieben frisch aufgesetzte Scrum-Teams arbeiten derzeit eine klassische Releasebeauftragung eines halben Jahres ab. Mitten im Release ging der Überblick darüber verloren, was tatsächlich schon ausgeliefert worden war, was bereits fertig entwickelt war und auf den Releasewechsel wartete und was noch zu tun war. Jedes Team für sich konnte dazu zwar Auskunft geben, aber die Zuordnung zum Company Backlog war mehr als schwierig aus den elektronischen Tools, aber auch vom Releaseboard abzulesen.
Dort sah man zwar ca. 100 Stories und Epics, allerdings konnte man nicht erkennen, was zu welchem Item aus dem Company Backlog beitrug bzw. ob es überhaupt im Company Backlog auftauchte. Die klassische Beschriftung mit Zahlen brachte uns leider auch kein Stück weiter. Also gingen wir auf Textmarker-Jagd, um möglichst viele unterschiedliche Farben zu ergattern. Als wir mit dem ersten Product Owner anfingen, die Stories aus seinem Backlog den unterschiedlichen Company Backlog Items zuzuordnen, gingen uns aber zu schnell die Farben aus. Was in der Theorie so schön aussieht, war bei uns im aktuellen Release absolute Theorie und hatte nichts mit dem tatsächlichen Releaseboard zu tun.
Nach kurzer Ratlosigkeit kam ein ScrumMaster auf die Idee, nicht nur Farben, sondern zusätzlich Symbole einzuführen. Ich gebe zu, ein Workaround! Wir sind einfach noch nicht bei thematischen Releases.
Aber immerhin half uns dieses Vorgehen zu identifizieren, was im Company Backlog alles fehlte und bei welchem der hoch priorisierten Epics im Backlog die Arbeit noch nicht mal gestartet worden war. Außerdem hatte es den schönen Nebeneffekt, dass sich die POs selbst Symbole und Farben aussuchen durften, mit denen sie ihre Stories kennzeichneten. Ich freue mich schon, wenn wir im Grooming demnächst über das Sonnenepic sprechen 😉
Da die Visualisierung initial einiges an Zeit beanspruchte, bekamen wir von den Büro-Bewohnern in unmittelbarer Umgebung des Releaseplans bei jeder Gelegenheit zu hören: “Ach, die KITA-Bewohner spielen wieder.” Für mich war es toll zu sehen, wie das Arbeiten an den Wänden, auf dem Boden und im Stehen zu sehr viel Interaktion und Aktion führte. Stifte wurden hin und her geworfen, über blöd gemalte Symbole gelacht, sich gegenseitig beim schnellen Ausmalen geholfen…
Meine Hypothese, warum es funktioniert hat? Weil es einfach war und jeder sofort mitmachen konnte!
Und trotzdem: Wir haben zwar jetzt eine Zuordnung der “User Stories” und Aufgaben zu einer übergeordneten Liste. Ein Company Backlog ist das allerdings noch nicht. Ein rhythmisches Liefern erst recht nicht! Es hat aber deutlich gemacht, dass wir etwas ändern müssen, wenn wir anfangen wollen, gemeinsam zu liefern!

Vertrauen macht produktiv

Wer kennt es nicht? Die größtmögliche Kreativität und Energie entfaltet sich erst, wenn nicht ständig ein Chef, Vorgesetzter oder Gruppenleiter hinter einem steht und Anweisungen bzw. Aufgaben verteilt. Das zeigt auch das sogenannte „Boss-Worker-Game“ sehr deutlich, das wir in unseren ScrumMaster Avanced Trainings durchführen. Dabei geht es darum, in einem eng gesteckten Rahmen (beispielsweise durch Tische begrenzt) möglichst viele Schritte in kurzer Zeit zu gehen, obwohl viele andere Teilnehmer zur gleichen Zeit dasselbe tun.
Hinter dem “Worker” steht ein „Boss“ und dirigiert ihn mit einfachen Kommandos. Nach einer gewissen Zeit wird das Ergebnis festgehalten und das Spiel mit einer kleinen, aber entscheidenden Änderung wiederholt. Der „Boss“ hat nun keine Befugnis mehr und der „Worker“ darf selbstorganisiert die Schritte tun, die er für richtig hält.Jedes Mal zeigt sich das gleiche Ergebnis: Die Leistung des „Workers“ steigt in der zweiten, selbstbestimmten, Runde erheblich an. Man kann sagen, seine Produktivität erhöht sich deutlich. So viel zur Moral von der Geschicht aus unserem Spiel.
Dass Selbstorganisation innerhalb eines sinnvoll gesteckten Rahmens viel Sinn macht, liest man auch in der Autobiografie “Das bin ich” des Profigolfers John Daly, der noch vor seinem 30. Geburtstag zwei der vier Major-Turniere gewann.
“Coach Loy hatte dafür gesorgt, dass wir alle im Team verhalten spielten. Er vertrat die Mentalität: „Spiel nicht auf Birdie, sonst kommt am Ende Bogey dabei heraus.“ Wir konnten unser Talent nicht beweisen. 1986 übernahm Coach Bill Woodley das Team, nachdem Coach Loy gegangen war. Sie unterschieden sich wie Tag und Nacht. Vollkommen verschieden. Wir waren alle gewissermaßen geschockt. Während Coach Loy gewollt hatte, dass die Dinge nach seinem Willen liefen, liess Woodley uns spielen. Bei Coach Loy hatte sich alles um Disziplin gedreht. Bei Coach Woodley ging es darum, ein Turnier zu gewinnen – wie du es anstelltest, lag an dir. Unter Coach Woodley zeigten wir, wo unsere Stärken lagen. Meine Stärke war der Abschlag. Nun machte mir niemand mehr Handzeichen, wie ich zu spielen hatte. Als Team rückten wir viel enger zusammen und spielten viel lockerer.”
Der kurze Ausschnitt aus John Dalys Geschichte zeigt sehr schön, was Scrum mit Selbstorganisation beabsichtigt:

Letztlich geht es für uns als ScrumMaster darum, dass unser Team sein eigenes Turnier gewinnt, welches auch immer es sein mag. Betrachten wir uns doch einmal als Scrum Coach unseres Teams und stellen uns die Frage, wie sehr wir Selbstorganisation zulassen. Oder macht es uns nervös, wenn das Team selbst über die Schritte entscheidet, die es wann innerhalb des Rahmens geht? Natürlich ist es manchmal schwer, diese Verantwortung abzugeben. Aber viele Beispiele zeigen, dass sich dieser Mut lohnt und Vertrauen mit Leistung belohnt wird.

Inseln der Agilität

Weh mir, wo nehm’ ich, wenn
Es Winter ist, die Blumen, und wo
Den Sonnenschein,
Und Schatten der Erde?
Die Mauern stehn
Sprachlos und kalt, im Winde
Klirren die Fahnen.
Friedrich Hölderlin (Hälfte des Lebens)
„Es gibt kein richtiges Leben im falschen.” Theodor W. Adorno hat damit die moralphilosophische Frage aufgeworfen, ob ein gutes Leben in einer Welt voller Ungerechtigkeit möglich ist.
Im Berufsleben lässt sich die Frage ebenso stellen: Ist ein guter, erfüllender Job in einem schwierigen, frustrierenden Unternehmensumfeld möglich? Menschen reagieren unterschiedlich, wenn sie spüren, dass sie sich in ihrem Job nicht entfalten können. Manche überfallen Selbstzweifel und Angst, andere gehen in den Widerstand bis hin zur Kündigung. Wiederum andere versuchen, sich mit den Verhältnissen zu arrangieren und eine halbwegs komfortable Nische zu finden, in der sie möglichst unbehelligt weitermachen können. Das ist dann so, wie wenn man im Regen unter einem Vorsprung Schutz sucht: Man wird nicht nass, aber wirklich schön ist es dort auch nicht.
In agilen Implementationen gibt es einen anderen Weg. Er läuft auf die Schaffung eines Mikrosystems mit eigener Anatomie hinaus. Dieses Mikrosystem nennen wir Scrum-Team. Indem wir ein Scrum-Team aufsetzen, schaffen wir für seine Mitglieder eine Heimat mit eigenen Werten und Regeln. Indem wir dem Team nach und nach die Verantwortung zur Produktgestaltung übertragen, schaffen wir darüber hinaus eine Arbeitsumgebung mit eigener Taktung.
Beides – Wertesystem und Taktung – sind zunächst nichts anderes als ferne Versprechen. Mitarbeiter, die es gewohnt sind, ihre Verantwortung entlang der Wertschöpfungskette nur punktuell oder diffus wahrzunehmen, stehen dem Versprechen häufig skeptisch gegenüber. Sie sehen im Großsystem Unternehmen alle Ursachen für ihre Unzufriedenheit – und müssen deshalb erst gar nicht anfangen, über ihre eigenen Handlungsfreiheiten zu reflektieren.
Bei der Errichtung eines solchen Mikrosystems hilft eine Führungskraft, die sich einerseits schützend vor das Team stellt, es andererseits aus der Komfortzone locken kann. Wir nennen sie ScrumMaster. Dann passiert etwas Spannnendes: Das Team fängt an, sich aus dem Schneckenhaus heraus zu tasten. Es beginnt zu spüren, dass nicht alles Übel fremdverschuldet ist. Und es bemerkt, dass es mit etwas Kreativität und Elan viel mehr leisten kann, als es sich bisher zugetraut hat.
Die ersten Früchte des Erfolges zeigen sich, wenn das Team anfängt, seine Frustration und Resignation in eine gewisse Unbekümmertheit und Leichtigkeit zu verwandeln. Frei nach dem Motto: Wenn keiner die entscheidenden Fragen stellen kann, dann tun wir das halt selber. Von dort an ist es nicht mehr weit, bis das Team damit beginnt, Entscheidungen selber zu treffen. Und eh‘ man sich versehen hat, ist sie da: Die Insel der Agilität. Zart und zerbrechlich, aber da.
Es gibt es also doch, das „richtige“ Leben im „falschen“. Das Sprint Review ist übrigens das Meeting par excellence, in dem das Großsystem Unternehmen den Gesinnungswandel innerhalb des Scrum-Teams registriert und auch zu schätzen versteht. Was dann folgt, ist ein Geben und Nehmen: Das Scrum-Team fordert heraus – und das Unternehmen lernt, damit umzugehen.
Tipp zum Abschluss: Lass dein Team auf einer Skala von 0-10 positionieren. Die Null bedeutet: Ich habe in meinem Unternehmen gar keine Freiheiten, selber zu entscheiden. Die zehn: Ich habe alle Freiheiten der Welt, selber zu entscheiden. Lass jeden kurz erzählen, warum er dort steht, wo er steht. Und bitte jeden dann, sich eine Maßnahmen zu überlegen, die er sofort umsetzen könnte, um auf der Skala um eine Zahl aufzurücken. Bilde dabei Gesprächspartner, die möglichst unterschiedlich auf der Skala stehen (also z.B. ein „Dreier“ mit einer „Siebener“). Lass die Maßnahmen aufschreiben und jedes Paar innerhalb von 72 Stunden berichten, wie es die Maßnahme umgesetzt hat und was es dabei beobachtet hat.
Theodor W. Adorno (1969): Minima Moralia. Suhrkamp Verlag, Frankfurt am Main.

Sind Taskforces die besseren Scrum-Teams?

Vor kurzem gab es eine spannende Situation bei meinem Kunden. Es gab plötzlich ein produktgefährdendes, technisches Problem – und ohne groß nachzudenken, wurde eine Taskforce gegründet. Die Taskforce hat das Feuer bravourös gelöscht und somit die gesamte Abteilung gerettet. Danach konnten diese Helden wieder in ihre alten Scrum-Teams zurückkehren und „normal weiterentwickeln“. Konkret bedeutet das: endlose Diskussionen zu Design-Konzepten, Murren bzgl. der vielen Scrum-Meetings und laufenden Absprachen, Über- bzw. Untercommittment, mangelndes Interesse an Tests etc.
Kommt euch das bekannt vor?
firefighters-115800_tpsdave_pixabay
Immer wieder stelle ich mir dieselbe Frage: Wieso scheinen Taskforces so viel besser zu funktionieren als Scrum-Teams? Wo ist der ausschlaggebende Unterschied zwischen einer Taskforce und einem Scrum-Team? Für mich ist das ganz einfach: es gibt keinen wesentlichen Unterschied. Doch denke ich, dass die Scrum-Welt noch viel zu lernen hat.
Die letzten Wochen habe ich damit verbracht, unterschiedlichste Personen zu befragen, weshalb die Taskforce so gut funktioniert hat und die Scrum-Teams nur langsam zum Laufen kommen. Hier sind ein paar der Mythen, denen ich auch schon früher begegnet bin:
„Eine Taskforce löst sich nach vollbrachten Tätigkeiten wieder auf.“
Ja, die Taskforce löst sich auf, sobald ihre Aufgabe zu Ende gebracht wurde. Genauso sollte das mit einem Scrum-Team sein: Wenn das Produkt vollbracht ist, kann sich das Team auflösen und anderen, neuen Aufgaben nachgehen. Hier ist die Dauer vielleicht unterschiedlich, aber nicht zwingend.
„Jede Taskforce hat ein klares Ziel.“
Hat das ein Scrum-Team nicht auch? Es gibt eine Produktvision – das übergreifende, große Ziel. Es gibt Backlog Items (Stories), die eines nach dem anderen kleine Meilensteine auf dem Weg zum Ziel darstellen. Und es gibt Sprintziele – greifbar, verständlich, SMART – damit das Team in jedem Sprint weiß, woran es seinen Erfolg orientieren kann.
„Die richtigen Personen kommen zusammen.“
Scrum ist eine Produktentwicklungsmethode. Aus diesem Grund sollte sich der Product Owner sein Team selbst zusammenstellen können – immerhin ist er für den Erfolg des Produktes hauptverantwortlich. Eine andere Möglichkeit wäre es, die operativ tätigen Dev.Teammitglieder selbst entscheiden zu lassen, wo sie etwas beitragen können und möchten. So finden sich auf kurz oder lang auch die richtigen Personen. Inspiration hierzu findet man unter anderem hier auf der Seite der Scrum Alliance.
„Wir stehen vor einer Herausforderung.“
Lasst uns „The New New Product Development Game“ zur Hand nehmen. Darin beschreiben Nonaka und Takeuchi die ersten Scrum-Teams. Und wie sahen die so aus? Jedes der genannten Teams hatte die klare Aufgabe, ein Produkt in kürzester Zeit performanter, besser, innovativer bzw. günstiger zu bauen. Ich kann euch nur raten: Wenn euer Product Owner bzw. das Management diese Herausforderung nicht an das Scrum-Team stellt, solltet ihr enger mit ihnen zusammenarbeiten und eine ähnlich klare Herausforderung einfordern.
„Eine Taskforce hat mehr Freiheiten.“
Genau darum geht es doch in Scrum. Der Rahmen ist gesteckt – einerseits durch das Management durch gewisse Budget-, Revisions- bzw. Infrastrukturvorgaben – andererseits durch den Prozess, der dem klaren, leicht überschaubaren Scrum-Framework folgt. Das gibt dem Team die Möglichkeit, sich innerhalb dieses gesteckten Rahmens frei zu bewegen und sich komplett auf seine eigentliche Arbeit zu konzentrieren – nämlich ein qualitativ hochwertiges Produkt zu liefern. Und falls sich das Team seine Freiheiten doch nicht selbst einräumen kann, gibt es einen ScrumMaster, der als direkter Link zur restlichen Organisation die Möglichkeit hat, jene Probleme transparent zu machen, die die Arbeit des Teams behindern. Der direkte Link zum Management hilft, um klar kommunizieren zu können, was das Team benötigt bzw. eben nicht benötigt, um die Herausforderung zu schaffen.
„Das Management zeigt Interesse an der Arbeit der Taskforce.“
Ist das nicht genau der schöne Nebeneffekt, den das Sprint Review Meeting nach jedem Sprint – typischerweise alle 2 Wochen – schafft, um genau diese Anerkennung und Wertschätzung vom Management bzw. anderen Außenstehenden zu erhalten?! Hier möchte ich aber auch die jeweiligen ScrumMaster und Product Owner auffordern, einfach mehr interne Werbung für ihr Produkt und das dahinterstehende Team zu machen.
„Taskforces müssen sich aufgrund ihrer Kurzlebigkeit nicht um ihre Konflikte kümmern.“
Nicht jedes Scrum-Team muss gleich harmonisch sein. Oft entstehen die besten Produkte durch Heterogenität (siehe Firmen wie IDEO  bzw. das Prinzip der T-shaped People). Die gebündelte Kreativität, die durch die verschiedensten Personen und Meinungen aufeinanderprallt, ist oft sehr anstrengend, aber auch fantastisch (genauso wie bei uns). Wichtig ist, dass die Dynamik des Teams stimmt, damit gemeinsam Leistung erbracht werden kann.
Jedoch, ich gebe es zu, hier gibt es einen kleinen Unterschied. Um genau dieses Thema – die Dynamiken des Teams – kümmert sich der ScrumMaster. Manche Taskforces existieren nicht lang genug, um besonders unterschwellige Konflikte austragen zu müssen. Ein Scrum-Team existiert meist länger, weswegen wir eine dezidierte Rolle für genau solche Fälle haben: den ScrumMaster.
Was haltet ihr von diesen Vergleichen? Mir zeigen diese Mythen bzw. Argumente zwei Aspekte auf:

Seht ihr das genauso?

Vom Suchen und Finden eines Projektplans

Anfangs sind Scrum-Implementationen recht übersichtlich. Dem Aufsetzen von Teams folgt eine intensive Lern- und Ausbildungsphase. Wenn alle Akteure ihre Rolle kennen und selbständig ausüben können, ist diese Phase zu Ende. Manche glauben dann, die agile Transformation sei nun ebenfalls abgeschlossen.
Das aber ist ein Irrtum. Denn Teams, die nach Scrum arbeiten, sind die eine Herausforderung. Die andere Herausforderung besteht im Umbau des gesamten Unternehmens hin zu einer Organisation, die erfolgreiche Produktentwicklung in den Mittelpunkt all ihrer Tätigkeiten stellt.
Und spätestens hier brauchen wir ihn: Den Projektplan für die Scrum-Implementierung. Ihn zu schreiben, ist keine leichte Sache. Auf unserem aktuellen Projekt glaubten wir schon, ihn zu haben. Für die kommenden sechs Monate hatten wir Woche für Woche die jeweils zu erreichenden Ziele eingetragen. Neulich habe ich ihn mir im Rückblick angeschaut und musste feststellen: Die zeitliche Schiene hat nichts gebracht außer der Illusion von Kontrolle. Das, was wir für Anfang Januar eingeplant hatten, ist tatsächlich im März aktuell geworden. Manches hat sich zwischenzeitlich als irrelevant erwiesen. Und vieles, das wir überhaupt nicht auf dem Schirm hatten, beherrscht jetzt unsere Arbeit.
Was war passiert? Wir hatten versucht, in die Kristallkugel zu blicken und dabei das festzumachen, was sich nicht festmachen lässt. Die Zukunft heißt nicht umsonst Zukunft – und jeder, der sie vorauszusagen können glaubt, übernimmt sich ein wenig.
Drei Monate später. Wir stehen vor folgender Situation: Die Scrum-Implementation nimmt vollen Lauf. Das Unternehmen hat beschlossen, die gesamte Entwicklung auf Scrum umzustellen. Das Fehlen eines Projektplans ist jetzt umso deutlicher. Unsere Kalender platzen vor Terminen, wir arbeiten sie nur noch ab. Und noch schlimmer: Keiner weiß so richtig, wo wir in der Implementation stehen. Die ersten fangen an zu glauben, wir seien jetzt mit Scrum fertig – und reagieren mit Unverständnis auf die Forderung des Managements nach weiteren Veränderungen.
In dieser Situation setzen wir uns nochmal hin – und schreiben alle Themen runter, die uns einfallen. Wir sortieren es – was ist Aufgabe des Transition Teams, was gehört zu den ScrumMastern und was zu den Product Ownern? Und wir versuchen es erneut auf eine zeitliche Achse zu bekommen. Wir wissen aus vergangener Erfahrung: Kalenderwochen sind eine zu kleine, zu detaillierte Einheit, um eine erste Orientierung zu bieten.
Also gehen wir gröber ran und ordnen die Themen vier Entwicklungsstufen zu:

Der Vorteil: Sind diese Stufen erstmal hinreichend klar charakterisiert, können wir einschätzen, wo die Scrum-Implementierung gerade steht und was noch alles vor uns liegt. Wir können auch sagen, welche Themen zwar wichtig, aber in der jetzigen Entwicklungsstufe noch nicht relevant sind. Noch deutlicher wird das Bild, wenn in einem weiteren Schritt für jedes Team (Transition Team, SM- und PO-Team) möglichst eindeutig beschrieben wird, woran wir erkennen können, auf welcher Stufe sich die Teams gerade befinden. Ein SM-Team, das von seinen vielen Impediments geradezu erschlagen wird, weil es nicht weiß, wohin es damit gehen soll, steht vermutlich auf der zweiten Stufe: Denn die Probleme sind sichtbar geworden, aber der Blick der ScrumMaster ist noch auf die Probleme, nicht auf die Lösungen gerichtet.

Woran merken wir, ob unser Projektplan funktioniert?


Wenn wir jeden Freitag in den Plan blicken können und daraus unsere Aufgaben für die kommende Woche entwicklen können. Wenn wir Kurs halten können, steuernd eingreifen können – und dann auch erkennen, welche Themen gerade gar nicht wichtig sind, und wo wir unbedingt noch nachhaken müssen. Wenn wir einem Product Owner den Plan zeigen können – und er ohne viel Nachdenken sagen kann, auf welcher Implementierungsstufe wir uns gerade befinden – und was wir als nächstes erreichen möchten.
Wie ist Eure Erfahrung bei größer angelegten Scrum-Implementationen? Woran habt ihr gemerkt, ob die Implementation noch auf Kurs ist? Und wie stellt ihr fest, was als nächstes kommt, was überhaupt noch zu tun ist, bevor die Implementation abgeschlossen ist? Ich bin gespannt auf Eure Erzählungen.

Erfolgreiche Scrum-Teams ziehen an einem Strang

Du bist auf der Suche nach einem Aperitif für deine Retrospektive? Du möchtest das komplette Team ins Tun bringen und zum Teamerfolg beitragen lassen? Du willst zeigen, dass Selbstorganisation Führung braucht und zwar eine ganz bestimmte Art und Weise von Führung? Du suchst nach einer Gelegenheit, dein Team an einem Strang ziehen zu lassen und gleichzeitig Spaß zu haben?
Dann probier mit deinem Team das „Communication Race“ aus. Um loszulegen brauchst du:
Zutaten
Schnur (je Spieler ca. 1 Meter), Quadrat aus Pappe (zugeschnitten auf 20×20 cm), zwei unterschiedlich farbige Filzstifte mit dünner Stiftspitze, 1 Flipchartbogen, ein schwarzer Neuland-Flipchart-Marker, Tisch
Teilnehmer
mindestens vier bis maximal 10 pro Team (bei mehr Spielern Teams teilen)
Zeit
45 Minuten (inklusive Debriefing)
Vorbereitungen für das Spiel
Zuschneiden eines Quadrates aus Pappe (20×20 cm), Filzstift mittig durch die Pappe stoßen und mit Tesafilm von beiden Seiten fixieren. Jedes Teammitglied hat sein Seil in der Pappe fixiert, der Parcours ist auf den Flipchart-Bogen aufgemalt.
Ablauf
Jeder Spieler nimmt sich ein Seilende. Der Stift wird am Startpunkt angesetzt. Das Team versucht nun, den vorgegebenen Weg zu überwinden und die Stiftelinie ans Ziel zu führen. Dieses ist erreicht, wenn eine ununterbrochene Linie vom Start zum Ziel gezogen wurde, die an keiner Stelle über die durch den Parcours vorgegebenen Linien hinausgegangen ist. Kommunikation unter den Teammitgliedern ist erlaubt. Es darf immer nur eine Hand das Seil berühren und nur am Seilende. Es gibt kein zeitliches Limit. Übermalt das Team auf seinem Weg die vorgegebene Strecke, muss es sich zum Ausgangspunkt (Start) zurückbegeben. Alle Teammitglieder müssen in jedem Moment des Spiels eine Hand am jeweiligen Seilende haben.
Mehr zum Communication Race findet ihr unter:  http://tastycupcakes.org/2013/04/communication-race/
Tipps
Ihr könnt bei längeren Strecken Zwischenziele benennen, damit ihr nicht immer wieder zum Anfang zurück müsst. Bereitet das Spielmaterial (Stift, Seil in der Pappe) vor. Der Parcours sollte ebenfalls bereits gemalt sein. Ist das Team sicherer, kann es sich auch später seinen eigenen Weg malen und Schwierigkeiten einbauen.
Varianten
Ihr könnt das Spiel genauso mit einem Team wie mit mehreren Teams in einem Wettbewerb gegeneinander spielen. Ihr erhöht den Schwierigkeitsgrad, wenn das Spiel auf dem Boden gespielt wird oder ihr ein Zeitlimit setzt. Wer denkt, dass er mit seinem Team in der Champions League angekommen ist, der kann das Spiel auch blind spielen lassen (ein Sehender als Kompass, der Rest des Teams kann nichts sehen).
Debriefing
Wer meine Blogs regelmäßig liest, weiß, dass ich ein fanatischer Fan des Debriefings bin, nicht zuletzt, weil nach dem Spiel eben vor dem Spiel ist. Damit das Spiel nicht alleine für sich steht und dadurch mögliche Synergien verloren gehen könnten, ist es wichtig, Leitfragen vorzugeben, die – je nach Thema – richtungsweisend den Spielprozess paraphrasieren und einen Transfer in den Alltag sicherstellen.
Mögliche Fragen können sein:

Spielanlässe
Retrospektive (Einstieg), Rollendefinitionen im Team, ein neues Team findet sich, innere Antreiber im Team (Zeitlimit), Rollenkonflikte, Selbstorganisation braucht Führung, etc.

How to organise a ScrumMaster Team in a large-scale environment?!

Late in the evening at the XP2013 in Vienna, I hosted an open space session under this title and am still surprised at how many participants actually joined me in discussion. It seems that I was not the only one faced with this question. While the session did not provide me with the sought-after perfect solution, it did give me an insight into how other companies structure the collaboration between individual ScrumMasters in order to act as a singular, strong force of change agents.
 
Here are some of the options that came up in conversation and that I can relate to due to having experienced them myself. Of course, these options may vary accordingly.
 

  • Meet on a weekly basis to talk about lessons learned when solving impediments and best practices in Scrum.
  • Meet on a daily basis in front of a ScrumMaster Taskboard (Impediment Backlog) to talk about current impediments and their progress.
  • Form a Scrum-Team and work in Sprints. If necessary, appoint your own ScrumMaster and Product Owner. Hold Backlog Groomings for identifying and prioritising general organisational impediments, Sprint Planning meetings for discussing the ‘What‘ followed by the ‘How‘, and Daily Scrums for synchronising your work. Make sure to finish each Sprint with a public Review and a Retrospective. Hint: Facilitating these meetings in a rotating manner can offer the ScrumMasters a chance to practice and learn new facilitation methods in a safe environment (i.e. different Sprint Retrospective styles).

 
In the end, however, I do not think that there is a right or a wrong answer. The only question that really matters is whether the Scrum-Teams are delivering valuable features or not. And if they aren‘t, the impediments hindering their productivity must be addressed and solved as quickly as possible. I do believe that a Team of like-minded persons with the same mission can achieve more than singular change agents. Once the ScrumMasters understand this for themselves, I am convinced that the right ‘how to‘ will come automatically. And this will probably differ depending on the persons involved and their specific system.

Effektive Wege, um Entscheidungen im Team zu treffen

uote author = “Karl Kraus”]”In zweifelhaften Fällen entscheide man sich für das Richtige.”[/quote]
Die Neuroforschung und alle Arten von Beratungen (z.B. das Coaching) befassen sich zur Zeit sehr intensiv mit der Frage, wie individuelle Entscheidungen zustande kommen und wie man privat, vor allem aber als Führungskraft, damit umgeht. Weniger Fokus liegt dagegen darauf, wie man in Teams effektiv Entscheidungen herbeiführt und schnell und zielorientiert kollektiv entscheidet.
Gruppen- oder Teamentscheidung – das klingt zuerst mal nach “alle reden mit”, nach langen Diskussionen oder gar Debatten (das sich aus “battere” – “schlagen” herleitet) in den Meetings und dann nicht selten mit Ergebnissen, hinter denen nicht alle stehen. Es gibt aber Strukturen, die uns helfen, die jeweiligen Entscheidungssituationen bereits im Vorfeld genau zu prüfen und einzuordnen, um dann den optimalsten Entscheidungsweg zu nutzen. Das kann der jeweils verantwortliche Moderator, der Teamleiter, ScrumMaster, oder auch das Team tun.

  1. Kontextentscheidungen, die von außen vorgegeben werden und umgesetzt werden müssen. Hier empfiehlt es sich, den Grad der Verpflichtung und den Spielraum genau zu checken und keine wertvolle Zeit darauf zu verwenden, breit zu diskutieren oder zu klagen, wenn es nicht weiterführt. Informieren, akzeptieren und umsetzen heißt die Devise. Dafür sollte die Führung sorgen und Transparenz, Sinn und Eindeutigkeit herstellen.
  2. Führungsentscheidungen (Teamleiter, ScrumMaster, ProductOwner, Projektleiter) müssen sich auf die entsprechende Verantwortung und Legitimation beziehen. Sie können je nach Ausgangslage begründet vorgegeben, oder müssen überzeugend verkauft werden. Für die führungsverantwortliche Person ist für die Umsetzung wichtig, das Akzeptanzlevel der Führungsentscheidung im Team zu eruieren. Teams sollten lernen, diesen schnellen und effektiven Weg zu Entscheidungen zu kommen, zu akzeptieren. Am besten funktioniert das über eine solides Vertrauen in die Führung und entspricht dann dem agilen Prinzip der Selbstorganisation, wenn die Führungsentscheidung legitimiert ist.
  3. Mehrheitsentscheidungen sind ein häufig und oft zu schnell praktifiziertes Vorgehen. Sozusagen der Klassiker. Über Information, Austausch und Argumentation bildet sich die Basis für eine Abstimmung. Sinnvoll ist hier der Einsatz visuell gestützter Techniken wie Punktabfragen etc. Zu beachten ist, dass Mehrheitsentscheidungen immer einen Aspekt von Sieg und Verlieren haben. Oft akzeptiert die unterlegene Minderheit das Ergebnis nur bedingt und das kann die Umsetzung schwächen. Bei Mehrheitsentscheidungen ist daher der Kontrollbedarf oft hoch. Die Frage, wer wie kontrolliert, sollte geklärt werden.
  4. Expertenentscheidungen delegieren die Entscheidung auf die hohe fachliche Kompetenz aus Wissen und Erfahrung einzelner Teammitglieder oder Teilgruppen. Auch hier ist transparente Information entscheidend wichtig und das Vertrauen aller in den Fachmann die Fachfrau. Bei dieser Form der Entscheidungsklärung ist es im Teamprozess wichtig, immer Feedback über die (gelungene) Umsetzung des Ergebnisses zu kommunizieren, um allen Sicherheit zu geben, die der Expertenmeinung zugestimmt haben.
  5. Konsensentscheidungen gelten als der “Königsweg” selbstorganisierter Teamentscheidungen. “Das Wort Konsens wurde in der Kanzleisprache im 15. Jahrhundert vom lat. consensus im Sinne von Übereinstimmung, Zustimmung entlehnt. Consensus gehört zu lat. con-sentire, das zusammenstimmen, übereinstimmen, zustimmen bedeutet. Den Titel Consensus tragen jene historischen Urkunden und Schriften, in denen eine erzielte Übereinstimmung bei dogmatischen Streitigkeiten dokumentiert ist.” (Wikipedia) In der Praxis bedeutet das eine Win-Win-Situation für alle am Entscheidungsprozess beteiligten Teammitglieder, die im Dialog erarbeitet wurde und in der Regel als hoch befriedigend erlebt wird. Häufig wird das Streben nach Konsens als zeitraubend, langwierig und extrem aufwendig eingeordnet und die vordergründig  „schnellere“ Mehrheitsentscheidung per Abstimmung gewählt. Sind Gruppen und Teams jedoch in der dialogischen Kommunikation geübt (siehe auch Blogbeiträge “Die wertvolle Meetingzeit sinnvoll nutzen (1)” und “Die wertvolle Meetingzeit sinnvoll nutzen (2)”, ist ein Konsens meist sehr schnell erreicht und unterstützt wirkungsvoll das Klima im Team sowie die Umsetzung und Nachhaltigkeit von Teamentscheidungen. Manchmal kann auch ein bewusster und transparenter Konsens im Dissens hilfreich sein, d.h. alles sind sich einig, dass aktuell die Unterschiede nicht aufzuheben sind und man sich in der Sache nicht einig ist. Muss jedoch unbedingt eine Entscheidung her, einigt man sich auf eine Führungs-, Experten- oder  Zufallsentscheidung (z.B. Los), die dann von allen angenommen und umgesetzt wird.

Zum Schluss noch ein paar Tipps für den konkreten Umgang mit Entscheidungen im Team:

Bewusste und selbstbewusste Führung formt starke Teams – lernen, wie es funktioniert: Scrum Supplements

Produktivität mal anders

Als ScrumMaster hat für mich die Produktivität meines Entwicklerteams die höchste Priorität. Impediments, sprich Blockaden, zu identifizieren und aus dem Weg zu räumen ist dabei meine hauptsächliche Tagesaufgabe. In einem meiner Projekte lief das mal auf ganz andere Art und Weise.

Ich seh etwas, das du nicht siehst

Ich drehte wieder einmal meine Runden durch unser Großraumbüro und da fiel mir plötzlich auf, dass einige Entwickler Schwierigkeiten mit dem Sehen zu haben scheinen. Das merkt man zum Beispiel an  verkniffenen Gesichtern, unnatürlichen Kopf- und Körperhaltungen oder gar gerötete Augen.
Als ursprünglicher Augenoptikermeister war ich gleich wieder in meinem alten Element und betrachtete das Thema Software-Entwicklung einmal mit ganz anderen Augen. Ich stellte mir die Frage, wie ein Entwickler wohl produktiv sein kann, wenn ihn aufgrund der nicht idealen Brille für den Arbeitsplatz brennende Augen, Rücken oder Kopfschmerzen plagen. Denn häufig ist dem so. Passt die Brille nicht zum Arbeitsplatz oder die Stärke der Brillengläser ist nicht mehr die aktuelle, hat das die eben beschriebenen Folgen.
Viele Menschen klagen darüber. Oft müssen sich Menschen am PC-Arbeitsplatz sogar täglich die Frage stellen: „Will ich gut sehen oder bequem sitzen?” Das eine darf im Idealfall das andere natürlich nicht ausschließen. Mit der richtigen Brille. Abhilfe muss also her.
Über alte Kontakte organisieren wir nun eine „Sehtest-Initiative“, in der ich den Entwicklern eine Augenüberprüfung anbieten möchte, um daraufhin mit einer Messbrille die ideale Korrektion der Sehschwäche direkt am Arbeitsplatz zu simulieren. Dem Entwickler kann der Nutzen einer optimalen Versorgung auf diese Art und Weise direkt vor Augen geführt werden. Im wahrsten Sinne. Und dies direkt an seinem Arbeitsplatz.
Lassen wir uns überraschen. Die Aktion wurde von den Team-Mitgliedern mit Vorfreude aufgenommen und wir organisieren derzeit das nötige Equipment für die Messungen über einen ortsansässigen Optiker.
Das formulierte Ziel ist jedenfalls klar: Produktivität bei gutem Sehen und bequemer Kopf- und Körperhaltung.

Wann ist ein Impediment ein Impediment?

Impediments sind häufig gar nicht so sichtbar und es ist eine Herausforderung , diese letztlich doch immer wieder zu identifizieren. Lange habe ich mich gefragt, wann ist ein Impediment wirklich ein Impediment und wann nur eine Kleinigkeit? Letztlich habe ich für mich und meine Arbeit herausgefunden, dass tatsächlich alles, was das Team davon abhält produktiv zu sein, ein Impediment darstellt. Und sei es nur die defekte Schreibtischlampe, deren Neubeschaffung in großen Konzernen leider Tage und zig Unterschriften bei Einkauf, Management etc. in Anspruch nimmt.
Also arbeite ich nach dem Motto: “Nichts ist zu klein, um ein Impediment zu sein.”

Warum überhaupt schätzen?

Schätzen bedeutet für viele Menschen Stress. Wie sollte es auch anders sein? Solange Schätzungen herangezogen werden, um das Fertigstellungsdatum festzulegen, wird es ein abgekartetes Spiel bleiben. Die einen wollen ein tolles Produkt liefern und versuchen daher, durch möglichst großzügige Angaben und dem Einschieben von vielen Pufferzonen ihre Freiheit zu erkaufen. Die anderen wollen den Kunden behalten, haben ihm vielleicht sogar schon Zusagen gemacht, und versuchen daher, die Zeit bis zur Auslieferung maximal zu reduzieren.
Natürlich ist die Spannung beiden Seiten bekannt – und so versucht jeder, das Spiel mit möglichst wenig Kompromissen zu überstehen. Das Spiel kostet üblicherweise viel Zeit und Nerven, und führt letztendlich zu lokalen Optimierungsstrategien: Hier die Strategie, das beste Produkt zu entwickeln. Dort die Strategie, den besten Marktwert für das Produkt zu erzielen. Das Gesamtergebnis muss suboptimal bleiben, weil jede Strategie eigensinning arbeitet, ohne die andere wirklich miteinzubeziehen.
Angesichts dessen haben wir zwei Möglichkeiten: Das Schätzen komplett sein zu lassen und dem Kunden nur noch das zu versprechen, was in den nächsten Iterationen jeweils fertig gestellt werden kann. Vorteil: Der Kunde zahlt für genau das, was er bekommt. Und er kann nach jeder Iteration entscheiden, ob er noch mehr braucht. Dadurch spart er sich den Aufwand und die Schleierhaftigkeit, die mit allen großen Spezifikationskatalogen einhergehen. Nachteil: Nicht jeder Kunde möchte so arbeiten.
Die zweite Möglichkeit besteht darin, das Schätzen komplett umzudeuten. Wir machen das so: Anstatt die Entwicklungsmannschaft nach dem Fertigstellungsdatum zu fragen, lassen wir sie mit dem Product Owner über das Produkt reden. Geht es zum Beispiel darum, ein neues Suchfeld zu implementieren, wird nicht über Aufwand für Entwicklung und Testen gesprochen, sondern um die Funktionalitäten dieses neuen Suchfelds.
Die Entwicklungsmannschaft fragt dann den Product Owner, was dieses Suchfeld leisten soll: Nach welchen Kriterien Anfragen durchgeführt werden sollen, in welcher Reihenfolge und Form die Ergebnisse angezeigt werden sollen, und so weiter. Aus solchen Gesprächen entwickelt sich ein gemeinsames Verständnis für das Produkt. Das Team wird in die Lage versetzt, die noch verbleibende Arbeit nach ihrem funktionalen Umfang zu schätzen.
Und damit ist auch die Brücke zwischen Entwicklung und Markt geschlagen: Der Product Owner, der nach einigen Sprints weiß, wie viel Funktionsumfang sein Team im historischen Durchschnitt pro Sprint liefern kann, kann nun zum Kunden gehen und ihm anhand seines priorisierten Backlogs erklären, welche Funktionalitäten er wann erwarten kann (Kristina Kleßmann hat hier eine anschauliche Beschreibung zum Schätzen nach Funktionalität geschrieben).

Eine große Umstellung

Das Schätzen nach Funktionalität bedeutet für viele eine große Umstellung. Wir alle sind es gewohnt, nach Aufwand zu schätzen. Ein Entwicklungsteam möchte möglichst früh klären, was alles zu tun ist, um eine neue Produkteigenschaft zu implementieren. Zudem wird beim Schätzen nach Funktionalität schnell deutlich, wenn keine Weiterentwicklung stattfindet. Konzeptstories (auch “Spikes” genannt) liefern genau so wenig Produktivität wie technische Aufgaben und solche, die “nur” auf ein Redesign einer bestehenden Funktionalität abzielen. Im “schlimmsten” Falle heißt das dann: Das Team hat über mehrere Sprints keinen funktionalen Mehrwert geliefert. Für viele Teams ist das ein echtes Problem – vor allem dann, wenn das Management sie an ihrer Velocity (also dem Durchsatz an Funktionalitäten pro Sprint misst). Sie schätzen dann lieber nach Aufwand oder Komplexität (oder einer alchemistisch anmutenden Mischung aus beiden), um dem Unternehmen zu zeigen: Schaut her, wir machen unsere Arbeit.
Und so ist es in Scrum häufig wie beim Arztbesuch. Keiner steht gerne im Unterwäsche vor dem Mensch im weißen Kittel, um sich auf Herz und Nieren prüfen zu lassen. Trotzdem ist es wichtig, sich ab und an die Blöße zu geben. Zu erkennen, dass es hier und da nicht so gut läuft. Dass kein Kunde der Welt wirklich bereit ist, für Konzepte oder Generalüberholungen zu zahlen. Dass ein Unternehmen es nicht mehr schafft, seine Produkte weiter zu entwickeln, sondern an Bestehendem herumdoktert.
Entscheidend ist dabei, wie ein Unternehmen mit dieser Erkenntnis umgeht. Wie geht es Mitarbeitern, die solche Defizite offen ansprechen? Werden sie ernstgenommen und anerkannt, oder eher sachte beiseite geschoben und am Ende des Tages ignoriert? Und selbst wenn es ein Problembewusstsein gibt: Führt das im Unternehmen zu Hilflosigkeit und Frustration oder raufen sich alle zusammen, um einen Schlachtplan zu entwerfen? Teams spüren sehr genau, wie ihr Unternehmen tickt, welche “Persönlichkeit” es hat. In einem Unternehmen, das am liebsten gut dastehen möchte, wird die Offenheit, die mit dem Schätzen nach Produktivität einhergeht, keine guten Chancen haben. Das heißt aber nicht, dass die Methode die falsche ist. Es zeigt nur, dass sie nicht zum Selbstverständnis des Unternehmens passt.
Siehe auch: Martin Fowler: Purpose of Estimation

Mit dem Computer Code bessere Teamarbeit erreichen

Zusammenarbeit im Team ist das A und O. Dabei werden Ergebnisse oder Lieferungen dann besonders gut, wenn es das Team geschafft hat, auf der Grundlage einer gemeinsamen Strategie zu planen und das Geplante dann Stück für Stück umzusetzen und anzuwenden. Bei Veränderungen, Unwägbarkeiten oder Lageänderungen gilt es, flexibel reagieren zu können und nicht an seinem ursprünglichen Plan festzuhalten (inspect and adapt). Dies gelingt durch regelmäßiges Feedback und/oder Innehalten. Im Laufe eines solchen Prozesses erlebt man immer wieder die Wirkung unterschiedlicher Handlungsmuster und muss darauf reagieren. Hier hat die Rollenverteilung im Team (who is who, wer macht was und warum, etc.) herausragenden Einfluss auf den Prozessverlauf und die Ergebnisse. Nicht selten kommt es bereits vor, aber auch während des Entstehens einer Lieferung zu Zielkonflikten (z.B. Was ist wichtiger? Arbeitsqualität oder Arbeitsgeschwindigkeit).
 
Die im ersten Absatz beschriebenen Aspekte sind für ein Team nichts Neues, sondern eher Alltag. Was kann man nun verbessern? Wie kann die Teamperformance gesteigert werden? Wie wird ein gutes Team noch besser? Wo fängt man an? Was ist das Wichtigste? Auf all diese oder weitere Fragen in dieser Richtung gibt es zumindest eine Musterantwort: Das ist von Team zu Team verschieden, man muss es ausprobieren und im wahrsten Sinne des Wortes erleben.
Mit dem nachfolgenden Teamspiel möchte ich euch einladen, die Reise “Wie verbessere ich Teamarbeit” anzutreten und durchzustarten. Nirgendwo ist der Mensch authentischer als beim Spielen. In diesem Sinne: Lasst das Spiel beginnen.

Der Computer Code – was braucht es, um mit dem Spiel zu starten?



Teilnehmer:   bis 25
Zeit:   30 Minuten
Ort:   Freifläche
Material:   50 Moderationskarten (rund und mit den Zahlen von 1 bis 50 beschriftet), Marker (schwarz), langes Seil (ca.15m), Stoppuhr
 
Ablauf und Regelwerk
Der ScrumMaster bereitet die Übungsfläche vor, ohne dass die Gruppe dabei zusieht. Mit der Schnur wird eine Spielfläche eingegrenzt, in die anschließend die Moderationskarten mit der beschrifteten Seite nach oben und nach dem Zufallsprinzip in der von der Schnur eingegrenzten Spielfläche verteilt werden. In ca. 10 Meter Entfernung wird eine Linie (Start) gezogen. Die Gruppe positioniert sich hinter der Startlinie.
Die gesamte Gruppe startet immer hinter der Startlinie (Stoppuhr läuft los – Versuch 1 bis 5). Der jeweilige Versuch endet mit der Rückkehr des letzten Teilnehmers hinter die Startlinie (Stoppuhr stoppt – Versuch 1 bis 5 endet). Damit endet ein Versuch. Die Gruppe hat in einer Gesamtzeit von 30 Minuten fünf Versuche, das Spielproblem zu lösen. Während eines Versuches darf sich immer nur eine Person innerhalb der umgrenzten Spielfläche aufhalten. Alle Teilnehmer dürfen bis zum Rand an die Spielfläche treten. Bei einem Verstoß berechnet der Spielleiter 20 Sekunden auf die Endzeit. Die “Strafzeiten” werden jeweils laut ausgerufen.
 
Ziel des Spiels ist es, dass die Gruppe es schafft, in möglichst kurzer Zeit alle in der Spielfläche liegenden Moderationskarten in der richtigen Reihenfolge (1, dann 2, dann, 3, dann, …bis 50) zu berühren (z.B. Hand oder Fuß) – also der richtige Code muss in den Rechner eingegeben werden. Falls eine Zahl in verkehrter Reihenfolge (z.B. 5 vor 4) berührt wird, werden ebenfalls 20 Sekunden auf die Endzeit berechnet. Schnelligkeit bringt also nur dann einen Nutzen, wenn das Endprodukt eine entsprechend hohe Qualität hat (z.B. wenige Fehler).
Die Moderationskarten dürfen ihren Ursprungsort nicht verlassen. Sind die fünf Versuche beispielsweise nach 20 Minuten beendet, dann ist auch das Spiel beendet. Hat das Team nach 30 Minuten erst drei Versuche absolviert, ist das Spiel ebenfalls zu Ende.
 
Besondere Spielhinweise
Die Entfernung zwischen Startlinie und Spielfläche sollte so groß sein, damit die Position der Zahlen nicht sichtbar ist. 50 Moderationskarten sind eine mögliche Anzahl. Es können entsprechend der Teamgröße auch weniger sein (d.h. bei 25 Personen ca. 50 Karten, bei 10 Personen reichen ca. 30).
Wichtig: Es darf nur hinter der Startlinie gesprochen werden! Nonverbale Signale sind auch sonst möglich. Sprechen im Spielfeld, also nach der Startlinie, wird jeweils mit 20 Sekunden Strafe versehen.
 
Varianten
Es können einzelne Zahlen in der Reihenfolge weggelassen werden.


Das Wichtigste zum (Ab-)Schluss
Lasst eine Intervention, in diesem Fall das Teamspiel “Computer Code”, nicht allein für sich stehen oder geht gar zur Tagesordnung über. Natürlich macht Spielen Spaß, aber es wäre schade, wenn ihr das Erlebte nicht reflektiert. Ich halte es für essentiell, zu hinterfragen, welche Erkenntnisse das Team aus der Intervention für sich ziehen kann, die in das Daily Business transferierbar sind. Rundet daher eine Intervention stets mit einem Debriefing ab! Nur auf diese Weise könnt ihr sicher stellen, dass eine intensive und wirksame Auseinandersetzung mit den Gedanken, Gefühlen und Reflexionen zur Umsetzung in den Teamalltag gewährleistet ist. Wie man ein gutes Debriefing gestalten kann, um eine gemeinsame Beschreibung der gemachten Erfahrungen zu erreichen, könnt ihr in meinem Blog “Wie viel Standing braucht ein ScrumMaster” nachlesen.
 
Literatur
Kriz, C. & Nöbauer B. (2006). Teamkompetenz. Konzepte, Trainingsmethoden, Praxis. Vandenhoeck & Ruprecht.
 
 
Übrigens: Seid ihr bei der XP 2013 in Wien dabei? Vom 3.6.-7.6. ist auch das bor!sgloger-Team vor Ort und wird die Besucher ordentlich in Bewegung bringen. Versäumt nicht das Supersize-Ball-Point-Game beim Open Space am Dienstag Nachmittag (4.6.)!

Lass dich überzeugen

Manchmal ertappe ich mich dabei, etwas ungeduldig zu werden, wenn Teams nicht sofort auf sinnvolle Vorschläge anspringen. Dabei weiß ich natürlich ganz genau, dass man nur das (gut) tut, von dem man auch überzeugt ist.
Ein anderer ScrumMaster erzählte mir dann, wie er kürzlich mit einer solchen Situation umgegangen ist. Er hat den Spieß quasi umgedreht. Nachdem das Team über die Vor- und Nachteile einer bestimmten agilen Praktik (automatisierte Tests) diskutiert hatte und sich dann als Team dafür entschieden hatte, diese Praktik fortan anzuwenden, hat er sich nochmals davon überzeugen lassen, um die Entscheidung zu verstärken.
Er begab sich in die Position/Haltung des Nichtwissens und ließ sich von den Teammitgliedern erklären, warum sie nun „unbedingt“ die Praktik einführen wollen. Dabei hat er so getan, als würde er das Vorgehen selbst nicht kennen und somit auch nicht die damit verbundenen Vorteile. Mit interessiertem Nachfragen hat er das Team dazu gebracht, ihm genau zu erklären, wie diese Tests funktionieren und warum es gut ist, automatisiert zu testen. Mit neugierigem Nachfragen hat er sich vergewissert, ob die Wirklichkeit des Gegenübers mit seiner übereinstimmt bzw. hat er die innere Landkarte des Teams besser kennengelernt. Er hat nicht einfach etwas angenommen und sich mit Hypothesen aus der vorangegangenen Diskussion zufrieden gegeben, sondern über diese Intervention seine und die vom Team konstruierte Wirklichkeit miteinander abgeglichen.
Nach einiger Zeit sagte er dann: “Achso, ihr wollt also diese automatischen Tests machen!”
Geradezu erleichtert rief das Team im Chor: “JA, GENAU!!!!” (Und meinte damit: “Endlich hat er es verstanden!!!”)
Kann man sich ein schöneres Commitment für die Anwendung einer bisher nicht genutzten agilen Praktik vorstellen, die man an viele Teams nur mit Mühe und Not herantragen kann?
Leider war ich nicht dabei. Bei der nächsten Möglichkeit werde ich mich aber auch mal überzeugen lassen anstatt überzeugen zu wollen!

Hut auf reicht nicht!

…nun bist du also ScrumMaster. In einem neuen Team, in einem für dich neuen Unternehmen, in einer neuen Branche. Quasi in der Fremde. Du betrittst das Glatteis. Es fühlt sich wackelig an. Und dennoch ist da der Reiz des Neuen, des Unbekannten. Eine unsichtbare Kraft motiviert dich wieder mal aufs Neue, einen guten Job zu machen. Aber, nur weil du nun den Hut des ScrumMasters, des latenten Teamleads auf dem Kopf trägst, bist du noch nicht von allen unumstritten und akzeptiert in deiner Rolle. Das klingt hart, ist jedoch die Realität, so wie ich sie in vielen Fällen erlebt habe, wenn ich die Führung neuer Teams übernahm. Dennoch kein Grund zum Pessimismus, solange man sich vor Augen führt, dass es nun zu liefern gilt. Sprich, Taten spürbar und transparent für das Team folgen zu lassen. Was also tun? Ich möchte einige Beispiele beleuchten, die einem auch als Branchenneuling helfen, von einem gestandenen Team akzeptiert zu werden.

Sei du selbst die Veränderung, die du dir wünschst für diese Welt!

Mit diesem Zitat von Mahatma Ghandi möchte ich eine Überleitung zu den kleinen alltäglichen Dingen schaffen, die jedoch schnell deutlich positive Wirkung haben können. Das kann heißen, die Teammitglieder am Morgen mit einem freundlichen Händeschütteln zu begrüßen, ihnen häufig ein Lächeln zu schenken oder mit regelmäßigen anerkennenden Worten zu ihrem Verhalten oder ihren Taten Respekt zu zollen. Es wird sich zeigen, dass ihre Erwartungen diesbezüglich übertroffen werden, denn sie sind diese Verhaltensweisen aus ihrem Berufsleben sehr wahrscheinlich nicht gewohnt. Ich selbst bin beruflich mit der Philosphie „behandle andere so, wie du selbst behandelt werden möchtest“ aufgewachsen. Daher erlebe ich, wenn ich mich daran halte, dass es aus dem Wald heraus schallt, wie ich es hinein rufe. Die anderen sind der Spiegel eines selbst. Dies meine ich hier im positiven Sinne. Schenke ich den Teammitgliedern einen respektvollen und freundlichen Umgang, so erhalte ich diesen zurück.

Taten sagen mehr als 1000 Worte!

Stehe zu dem was du sagst, besonders zu dem, was du ankündigst. Das ist eine Erkenntnis, die ich aus vielen Erfahrungen teilen möchte. Teammitglieder, Mitarbeiter, Kollegen oder andere merken sich in der Regel sehr gut, was angekündigt wurde. Es herrscht also eine Erwartungshaltung. Auch wenn sie noch so klein ist. Das können wir gut finden oder eben auch nicht. Aber es ist so. Wir haben sie durch Worte erzeugt. Also sollten wir unseren Worten auch Taten folgen lassen. Nicht nur das. Ob ich vorgebe, also sage, ein engagierter Kollege, in unserem Falle SrumMaster zu sein, oder es tatsächlich vorlebe, ist ein großer Unterschied. Fragen wir uns also. Ehrlich und im Stillen mit uns selbst. Bin ich wirklich für die Teamkollegen da? Habe ich ein Ohr für ihre Themen? Lebe ich Engagement vor oder sehe ich eigentlich zu, stets sehr pünktlich den Arbeitsplatz zu verlassen und bin meist der Erste, der geht?

Schaffe Transparenz!

Ganz egal, ob als ScrumMaster, Manager, Führungskraft … Man steht im Fokus. Gewollt oder nicht. Die Berechtigung den „Hut“ zu tragen, der uns zum ScrumMaster macht, müssen wir uns immer wieder durch Taten verdienen. Hier hilft uns die Transparenz. Häufig ist die Arbeit eines ScrumMasters nicht so sehr sichtbar. Wir hacken nicht den halben Tag in unseren Computer. Wir sind häufig nicht zu sehen, da wir in irgendwelchen Meetings stecken und abends können wir keine Verkaufszahlen präsentieren. Machen wir doch also einfach transparent, was wir den Tag über so tun. Machen wir es sichtbar. Wir brechen uns keinen Zacken aus der Krone. Und, ich finde es geht die Teammitglieder sehr wohl etwas an, was ich für sie und unser Team den lieben langen Tag so tue. Das funktioniert sehr gut über ein persönliches Taskboard, das in Papierform (Flipchart) an unserem Platz hängt, sowie ein ebenso sichtbares Impediment Backlog. Unsere Aufgabe ist es schließlich, Impediments aufzuspüren und aus dem Weg zu räumen. Das darf gerne sichtbar sein. Erledigte Impediments oder Tasks wandern über unser Board. Ein Gradmesser für unsere Leistung. Für uns und unsere Teamkollegen. Letztlich möchte ich mich noch dafür aussprechen ebenso transparent zu machen, wo ich mich befinde. Auch das kann man am persönlichen Taskboard ersichtlich machen. „Im Meeting/Raum xyz oder auch „in der Mittagspause“ sind mögliche Varianten, dem Team zu zeigen, dass ich es respektiere.
Die Beispiele, die ich heute beschrieben habe, sind sehr leicht umzusetzen, haben jedoch große Wirkung. Denn häufig scheitert es einfach im Kleinen und in der Häufung dieser Kleinigkeiten. Wer kennt es nicht?! „Mein Chef sagt mir nie Guten Morgen“ oder „…nie werde ich gelobt“. Diese und andere Aussagen haben wir alle schon gehört oder vielleicht sogar gemacht. Gehen wir also mit positivem Beispiel voran und sorgen für eine gute Stimmung. Lieferung, Qualität, Produktivität und Profitabilität sind zwar die klaren Erwartungen und Ziele, die ein Scrum-Team verfolgt und erfolgreich macht. Das, was uns letztlich jedoch glücklich macht neben unseren Erfolgen, ist eines: Stimmung.
Abschließend möchte ich eine Frage zum Nachdenken stellen:
„Ob groß oder klein. Begeisterung ist nichts anderes als übertroffene Erwartung. Was tue ich dafür?“

Der Sin Obelisk oder die Tücken der Teamdynamik

Auf meinen vielen Reisen habe ich stets die beste Möglichkeit zu reflektieren. Sei es im Zug, Taxi, Bus, Flugzeug oder in der U-Bahn – ich genieße es, diese Zeit damit zu überbrücken, dass ich meine Gedanken über die letzten Stunden schweifen lasse. Im Zug von München nach Oldenburg reflektierte ich letztens über das Team Booster Training, das ich in den letzten zwei Tagen bei Dieter Rösner absolviert hatte. Wir waren eine spannende Gruppe (bestehend aus zehn Männern und mir als Quotenlady), die durch die Teamentwicklungsübungen innerhalb von 16 Stunden Training, einem Sushi-Dinner in der Innenstadt und einem Absacker-Weizen an der Hotelbar langsam aber stetig zusammenwuchs. Die erste Übung, die wir jedoch als „Team“ durchführen hätten sollen, war der Sin Obelisk. Diese Übung wird mir noch eine Weile in Erinnerung bleiben.

In diesem Spiel geht es darum, anhand von (teilweise unnötigen) Informationen auf Spielkarten eine einigermaßen simple Rechenaufgabe im Team zu lösen. Das Spiel zeigt die Dynamik von Teams sehr gut auf. Wer mehr zu diesem Spiel erfahren möchte, kann es gerne hier (http://www.teamentwickler.eu/sin-obelisk) nachlesen.

Unsere Durchführung war das reinste Chaos. Da ich normalerweise aus dem Blickwinkel des Coaches ein Team beobachte, fand ich es spannend, mal Teil eines DevTeams sein zu dürfen. Oh boy, hab ich das schnell bereut! Obwohl ich nun doch ein Weilchen im agilen Umfeld tätig bin und schon einige Teams gesehen habe, verlief die Kommunikation und Rollenteilung letztendlich so chaotisch, dass ich mich mental komplett ausklingen musste und die Hälfte des Spieles nur von der Seitenlinie aus zusah.

Weshalb kam es dazu? Und weshalb hat niemand darauf reagiert, dass sich ein Teammitglied abseilt? Oft gibt es keine simple Antwort auf diese Frage, doch in diesem Fall schon. Zwei Themen spielten darauf ein: Rollentrennung und Misskommunikation. Der ScrumMaster war kein ScrumMaster, sondern agierte stattdessen als DevTeammitglied. Das DevTeam hat es – u.a. als Resultat daraus – nicht geschafft, auf einer Ebene zu kommunizieren. Die Liste an Frustrationen, die innerhalb von 40 Minuten aufgrund dieser zwei elementaren Fehler zustande kamen, ist lang.

Hauptproblem: Kein gemeinsames Ziel

Die Fragestellung der gewünschten Lösung war einigen Personen bis zum Schluss unklar. Die (mangelnde) Visualisierung wurde nur dank eines Dev.Teammitglieds gestartet. Der ScrumMaster war Schriftführer und Rechenmeister zugleich. Die Konversationen liefen kreuz und quer. Wenn eine Frage auftrat, wurde sie nur zur Hälfte beantwortet, da sich alle ständig gegenseitig unterbrachen. Unnütze Informationen, die schon als solche identifiziert worden waren, wurden weiterhin öfters in den Raum geworfen. Der Kunde wurde nicht eingebunden. Obwohl eine (falsche) Lösung in der Hälfte der Zeit ausgerechnet wurde, verschwendeten wir die gesamte Timebox (Sprint), statt den Kunden früher um Feedback zu bitten. Als ein Dev.Teammitglied für (Kommunikations-)Ordnung sorgen wollte, kam eine direkte Ansage vom mitentwickelnden ScrumMaster: „Ich bin hier der ScrumMaster.“ Das i-Pünktelchen war für mich erreicht, als ein Einzelgänger im Dev.Team die korrekte Antwort fand, diese vom Kunden bestätigt bekam und das Team in seiner Dynamik weiterhin auf seinem eigenen, aber falschen (Rechen-)Weg beharrte.

Die multiplen Vergleiche zu einem echten Scrum-Team werde ich nicht explizit aufzählen. Die kann man schnell erkennen bzw. spätestens nach dem eigenen Ausprobieren der Übung vermutlich bestätigen. Doch eines möchte ich hervorheben: Unsere Ausübung des Sin Obelisks hat die Wichtigkeit der ScrumMaster Rolle auch für alle Skeptiker verdeutlicht. Hätte der dezidierte ScrumMaster seine Führungsrolle komplett eingenommen, hätte er darauf geachtet, dass das WAS klar ist, bevor wir uns in das WIE stürzen. Er hätte jedem eine Stimme gegeben und das Kommunikationschaos entbündelt. Das Feedback des Kunden wäre frühzeitig eingefordert worden und er hätte sich über jeden Verbesserungsvorschlag aus dem Team gefreut. Und so wären wir gemeinsam und vermutlich schneller zur Lösung gekommen – ohne dass ich von der Seitenlinie zuschauen musste und ein Dev.Teammitglied die Lösung alleine fand.

Doch eines muss ich dem ScrumMaster lassen: In der anschließenden Retrospektive war er sehr reflektiert und äußerte viel Selbstkritik. Hätten wir die Übung ein weiteres Mal spielen können, bin ich mir sicher, dass wir eine eindeutige Verbesserung erzielt hätten. Und nicht nur, weil wir die richtige Antwort dann schon kannten…

Termine zu den nächsten Scrum Supplements Trainings mit Dieter Rösner findet ihr hier.

ScrumMaster schützen den Prozess oder warum klein(st)e Veränderungen Applaus bekommen

„Wir wollen das Scrum of Scrums (SoS) anders gestalten – und zwar grundlegend. So, wie es jetzt gerade läuft, funktioniert es nicht.“
Mit diesen Worten begrüßte mich vor einiger Zeit ein Company ScrumMaster, den ich zurzeit coache. Er berichtete, dass das Scrum of Scrums seit einigen Wochen bei den Teams in der Kritik stehen würde, weil die dort besprochenen Inhalte den Teams wenig Mehrwert brächten und die dort investierten 15 Minuten Zeitverschwendung seien. Es sei vor allem herausgekommen, dass nicht jedes Team jedem anderen Team etwas zu sagen habe – und schon gar nicht jeden Tag. Vielmehr gäbe es Teams, die immer mit den gleichen Teams kommunizieren und genau das müsse man verstärken und statt einer großen Plattform mehrere kleinere Gelegenheiten schaffen, bei denen diese Themenverwandtschaften besprochen werden können. Man habe sogar schon einen Namen für diese neue Form der Zusammenarbeit gefunden: Meta-Scrums. Die ScrumMaster haben sich nach Rücksprache mit ihren Teams entschieden, das SoS- Setting mit „Meta-Scrums“ zu revolutionieren.
Ich lobte meinen Coachee für diese tolle Idee und unterstütze seine Ausführungen, indem ich auf seinen nachhaltigen Inspect-and-Adapt-Drang verwies. Ich schloss mein Lob mit einem nachdenklichen Seufzer. Leicht verunsicherte fragte mich der Company ScrumMaster, ob ich mit der Entscheidung nicht zufrieden sei.
Ich antwortete: „Ja und nein.“ Ich bestärkte ihn erneut darin, immer auf der Suche nach Verbesserungen bzw. Veränderungen zu bleiben und die Teams weiter als Meinungs- und Stimmungsbarometer zu nutzen (Ask the team). Ich erläuterte ihm aber, worin ich ein Problem erkannt habe. Meines Erachtens wäre eine Big-Bang-Lösung das falsche Signal an die Teams und würde der Reputation der ScrumMaster eher schaden. Warum? Der ScrumMaster hat die Verantwortung, den Scrum-Prozess zu bewahren und alles dafür zu tun, um die Produktivität seines Teams zu steigern. Mit der Meeting-Revolution würde jedoch der Prozess in Frage gestellt werden.
Wurde wirklich alles unternommen, um das kritikbehaftete SoS zu etablieren? Nein. Auf die Frage, ob alle ScrumMaster dafür gesorgt hätten, dass der Sinn des Scrum of Scrums in den Teams verstanden wurde und damit die (Selbst-) Verantwortung der einzelnen Teammitglieder geklärt sei, musste der Company ScrumMaster sich eingestehen, dass das „interne Marketing“ für das SoS Lücken aufwies. Seine Entscheidung für einen vollständig neu aufgesetzten Prozess kam noch stärker ins Wanken, als ich ihn bat, sich nochmal vollständig von seiner gefundenen Lösung zu entfernen und meine Fragen zu beantworten: Was war gut am alten SoS-Prozess? Was hatte das SoS bislang erfolgreich gemacht? Warum sollte man das SoS unbedingt behalten? Ich intensivierte meine Lösungsfokussierung, indem ich dem Company ScrumMaster riet, auch sein ScrumMaster-Team mit dieser Denkrichtung zu konfrontieren.

Alles anders

Gesagt, getan. Zwei Wochen später wurde ich bei meinem nächsten Besuch Zeuge eines lebhaften, gut besuchten, produktiven Scrum of Scrums. Am Ende gab es sogar Applaus! Die Teams applaudierten ihrer eigenen Performance. Verrückte Welt! Was ging hier vor sich? Wurde ich gerade Zeuge des ersten Scrum-Bestechungsskandals? Wurde verdeckt körperliche Gewalt an den Teams geübt?
Nein! Natürlich nicht. Aber wie war dann diese (Ver-)Wandlung zu erklären? Es klingt fast zu simpel, aber das ScrumMaster-Team hatte lediglich zwei klein(st)e Veränderungen vorgenommen:

Durch eine Verstärkung der Team-Autonomie wurde erreicht, dass das SoS einen neuen Anstrich erhielt. Faktisch wurde an (nur) zwei kleinen Schrauben im Räderwerk des Meetings gedreht. Das Ergebnis: klein(st)e Veränderung, große Wirkung. Es ist immer wieder beeindruckend, was möglich ist, wann man Teams mit einem Mehr an Autonomie ausstattet. Genau so verstehe ich das Prinzip der Selbstorganisation. Das erste Setting des SoS hatte einen kleinen, engen Rahmen mit wenig Freiheitsgraden, wenig Spielraum für Fehler und klaren Grenzen. Mit der Zeit werden die Teams freier, sicherer im Prozess und wünschen sich mehr Gestaltungsspielraum. Agil sein bedeutet, diese Freiheit zu geben und die Voraussetzungen dafür zu schaffen, dass der Prozess weiter funktioniert.
Die agile Haltung „inspect and adapt“ hat nicht den Anspruch, im großen Stile gelebt zu werden. Viel wichtiger ist es, konsequent dafür zu sorgen, dass der Hunger nach Verbesserungen nie gestillt ist. Alles ist möglich, alles kann/darf, aber nichts muss. Entscheidungen sind immer in die Zukunft gerichtet und sind daher immer mit Unsicherheit behaftet. Sie sind jedoch genauso wenig in Stein gemeißelt und können jederzeit justiert werden – wenn wir uns den Handlungsspielraum für Veränderungen bewahren, agil bleiben. Bevor jedoch ein neuer Weg eingeschlagen wird, sollten wir innehalten und uns (retrospektiv) umschauen, um für uns festzuhalten, was gut an dem Weg war, den wir gegangen sind und was wir von dem, was gut war, behalten sollten – nutze, was existiert und, wenn es dich erfolgreich macht, dann mach es größer.

Zählen ist doch ganz einfach, oder?

Auf der Suche nach Separators (Unterbrechern zwischen den Sequenzen “Was lief gut?” und “Was kann verbessert werden?”) für eine Retro bin ich auf drei ganz einfache und doch wirkungsvolle kurze Übungen gestoßen. Sie lassen sich ohne großartige Vorbereitung und Zeitaufwand durchführen und können je nach Retro-Ziel eingesetzt werden.
 
Variante 1 habe ich letzte Woche ausprobiert. Nach dem anfänglichen „Wie jetzt? Wir sollen bis 3 zählen? Ist das Dein Ernst?“, stellte sich schnell Überraschung ein. Es stellte sich nämlich heraus, dass es nicht so einfach ist, wie gedacht.
Durch die Kombination von kognitiver und physischer Aktivität verbinden sich unterschiedliche Bereiche im Gehirn. Dadurch wird auch das einfache Zählen bis 3 zu einer Herausforderung!

Variante 1: 1, 2 … 3

ca. 3-5 Minuten – mindestens 2 Personen

  • Jeweils 2 Personen tun sich zusammen und zählen bis 3. Dabei wechseln sich die Personen immer ab (Person 1 zählt 1, Person 2 zählt 2, Person 1 zählt 3, Person 2 zählt 1, Person 1 zählt 2 usw.).
  • Nach ca. 30-40 Sekunden hin und her zählen gibt es eine neue Vorgabe: Die Zahl 1 muss jedes Mal durch z.B. ein Klatschen ersetzt werden.
  • Wieder 30-40 Sekunden später wird die 2 durch hüpfen, stampfen, Füße anheben etc. ersetzt. Als Beobachter und Spielanleiter ist es lustig, die Gesichter der Zähler zu beobachten – man kann ihnen die Konzentration quasi ansehen.
  • Je nach Belieben kann man weitere 30-40 Sekunden später auch die 3 durch eine Geste ersetzen. Nicken, auf den Tisch klopfen, einmal in die Runde drehen etc. Vielleicht hat auch einer der Zähler eine gute Idee.

Nachher kurz fragen, was beobachtet wurde, bzw. wie man sich bei den Änderungen der Vorgaben gefühlt hat. Evtl. kann man die Brücke zur aktuellen Situation (Veränderung im Unternehmen, Scrum im Allgemeinen) schlagen: einfache Regeln können schwer zu befolgen sein, Koordination, zeitliche Abstimmung und Synchronisation sind nicht einfach. Bei Veränderungen braucht es immer wieder eine gewisse Zeit, bis man sich auf die neuen Rahmenbedingungen und das Gegenüber eingestellt hat.

Variante 2: 33 / 42

ca. 5 Minuten – mindestens 3 Personen

  • Teilnehmer stehen im Kreis und rufen nacheinander (z.B. reihum) die Zahlen von 1 bis 33 (oder eine andere beliebige Nummer – je nachdem, wie lange es dauern soll).
  • Immer wenn die Zahl durch 3 teilbar ist oder eine 3 enthält, wird ANSTATT die Zahl zu rufen, gemeinsam in die Hände geklatscht (oder eine andere Geste ausgeführt).
  • Wird ein Fehler gemacht, fängt man wieder bei 1 an – bis die Gruppe es zu der vorgegebenen Zahl schafft.

Hier muss man mitdenken und den anderen zuhören. Man kann nur als Team liefern!

Variante 3: Blindes Zählen

ca. 10-15 Minuten – mindestens 5 Personen

  • Die Teilnehmer stehen im Kreis und schließen ihre Augen.
  • Es soll laut bis 10 gezählt werden. Jede Zahl darf aber nur von einer Person und einmal genannt werden.
  • Wird eine Zahl von zwei oder mehr Personen laut genannt, fängt man von vorne an.

Hier ist Kollaboration gefragt. Möglicherweise kommt das Team drauf, dass eine Person komplett alleine zählt oder sie eine bestimmte Reihenfolge festlegen.
 
Wo ich das gefunden habe, gibt es noch mehr :-): http://agiletrail.com/2012/03/27/8-great-short-games-for-groups/ – vielen Dank fürs Teilen! Oder versucht das Linie-Überqueren von David aus.
Viel Spaß beim Ausprobieren und Variieren!

How internationally distributed Teams can improve their Sprint Planning 2

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 7)
Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum
Part 6: How internationally distributed Teams can improve their Sprint Planning 1
Stephanie G.: Having discussed Sprint Planning 1, let us continue with your tipps & tricks for Sprint Planning 2. How would you conduct this design meeting?
Ina K.: I would actually say that it‘s quite similar to Sprint Planning 1, apart from the Product Owner not being present. Sometimes the meeting is off to a slow start. If that‘s the case, the ScrumMaster should get involved and start filming people (see Christof’s answer in How internationally distributed Teams can improve their Sprint Planning 1) as well as make sure that the Team members who document the meeting rotate. Once the Team members properly get going, the ScrumMaster can retreat  and remain in a position of observation. Watch the Team – are they interacting enough? Do they seem to have a common understanding? Is everyone adding to the conversation? It‘s important to keep an eye out for such things, as the DevTeam members usually don‘t. Once they actually start looking out for it by themselves, the ScrumMaster has achieved wonders.
Hélène V.: The most important aspect of Sprint Planning 2 is that the common design solution that the Team has agreed upon is visualized and can be seen by all Team members. Only if this has happened, can the distributing of Tasks on a cross-location basis begin. Some Teams think that they do not need any visualisation … all I can say is that distributed Teams who believe this myth have a much higher chance of forgetting important aspects to their design.
Kristina K.: My Team had this issue. The fact that they typed up the Tasks into an electronic tool didn‘t help either, since it sometimes seemed that only the one who did the typing also did the thinking. The fact that the know-how was so unevenly distributed was an impediment in Sprint Planning 2, too. The lack of drawing meant that there was no real common Team understanding of the design – they didn‘t talk about how to implement the User Stories, but rather talked about what singular steps were necessary to implement them.
Bernd K.: We didn‘t really have what you can call a design session either. Sometimes the Team members used the flip charts for drawing, but then I had to take a picture (since the quality of our webcam was not good enough) and send it to the other Team members. This alone would take 5 minutes, by which time the moment for entering in the design discussion was over.
Generally, I did not enjoy Sprint Planning 2 – it often stretched out over three to four hours, which is two hours longer than a Sprint Planning for a two-week sprint should be. The problem was that our electronic tool did not have a word limit for Tasks, meaning that the Team often spent ages on writing them. This did not help to bridge the geographical gap either: the Team members in Romania were rather pragmatic, while the ones in Germany could be called the „philosophers“ – wishing to specify their Tasks and over-thinking the why what, when and where. While the Team dynamic of a co-located Team would have quickly eliminated this discrepancy with smiles or a nervous look, the Romanians were hidden behind a microphone and nobody knew what they were thinking.
Kristina K.: Oh dear, that sounds quite irritating. What I started implementing after a while was to ask the various locations to prepare several design options and to then challenge each other during Sprint Planning 2. In the end, we used the best idea out of all of them and wrote Tasks for it. This ensured that everyone on the Team had actually thought about the Stories, even if they‘re no expert.
Hélène V.: Yes, that‘s what I would recommend, too. After Sprint Planning 1, the Team should do a short mapping of the areas and topics that need discussing. You could then divide up the topics for each location i.e. location A takes the module on the database approach, location B focusses on another solution etc.
Christof B.: I agree with both of you, but I think that the decision of splitting up a Team for or in preparation of Sprint Planning 2 really depends on the Team constellation. If all roles are represented at all locations, I do think that the Sprint Planning 2 can be conducted as group work – meaning that each location grabs its own User Story, does its own mini-Sprint Planning 2 and then presents it to the rest of the Team after 30 minutes. After reviewing the outcome, the entire Team writes the Tasks together. However, this is only possible if both front-end and back-end are present at all locations. This option is not possible if i.e. testers and developers are in different locations.
Stephanie G.: It is so interesting that you all recommend splitting up the meeting, since I actually used to do the same. Only I did not split it in the way of one Story in each location, but rather one person from each location formed a Team, which would together work on one Story (see Pre-SP2 Design Sessions or How to use your Time during a Sprint Change?).
Christof B.: Sprint Planning 2 should not be underestimated. It is certainly not trivial, as it can be chaotic due to the necessary interaction between the Team members. After all, it is not only a meeting, but a creative process, design thinking, architectural brain-storming etc. A lot happens during SP2. I don‘t believe that its doable over the phone. It‘s even nearly impossible to do via video conference. I really think it‘s best if each location works on its own concept during Sprint Planning 2, which is only interrupted by SoS-like coordination meetings where the whole Team gets together again. For example, a design session for 30-45 minutes, followed by 10-15mins of presentation by each location including feedback.
Deborah W.: Funny. I never had any difficulties with Sprint Planning 2, meaning that I could always really enjoy this meeting. I thought it was one of the simpler ones when dealing with distributed Teams. Maybe it was an exception, but my Team members got really involved – even across locations. It was easier than SP1, since there was always less to show. Yes, we did draw a few diagrams and design the architecture, but not for too long. The topic was pretty clear to everyone, so the meeting was concise and short.
Stephanie G.: I love it when opinions diverge as much as yours right now. So before you all get jealous of Deborah‘s Team, let me quickly sum up the main points of advice:

 

ScrumMaster sind Meister der Effekte und Illusionen (Teil 2) – der Halo-Effekt

Im Psychologiestudium war die Wahrnehmungspsychologie eines meiner Lieblingsfächer. Ich kann mich noch gut daran erinnern, wie mein Professor zwei Fotos zweier Männer mittleren Alters nebeneinander hinlegte: Der eine im teuren Armani-Anzug, frisch rasiert, wie aus dem Ei gepellt. Der andere im Freizeitlook, Drei-Tage-Bart. Der Professor fragte uns: “Bei welchem der beiden Herren würden Sie eher eine Lebensversicherung  kaufen?” Interessanterweise entschieden sich fast alle Studenten für den Anzugträger und wurden damit Opfer des Halo-Effekts (vom Griechischen hàlos = Lichthof). Der Halo-Effekt (oder Hofeffekt) ist einer der am häufigsten auftretenden Beurteilungs- bzw. Wahrnehmungsfehler. Er besagt, dass die Dominanz einzelner Eigenschaften bzw. Attribute den Gesamteindruck einer Person bestimmt und auf diese Weise die Wahrnehmung weiterer Eigenschaften überstrahlt. So können Äußerlichkeiten wie das Aussehen, die Kleidung oder gar die Körpergröße den Ausschlag dafür geben, ob man z.B. kompetent oder freundlich wahrgenommen wird. Das Märchen “Des Kaisers neue Kleider” von Hans Christian Andersen ist ein schönes Beispiel für die kritische Auseinandersetzung mit den Auswirkungen des Halo-Effekts.
Ein ScrumMaster sollte daher stets auf der Hut sein. Er sollte zumindest um den Halo-Effekt wissen und nicht nur sich, sondern auch sein Team vor seinen Fallen schützen. Denn es ist gerade das System “Team”, das den Sirenen des Halo-Effekts auf besondere Weise verfällt: “teams tend not to be blamed for their failures“. Charles E. Naquin and Renee O. Tynan von der Universität von Notre Dame fanden in The Team Halo Effect: Why Teams Are Not Blamed for Their Failures”  Nachweise dafür, dass “the nature of the causal attribution processes used to diagnose failure scenarios leads to individuals being more likely to be identified as the cause of team failure than the team as a collective. Team schema development, as indexed by team experience, influences this effect, with individuals who have more team experience being less likely to show the team halo effect.”

Wenn das Team halo-ziniert

In zwei interessanten Studien belegen Naquin und Tynan ihre Hypothesen, die für jeden ScrumMaster Anlass sein sollten, sich und die Performance seines Teams kritisch zu hinterfragen. Ich gebe diese Empfehlung, weil Teams, genauso wie Individuen (vgl. Attributionstheorie von Weiner, die zu den kognitiven Emotionstheorien zählt), zwar die Ursachen ihrer Erfolge den eigenen Fähigkeiten zubilligen, Misserfolge werden jedoch meist (nicht immer, aber überwiegend) äußeren Einflüssen (und eben nicht mangelhafter Planung, unzureichender Kommunikation, schlechter interner Aufgabenverteilung oder fehlender Schwerpunktbildung) zugeschrieben. Der selbstkritische Blick wird durch die eigene Hybris verfälscht und durchgehend abgeschwächt. Selbst Retrospektiven, also die eigens für ein Team geschaffene Plattform, offen, direkt und schonungslos eine Inventur der eigenen Performance zu machen, um möglichst produktiver zu werden, geben im Schritt 4 “Was könnte verbessert werden” ausreichend Gelegenheit für Halo-zinationen: z.B. “Wir haben viel zu viele Meetings, um überhaupt was arbeiten zu können”, “Wir sind viel zu heterogen, um unsere Arbeit zu teilen oder an den gleichen Aufgaben gemeinsam zu performen”, “Wir können das SP1 und das SP2 ruhig mischen. Das geht doch dann alles viel schneller”, usw.
Das Phänomen des Halo-Effekts ist typisch, menschlich und nicht vollkommen auszuschalten. Aber es lässt sich eindämmen, indem der ScrumMaster es offen anspricht und den Mut hat, seinem Team den Spiegel vorzuhalten. Er ist der Prozesshüter. Er ist verantwortlich, dass die Produktivität steigt. Gelingen kann das, wenn das Team seine Leistung ohne Halo-zinationen beleuchtet und auf dieser Grundlage hinterfragt. Nur so kann die “Weisheit der Vielen” zur Entfaltung kommen und die wirklichen Stärken einer Gruppe zum Ausdruck bringen. Das Ganze ist immer mehr als die Summe seiner Teile und demnach sollte der Fokus des ScrumMasters immer auf beiden “Systemen” liegen bzw. sie gleich wichtig analysieren und verbessern wollen: das Individuum und das Team. Ich sehe viel zu selten, dass ein ScrumMaster das Team als Ganzes betrachtet und coacht (außerhalb der Retrospektive). Die Kunst dabei ist, das Team so zu sehen, als wäre es ein Individuum. Aber eben eines mit unterschiedlichen Charakteren – eine ganz besondere Herausforderung.


Literatur
Charles E. Naquin &Renee O. Tynan (2003). Team Halo Effect: Why Teams Are Not Blamed for Their Failures. Journal of Applied Psychology Copyright 2003 by the American Psychological Association, Inc.
2003, Vol. 88, No. 2, 332–340. University of Notre Dame
ScrumMaster sind Meister der Effekte und Illusionen (Teil 1) – der Othello Effekt

How internationally distributed Teams can improve their Sprint Planning 1

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 6)
Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum

Stephanie G.: Now that we have already spoken about the Daily, I would say we continue with the first meeting of a Sprint – the Sprint Planning 1. Anything you would recommend to watch out for in this meeting?
Kristina K.: I sometimes find that Teams do not really discuss Stories or ask questions about them prior to Sprint Planning 1. As a ScrumMaster, one should keep an eye out for this. Particularly with distributed Teams, one should try to arrange discussions that would normally emerge in an everyday Team setting i.e. during lunch time after an Estimation Meeting. I  could imagine that the distributed setting makes the use of the Sprint Planning Checklist even more important, as it provides the Team members with a clear structure and can inform them about the Story by way of going through a set of topics. As you can hear, I find the preparation for Sprint Planning 1 – meaning the discussing and clarifying of the upcoming User Stories – to be absolutely vital. Ideally, the Team members should enter the meeting already knowing the upcoming Stories really well, so that they have lots of ideas for i.e. Acceptance Criteria and a list of questions prepared. In the best case, the meeting is shorter than the planned time-box.
Ina K.: Yes, it‘s the Product Owner‘s responsibility to give the required information to the Team in advance and make sure that it has been registered by all of the Team members before going into the Sprint Planning 1. You‘ll laugh – but yes, this also includes the access to where the Product Backlog and any additional information can be found.
Hélène V.: I recommend that – at the very beginning of Sprint Planning 1 – the Product Owner should give an overview of his expectations of what he wants the Dev.Team to have achieved until the end of the Sprint.  It is important that everyone on the Scrum Team has one shared big picture of the product. After that, there‘s always the possibility of dividing up into smaller groups either cross-location or per location and only coming together in Scrum of Scrums.
Kristina K.: And don‘t forget to take more breaks than you normally would, since it‘s much more exhausting to do it over the phone. Also, make sure to involve everyone as much as possible, so that they don‘t fall asleep at the other locations.
Christof B.: Since the Sprint Plannings are the longest meetings in Scrum, it‘s important to be visually connected as well, as it‘s much more difficult to stay focused if you can‘t connect any faces to the voices. In the past, I‘ve actually attended the Sprint Planning of Ina‘s Team and it was always interesting to see how she would use a standard webcam and play film director with it. It‘s not very interesting to see static images – the mind stops noticing them after a while – but if you do it like Ina, who used to walk around the room, film people when yawning or chitchatting, it‘s much more entertaining and more real-life, I would say.
Stephanie G.: Ina, that sounds like you had quite a lot of fun during your meetings. But now I‘m wondering – what happens during the meeting itself?
Bernd K.: We actually came together for every second Sprint change, which was very helpful. For every other Sprint change, we generally used our tool iceScrum and while the PO would present his Stories one after another, each location would follow his talk on its respective screen. Whoever then had a question could use the computer mouse to circle the part in the User Story that needed more detailled explaining. However, we always had to ask explicitly whether the persons in Rumania had any questions, as they mostly had their microphones on mute due to the background noises in their office. Furthermore, the quality of the audio tool was not ideal, which meant that we had to repeat ourselves quite often. But the Sprint Planning 1 really made the progress of the Team quite obvious: in the beginning, the guidelines where more or less dictated, yet after a few months, the Team really began sitting down and typing up Requirements, User Acceptance Tests etc by themselves.
Deborah W.: We always used flip charts. I think that if you use actual paper, it might be easier for people‘s minds to start wandering off, while on the other hand, it‘s also much easier to get them involved again. We used flip charts on both sides and had static cameras streaming the image, and while the one location was writing, the other one saw the scene on their screen. We switched to the other location’s flip chart after every Story. The cameras were excellent, so we could decipher everything. Besides, we were also connected via teleconference. A piece of advice: if you don‘t have the chance to set up flip charts in all locations, then try to involve those watching with some small tasks – for example: get them to write down User Acceptance Tests in advance. Anything to get them mentally involved.
Christof B.: Yes, and don‘t forget to send the pictures of the flip charts to the other locations afterwards, so that they can print them off and hang them up on their own walls, too.
Stephanie G.: Alright – thanks a lot. Anything else to add that we haven‘t covered yet?
Ina K.: One last thing. What I always enjoyed doing as a ScrumMaster was to ask the Dev.Team a few – perhaps simple –  questions, particularly when a Team member looked slightly lost. This way, I make sure that nobody loses face by having to ask a question that should really be clear to all members of the Team. In the past, my questions have often triggered a discussion within the Team, showing that there had still been some slight confusion. Having asked my Team members for feedback, I‘ve also learned that a lot of questions aren‘t asked, as they think that it would be embarrassing and they‘d rather wait for Sprint Planning 2 in the hope that it comes up automatically. With this in mind, I would say that asking questions from an “outside perspective” almost belongs to the ScrumMaster‘s job description under the aspect of „Protect your Team“.
Stephanie G.: Thank you for all your input. Our readers will surely appreciate that a lot. Summing up the steps, you would recommend:

  1. Make sure  that the Team comes prepared and knows the Product Backlog.
  2. The PO should start the Sprint Planning 1 by presenting the big picture.
  3. If you can use flip charts, do so – but don’t forget to send the images to the other locations.
  4. Ask (some simple) questions to make sure that everyone has the same understanding.

Alright, now what about the next meeting – Sprint Planning 2?!

Die (Über-)Lieferung von Vertrauen

Nahezu jedes Unternehmen hat Erfahrungen mit der Beauftragung von Software-Entwicklungsprojekten und das sind zum Teil schlechte Erfahrungen. Durch solche schlechte Erfahrungen haben über die Zeit immer mehr Organisationen das Vertrauen in ihre Software-Entwicklung verloren. Ich möchte nicht behaupten, dass es nur furchtbare Software-Entwicklungsprojekte gibt. Aber ich behaupte, dass wir hier zu großen Teilen in einer Vertrauenskrise leben. Diese Vertrauenskrise hat nicht nur mit enttäuschten Erwartungen zu tun, sondern auch mit einer veränderten Welt, in der Vertrauen nicht mehr über langfristige Bindungen aufgebaut wird (Vertrautheit), sondern in der Schnelllebigkeit entstehen muss. Wir brauchen also einen anderen Weg, um Vertrauen über mangelnde Vertrautheit zu entwickeln. Kommen wir nochmal zurück zu den Software-Entwicklungsprojekten und verallgemeinern kurz: Umso weniger Vertrauen besteht, desto mehr Kontrolle möchte man ausüben. Vertrauen und Kontrolle versteht man weitläufig als entgegengesetzte Pole, die nicht gleichzeitig existieren können.

Wenn wir das Problem kennen, dann kennen wir doch auch die Lösung?

Vertrauen entsteht nicht über Worte, das wissen wir bestimmt, denn das ist neuronal in unserem Gehirn so verankert. Wir benötigen also Taten, die sich einer schnelllebigen Welt anpassen. Taten, die es ermöglichen, die Erwartungen eines Auftraggebers, eines Kunden und jene von Endnutzern mit dem Beauftragten abzugleichen. Wir als Software-Entwickler brauchen Lieferungen qualitativer, anwendbarer Software in kurzen Zyklen. Mit den Lieferungen zeigen wir, dass wir verstanden haben und liefern können was beauftragt wurde. Wir zeigen, dass wir den impliziten Anspruch auf Qualität halten können. Zudem rücken wir Kunden und Nutzer in den Mittelpunkt, beziehen ihn immer wieder in die Entwicklung ein und geben ihnen eine Stimme. Wichtig dabei ist, dass wir diesen Prozess wiederholen, ritualisieren, oft durchführen, damit wir als Software-Entwickler Verlässlichkeit zeigen können. Wir zeigen, dass es kein Glückstreffer war, sondern dass wir wiederholt qualitative Software  liefern können – wir zeigen professionelles Arbeiten. Im Scrum-Prozess stehen die Lieferung und das Präsentieren der fertigen Funktionen am Ende jedes Sprints, üblicherweise nach 14 Tagen. Am Ende jedes Sprints zeigt das Scrum-Team die lauffähigen Funktionen im Review den Kunden und Nutzern.
Da wir gerade beim Kunden sind, bleiben wir kurz bei ihm. Es wäre fahrlässig, würde der Kunde die Kontrolle aufgeben. Die beauftragte Software ist relevant für die Ergebnisse des eigenen Unternehmens und soll dazu beitragen, die Zukunft des Unternehmens zu sichern. Als Kunden brauchen wir also einen Kontrollmechanismus. Diesen Kontrollmechanismus sollte man nicht an Worten, konkret Verträgen, festmachen, sondern man sollte auch hier wieder auf Taten setzen. Ein wichtiges, wenn nicht gar das Kontrollelement des Kunden sind die Reviews, die er einfordern und aktiv daran teilnehmen sollte. Das Review ist die Fortschrittskontrolle und die Kontrolle des inhaltlich Gelieferten. Zudem ist es die Kontrolle über die Schnelllebigkeit der Märkte, denn wenn Sie als Kunde agil entwickeln lassen, bekommen Sie Kontrolle über Time-to-Market und haben Einfluss auf Änderungen – idealerweise sogar “Change for free“, solange sie auch den Umfang Ihres Produkts/Projekts anpassen. Dafür sollten Sie auch einen Vertrag aufsetzen, der das Ganze widerspiegelt. Auch das ist heutzutage möglich und sogar Wunsch bei vielen Software-Entwicklungen.

Fazit

Liefern wir als Software-Entwickler regelmäßig in kleinen Abständen mit hoher Qualität, so haben wir die Chance, zerstörtes Vertrauen aufzubauen oder dem gewährten Vertrauensvorschuss gerecht zu werden. Nutzen wir Rückkopplungspunkte wie Reviews dazu den Kunden einzubinden, lösen wir sogar das Paradoxon von Vertrauen und Kontrolle zu unserem Vorteil auf. Letztlich gewinnen beide, der Kunde und die Software-Entwicklung. Die Software-Entwicklung vielleicht sogar ein wenig mehr, denn sie hat etwas zurückzugewinnen und das gilt für die gesamte Branche.

How internationally distributed Teams can improve their Daily Scrum

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 5)
Part 1: Does distance cancel out efficiency of internationally dispersed Teams?

Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Stephanie G.: Now that we have discussed internationally distributed Teams in broader terms, I would like to get to the more practical part of this interview. Let‘s start with the most frequent meeting: the Daily Scrum. Would you say that it‘s more difficult to stay within the time-box of 15 minutes in comparison to co-located Teams? Is there something that you would really advise watching out for during the Daily?
Ina K.: No, I wouldn‘t say that it‘s any different in terms of keeping the time-box. It‘s all about keeping an ear open for discussions that don‘t belong in the Daily. Sometimes it‘s just a matter of using the microphone and asking the Team, “Is the current discussion of interest to everyone? Could we perhaps talk about this afterwards?“ The ScrumMaster should always ponder over how the Daily Scrum could be made even more efficient, since a lack of concentration and focus by the Team members leads to a downward spiral of effectiveness. I always found it important to act as a kind of motivator, meaning that I would try to make the Daily Scrum at least a little bit entertaining. As a ScrumMaster, it is important to get a feeling for the Team – what jokes do they enjoy, what are their character traits, do they prefer technical discussions, do they ever speak of their private lives etc.?! Once you understand your Team, it is much easier to integrate the Team members from the other locations into the Daily. I have seen far too many ScrumMasters (no matter whether co-located or distributed, actually) that sluggishly stand in the background waiting for the meeting to be over – if you don‘t show any enthusiasm for what you propagate, why should your Team members?!
Kristina K.: Actually, in contrast to Ina, we didn’t stick to the 15 minutes, as the Team seemed to need a bit of extra time in order to make the meeting most effective. At the time, I found this to be more important than sticking to a time-box of exactly 15 minutes. It is no surprise, as my Team consisted of about 11 Dev. Team members and several locations. The English language levels varied strongly, the technology was a definite impediment and – as I have already mentioned during the previous question (Interview 4 link) – the tool did not facilitate the flow of the meeting. Still, I always continued analyzing the meeting in terms of its time-box, as this helped me to develop new ideas that could help my Team plan their day better as well as maybe hold an effective meeting in less  time.
Christof B.: That‘s true, Kristina, your situation is not so unusual. Distributed Teams are often larger than co-located ones. If that‘s the case, one simply has to accept the fact that it may take slightly longer than the standard 15 minutes. Also, communicating over the telephone with each other makes the meeting more exhausting (which is why Ina‘s tips are great, by the way) and if the technology was not specifically selected for the Team‘s needs, the likelihood of having to repeat yourself a lot is rather high. Staying within the 15 minutes time-box can really be quite difficult.
Stephanie G.: I‘ve also experienced that the technology has a large impact on the efficiency of the Daily. What do the others think?
Deborah W.: As a ScrumMaster, it‘s important to make sure that all the technology is set up properly well in advance. Ten minutes should suffice if it ensures that the equipment is ready to be used right from the start. As Christof mentioned – depending on the transmission (sadly, most Teams do not have the budget that we had spoken of earlier – see Interview 3), you might have to set the time-box at 20 minutes. When my Team started out, we only used to be able to hear each other, but after less than a week, the Dev. Team independently bought a webcam, so that they could combine the voices with images.
Bernd K.: Oh dear – speaking of transmission. I can‘t even count how many times our connection broke off during any kind of meeting. Also, we didn‘t have a webcam, so it was very important to ensure that everyone knew whose turn it was and who was currently speaking. Whether this is done by saying one‘s name before speaking, through colour codes in the Taskboard tool or some other way, is up to the Team.
Christof B.: I always liked the idea of having a Speaker Token, which can be passed around depending on who wants to go next. You can also play Ping Pong with the Team members in the other locations – Team member in location A followed by Team member in location B, then someone in location A again etc – but this makes it even more difficult to stay within the 15 minutes and the ScrumMaster really has to keep an eye out on who‘s up next. The advantage is that people stay more focused.
Bernd K.: Oh, that sounds quite good, Christof. I‘ll try that out next time. But generally, the Daily was interesting, as it showed a large cultural difference between the Team members in Romania, who were rather held back, and those in German, who would talk quite a lot. As a ScrumMaster, I had to ensure that everyone got his or her turn to voice the current progress of the Tasks.
Stephanie G.: I can imagine that if – as you say – the Team members in Germany were quite talkative, that must have made it difficult to stay within the time-box, as well?! I know my Team always wanted to use this meeting to discuss everything right away and get all questions answered – although these questions had mostly little to do with planning the work for the day.
Bernd K.: That‘s exactly one of the issues that we had. The Team was simply trying to use the opportunity that the connection between the two locations was already established. So I tried to separate the „Now“ and „Later“ a bit more strictly and pushed them towards using group chat rooms more frequently or setting up a telephone connection in the middle of the day in order to coordinate their work. I also encouraged the Team members individually to start picking up the phone and directly calling each other outside of the Daily, too.
Hélène V.: Bernd, I am completely with you. I would really advise to start using the Daily for shortly coordinating everyone‘s availability for the upcoming 24 hours. When sitting together in one room, it‘s easy to figure out the best available time for meeting up and discussing something. This isn‘t the same for distributed Teams. Another option would be to simply say that the Daily is automatically followed by another synchronisation meeting a few hours later. That way, coordination takes place more often and it becomes more natural for the Team members to talk to each other several times throughout the day. But I can say this about the Daily: It really is a challenge to ensure that everyone knows exactly what each Team member is currently working on. This is not just difficult for distributed Teams. But it is important to use the Daily for making this transparent! No matter which tool the Team uses, it should be elusive on what progress has already been made and what is still missing.
Stephanie G.: Thank you! You‘ve given our audience quite a few useful tips. Let‘s see whether I can summarise them as:

First things first

Ich gebe zu, man könnte es als luxuriös bezeichnen, eine komplette Woche mit einem neuen Team zu verbringen, bevor der tatsächliche Sprint startet. Mittlerweile betrachte ich es aber als notwendig, vor allem wenn das Team vorher nicht zusammen und nicht mit Scrum gearbeitet hat. Vor allem aber, wenn die Teammitglieder nicht daran gewöhnt sind, zu diskutieren und sich einzubringen.
 

Was man eine ganze Woche lang macht?

1) Scrum Basics vermitteln
Jeder hat über den Flurfunk oder die Unternehmenskommunikation im Rahmen der Einführung von Scrum bestimmte Buzzwords mitbekommen. Manche haben sich selbst eine Vorstellung gemacht, andere nachgelesen und wieder andere können mit den Begriffen nichts anfangen. Also, in Kürze – einen Tag – Rollen, Meetings, Artefakte. So legt man zumindest gleich zu Beginn die Grundlage für ein gemeinsames Verständnis – und eine gemeinsame Sprache verbindet zusätzlich.
 
2) Das Team kennenlernen
Ob ScrumMaster, Product Owner oder Teammitglied: Jeder ist neu im Team. Daher sollte man sich die Zeit nehmen, sich über die gewöhnliche Vorstellungsrunde mit Namen und Abteilungskürzel kennenzulernen. Ich bereite zwar eine Art Story Map vor, lasse dann aber die Teammitglieder durch Punkte entscheiden, was sie machen wollen, um sich, Scrum, die Hintergründe und den organisatorischen Rahmen kennenzulernen.
 
3) Vision und Backlog
Sich (als ScrumMaster) Zeit nehmen, den Product Owner gründlich auszufragen: Was ist das Produkt? Wer die Nutzer? Und welchen Nutzen wollen wir für sie bereitstellen? Kann man eine Vision erarbeiten oder fehlt es dafür an etwas?
 
Oft wundert man sich, dass es ein Team gibt und man vermeintlich starten kann, aber noch gar nicht richtig klar ist, was gemacht werden soll. Wenn man Glück hat, ist es für eine “strategische Runde” noch nicht zu spät, bevor die Verwirrung das ganze Team erfasst. Im besten Fall kann der PO nochmal drüber schlafen und nochmal weiterentwickeln, schärfen oder verwerfen, bevor er das Ergebnis zum ersten Mal mit dem Team diskutiert.
 
Vor allem einen nicht fertige Vision, ein mageres Backlog und die gemeinsame Erarbeitung der Personas mit dem Team laden zum Teilen der Meinungen ein. Durchstreichen erwünscht – und das ist “analog” einfacher als in einer ppt. Gemeinsam geschriebene User Stories, selbst wenn man nachher nicht alle braucht, machen deutlich, wie schwierig oft der Nutzenaspekt ist. Vor allem wenn man den Kunden bereits kennt und in der Regel einfach abarbeitet.
 
Gebt den Teammitgliedern etwas Zeit, wenn sie nicht gleich zu Beginn eifrig diskutieren. Oft sind sie es nicht gewöhnt, gefragt und gehört zu werden.
 
4) Infrastruktur und Wissen
Einen Raum beziehen, Rechner neu aufstellen, ein Taskboard bauen, weitere benötigte Infrastruktur- und Testumgebungen identifizieren, ggf. eine Schulung zu für das Team wichtigen Inhalten organisieren.
 
5) Definition of Done
Was ist selbstverständlich? Was wäre gut, wenn man es tun würde? Und was würden wir gerne tun, haben aber nicht die Mittel? Arbeitsweisen und Begriffsverwendungen variieren oft schon, wenn man die Seite des Flurs wechselt, ganz zu schweigen von Abteilungen. Das Sammeln der Antworten auf die Fragen oben ist für mich eine Herangehensweise, dem Team die Möglichkeiten und weniger die Doku-Regeln hinter der DoD zu vermitteln. Außerdem füllt sich das Impediment Backlog fast wie von selbst und das Team gibt bereits vor dem ersten Planning ein Commitment ab – und sei es nur um zu versuchen, die selbst gesteckten hohe Qualitätsziele zu erreichen.
 
First Things First – sich Zeit für die strategische Planung nehmen, bevor man in der Taktik der neuen Situation versinkt. Es lohnt sich und ist genauso ein Bestandteil von Scrum wie die Sprints.

ScrumMaster schenken kleine Freuden mit Scrum

Es sind die kleinen Freuden des Lebens, die unser Tun manchmal besonders machen. Sie passieren spontan, überraschend oder auch unvorbereitet. Genau darin steckt ihre tiefgreifende Kraft. Man rechnet nicht mit ihnen. Und plötzlich sind sie da. Sie lösen einen vollwertigen Cocktail an Gefühlen in uns aus. Ein wahres Fest für jeden Neurobiologen. Ein kleines Feuerwerk aus Endorphinen.
Vielleicht fragt ihr euch, wie ich auf dieses Thema gekommen bin. Dieser Beitrag ist entstanden, weil mir vor ein paar Tagen eine solche kleine Freude am eigenen Leib zuteil wurde. Nach zweiwöchiger Abwesenheit kam ich an den Arbeitsplatz, der mir bei einem meiner Kunden zur Verfügung gestellt wird. Auf meinem Schreibtisch fand ich diese Nachricht vor:

 
Das Ergebnis war echt erlebte Freude. Kann ein Arbeitstag wertschätzender starten? Ich bin für diesen einen Moment, meinen Moment, nicht mehr aus dem Strahlen gekommen:

Take a smile

Eine schöne und bemerkenswerte Variante zu dem Willkommen-Post-it, die ich immer wieder gerne nutze, um für eine kleine Freude, ein Schmunzeln, zu sorgen, ist das Take a smile-Post it.

Mögliche „Einsatzgebiete“? Es kann den bzw. die Empfänger beispielsweise über einen ganzen Sprint begleiten (jeden Tag ein Lächeln). Es kann aber auch für ein Lächeln pro Teammitglied stehen. Take a smile ist genauso einsetzbar für ein einzelnes Teammitglied, dem es vielleicht gerade nicht so gut geht. Vielleicht verteilt ihr es an eure Besucher im Daily oder im Review. Wenn ihr aber die Wirkung erstmal einfach so ausprobieren wollt, dann hängt ein Post-it an die Eingangstür, die zum Teamraum führt. Ich garantiere euch, dass ihr Abnehmer finden werdet und denen ihr unter Garantie mindestens ein Schmunzeln entlocken werdet.

Der Briefwechsel

Wer als ScrumMaster einen erinnerungswürdigen Moment von Freude, gemischt mit einem gerührten Innehalten erzeugen möchte, sollte sein Team zu einem „Briefwechsel“ bewegen. Der Zeitaufwand ist im Verhältnis zur Wirkung verschwindend gering und ein Zusammenrücken im Team ist nahezu garantiert. Der Briefwechsel kann als Separator in einer Retrospektive zum Einsatz kommen, aber auch als möglicher Wochenabschluss in ein erholsames Wochenende einleiten. Was habt ihr zu tun? Sorgt für eine lockere, aber störungsfreie Atmosphäre im Teamraum (z.B. lockerer Stuhlkreis, wenn das räumlich möglich ist; jedes Teammitglied kann aber auch an seinem Arbeitsplatz sitzen, sofern das Team in einem Raum ist und nicht verteilt). Jeder bekommt einen Stift. einen Briefbogen und einen Briefumschlag. Ich empfehle euch, echtes Briefpapier zu nehmen. Das sieht einfach schöner aus und macht den Briefwechsel authentischer. Eure Teammitglieder sollen ihren Namen gut lesbar in eine Ecke des vor ihnen liegenden Briefpapiers schreiben. Bei der Überschrift für den Briefwechsel seid ihr nun frei. Wählt ein Motto in Form eines Satzanfanges, der dann jeweils vervollständigt werden soll: z.B. Es ist schön, mit dir in einem Team arbeiten zu dürfen, weil … oder Ich möchte dir heute ein Kompliment machen, weil… Hat jedes Teammitglied seinen Namen und die Überschrift auf seinen Brief geschrieben, wird der Briefbogen im Uhrzeigersinn an den Nächsten weitergegeben. Dieser widmet nun dem Briefbesitzer (Name steht auf dem Briefbogen) seine persönlichen Worte durch die Vervollständigung des Satzanfangs (siehe oben). Und weiter geht es. Der Brief wird an das nächste Teammitglied übergeben. Dieser Ablauf findet solange seine Fortsetzung, bis der Briefbesitzer beim nächsten Briefwechsel überreicht werden würde. Ist der Satz formuliert, wird der Brief gefaltet und kommt in den Briefumschlag. Schreibt den Namen des Empfängers nun auf den Umschlag und übergebt den Brief an seinen Empfänger.
Der Briefwechsel – auf einen Blick
Zutaten: 1 Briefbogen, 1 Briefumschlag, 1 Stift (alles je Teammitglied)
Zeitlicher Aufwand: Teammitglieder mal zwei in Minuten
Sinn und Zweck: Wir schenken uns Freude
Räumliche Bedingungen: störungsfreie Teamatmosphäre
Anlass: Separator in einer Retrospektive, Wochenabschluss, für gute Laune zwischendurch
ScrumMaster, nehmt meinen Blog zum Anlass, verteilt kleine Freuden mit Scrum und schaut, was ihr bei den Menschen auslöst und bewegt. Denkt daran, dass die Wahrheit uns allen ins Gesicht geschrieben steht. Wer sich übrigens wirklich sicher sein möchte, ob er bei seinem Gegenüber „echt erlebte Freude“ (1) produziert hat, möge sich nicht allein auf hochgezogene Mundwinkel konzentrieren. Die Basisemotion der Freude, wenn sie echt erlebt und nicht nur sozial erwünscht geäußert wird, tritt zweifelsfrei nur in Kombination mit der Muskelkontraktion des Wangenhebers (musculus orbicularis occuli) auf. Wangenheber? Nein, ihr habt euch nicht verlesen und nein, ich meinte nicht Wagenheber. Den braucht es hoffentlich nicht für diesen Muskeleinsatz. Die Kontraktion des Wangenhebers kann leicht ausfindig gemacht werden. An den Außenseiten der Augen werden die sogenannten „Krähenfüßchen“ sichtbar, die natürlich auf meinem Freude-Foto kaum zu erkennen sind :-).
Und jetzt los. Verschenkt Freude. Ich bin mir sicher, dass ihr dankbare Abnehmer finden werdet.
 
Literatur
(1) P. Ekman (2012). Emotionen lesen.

Der Sprint – ein Zeitplan für Macher

Wer beim Sprinten ins Stolpern kommt, wird meist von etwas abgelenkt. Das gilt zumindest in den Sprints, die im Büro stattfinden. Den Sprint in Scrum gibt es aus vielen Gründen: Er dient der Synchronisation, stellt eine Grenze gegen Überlast dar (WIP-Limit) und sorgt für störungsfreies Arbeiten.

Synchronisation

Der Sprint dient der Synchronisation für die Priorisierung und Lieferung. Hierbei besteht die gleiche Kadenz für Priorisierung und Lieferung. Die gleiche Kadenz heißt, es wird zu Anfang des Sprints festgelegt, was in die freien Slots kommt, die im nächsten Sprint frei sind und es wird festgelegt, wann das Scrum-Team die nächsten Ergebnisse liefert. Sobald man in Scrum das Sprinten startet, legt man den Rahmen, die Kadenz automatisch fest. Man legt Synchronisationspunkte fest und die damit verbundenen Transaktionskosten.
Die Transaktionskosten der Koordination minimiert man bei einer regelmäßigen Priorisierung. Es ist klar, wann wer zusammenkommen muss und jeder kennt den Rhythmus.
Transaktionskosten für die Lieferung hängen von mehreren Faktoren ab: Wie aufwendig sind Koordination und Integration, wie hoch ist der Grad der Automatisierung und wie schnell kann, wie schnell muss man Geschäftswert für den Endnutzer bereitstellen.
Die Automatisierung hat heutzutage noch viel mit Professionalisierung der Software-Entwicklung zu tun. Unternehmen, bei denen bisher wenig automatisiert ist, haben meist hohe Transaktionskosten. Solche Kosten sind oftmals auf manuelle Qualitätssicherung und hohe Koordinationskosten für Integration und Releases zurückzuführen. Meist führen gerade solche langen Lieferzeiten jedoch zu einem Teufelskreis: Da die Transaktionskosten hoch sind, meiden Unternehmen kurze Zyklen. Lange Zyklen beinhalten immer ein höheres Risiko an Fehlern. Kombiniert man nun lange Zyklen mit der Angst vor Fehlern in der Praxis, stellen sich nochmals höhere Transaktionskosten durch ausgeprägte Testphasen ein. Da man zum einen mehr testet, zum anderen fehlerhafte Funktionen länger in der Praxis hat, verlängert sich der Zeitraum des fehlenden Geschäftswerts. Derweil sitzt der Kunde noch mit Praxisfehlern auf der langen Bank. Wartet der Kunde auf der Bank, dann führt das häufig zu Mitnahmeeffekten durch Wettbewerber.

WIP-Limit

“Limit work in progress” – so richtig wichtig, leider oft so richtig wenig verstanden. Überlast in Unternehmen führt nicht nur dazu, dass alles lange dauert und keiner mehr Lust hat. Es führt vor allem dazu, dass fast nichts mehr geht. Menschen betankt man nicht wie Maschinen, die dann bis auf eine gewisse Grundwartung mit einer geringen Fehlerquote arbeiten. Wann geht fast nichts mehr? Wenn alles aufeinander wartet und gemeinsame Synchronisationspunkte zu selten oder unkoordiniert stattfinden. Dann ergeben sich Abhängigkeiten, die nur noch so ungefähr aus der Vogelperspektive erfasst werden können. Wenn die Vogelperspektive hier helfen würde, dann wäre das schön, meiner Erfahrung nach zählen allerdings vor allem die Details.
Im Sprint limitiert das Entwicklungsteam die eigene Auslastung. Das Entwicklungsteam zieht sich die eigene Auslastung, manchmal auch die eigene Überlastung. Dadurch entsteht für den Zeitraum des Sprints ein limitiertes System, ähnlich einem Währungssystem, es entsteht eine Knappheit. Mit dieser Knappheit kann man arbeiten. Indem ich ausweise, dass im nächsten Zeitraum nicht mehr geht, zeige ich deutlich auf, was geliefert wird. Meine Lieferung rückt in den Fokus.
Des Weiteren kann bei Blockaden nicht auf etwas weniger Wichtiges ausgewichen werden, sondern es muss genau an dem gearbeitet werden, was wichtig ist. Trifft man auf Blockaden, so sind sie zu lösen. Ist das System nicht limitiert, so wäre die natürliche Reaktion, sich mit etwas anderem zu beschäftigten. Das führt in vielen Organisationen dazu, dass Blockaden selten oder nie gelöst werden und man sich mit ihnen abfindet. In einem knappen System geht das nicht. Es muss etwas getan werden, der Fokus auf den Wert bleibt erhalten und man reduziert deutlich die Parallelität und damit den Auslöser für das heutzutage vielmals gescheiterte Multiprojektmanagement.
Wichtig ist, die so erzeugte Knappheit im System aufrechtzuerhalten: Wird das System ständig gestört z. B. durch Incidents, dann werden schnell die Vorteile eines solchen Systems obsolet (stabile Transaktionskosten für Priorisierung, Lieferung, konsequentes Auflösen von Hindernissen, etc.).

Störungsfreies Arbeiten

Wer kennt es nicht: Manager hetzen stundenweise von Termin zu Termin. Stimmen sich ab, tauschen sich aus und tragen all die neuen Erkenntnisse überall dorthin, wo sie aktuell noch gar nicht sein müssten – ins Entwicklungsteam. Auf der anderen Seite sitzen im Entwicklungsteam Menschen, die Zeit benötigen, sich in ihre Arbeit zu vertiefen.
Ich beschreibe Software-Entwicklung meist so: Du sitzt da vor deinem PC und über dir schwebt ein stetig wachsendes Konstrukt von Beziehungen, Abläufen und Strukturen. Es ist wie ein kleines Wolkenschloss, dass mit jeder Zeile Code, die du liest, wächst. Immer mehr Gedankenblasen steigen vor dir auf bis dann… ja dann klingelt das Telefon, es kommt jemand herein, spricht dich an und du siehst weit am Horizont die letzte Gedankenblase zerplatzen und dein Wolkenschloss ist vom Winde verweht. Um ein solches Konstrukt zu erzeugen benötigt es Zeit, es ist aufwendig und anstrengend.
Wenn wir die Zeitpläne eines Managers mit dem eines Entwicklungsteams vergleichen, dann sehen wir kleine Zeiteinheiten über den Tag verteilt beim Manager und große Zeiteinheiten beim Entwickler. Jetzt würde manch einer sagen, dass es jede Menge Entwickler gibt, die auch einen zerstückelten Zeitplan mit sich herumtragen. Hier stelle ich die Frage: “Wie viel wird von demjenigen dann noch entwickelt und wie viel managt er schon?”
Paul Graham nannte 2009 die unterschiedlichen Zeitpläne “Maker’s schedule, manager’s schedule“. Er bringt dort zum Ausdruck, dass diese beiden Zeitpläne konträr zueinander stehen und so wenig wie möglich aufeinandertreffen sollten, damit die Produktivität der Macher (Entwickler) möglichst wenig beeinträchtigt wird. Im Umkehrschluss schlägt er vor, dass beide Zeitpläne voneinander entkoppelt werden sollten. Spannenderweise findet dieses Prinzip sich im Agilen im Allgemeinen und bei Scrum im Speziellen wieder. In Scrum entkoppeln die Sprints die beiden unterschiedlichen Zeitpläne voneinander. Im Sprint sorgt der ScrumMaster für störungsfreies Arbeiten und gibt seinem Entwicklungsteam den Freiraum und die Zeit, möglichst autonom und produktiv zu arbeiten. Zum anderen entkoppeln die Rollen Product Owner und ScrumMaster die Zeitpläne. Das geschieht dadurch, dass beide für das Scrum-Team zwischen den Zeitplänen vermitteln, indem sie selbst als Puffer und Filter agieren. Ein weiterer Vorteil ist, dass sich das Entwicklungsteam gegenüber Störungen ausgehend von den beiden Rollen auch durchsetzen kann, da weder ScrumMaster noch Product Owner disziplinarische Vorgesetzte des Teams sind.

Zieleinlauf

Der Sprint isoliert die hektische Welt des Managements vom Zeitplan eines Entwicklers. Entwickler können sich so fokussieren und gedankenintensive Arbeit leichter abschließen. Der Sprint fördert stabile Bedingungen, die zu niedrigeren und stabilen Transaktionskosten führen und ermöglicht Professionalisierung aufgrund von kleinen Lieferungen. Als knappes System führt der Sprint dazu, dass Blockaden gelöst werden müssen und zukünftig nicht auch anderen Arbeiten im Weg stehen. “Wenn Sie mich fragen: Ich mag ihn, den Sprint!”

Interview mit einem ScrumMaster oder die Reise zu einem fremden Planeten

Ein guter ScrumMaster zeichnet sich dadurch aus, dass er immer und überall auf der Suche nach Verbesserungen ist, die zur Steigerung der Produktivität seines Teams beitragen. Hierzu sollte er seinen Blick in alle Richtungen schweifen lassen. In der operativen Hektik des täglichen Tuns passiert es dann nicht selten, dass ein Bereich übersehen oder gar vergessen wird: der Blick auf sich selbst. Wer andere bewegen und verändern will, der sollte zuerst sich selbst bewegen, um so zu (s)einer Veränderung beitragen zu können.
Katja Lüdtke, seit einem Jahr ScrumMaster beim E-Postbrief, versteht diesen Anspruch auf ihre ganz eigene Art und Weise und sagt: „Yin und Yang. Weich und hart. Stark und schwach. Nichts ist absolut. Die Eigenschaften definieren sich immer im Vergleich. Also, es ist wichtig, nach draußen zu gehen und sich auch andere Welten anzuschauen, um relativieren zu können, um neue Erkenntnisse zu gewinnen und daraus zu lernen.“  Und Katja nahm sich selbst beim Wort und ging nach „draußen“, zur ESG nach Wolfsburg. Im Rahmen einer Weiterbildung von bor!sgloger consulting, die von ihrem Chef, Dr. Oliver Zeiler (Mitglied des Bereichsvorstands BRIEF GB 32), möglich gemacht wurde, implementierte sie dort in einem gerade neu aufgestellten Team Scrum. Drei Sprints (sechs Wochen) lang durfte sie dort als ScrumMaster und ScrumCoach ihren Blick über den Tellerrand nicht nur schweifen lassen, sondern auf besondere Weise schärfen.
Über ihre Erlebnisse, die vielen Erkenntnisse und kleinen Geschichten möchte ich heute mit Katja reden.
D.: Hallo Katja, du bist zurück von deiner kleinen Reise. Wie ist es dir ergangen?
K.: Es war besonders. Es stimmt, was Mike Cohn sagt: Scrum ist anders. Ich würde dies aber gerne ergänzen wollen: Scrum ist woanders anders.
D.: Wie meinst du das?
K: Es war wie Sprinten auf einem anderen Planeten. Ich durfte Scrum und mich als ScrumMaster und Coach in einer völlig neuen Umgebung, auf einem fremden Planeten erleben. Von drei meiner wichtigsten Beobachtungen und Erkenntnisse möchte ich gern berichten.
D.: Dann leg mal los. Du machst mich neugierig.

Beobachtung 1: Kleine Teams sind tatsächlich dynamischer als größere

Die „Fremdlinge“ haben sich für die agile Entwicklung eines neuen Produkts in kleinen Teams von vier bis fünf Personen organisiert. Das war neu für mich, da ich als ScrumMaster bislang nur die Arbeit mit Teams von acht bis zehn Personen kannte und diese Größe für mich selbstverständlich war. Nun beobachtete ich gespannt die Auswirkungen einer noch kleineren Organisationseinheit und stellte fest, dass die Teammitglieder häufiger zu Wort kommen als in einer größeren und das persönliche Kennenlernen begünstigt ist. Klingt erst mal logisch, hat aber in letzter Konsequenz große Auswirkungen. Die Phasen der Teamentwicklung sind im Vergleich mit einem Team, das aus mehr als acht Personen besteht, kürzer. Im Team werden die Ideen schneller besprochen, die Aufgaben rotieren zügiger, bei Problemen finden sich fast automatisch Partner, um diese  lösen zu können. Als Teammitglied ist man stärker gefordert und kann sich weder verstecken, noch geht man in der Anonymität unter, weil man vielleicht zu leise ist. Es ist in jedem Moment offensichtlich, wie die zugesicherte Eigenverantwortung gelebt wird – nicht zuletzt, weil man irgendwie muss, aber dadurch auch will. Das bedeutet, dass die persönliche Motivation, das Ziel zu erreichen, höher ist, da gute Ergebnisse viel schneller sichtbar sind und zur Anerkennung führen.
Weitere Vorteile eines kleineren Teams ergeben sich aus der Arbeit des ScrumMasters: Die Timeboxes für Meetings sind, ohne das Team zu überfordern, leichter einhaltbar – weniger Köpfe, weniger Kontroversen. Für die Verbesserung der Persönlichkeits- und Team-Entwicklung bleibt somit auch mehr Raum, was sich natürlich direkt in der Arbeitseffektivität widerspiegelt – die Velocity steigt, die Qualität bleibt hoch. Folge: Der ScrumMaster kann sich mehr und nachhaltiger um die Lösung von Impediments kümmern.

Beobachtung 2: Ein ScrumMaster schützt das Team, aber er hat keine Schützlinge

Kennt ihr das Bild der Glucke mit ihren kleinen Küken, die ihr nahezu blind folgen, wenn sie gemeinsam zum Spazieren gehen? Die Glucke unternimmt alles, damit ihre Zöglinge vor allem und jedem geschützt werden. Manchmal verhalten sich ScrumMaster genau so, wenn sie seit vielen Sprints mit dem gleichen Entwicklungsteam zusammen sind. Natürlich ist es absolut menschlich, dass sich mit der Zeit Freundschaften zwischen dem ScrumMaster und den Teammitgliedern bilden, Menschen wachsen sich ans Herz oder gewöhnen sich einfach aneinander. Und dann? Neigen wir dann nicht dazu, Schwächen nicht mehr so konsequent und bedingungslos anzusprechen, das Gegenüber zu schonen und Missstände sogar zu ignorieren? Interessant: Auf dem fremden „Planeten“ zeigten die „Außerirdischen“ sehr ähnliche Symptome. Sie haben allerdings ziemlich schnell eine Lösung gefunden: eine ScrumMaster-Rotation!
Es wurde erkannt und angewendet, dass jeder ScrumMaster seinen eigenen Stil und seine Stärken hat, die auf unterschiedliche Weise eine Performance-Steigerung im Team bewirken können. Erst gute und gemeinsame Emotionen lassen ein Gefühl für Gemeinschaft und Vertraulichkeit entstehen. Das ist anzustreben, um konzentriert arbeiten zu können. Aber ein regelmäßiger Teamwechsel ist eine Chance für den ScrumMaster und für das Entwicklungsteam: Der eine vermeidet die Fallen der Routine und das Team profitiert von den Fähigkeiten anderer ScrumMaster.

Beobachtung 3: Eine wirkungsvollen Vision unterstützt die Veränderung

Mut zu signifikanten Veränderungen in der Organisation haben, ist ein agiler Wert (Courage). Zu wenig davon kann teuer für ein Unternehmen sein, das auf dem Weg zur Agilisierung ist. Änderungen sind bekanntlich unbequem und schmerzhaft, können Angst und Widerstand erzeugen. Grund genug, um diese unter Vorwand nicht umzusetzen oder zu verschieben.
Auf dem „Planeten“, den ich besuchte, haben dessen “Bewohner“ im Rahmen der Entwicklung neuer Produkte einen Weg gefunden, mit den Veränderungsängsten umzugehen: Sie stellen sich ein sehr klares Bild einer gemeinsamen gewünschten Zukunft vor. Das tun sie so lange, bis dieses Bild so vielversprechend, klar und schön ist, dass es eine große Anziehungskraft entwickelt, für alle! Sie beginnen die Zukunft mit dem neuen Produkt zu lieben! Danach fällt es allen leichter, die Kraft und die Entschlossenheit für die Bewältigung der Schwierigkeiten auf dem Weg dahin zu finden.
Ich bin jetzt von der Reise zurück, fest entschlossen das zu nutzen, einzusetzen und anderen zurückzugeben, was ich für mich erkannt, herausgefunden, erlebt habe.
Hier mein Aufruf an die vielen ScrumMaster, die sicher ständig ihre neugierigen Blicke als Change Agent schweifen lassen:

Ich bin seit meiner Rückkehr von diesem gar nicht mehr so fremden Planeten überzeugt, dass wenn ihr schon einen der drei Punkte verfolgt, viele Erfolgsstories auch auf euren Heimatplaneten entstehen.

Definition of Done: Die harte Schule

Das Ende des Sprints naht und nur noch Tasks wie “Systemdoku ergänzen” und “Abnahme mit dem PO durchführen” kleben in der To-Do-Spalte. Ein Blick auf die Definition of Done neben dem Board verrät, dass das Team sich dazu committed hat, die Doku abzuschließen, bevor sie eine Story als DONE deklariert und somit dem PO zur Abnahme übergeben kann.
Nun ist es aber doch dringend, man könne die Systemdoku doch auch machen, nachdem die Abnahme vom PO erfolgt sei. Sie wäre ja schließlich sowieso nur von Entwicklern für Entwickler, den PO würde das nicht interessieren und er würde es auch nicht lesen. Vielleicht würde er noch Fehler finden oder Anpassungen haben wollen und dann müsse man die doch dringender machen als die Systemdoku. Ein Implementierungs-Task sei schließlich wichtiger als ein Doku Task …

Die Biegbarkeit der DoD

Ich diskutierte lange mit dem Teammitglied über Sinn und Unsinn der DoD. Als dann das Argument fiel “Dann müssen wir eben die DoD anpassen, da steht sowieso zu viel drin! Und du hast gesagt, dass das Team die DoD festlegt, stimmts?”, mischte sich ein weiteres Teammitglied ein. Zuerst stimmte er in den Chor der DoD-Kürzung ein, doch bei ernsthafter Betrachtung stellte er fest: “Naja, der faule Entwicklerteil in mir sagt, dass wir etwas streichen sollten, aber der vernünftige sagt, dass wir es sonst nur wieder aufschieben. Dann wird es so wie in den alten Projekten: Die Doku machen wir, wenn wir noch Aufwand übrig haben! Und dann hat man natürlich keinen Aufwand übrig!”
Im Nachgang, als ich von dem Erlebnis erzählte, wurde mir klar, dass Scrum wahrscheinlich einfach eine Methode ist, mit der sich Menschen selbst überlisten. In einem guten Moment schreibt man alles auf, was sinnvoll ist und committet sich schnell dazu, bevor man es sich wieder anders überlegt. Später fragt man sich an der einen oder anderen Stelle, warum genau man sich auf so etwas eingelassen hat. Hätte man nicht gleich sehen können, wie unrealistisch das ist bzw. wie viel Disziplin nötig ist, um das dauerhaft einzuhalten? Immerhin würden mir heute tausend Gründe einfallen, warum etwas anderes viiieel wichtiger ist als Doku, nochmaliges komplettes Testen nach einer minimalen Änderung, Testautomatisierung etc.
Pilotprojekten wird oft ein großer Vertrauensvorschuss gewährt. Man hebelt die “normalen” Prozesse aus und vertraut, dass das Team mit seinem eigenen Anspruch eine hohe Qualität liefert. Das ist gut und richtig. Oft jedoch holen einen alte Verhaltensweisen wie Featuredruck oder das Ziel der Performance-Steigerung schnell ein. Die Teammitglieder sind gewohnt an der Qualität zu sparen, wenn es knapp wird, kurzfristige vermeintliche Erfolge über z.B. die Wartbarkeit zu stellen. Im Einzelfall scheint es daher manchmal kleinkariert, auf den Regeln zu beharren. In dieser Situation sollte man sich schleunigst daran erinnern, dass man sich aus gutem Grunde selbst ausgetrickst hat.

Der ScrumMaster im Sprint Review oder warum Ja-Aber-Sager ein Impediment sind

In meinen Beobachtungen des Daily Business von Scrum-Teams stoße ich in regelmäßigen Abständen auf ein interessantes, aber auch bedenkenswertes und manchmal ärgerliches Phänomen. Viele ScrumMaster kommen beim Sprint Review ihrer essentiellen Verantwortung als Meeting Facilitator, Change Agent und Servant Leader nur bedingt nach. Immer wieder erlebe ich, dass das Sprint Review vom ScrumMaster als eine Art Auszeit genutzt wird. Während der Product Owner u.a. allen Anwesenden das Sprint Goal vorstellt, in diesem Kontext die ausgewählten Backlog Items erläutert, einen Ausblick auf die nächsten Userstories in der Roadmap gibt und das Entwicklungsteam die Ergebnisse des Sprints vorstellt, sollte der ScrumMaster die vornehmliche Aufgabe verfolgen, das Sprint Review zu moderieren. Moderation ist jedoch vielschichtig und wird von so manchem ScrumMaster nur eingeschränkt oder gar nicht umgesetzt.
Bevor ich allerdings hier tiefer erkläre, was mir bei der Umsetzung durch die ScrumMaster fehlt, möchte ich noch einen Schritt zurück gehen und beleuchten, warum das Sprint Review ein so wichtiges Meeting ist.
 

Warum das Sprint Review so wichtig ist

Glaubt man Boris Gloger und seiner Meinung in Scrum – Produkte zuverlässig und schnell entwickeln zur Sprint Review, kann die „Bedeutung dieses Meetings nicht genug betont werden“ (Gloger, 2011, S. 176). Das Sprint Review dient der Statuserhebung im laufenden Projekt und soll im Wesentlichen eine Antwort auf die Frage geben, ob „das Team geliefert (hat), was es versprach“ (a.a.O.). In noch unerfahrenen Scrum-Teams und Unternehmen, die noch am Anfang ihrer agilen Organisationsentwicklung stehen, wird das Meeting häufig als Präsentation durchgeführt. Das Sprint Review ist jedoch mitnichten eine Veranstaltung, in der den anderen (z.B. Management, Customer, Anwender, Fachabteilungen, Lieferanten, etc.) lediglich via Power Point das Produkt gezeigt wird. Vielmehr dient die Review (engl. Bewertung) als Einladung, „die Funktionalität auszuprobieren“ (Gloger, 2011, S. 178). Auf diesem Weg erhofft sich das Team, Feedback zu bekommen, „neue Ideen zu generieren und neue Möglichkeiten nutzen zu können“ (a.a.O.).
 

Feedback(un)kultur

Ein Feedback zu geben, ist jedoch eine hohe Kunst. Dieser sind leider nur wenige wirklich gewachsen, was dazu führt, dass das, was an Feedback bei jenen (Entwicklungsteam) ankommt, die damit ursprünglich den Wunsch und die Hoffnung verbunden hatten, Anerkennung für die getane Arbeit im vergangenen Sprint zu erhalten und/oder ungenutzte Perspektiven aufgezeigt zu bekommen, oftmals ernüchternd, manchmal sogar erschütternd und vor allem demotivierend ist. Den Klassiker der Feedback(un)kultur vertritt in diesem Zusammenhang die Gruppe der Ja-aber-Sager. Die Ja-aber-Sager sind während einer Sprint Review leicht zu erkennen. Haltet Ausschau nach Kopfschütteln und übermotivierten Meldeversuchen (z.B. Handmeldung, die durch Fingerschnipsen verstärkt wird), die von paraverbalen Ungedulsäußerungen (z.B. Seufzen) begleitet werden und schließlich in einem Wortbeitrag münden, die mit der Einleitung „Ja, aber“ ein (aus Sendersicht) plausibles und unumstößliches Gegenargument (z.B. Befürchtung, unüberwindbares Problem, etc.) liefern. Die Reaktion auf ein „Ja, aber“ ist fast immer die gleiche: Man (das Entwicklungsteam) rechtfertigt sich und es entbrennt ein fieberhafter Wettstreit darüber, wer Recht hat. Schließlich und letztendlich ist es die abgelaufene Timebox, die Schlimmeres verhindert. Zurück bleibt ein kritisiertes und verunsichertes Entwicklungsteam.
 
Möglicherweise habe ich das Szenario ein wenig überspitzt dargestellt und es geht keineswegs darum zu sagen, dass Ja-Aber-Sager unrecht haben. Nichtsdestotrotz erlebe ich regelmäßig solche Beispiele in ähnlicher Ausprägung. Und weil ein „Ja, aber“ zu keiner Zeit ein konstruktiver oder gewinnbringender Einstieg in einen ernsthaften Fachdiskurs ist, sondern „ein erbitterter Kampf um die Unanfechtbarkeit der eigenen Meinung“ (http://www.gedankenzirkus.de/wordpress/die-ja-aber-dummschwatzer), muss es eine aktive Instanz geben, die Regeln aufstellt und Ja-Aber-Argumente nicht einfach zur Kenntnis nimmt und so ein Entwicklungsteam mit der Kritik – im wahrsten Sinne des Wortes –  im Regen stehen lässt. Dieser Jemand ist und kann nur einer sein: der ScrumMaster.
 
Der ScrumMaster muss wie in jedem anderen Scrum Meeting auch in einem Sprint Review seiner Verantwortung in dreifacher Weise nachkommen:

  • Als Meeting Facilitator gibt der ScrumMaster für das Sprint Review Kommunikationsregeln vor und macht diese für alle Besucher transparent. Eine Regel könnte beispielsweise lauten: “Eine Wortmeldung beginnt nicht mit „Ja, aber“.” Er tritt als Moderator des Meetings auf und sorgt unter anderem dafür, dass sich die Beteiligten ausreden lassen und verschiebt (zeitintensive) Diskussionen auf einen späteren Zeitpunkt.
  • Als Servant Leader stellt sich der ScrumMaster schützend vor sein Team. Er bestärkt es, kritisches Feedback ebenso offen und dankbar wie positives anzunehmen, ohne es zu kommentieren oder sich zu rechtfertigen: don`t feed the feedback!
  • Als Change Agent setzt er sich im Rahmen des Sprint Reviews konsequent für die Einhaltung der vorgegebenen Kommunikations- und Feedbackregeln ein, um auf diese Weise Werte wie Wertschätzung oder Respekt zu stärken und sie über die Teamgrenze hinaus zu transportieren und unternehmensweit zu etablieren.

Rezept gegen Ja-Aber-Sager

Man mag es kaum glauben. Es sind nur zwei Worte und sie können trotzdem eine vernichtende Wirkung haben. Es scheint nahezu unmöglich, noch an positive Kommunikation zu denken, wenn die Kommunikation des Gegenübers alles andere als wertschätzend ist. So schwierig muss der konstruktive Umgang mit Ja-Aber-Sagern allerdings gar nicht sein, wenn es gelingt, den eigenen Ärger über den gerade geäußerten Widerstand zu reframen (umzudrehen) und dem Gegenüber mit Verständnis für seinen Einwand zu begegnen.
 
Also: Beginnt eure Reaktionen auf das Ja-Aber-Argument mit „Das verstehe ich…“, „Da hast du recht…“ oder „Das ist ein interessanter Punkt …“ und fügt dann das magische Wort „und“ ein, bringt euer nächstes Argument oder verstärkt das vorangegangene Argument durch mehr Detailtiefe!
 
Ein einfaches “Dankeschön” ist ein weiteres, sehr erfolgreiches Rezept gegen Ja-Sager. Ja, ihr habt richtig gelesen. Gerade wurde eure Arbeit des letzten Sprints nicht besonders wertschätzend beurteilt und ihr sollt euch bedanken, z. B. mit den Worten: “Vielen Dank für dein Feedback. Wir nehmen dein Argument mal mit ins Team und diskutieren es aus. Was hältst du davon, wenn du dann einfach dazukommst und wir schauen, was das für das Ergebnis unseres Sprints bedeutet. Wann hast du Zeit für uns?“


Literatur
B. Gloger (2011). Scrum – Produkte zuverlässig und schnell entwickeln. Hanser Verlag

Wie schreibe ich eine User Story oder anders gefragt: Was nützt mir der Nebel?

Der Weg zur User Story fällt vielen erstmal schwer und zwar an der Stelle, an der man es eigentlich nicht erwarten sollte: Beim Formulieren des Nutzens. Wir sind so darauf getrimmt Funktionen zu beschreiben, dass uns der Nutzen implizit bewusst ist, jedoch anfangs nicht zu greifen erscheint. Einen Nutzen zu beschreiben und ihn in Worte zu fassen fällt schwer, es ist wie das Greifen nach einem Nebelfaden, der kurz vor der Berührung zerstäubt.
Im Nebel, so fühlen sich viele Teams, wenn sie Anforderungen ohne Nutzen übergeben bekommen. Sie müssen anfangen die Schemen, die geschrieben stehen, zu interpretieren. Den Nutzen in den Sätzen, Zusammenhängen zu finden, die Schwaden zu durchtrennen und zu entwirren. Gelingt es, dann haben wir bestenfalls eine Funktion mit einer Interpretation des Nutzens und wir können hoffen, dass die Beteiligten miteinander reden, um zu validieren, ob die Funktion auch den gewünschten Nutzen erfüllt.

“Gib mir einen Nutzen und ich gebe dir die Funktion dazu, die Du dir wünscht.”

Das ist mein persönlicher Leitspruch und auch meine Empfehlung, wenn es darum geht, User Stories zu schreiben. Fangt mit den Fragen “Wer” und “Wozu” an und schreibt diese auf. Startet beispielsweise so:
Als Stammkunde Ralf Müller möchte ich …, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.
Wenn ihr eine gute Idee habt, dann schreibt noch die Frage nach dem “Was” dazu, also die Funktion:
Als Stammkunde Ralf Müller möchte ich eine Benachrichtigung, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.
Am besten ist es, wenn ihr das “Was” gemeinsam mit eurem Entwicklungsteam klärt. Verstehen sie den Nutzen, dann werden Sie eine Funktion finden, die den Nutzen erfüllt. Spätestens im Sprint Planning 1 sollten die Anforderungen dann geklärt werden. Vielleicht schlägt das Entwicklungsteam neben der E-Mail Benachrichtigung und der direkten Anzeige auf der Folgeseite noch das Versenden einer Benachrichtigung per Blumenstrauß vor – wer weiß.
Um der angesprochenen Funktion etwas mehr Gestalt zu geben, formuliert ihr noch Akzeptanzkritierien. Dadurch könnt ihr den Rahmen aufspannen und vorgeben, was minimal erfüllt werden muss – nicht mehr, aber auch nicht weniger. Auch diese Kriterien klärt ihr gemeinsam mit dem Entwicklungsteam und zwar im Dialog und zwar von Angesicht zu Angesicht. Vom Entwicklungsteam lasst ihr dann Akzeptanztests bzgl. der  Akzeptanzkritierien aufstellen. Ein Kriterium könnte in unserem Beispiel sein:
Die Bestätigung erfolgt auf zwei Kommunikationskanälen. Ein Kommunikationskanal ist im System, der andere der Postweg.

Warum sollte das Entwicklungsteam die Funktion ausformulieren?

Das ist für mich implizit eine Frage nach der Reife des Teams. Jedes Entwicklungsteam lernt am eigenen Produkt die Fachdomäne, in der es sich bewegt und wird über die Zeit zum Domänenspezialisten. Das ist jedoch nur ein Grund, ein wichtigerer ist der folgende: Jedes Team weiß am besten, wie sich der gewünschte Nutzen im System am besten abbilden lässt. Ein cross-funktionales Team zeigt hier seine Stärken, jedoch kennt jedes andere Entwicklungsteam es auch besser als der Kunde bzw. die meisten User. Man fragt sie nur zu selten.
Ein Grund hierfür ist sicherlich, dass die User sich nicht die Fragen stellen müssen, die ein Teammitglied sich stellt, zum Beispiel: “Wie passt die Funktion in das Konzept der Anwendung?”, “Muss ich hier auch die Funktionen A, B und C berücksichtigen?” Ein Entwicklungsteam hat einen ganz anderen Kontext zum Produkt, das es entwickelt. Dieser muss aufgebaut werden.

Was benötigt eine gute User Story jetzt noch?

Wir haben das normale Format mit Wer, Was, Wozu – also: Als <Persona> möchte ich <Funktion>, damit ich <Nutzen>. Wir haben Akzeptanzkritierien , die aufzeigen, was minimal geliefert werden muss. Akzeptanztests, die das Entwicklungsteam ausformuliert und die aufzeigen, dass die Akzeptanzkritierien erfüllt werden. Was fehlt?
Es ist der Nebel.
In unserem Beispiel ist der Nebel zuerst der leere Funktionsteil. Hier muss Kommunikation erfolgen, damit geklärt wird was selbst der Platzhalter Benachrichtigung später konkret heißen soll. Konkret gesagt ist der Nebel keine Worthülse, die beliebig interpretiert werden darf, trotzdem ist der Nebel die Unklarheit auf dem Weg zur Implementierung.
Eine User Story ist ein Anlass zur Konversation. Das bedeutet, wir benötigen eine gewisse Unstabilität in der User Story, damit eine Konversation, ein Dialog entstehen kann. Wir brauchen Unschärfe. Hier brauchen wir allerdings die Art von Nebel, die nicht verschleiert. Nicht der Nebel, der durch schöne Worte und vermeintliche Vollständigkeit und die stumpfe Präzision eines Löffels uns denken lässt: “Alles steht hier geschrieben, genau das brauchen wir so wie es formuliert wurde.” Nein, wir brauchen den Nebel, der uns fragen lässt: “Hey, sollen wir lieber links oder rechts gehen, ich bin mir gerade nicht ganz sicher.” Software-Entwicklung ist zu großen Teilen ein Kommunikationsproblem und zu genaue Anweisungen verstärken dieses Problem. Bei zu genauen Anweisungen fragen wir nicht mehr nach, die Kommunikation versiegt.
Für viele von Euch ist die Fahrt, der Spaziergang im Nebel erstmals ungewohnt, lasst ihn trotzdem zu und lasst Euch drauf ein. Es ist faszinierend, was nach kurzer Zeit vor einem auftaucht und welche Überraschungen und Details einem ins Auge fallen, die man aus der Ferne, selbst mit Weitblick, nicht hätte erkennen können.

ScrumMaster und gleichzeitig Teammitglied – ein Oxymoron

Ich mag unterschiedliche Meinungen. Ich halte fachliche Diskussionen für immens wichtig, wenn man sich und seinen Horizont erweitern möchte und die Tiefe einer Problemstellung ergründen will. Manchmal finde ich es sogar noch gewinnbringender, Diskurse von Menschen zu bestimmten Themen nur beobachten zu dürfen – aus der Adlerperspektive Fakten, Stimmungen und Argumente durch den Raum fliegen zu sehen und sein eigenes Bild zu schärfen, z.B. wer denn nun die Schuld trägt, dass der Berliner Flughafen ein Synonym von Michael Endes Bestseller „Die unendliche Geschichte“ zu sein scheint, ob es eine gute Entscheidung von Bayern München war, Pep Guardiola als neuen Trainer an die Isar zu holen oder wie (un)sinnig, Aufwandsschätzungen tatsächlich sind.
Es gibt allerdings auch Themen, die sind aus meiner Sicht indiskutabel. Das klingt dogmatisch, absolut, sogar intolerant. Ja, das stimmt. Und dennoch vertrete ich diese Auffassung mit absoluter Hingabe und Leidenschaft. Nicht, weil ich ein Besserwisser bin oder ein Problem habe, andere Meinungen anzunehmen. Keineswegs. Vielmehr nehme ich meine Profession als Berater ernst und möchte mit dieser Intoleranz andere Menschen an meinen Erfahrungen teilhaben lassen und sie davor bewahren, dieselben Fehler zu machen, die anderen zum Verhängnis wurden und immer wieder werden.
Ein Thema, das mich (manchmal) meine gute Erziehung vergessen lässt (ich nutze gerade das Stilmittel der Übertreibung, um mein Anliegen zu betonen, habt bitte Nachsicht mit mir), ist die fortwährende Diskussion, ob ein ScrumMaster auch gleichzeitig Mitglied des Entwicklungsteams sein kann. In jedem ScrumMaster Advanced Training wird diese Frage gestellt. Und das ist auch gut so. Meine Antwort beginnt immer gleich: „Die Frage ist ein Oxymoron – ein Widerspruch in sich!“ Ein ScrumMaster kann nicht gleichzeitig Teil des Entwicklungsteams sein. ScrumMaster zu sein ist ein Fulltime-Job. Jeder, der behauptet, das die three-hats-challenge (Change Agent, Servant Leader und Meeting Facilitator) nebenbei erledigt werden kann, ist meines Erachtens auf dem Holzweg. Die Doppelrolle, ScrumMaster und Teammitglied, bringt immer einen Interessenkonflikt mit sich und erinnert an das Gefangenendilemma: Sage ich zu dem einen Ja, verneine ich das andere. Ich kann nicht an zwei Orten gleichzeitig sein. Zwei simple Beispiele und doch so entwaffnend für die Argumentationslogik all derer, die postulieren, dass es doch gar nicht so schwer sei, beide Rollen und Verantwortungsbereiche unter einen Hut zu bekommen:

Ein Widerspruch in sich – ganz gleich wie groß die Schlupflöcher sind

So klein das Schlupfloch auch sein mag, es bleibt ein Widerspruch in sich. Hier eine Auflistung der beliebtesten Schlupflöcher „ScrumMaster und Teammitglied zugleich – das geht“:
Schlupfloch 1 oder weniger ist mehr: Das Entwicklungsteam besteht nur aus wenigen Entwicklern.
Schlupfloch 2 oder die sachliche Romanze: Der ScrumMaster ist nur ein Nebenjob (SM als Overhead und unterfordert).
Schlupfloch 3 oder das offenkundige Geheimnis: Der ScrumMaster hat als Entwickler eine geringere Entwicklungslast als seine Teamkollegen zu tragen.
Schlupfloch 4 oder das absichtliche Versehen: Als Servant Leader-Tätigkeiten werden Aktivitäten rund um das Konfigurationsmanagement, also Source-Code-Repositories aufsetzen, Toolketten pflegen, Continuous Deployment organisieren und optimieren, Continuous-Integration-Server aufsetzen, Jobs konfigurieren und verbessern, Toolketten optimieren, Backup-Prozeduren kontrollieren und testen, Branches aufräumen, etc., verstanden, um die Vollzeit-Entwickler zu entlasten.
Schlupfloch 5 oder das herrenlose Damenrad: Der ScrumMaster entscheidet für sich selbst, welche Verantwortung gerade die höhere Priorität hat, ScrumMaster sein oder Teammitglied.
Schlupfloch hin oder her, ScrumMaster und gleichzeitig Mitglied eines Entwicklungsteams zu sein ist und bleibt ein Oxymoron – ein Widerspruch in sich – sogar rechnerisch: 2 x 50% Auslastung macht eben nicht 100%, sondern 150%, da der Mensch (vielmehr sein Gehirn) jedesmal Zeit und Energie aufbraucht, um den Rollenwechsel zu schaffen. Und wer jetzt noch immer der Überzeugung ist, dass beide Rollen in einer Person vereinbar sind, der soll zumindest wissen, dass er gegen einen der fünf agilen Scrum-Werte verstößt: Fokus. Wie kann man das Ziel verfolgen, als Vorbild vorangehen und Menschen dazu bringen zu wollen, sich zu fokussieren, wenn man sich selbst schon bei der Übersetzung seiner eigenen Verantwortung widerspricht?

Der Führungsanspruch des ScrumMasters

Kennst Du ScrumMaster, die auch starken Gegenwind aus dem eigenen Team aushalten können? Die mit ihrem Team in leidenschaftliche Diskussionen gehen und auch dann nicht von ihrem Standpunkt abrücken, wenn das Team geschlossen anderer Meinung ist? Wenn ein ScrumMaster wirklich laterale Führung ausüben soll, dann müssten wir solche Situationen viel öfter erleben.

Was aber ist Führung?

Reinhard K. Sprenger zeigt in seinem Buch Radikal führen, dass Führung zum Lösen von Konflikten da ist. Was tun, wenn zwei oder mehr Handlungsalternativen da sind – und keine sich auf den ersten, zweiten oder gar dritten Blick als die eindeutig bessere entpuppt? Oft muss eine Entscheidung her. Und genau das – die Fähigkeit, in solchen Momenten Entscheidungen zu treffen und durchzusetzen – macht Führung aus.
Sprenger unterscheidet zwischen Wahl und Entscheidung. Bei einer Wahl können wir die verschiedenen Optionen auf die Waagschale legen. Wir können dann sehen, welche schwerer wiegt – wo die besseren Argumente sind. Bei einer Entscheidung ist die Ausgangslage komplett anders: Es gibt für jede Handlungsoption Argumente, aber keine Option sticht deutlich genug hervor, um die Situation entscheidbar zu machen.

Entscheiden in einer unentscheidbaren Situation: Wie lösen wir die Paradoxie?

Stellen wir uns folgende Situation vor: Ein Scrum-Team möchte nach sechs Monaten die Länge des Sprints von zwei auf drei Wochen verlängern. Es hat diesen Wunsch nun schon in mehreren Retrospektiven thematisiert und verschiedene Argumente dafür vorgebracht. Das Meinungsbild im Team ist seit mehreren Wochen unverändert geblieben.
Der ScrumMaster dieses Teams hat zumindest zwei Möglichkeiten:

Angenommen, der ScrumMaster wählt den zweiten Weg. Seine Position ist für die Beibehaltung der zweiwöchigen Sprints – damit geht er in das Team. Da der ScrumMaster keine disziplinarische Führungkraft ist, darf er seine Entscheidung dem Team nicht einfach vorschreiben. Er muss es dazu bringen, seine Entscheidung mitzutragen.
Wichtig sind hier vor allem zwei Dinge:

  1. Der ScrumMaster muss dem Team deutlich machen, warum ihm seine Position wichtig ist. Ansonsten wird das Team nicht verstehen, warum es ihm folgen soll. Das heißt im Umkehrschluss, dass ein ScrumMaster sich überlegen muss, wo er seinen Führungsanspruch geltend machen muss und wo das Team besser selber entscheidet.
  2. Der ScrumMaster muss dem Team deutlich machen, dass er nicht bereit ist, ohne Weiteres von seiner Position abzuweichen. Fängt er nämlich an, beim ersten Gegenargument ins Zweifeln zu geraten und seine Meinung zu revidieren, lässt er seine Führungsrolle fallen und wird zum Mitdiskutierer auf gleicher Ebene. Das Team merkt dann, dass es sich nicht wirklich an seinem ScrumMaster reiben kann. Standhaftigkeit ist aber nicht mit Sturheit zu verwechseln. Deshalb sollte der ScrumMaster seine Position so vermitteln, dass sie dem Team zugleich eine Perspektive bietet: Was muss alles getan werden, damit zweiwöchige Sprints besser werden? Damit die Skepsis des Teams verschwindet? Und wie kann der ScrumMaster als Servant Leader dabei helfen? Eventuell ergibt sich dann sogar eine Kompromisslösung. Zum Beispiel: Zweiwöchige Sprints ja, aber dafür Commitment auf weniger Stories, die dann dafür wirklich fertiggestellt werden.

Für den ScrumMaster ist die Situation eine Probe seiner Autorität: Wenn das Team seine laterale Führungsrolle anerkennt, wird es ihm letztlich folgen. Wenn es das nicht tut, wird es seiner ursprünglichen Überzeugung folgen und damit dem ScrumMaster signalisieren: “Du gibst uns nicht den Weg vor.”
So gesehen hat der ScrumMaster für sein Team eine Ankerfunktion: Er markiert Positionen als unverrückbar und setzt damit dem Team Handlungsgrenzen. Diese Grenzsetzung darf ruhig Irritation auslösen und konträr zum Team stehen. Negativ wird Führung erst dann, wenn sie die Entwicklung des Team einschränkt. Dann wird der ScrumMaster zum Impediment – und sollte besser gehen.
Keine Führung  (und das ist unter ScrumMaster die weitaus häufigere Situation) kann aber ebenso verheerend sein. Denn ein ScrumMaster, der immer nur sein Team entscheiden lässt, mag zwar jede Menge von Scrum verstehen – sein Team wird er damit nicht wirklich befruchten können. Denn Meister kann nur sein, wer die Gefolgschaft eines Lehrlings für sich gewinnen kann.
Reinhard K. Sprenger 2012: Radikal führen. Campus Verlag.
Siehe auch:

Der ScrumMaster, der besser keiner sein sollte
Führung selbstorganisierter Teams – alte Theorie vs. Scrum

Führung selbstorganisierter Teams – alte Theorie vs. Scrum

Die Rolle des ScrumMasters wird gerne schnell auf die des Moderators und des Organisators reduziert. Das ist schön greifbar und man hat die Erfahrung, dass solche Aufgaben wichtig sind und somit ihre Daseinsbereichtigung haben. ScrumMaster zu sein ist allerdings mehr als das. Es ist eine moderne Art der Führung, ohne disziplinarisch vorgesetzt zu sein. Die Kombination mit der Führung eines selbstorganisierten Teams wirft daher schon lange Fragen auf wie:

Solche Fragen tauchen nicht nur in Scrum auf, sondern begleiten die Forschung und Praxis selbstorganisierter Teams seit jeher. Schon 1986 versuchten sich Manz/Sims in ihrem Artikel “Leading Self-managed Groups: a Concept  Analysis of a Paradox” an einer integrativen Perspektive zur Führungsrolle in selbstorganisierten Teams. Dabei fassen sie auf Grundlage der sozio-technischen Systemtheorie und der sozial-kognitiven Lerntheorie das im Folgenden beschriebene Führungsverhalten zusammen. Da mir beim Lesen und Zusammenstellen vieles doch sehr bekannt vorkam, werde ich einfach die entsprechende Scrum-Sicht der Dinge ergänzen. In diesem Blog die gruppeninternen Aufgaben (direkt auf die Gruppe bezogen) und beim nächsten Mal die Aufgaben/Verhalten an der Grenze von der Gruppe zur Organisation.
Obwohl es in der Darstellung nicht explizit benannt wird, betrachten Manz/Sims (1986, S. 147) externes Führungsverhalten. Vielleicht hilft die Aufstellung dem einen oder anderen bei der Argumentation, warum wirklich ein ScrumMaster pro Team bzw. nur ein Team pro ScrumMaster drin ist!

Aufgaben Teamleitung eines selbstorganisierten Teams nach Manz/Sims Aufgaben des ScrumMasters
Mit dem allgemeinen Ziel, die Leistung des Teams zu steigern, sorgt der externe Teamleiter für die Förderung, Ver- und Bestärkung (und ggf. Unterstützung), nicht Durchführung oder Anleitung der Gruppe (vgl. Manz/Sims, 1986, S. 148f., 150f. ): 
Der ScrumMaster beschützt das Team vor externen Unterbrechungen und Störungen. Er hilft Probleme zu beseitigen, verbessert die Produktivität des Teams, treibt „inspect and adapt“ Zyklen voran. Er ist Moderator und lateraler – d.h. nicht weisungsbefugter – Leiter des Teams. Er arbeitet mit dem Product Owner, um die Rentabilität von Investitionen ins Produkt zu maximieren. Er stellt sicher, dass agile Prinzipien und Ideale verstanden und organisationsweit respektiert werden. Aber: Er ist nicht verantwortlich für die Lieferung des Produkts.
  • gruppeninterne Kommunikation – Austausch und Diskussion von Ideen und Bedenken
  • Der ScrumMaster sollte beim Team sitzen, damit er den Austausch mit Fragen initiieren, oder ggf. das Weiterführen fördern kann
  • Training unerfahrener Mitarbeiter durch das Team – Erschließung der Potenziale der Gruppe
  • Der ScrumMaster sorgt dafür, dass z.B. durch Pairing, Reviews, gemeinsame Plannings etc. der Wissensaufbau und Austausch funktioniert und somit alle bestmöglich beisteuern können
  • Problemlösung im Team – Evaluation und Lösung der eigenen Probleme
  • Der ScrumMaster gibt keine Lösungen vor (selbst wenn ihm sofort eine einfällt) oder Anweisungen, sondern versucht z.B. durch Fragen das Team zur eigenständigen Lösungsfindung und ggf. Alternativenbetrachtung zu bringen
  • teaminterne Arbeitsverteilung – effektive Aufteilung der Aufgaben zwischen Mitgliedern
  • Nicht nur im Daily achtet der SM darauf, dass der nötige Fokus bleibt und die Teammitglieder gemeinsam an der Lösung arbeiten
  • Planung – Koordination und Festlegung der notwendigen Aktivitäten vor der Durchführung
  • Moderation im Sprint Planning 1 und 2 und bei aufkommenden Unklarheiten oder Verbesserungsvorschlägen sorgt für ein gemeinsames Bild und Verständis, bevor man anfängt umzusetzen
  • Selbstbeobachtung / Selbstüberwachung – Gewinnung von Informationen über die eigene Arbeit als Grund