Die Suche nach dem Warum – und wie Sie Ihre Vision finden

Ich arbeite jeden Tag mit Teams zusammen, die auf ambitionierte Ziele hinarbeiten. Sie bereiten beispielsweise den Market-Launch eines völlig neuartigen Hardware-Produkts vor oder überarbeiten das bestehende IT-System grundlegend. Diese Produkte erweitern das bisherige Angebot des Unternehmens. Sie sind Teil der Weiterentwicklung des aktuellen Geschäftsmodells und zahlen auf die Neuausrichtung ein, die vom Top-Management angestrebt wird. Die Teams selbst sehen jedoch häufig nur eines: Diese neuartigen Produkte passen nicht zum bisherigen Angebot des Unternehmens. Und so steht immer wieder die unausgesprochene Frage im Raum: Warum machen wir das?

Die Antwort auf dieses Warum bleibt man den Teams oft schuldig. Man gibt ihnen keine Vision, zeichnet ihnen kein Bild der Zukunft und lässt sie im Ungewissen, worauf ihre Arbeit einzahlt. Wenn wir uns die folgende Geschichte ansehen, wird jedoch deutlich, welchen entscheidenden Unterschied ein solches Zukunftsbild bewirken kann:

Ein Fremder geht durch die Gassen einer Stadt. Er trifft auf drei Maurer und sieht ihnen bei der Arbeit zu. Nach einiger Zeit fragt er die drei, was sie da tun. „Das sehen Sie doch”, erwidert der erste mürrisch, „Ich bearbeite einen Stein.” Und der zweite Maurer, der das Gleiche tut, sagt gelangweilt: „Na, ich errichte eine Mauer.” Der dritte Maurer allerdings antwortet mit glänzenden Augen: „Ich baue eine Kathedrale.”

Wir wollen alle eine Kathedrale bauen

Warum ist eine Vision wie der Bau einer Kathedrale so wichtig für uns? Weil wir alle auf der Suche nach unserem persönlichen Warum sind, das uns jeden Tag aufs Neue motiviert. Wir sind auf der Suche nach einer Vision, die unsere persönlichen Werte widerspiegelt. Und nach einer Organisation, die nach diesen Werten ausgerichtet ist und in der wir durch unsere tägliche Arbeit zur Umsetzung dieser Vision beitragen können. Wir wollen nicht einfach nur Stein auf Stein setzen. Wir wollen in 10 Jahren zu unseren Kindern sagen können: Das, was ich getan habe, hat etwas bewirkt. Siehst du diese Kathedrale dort? Die habe ich miterrichtet! Besonders in Zeiten der Veränderung und bei der Neuausrichtung eines Unternehmens braucht jeder Mitarbeiter und jedes Team ein solches Ziel vor Augen. Ein Ziel, das die Hoffnung auf Verbesserung aufkeimen lässt und den Weg in die neue Zukunft zeigt.

Und doch fehlt vielen Teams und Unternehmen eine solche Vision. Woran kann das liegen? Zum einen mangelt es oft an Zeit und andererseits fehlt das Wissen darüber, wie man überhaupt eine Vision entwickelt. Dabei ist das gar nicht so schwer.

Der Bauplan für Ihre Vision

Der erste Schritt ist meiner Erfahrung nach, sich als Führungspersönlichkeit – sei es als Product Owner oder Cluster Lead – die Zeit zu nehmen, um sich selbst darüber klar zu werden: Warum brauchen wir dieses Produkt? Eine Vision wirkt durch die Kraft der Worte, daher sollten Sie diesen ersten Entwurf Ihres Zukunftsbildes niederschreiben. Und dann stellen Sie sich die folgenden Fragen:

Wenn Sie jede dieser Antworten mit Ja beantworten können, dann nehmen Sie Ihre Vision und reden Sie darüber. Teilen Sie diese mit Sparring-Partnern und passen Sie sie immer wieder an. Sobald Sie Ihre Vision durch Iterationen entsprechend nachgeschärft haben, können Sie diese Ihrem Team vorstellen. Freuen Sie sich auf das Feedback, das ihnen dabei helfen wird, Ihr Zukunftsbild noch präziser zu formulieren.

Anschließend bleibt noch ein letzter wichtiger Schritt: Schicken Sie das Team mit dieser Vision auf die Suche nach dem Wie. Wie können wir als Team diese Vision erreichen? Welche Schritte sind notwendig? Seien Sie für Ihr Team da und beantworten Sie dessen Fragen. Und vor allem: Beobachten Sie, wie sich die Zusammenarbeit positiv verändert!

Agilität muss man aushalten können – Szenen aus der Praxis

1. Sackgasse Selbstorganisation – wenn keiner pullt

Auch bei borisgloger consulting richten wir den Blick regelmäßig nach innen. Retrospektiven sind für uns ein fester Bestandteil, um gemeinsam herauszufinden, mit welchen konkreten Maßnahmen wir Verbesserungen herbeiführen können. Mit zwei weiteren Kollegen übernahm ich die Planung einer dieser Retrospektiven. Die Wahl fiel auf ein Format, bei dem das Team in zwei Gruppen aufgeteilt wird, die sich am Ende die erarbeiteten Ergebnisse gegenseitig vorstellen. Warum? Weil man bei diesem Format gleich zweimal Feedback bekommt: einmal in der Teilgruppe und danach beim Vorstellen und Challengen der Ergebnisse am Ende.

Alle waren mit dem Ergebnis zufrieden. Zuletzt sollten noch die zuständigen Kollegen gefunden werden, die die erarbeiteten Maßnahmen dann angehen und umsetzen würden. Die Frage „Wer kümmert sich drum?“ stand im Raum. Schweigen. Auch nach einer Weile gab es kein „hier“ zu hören. Selbst in selbstorganisierten Unternehmen ist das nicht unbedingt überraschend. Dennoch, für einige im Team war das höchst unbefriedigend. Die Gründe für die Zurückhaltung sind vielseitig: Die eigene Priorisierung der Aufgaben, wichtige andere Commitments am gleichen Tag etc. Wie schafft man es trotzdem, die Verantwortung zu verteilen? Das Pull-Prinzip, nach dem wir arbeiten, fordert, dass die Arbeit im agilen Kontext freiwillig gezogen und eben nicht angeordnet wird.

Option A: Vielleicht werden die definierten Maßnahmen später gezogen oder auch gar nicht, wenn anderes einfach höher priorisiert ist.
Option B: Der ScrumMaster weist daraufhin, dass die Aufgabe auch gemeinsam übernommen werden kann und motiviert dadurch neuere Teammitglieder, den Sprung ins kalte Wasser zu wagen.
Option C: Der Product Owner priorisiert diese Aufgabe höher und vermittelt damit, dass die Aufgabe wichtig ist und gezogen werden sollte.

Wenn Teams mit Scrum zu arbeiten beginnen, ist das freiwillige Pull-Prinzip oft schwierig zu akzeptieren oder schwer nachvollziehbar. Ist es nicht viel einfacher, Aufgaben direkt zu verteilen anstatt zu warten? Das wäre am Anfang tatsächlich einfacher. Nur, ist es eine nachhaltige Alternative, die Aktivitäten per Ansage zu verteilen? Wie groß ist dann die Wahrscheinlichkeit, dass sie mit der notwendigen Motivation und Konsequenz umgesetzt werden? Was bleibt dafür im Gegenzug liegen? Hier braucht es Mut, unterschiedliche Optionen auszuprobieren und darauf zu vertrauen, dass die Teammitglieder eine Lösung finden werden.

2. Commitment muss gelernt werden

Gleiches Thema, anderes Setting. Ich hatte zu einer teamübergreifenden Retrospektive eingeladen. Es sollten Vertreter von zwei Teams geschickt werden. Ich erhielt die Zusage aller Kollegen und bereitete die Retro vor.

13:59 Uhr am Tag der Retro – Wir warteten auf vier Teilnehmer. Dafür hatte ein Team noch weitere Kollegen mitgebracht. Enttäuscht über das Nichterscheinen der Kollegen schlug jemand vor, die Retro abzusagen oder zumindest dafür zu sorgen, dass aus jedem Team gleich viele Personen am Meeting teilnehmen würden, damit es gerecht blieb. Das kam für mich nicht in Frage.

Ich konnte die anderen überzeugen, die Retro genau mit jenen Personen durchzuführen, die gekommen waren – ein Grundsatz, der auch im Open Space Format Anwendung findet. Mit der Aussage „Diejenigen, die kommen, sind die richtigen“ haben wir unsere Retrospektive durchgeführt und sogar die Timebox eingehalten. Es kamen tolle Ergebnisse dabei heraus und das Meeting war ein voller Erfolg!

Auch hier waren die Beteiligten erst unzufrieden mit der Situation. Und auch in diesem Fall spielt das Prinzip der Freiwilligkeit eine Rolle. Im „Open Space“ kennt man zudem das Gesetz der zwei Füße, das besagt, dass jeder nur dann erscheint, wenn er oder sie etwas lernen oder einen Beitrag leisten kann. Das war in diesem Meeting der Fall.

Agilität braucht viel Geduld und Durchhaltevermögen. Die Beteiligten dürfen die Prinzipien selbst in schwierigen Situationen nicht fallen lassen, auch wenn es Zeit braucht, bis alle an Bord sind und die agilen Werte und Prinzipien leben können.

Bis dahin gilt: In solchen Situationen muss man Agilität einfach mal aushalten können.

Foto: CC0 Creative Commons – pixabay, Pexels

Fostering cultural change by failing to deliver

What do cultural change and improving delivery results have to do with one another? This could very well be a question posed in any business environment that is facing calls for change and embracing new ways of thinking. Often by inertia, many companies, especially if they are doing well, will be quite resistant to change because they are doing well enough.

The fundamental assumption is that cultural change is about improving performance and therefore improving delivery. In that respect cultural change means living values such as openness, commitment, respect and courage. It also means building accountability where people in the company do things not because they have to do them, but because they want to do them. In essence, it is about developing and continuously refining an environment that enables seeing everyone’s role in an organisation not as a passive component, but an active contributor.

But, how is it connected to delivery? That is both simple and very difficult. The simple part is that by living the above-mentioned values individuals at all levels of an organisation are able to play accountable, self-reflecting roles who share a common vision and goal, therefore putting their efforts towards achieving it as a collective and improving performance. The difficult part is convincing people that this is worthwhile, and facilitating a process that will help them share the same vision and the same goal.

Change – everyone’s responsibility

So, who is responsible for bringing about cultural change? The simple answer is, everyone. It is a matter of having the management level committing and living the values and then unequivocally communicate them through the organisation. The more people in the organisation become acquainted with the values, the easier it will be to create a spontaneous communication matrix where the vision and values related to it are communicated and lived by, from meetings to lunch breaks. Clearly and consistently communicating values and visions and living those values will be the best form of feedback to everyone, that this is the way to go. This is what makes a team that does work, into a team that wants to do work and enjoys being a part of what it is doing.

The challenge, however, is that change, all other things remaining constant, is usually difficult. Not only that, but the saying ‘if it isn’t broken, don’t try to fix it’ goes a long way in thwarting innovation.

How to initiate change when everything seems okay

The benefits of change described above may be completely clear to the management, and the people in the company, but until they are in some kind of trouble and need to change something, will they do something about it? It is a bit like a company selling goods online. They have been doing well for years, but the introduction of new companies who are offering the same goods through a more user-friendly webpage, they are beginning to see a drop in their market share. The competitors have, on the other hand, been seeing a steady increase. Looking back, they could have changed, for example improving their 10-year-old webpage, which was clearly out of date and putting some customers off. Instead they relied on their previous performance and reputation thus ignoring the need for change even though the signs were there. Now, that the results are consistently indicating something is not right they are hearing the alarm bells ringing. And what do they do? They develop a new web page, by which time some damage has been done and their competitors have perhaps gained the upper hand. This tells us two things:

The example above can be put into a different context and at a different level. Imagine a team inside a company working on a new software. They have a large user story that they have committed to resolving over a period of time, i.e. a several sprints. They began working on them, but soon realised that they might not be making the release date because testing software is preventing them from carrying out tests as they develop rather relying on the end test. Although they have a development plan, they are not reflecting on the risks and communicating them. In other words, they have not embraced a culture which gives them the freedom to organise their work by continuously reflecting and producing smaller functional releases. With the deadline and the all-important release looming large, what does the team do?

The art of letting them fail

If you are the Product Owner, and your goal is cultural change, which you believe will bring better performance in the future, you will not intervene. Even if that means that the team will probably fail to deliver a functional product? Yes, even if that is what it takes. Of course, you weigh out the risks and benefits, but if you are serious about investing in cultural change, and having a real team, then you may realise that it is better off letting them fail.

The logic behind this is that just like the goods provider with an outdated website, there needs to be a trigger for the team or a company to learn to change and live the agile principles. If you as the Product Owner step in the team has not learnt much. In fact, if they are new to the agile working environment intervention will only end up supporting their view that old ways are best. They will be happy to play with agile methods, but not take the associated responsibility. And as always, the product owner (or the big boss) solves it all. If, on the other hand, you let them fail you have probably done them a favour because they will be able to question what they are doing as a team and realise that the commitment and responsibility were not there from their side. In other words, you as a company will fail on delivering in the short run but will have probably succeeded in massively investing in cultural change that will yield results in the long run.

Support the learning process

This does not mean that you need to let everything burn down in an instant. Culture change is also about patience, trust, and strategic thinking. All are immensely important before embarking on letting teams experience failure in order to stimulate change culture. First of all, there needs to be consensus that cultural change is a strategy that requires commitment, even if it does not (and it probably won’t) work immediately. As a ScrumMaster and a Product Owner you need to have trust that the team will be able to reflect on the results and the reasons for the results. You also need to show patience and provide an enabling environment for the team to reflect and find a solution to the reasons for the failure. Communicating values and visions, while also living by them is crucial in this respect because it will help the team feel that they themselves have a place to reflect and therefore move forward. Ultimately, what you as both a ScrumMaster or a Product Owner want to have is a team that are change agents.

Wie man einen Wal in die Freiheit springen lässt – der Free Willy Ride in Agile Organizations

Mittlerweile sind in Unternehmen die 5 Phasen der Veränderung (bzw. der Trauer) nach Kübler-Ross allseits bekannt. Scheinbar bildet das Modell etwas ab, das Menschen mal mehr, mal weniger wiedererkennen und das ihnen in Veränderungsprozessen Orientierung bietet. Nach nunmehr einiger Zeit in der Rolle als ScrumMaster stelle ich folgende These auf:

Das Hineintragen des agilen Prinzips der Freiwilligkeit in ein klassisch arbeitendes Team verläuft (in den meisten Fällen) ebenfalls nach einem bestimmten Muster.

Ich nenne dieses Muster „Free Willy Ride in Agile Organizations“ nach Vera Ferreira Mafra. Zum einen amüsiert mich das Wortspiel im Englischen und zum anderen erscheint mir die Geschichte des berühmten Film-Wals „Free Willy“ eine gute Analogie zu sein. Ein Wal in Gefangenschaft (Kultur des Command & Control) schafft durch die Freundschaft mit einem Jungen (Agilität & ScrumMaster) den Sprung in die Freiheit (Leben der Freiwilligkeit & neue Haltung zur Arbeit). Die dramatische Komponente des Films, dass der Tierparkbesitzer Free Willy töten möchte, um die Versicherungsprämie zu kassieren, klammere ich für meine Zwecke aus.

Was ist der Free Willy Ride?

Der Free Willy Ride besteht aus acht Stationen: Kennenlernen – Sacken lassen – konfrontiert werden – Widerstand leisten – Verstehen – Transfer starten – Einspruch erheben – selbstverständlich anwenden

Veränderung

1. Kennenlernen
Zu Beginn hat der ScrumMaster einen großen Beitrag als Trainer zu leisten, um die agilen Prinzipien und Werte in einem Team bekannt zu machen. Durch Schulungen, Formate wie Brown Bag Sessions oder Scrum Shots, Literatur und und und erfahren die Teammitglieder, dass Freiwilligkeit ein agiles Prinzip ist. Die Augen werden groß, die Ohren spitz: Freiwilligkeit – das klingt gut!

2. Sacken lassen
Was eingangs zu großen Augen geführt hat, entpuppt sich bald als diffuse Worthülse. Als ScrumMaster lege ich meinen Fokus gerade auf Fokus und Commitment. Das Ziel ist, die Teams in einen Liefermodus zu bringen und Vertrauen zu mir aufzubauen. Wo macht sich denn nun die Freiwilligkeit bemerkbar?

3. Konfrontiert werden
Nachdem mich das Team als ScrumMaster nun schon ein wenig kennt und mit den Basics bereits erste Erfolge gefeiert hat, zaubere ich das Prinzip der Freiwilligkeit aus dem Hut. Ich nutze jede sich mir bietende Meetingsituation, um verschiedene agile Prinzipien gebetsmühlenartig zu platzieren:

Wenn ich merke, dass ein Meeting unzureichend vorbereitet ist und in vielschichtige Diskussionen ausartet, stehe ich auf, berufe mich ebenfalls auf das Prinzip der zwei Füße und verlasse ohne weitere Erklärung den Meetingraum. Ein völlig perplexes Team bleibt zurück. Ich ziehe es durch und das Team erlebt Freiwilligkeit. In den Teammitgliedern bewegt es etwas, gut so.

4. Widerstand leisten
Freiwilligkeit als Gesprächsthema steht jetzt im Raum. Egal wie sich die Teammitglieder drehen und wenden, ich piekse mit der Freiwilligkeit. Und jetzt passiert etwas Spannendes: Die Teammitglieder instrumentalisieren das Prinzip der Freiwilligkeit. Es fallen Sätze wie:

Die Teams führen das Thema ad absurdum, aus den Mündern tönen Ironie und Skepsis – aber: Sie sprechen darüber und nutzen die Begrifflichkeiten. Klammheimlich vollführe ich Freudentänze: Endlich habe ich eine Basis, auf der ich in die konstruktive Auseinandersetzung mit dem Team gehen kann.

5. Verstehen
„Lasst uns doch mal eine kleine Session starten, die wir einzig und allein dem Thema Freiwilligkeit widmen!“ Ich erkläre dem Team, in welchen Rahmen sich diese proklamierte Freiwilligkeit einbettet. Ich erzähle ihnen von ihrer Aufgabe als Dev-Team, die Qualität des Produkts sicherzustellen, und von Team-Commitment. Ich erkläre ihnen, dass die Freiwilligkeit ihre Wahlmöglichkeiten erweitert: Sie dürfen auf einmal „Nein“ sagen und sie dürfen auf einmal sagen, bei welchen Aufgaben sie sich selbst sehen.

6. Transfer starten
Freiwilligkeit ist nach der Session kein Schwarz-Weiß-Thema mehr. An manchen Teammitgliedern ist das Thema ohnehin vorbeigegangen, weil es ihnen nicht wichtig erscheint, andere verweilen weiterhin im Widerstand. Das ist völlig okay, ich konzentriere mich auf diejenigen, die neugierig fragen und sich in ihrem Alltag damit auseinandersetzen. „Also ich sehe gerade ehrlich gesagt keinen Mehrwert für mich in diesem Meeting und einen Beitrag leisten kann ich auch nicht … Gesetz der zwei Füße, oder?“ „Jetzt ist der richtige Zeitpunkt zu pullen, oder?“ Sie sprechen ihre Gedanken aus und hängen gefühlt an jeden Satz ein fragendes „oder?“, oder sie machen Aussagen und gehen am Satzende etwas mit ihrer Stimme hoch – meine detektivischen Sensoren springen an: Eine Frage als Aussage getarnt. Aha! Sie erfragen mein Feedback und tarieren aus, ob sie richtig liegen oder ob noch etwas fehlt.

7. Einspruch erheben
Meist haben die Teammitglieder nun für sich selbst in den verschiedensten Situationen hinterfragt, wann das Prinzip der Freiwilligkeit für sie greift und wie es mit anderen Prinzipien zusammenhängt. Im nächsten Schritt werden sie mutiger. Sie beobachten gezielt Situationen und nehmen für andere die Rolle des Richters ein: „Klaus, als PO ist es nicht deine Aufgabe, Tasks zuzuweisen! Das widerspricht dem Pull-Prinzip!“ Jackpot! Ich bin nicht mehr ein einsames querulantisches Fähnchen im Wind mit der Aufschrift Scrum. Stattdessen habe ich aus dem Team selbst heraus Fürsprecher gewinnen können! Dem Schneeballprinzip folgend, setzen sich zunehmend mehr Teammitglieder damit auseinander und es wird zum Usus im Team.

8. Selbstverständlich anwenden
Und dann springt Free Willy in die Freiheit und lässt los! Die Freiwilligkeit ist dem Team durch die bewusste Auseinandersetzung und durch die Reflexion in spezifischen Situationen in Fleisch und Blut übergegangen. Sie ist zum integralen Bestandteil der Arbeitsweise geworden.

Es hat mit einer Blogidee zum Thema Freiwilligkeit im agilen Arbeitsumfeld und einem Wortspiel begonnen. Ich wollte einen Namen für mein skizziertes Muster finden und das hat für mich persönlich den Wal schließlich zu einem Sinnbild für Freiwilligkeit in Teams werden lassen. Auf dem Weg zur gelebten Freiwilligkeit beobachte ich meine Teams und frage mich: „In welcher Phase schwimmt Free Willy gerade rum?“

Foto: CC0 Creative Commons – pixabay, Free-Photos

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.

Wohnung putzen mit dem Minimum Viable Product

„MVP“ – Minimum Viable Product – ist ein verbrannter Begriff. Er wurde missbraucht, um eine Brücke zwischen dem klassischen und dem agilen Projektmanagement zu schlagen. Arbeitspakete des Projektablaufplans werden kurzerhand zu MVPs umgetauft – so wirkt alles schon viel agiler. Dabei wird jedoch eines vergessen: Ein MVP ist ein Produkt, das mit seinen Eigenschaften bereits die minimalen Anforderungen des Kunden abdeckt. Ein Produkt, das in sich geschlossen ist und einen Mehrwert bietet. Etwas, das schon verkauft werden könnte und wofür der Kunde bezahlen würde. Wenn der Kunde beispielsweise sagt, er möchte von Punkt A zu Punkt B gelangen, dann ist ihm mit einem Reifen nicht geholfen. Dazu benötigt er schon ein Fortbewegungsmittel, das seiner wichtigsten Anforderung – der Fortbewegung – genügt. Aufbauend auf diesem MVP können anschließend weitere Anforderungen hinzugefügt werden – der Kundennutzen wächst und ein neues MVP entsteht. Trotzdem fällt es vielen schwer, die Übertragung aus der klassischen Welt mit ihrer Meilensteinplanung hin zur Customer Journey mit MVPs und einem Releaseplan nachzuvollziehen. Für den Ausbruch aus diesen eingefahrenen Denkmustern braucht man manchmal aber nur einen kreativen Ansatz, um den Zusammenhang klarer zu machen. Was eignet sich dafür besser als eine alltägliche Situation?

Putzen Sie Ihre Wohnung – MVP 1

Angenommen, der Wohnungsputz wird hauptsächlich von Ihrer Partnerin oder Ihrem Partner durchgeführt. Stellen Sie sich vor, sie wollen ihr oder ihm diese Aufgabe nun einmal komplett abnehmen. Wo fangen Sie an zu putzen? Welche Räume nehmen Sie sich vor? Und die wichtigste Frage: Wie viel müssen Sie putzen, damit sie oder er zufrieden ist, Sie aber nicht mehr als nötig gemacht haben? Dafür ist für Sie wichtig zu wissen, was der „Putz-Standard“ bei Ihnen zuhause ist. Die Mindestanforderungen Ihrer Partnerin oder Ihres Partners an den Wohnungsputz sind ein wichtiger Teil der Vorbereitung. Sinnvoll ist es außerdem, die Aufgaben zu sammeln, die in der gesamten Wohnung regelmäßig anfallen. Diese Aufgaben können gut den jeweiligen Räumen zugeordnet werden. So entsteht eine in Rubriken strukturierte Sammlung wie „Wohnzimmer“, „Küche“, „Bad“ und „Schlafzimmer“. Diese Rubriken können Sie mit Themenklammern gleichsetzen, also sogenannten Epics.
Wenn Sie nun also wissen, dass Ihre Partnerin oder Ihr Partner glücklich ist, wenn in jedem Raum gewisse Aufgaben erledigt sind, so ergibt sich für Sie eine Anzahl an Aufgaben, die in Summe das MVP ergeben. Nach der Erledigung sämtlicher Aufgaben, die zur Erfüllung des MVPs beitragen, kann das Ergebnis vorgeführt werden. Sie werden recht schnell merken, ob Ihre Überraschung geglückt ist und Sie alle Anforderungen erfüllt haben!

Stellen Sie sich vor, die Schwiegermutter kommt zu Besuch – MVP 2

Nun ist also Ihre Partnerin oder Ihr Partner durch dieses MVP zufrieden gestellt. Was passiert allerdings, wenn sich spontan die Schwiegermutter mit einem Besuch ankündigt? Dann muss das ursprüngliche MVP ein bisschen erweitert werden. Und zwar um genau die Aufgaben, die dabei helfen, auch die Schwiegermutter zufrieden zu stellen. Die Anforderungen aus dem ersten MVP bestehen weiterhin, es gibt jedoch Aufgaben, die es ergänzen. Das Gesamtpaket ergibt dann ein neues MVP.
Die gleiche Vorgehensweise kann auch in der Produktentwicklung angewendet werden. Auch dort sollte angestrebt werden, mit einem ersten Produkt, das dem Kunden einen Mehrwert bietet, den Markt bedienen zu können. Somit kann erstes Kundenfeedback frühestmöglich in die nächste Iteration einfließen. Außerdem lassen sich mit diesem Ansatz Fehlinvestitionen vermeiden und somit das Risiko minimieren, indem früh erkannt wird, ob eine Weiterentwicklung des MVP rentabel ist und welche Funktionalitäten vom Kunden überhaupt gewünscht und bezahlt werden.
Allgemein ist, wie auch beim Wohnungsputz, dabei zu berücksichtigen, wer die Zielgruppe des Produkts ist. So können Unternehmen entlang der Customer Journey ein Produkt entwickeln, das die rentabelsten Funktionalitäten enthält und die Kundenbedürfnisse befriedigt. Im Gegensatz zur klassischen Produktentwicklung setzt der Cashflow hierbei wesentlich früher ein, die Reaktions- sowie Entwicklungszeiten sind kürzer und der Kunde steht im Zentrum der Überlegungen. Der Trick ist also eine geänderte Perspektive auf die Produktentstehung.

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

Agiles Demand Management im skalierten Umfeld

Klassische Unternehmensbereiche und Scrum treffen oft aufeinander. Fast immer stellt sich dabei auch folgende Frage: Wie kann beides auf einen Nenner gebracht werden? Diese Frage stellt sich auch beim Anforderungsmanagement. Denn im grundlegenden Konzept von Scrum gibt es lediglich die Rollen Product Owner, ScrumMaster und Entwicklungsteam – Boris Gloger hat das Konzept um die Rollen Kunde, Management und Nutzer erweitert. Das klassische Demand Management wie in Großkonzernen, bei dem interne Anforderungen bewertet und gesteuert werden, findet sich in keiner der Rollen direkt wieder.
Der täglichen Arbeit des Anforderungsmanagements kommt die Rolle des Kunden noch am nächsten. Er liefert dem Product Owner jene Impulse, die er in eine Vision bündelt, um dem Entwicklungsteam die richtige Orientierung zu geben. Nun werden in einem Großkonzern auf eine entwickelnde Abteilung jedes Jahr hunderte Anforderungen aus allen Teilen des Unternehmens eingesteuert. Hier reicht die Rolle des methodisch sauber aufgesetzten Kunden nicht mehr aus, um die Anforderung zu handhaben.

Eine Lösung: das Demand Management Team

Doch für diese Problematik im skalierten Umfeld ist die Lösung leichter als gedacht. Bei einer größeren Anzahl von Scrum-Teams wird zwischen Kunde und Chief Product Owner (CPO) ein vorgelagertes Scrum-Team aufgesetzt: das Demand Management Team. Es arbeitet in regulären Sprints und übergibt im Refinement dem CPO die evaluierten und spezifizierten Anforderungen. Bei diesem Refinement können bzw. sollten neben dem CPO und dem Demand Management durchaus auch andere Experten anwesend sein. Schließlich kann ab einem bestimmten Komplexitätsgrad eine einzelne Person nicht die fachliche Tiefe mitbringen, um für Großprojekte alle Anforderungen adäquat zu priorisieren und den Return on Investment bewerten zu können.
Nach dem Overall Refinement werden die Anforderungen in den Sprintzyklen der skaliert zusammenarbeitenden Scrum-Teams bearbeitet. Am Ende des Sprints tritt das Demand Management wieder auf den Plan, um den Kunden und seine zu Beginn des Sprints eingesteuerten Anforderungen im “Overall Review” zu vertreten. Hier hat das Demand Management auch die Möglichkeit, Änderungen des Kunden zu kommunizieren. Sollte es der Kunde einfordern, ist das Demand Management in der Rolle des Transmitters nach diesem Termin auch aussagekräftig zu Zwischenständen und Teillieferungen. In der darauf folgenden “Overall Retro“ wird neben den projektübergreifenden Learnings auch der Rahmen aufgespannt, um die Zusammenarbeit zwischen Demand Management und CPO zu evaluieren und langfristig zu verbessern.
In der Praxis funktioniert diese Lösung sehr gut, dennoch sollten einige Voraussetzungen erfüllt sein, um den Übergang in die Agilität zu vereinfachen. Im ersten Schritt sollten die betroffenen Personen zu einem frühzeitigen Zeitpunkt inhaltlich und methodisch auf den gleichen Wissensstand gesetzt werden, sodass alle Beteiligten die gleiche Vorstellung von Begrifflichkeiten oder Artefakten haben. Sind Methode und Inhalte, sowie deren Anwendung klar, kann im finalen Schritt die Integration eines eigenen Scrum-Teams “Demand Management” angestrebt werden.

Foto: CC0 Creative Commons, pixabay – ulrichw

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