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.