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!

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Als ScrumMaster werde ich in Unternehmen geholt, um zur Produktivitätssteigerung Scrum „einzuführen“. Relativ schnell begegne ich dabei folgendem Umstand: Viele Product Owner haben nicht im Blick, was ihr Team eigentlich genau liefern soll. Jedenfalls beantworten sie diese Frage selten aus Kundensicht. Meistens treffe ich auf Product Owner, die durch ihre lange Erfahrung und ihr umfangreiches Wissen zwar Experten für ihre Produktsparte geworden sind, aber ihr Blick hängt am eigenen Tun und Denken fest. Letzteres ist folglich zu wenig nach draußen gerichtet, in die Erlebniswelt des Kunden und des Nutzers. Für mich als ScrumMaster bedeutet das, den Product Owner und das Entwicklungsteam zu dieser Sicht- und Denkweise hinzuführen, was viel umfassendere Implikationen hat, als einfach mal eine neue Methode „einzuführen“. Genau genommen sprechen wir von der Entwicklung hin zu einer kundenorientierten Organisation, und das wirkt sich gleich auf mehreren Ebenen aus:
Ein wichtiger erster Schritt ist, eine agile Produktentwicklung zu etablieren. Das heißt im Idealfall, dem Scrum-Team beizubringen, wie man iterativ ein MVP (Minimum Viable Product) entwickelt und es dem Markt bzw. den Usern aussetzt – bis ein Produkt gefunden wird, das es sich in allen Details fertig zu bauen lohnt.
In diesem Prozess stellt man wiederum fest, wo es im Team an Skills mangelt, und in der Regel tut es das. Die nächste Aufgabe wäre also, diese Skills zu entwickeln. In der Softwareentwicklung hat sich für den Aufbau und den Austausch von Wissen das Mob bzw. Pair Programming etabliert, das Prinzip lässt sich aber auf andere Arbeitsbereiche anwenden. Fehlen bestimmte Skills zur Gänze, muss man sich diese zusätzliche Kompetenz ins Team holen.
Auf der Ebene der Infrastruktur stößt man schnell an Grenzen, die aufgelöst werden wollen: Hat das Team überhaupt geeignete Räume, in denen die Zusammenarbeit möglich ist? Sind Kommunikationsmittel im Einsatz, mit denen die Teamarbeit strukturell überhaupt abgebildet werden kann („Pull“-basierte Tools wie Slack oder Microsoft Teams können das), oder läuft die schriftliche Kommunikation des Teams hauptsächlich über E-Mail? Gibt es Arbeitsmaterialien wie Flipcharts, Whiteboards etc. erstens in ausreichender Menge und zweitens in guter Qualität?
Bleibt noch die Ebene der Architektur, auf die man einen Blick werfen sollte. Wie ist das Unternehmen organisiert und passt diese Organisationsstruktur überhaupt zu dem Produkt, das sich die Kunden und Anwender wünschen? Eng verbunden damit ist die Frage der Führungskultur in der Organisation: Sind Selbstorganisation, Freiwilligkeit und Commitment erlaubt und werden sie belohnt?
Was bedeutet das für die Arbeit als ScrumMaster oder Agile Coach? Ich muss einerseits die genannten Ebenen im Blick behalten und gleichzeitig meine Rolle mit Konsequenz leben. Das bedeutet, die agilen Werte und Prinzipien mit Bestimmtheit zu vertreten. Das bedeutet zum Beispiel, den nötigen langen Atem mitzubringen und dem Management so lange auf den Nerv zu gehen, bis die Lizenz für das geeignete Kommunikationstool gekauft wurde. Müsste ich das Handeln des ScrumMasters auf einen Aspekt reduzieren: immer wieder transparent machen, wo es hängt – auf allen Ebenen. Nur so komme ich überhaupt an die entscheidenden Punkte heran, die eine Organisation in ihrer Produktivität behindern.

Product Owner in Scrum

The Product Owner is mostly known to be responsible for two major things: a healthy ROI and prioritizing the backlog. However, his tasks go way beyond that and are critical for a Scrum team to succeed.
If you want to find out which other responsibilities a Product Owner has, please join me for my how-to video.

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

Wenn’s wichtig ist, kommt’s wieder: über das "Nein" des Product Owners

In meiner Karriere als Beraterin durfte ich viele Projekte und Produktentwicklungen beobachten. Eine dieser Beobachtungen möchte ich besonders gerne teilen: Teams, die zu vielen Anforderungen „nein“ sagen, sagen immer zu einigen wenigen, wirklich wichtigen, ein ganz klares „Ja“. Diese Anforderungen werden mit einem Commitment gekrönt und werden garantiert in einer hohen Qualität geliefert. Diejenigen, die zu allem „ja“ sagen, bekommen in der Regel nur Weniges wirklich fertig. Hier wird es immer schwieriger, sich zu fokussieren und eine gute Priorisierung hinzubekommen.
Und wenn das Team merkt, dass etwas mal wirklich vergessen wurde, oder sich auf Basis der gelieferten Features und Stakeholderfeedback herausstellt, dass etwas wichtig ist, wird dies vom PO bereitwillig ins Backlog aufgenommen.
Das St. Galler Management Modell sagt dazu: „Durch das Weglassen von Vielem wird das Realisieren von Wenigem ermöglicht.“ Damit stellt es ein Grundparadigma für gutes Management heraus, das mit den Werten, Haltungen und Sichtweisen agiler Produktentwicklung und der Aufgabe des PO übereinstimmt, mit Anforderungen sehr selektiv umzugehen.
Der gute Product Owner bewältigt zwei Herausforderungen:
a.) Er bringt den Mut zum „Nein“ auf und
b.) vertraut darauf, dass wirklich Wichtiges wiederkommt, obwohl es schon einmal abgelehnt wurde.
Das spart Zeit beim Verwalten langer Anforderungslisten und ermöglicht den Fokus auf das Liefern, aufs Wesentliche.
Wagen Sie das Experiment und sagen Sie „Nein“.

Foto: (c) rawpixel

Scrum – eigentlich so einfach wie kochen

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

Mit Offenheit kocht es sich leichter

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

Die Vision: Pasta oder Schweinshaxe?

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

Die Constraints: der Blick in den Kühlschrank

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

Die Rollen: Verantwortung teilen – kochen im Team

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

Kochen und abschmecken: Selbstreflexion und Feedback-Loops

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

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

Video: Der Product Owner

Die Rolle des Product Owner ist vielleicht die einfachste Rolle und doch auch jene, die von vielen vollkommen missverstanden wird. Der Product Owner ist Teil des Scrum-Teams. Er arbeitet mit dem Scrum-Team. Das heißt: Er ist kein Anforderer, der etwas vom Team bauen lässt, sondern ein integraler Teil. Er hat eine spezielle Sicht auf die gemeinsame Arbeit. Er will, dass das Scrum-Team möglichst nur das liefert, was auch wertvoll ist – also vom Kunden gekauft werden wird.
Der Product Owner ist für den Return on Investment zuständig, er entwickelt die Produktvision, teilt diese, arbeitet mit den Stakeholdern, um die Constraints zu finden und reduziert das Backlog immer wieder, um möglichst nur das Wichtigste und Wertvollste zu entwickeln.
 
image_Strategie-Product_Owner
 
Im Video stelle ich den Product Owner kurz vor und ich hoffe, es ist verständlich, was ich dazu zu sagen habe.
 

 
Viel Spaß beim Anschauen! — Boris

How do stakeholders participate in Scrum projects?

A program manager asked me how one makes sure that all necessary information from different stakeholders is considered in a Scrum initiative. How can it be made sure that nothing gets forgotten? Usually, the answer to this question is: the team has to care for all the information. Another solution would be: everybody needs to be part of the team. However, these solutions look great on paper but they are not feasible in organisations which want to start using an agile approach. Well, at least in the beginning.
We have to differentiate between strategical and tactical processes of product development. In other words, you have to consider the long term view (strategical) and short term view (tactical). Any organisation needs to plan and execute both processes simultaneously. But both aspects need different good practices to support success.
I suggest to free the Product Owner from working on tactical issues as much as possible. So we do not want him/her to spend time on e.g. writing user stories or talking to end users to come up with ideas for features. At borisgloger consulting we believe his/her capabilities should be strengthened in order to work on the strategic level. On one hand that means he/she shall have the authority to work strategically more often and on the other hand it means he/she shall dedicate his/her time to the practices that one needs for performing on this level:

Most people in the Scrum community know how to build a product vision or a product backlog but what is a list of constraints? What is its purpose and where does it come from?
image_stakeholders
 

List of Constraints

The list of constraints contains the needs of the stakeholders. The Product Owner is responsible for facilitating a conversation amongst all stakeholders. In this conversation they are supposed to talk about their specific needs (see picture above). I use the word “needs” instead of “interests” because I want to distinguish strategic needs from tactical features. For instance, if someone in an organisation is responsible for making sure that a product meets the regulatory requirements of the Food and Drug Administration (FDA), he has the need that these requirements are acknowledged. So it is the job of the Product Owner to translate this need into strategical constraints. This practice ensures that the regulatory requirements are not treated as a low priority feature.
Together with all stakeholders, the Product Owner creates the list of constraints at the beginning of a Scrum initiative (product, service). However, it is not a static but a rather dynamic list. It is the job of the Product Owner to stabilise this list over time. To do this, he creates a reflexive process that continuously reviews the validity of constraints. He also updates the list if necessary. Please notice that he has to communicate all updates to all stakeholders. He also has to ensure that all resulting changes are incorporated into the product or service.

Stakeholders

For understanding Scrum as a model, reducing the list of stakeholders to a set of roles is useful. However, a model masks the fact that a Product Owner needs to take the needs of all stakeholders into account. So, who is a stakeholder of a Scrum initiative? Which players are part of a project or department? Who is influenced by it? Who wants to influence the outcome of the project, even if they do not have a role within the project? And, most important, what are their interests and motives? Analysing who will be relevant stakeholders is essential for being successful with your projects. Again, the list of stakeholders must be reviewed and monitored throughout the delivery cycles. So the list I present here is not a comprehensive one but may rather be seen as a starting point for you:

  1. Customer (internal, external): Who is the customer? Who ist the real decision maker? What is his/her need?
  2. People in the development team: What does every individual in the team want to achieve for his- or herself? Maybe your team consists of parents of very young children. What do they need to be effective team members?
  3. Other departments/projects: What are the needs of these projects or departments? Means: Which interests does the management of these initiatives have? For example:
    a. HR department
    b. the work council
    c. Sales
  4. End user: Who is the end user? Which needs do they have, besides ideas for new features?
  5. Management:  Which interests does the management or the management of sister departments have? Are there any political aspects we have to bear in mind in this project?
  6. Suppliers (other teams, external companies): Do our suppliers have specific needs that our  project/service needs to meet
  7. Governments/Regulators: Is there a player that we need to take into consideration? What do we need to know about them?

Dialogue

In our company we follow a very strict principle: “Community building first, decision making second.” It means more or less: bring the respective people together and do so on a regular basis. What’s the idea behind this? We want to create a mutual relationship to build trust. Because we believe trust is based on knowing each other. So it is paramount that the Product Owner talks with all people using round table discussions. The purpose of this conversation is to recognise all needs and build trust.
We use a format called the Circle Way to facilitate these meetings successfully [1]. By doing this on a regular basis you will be able to create a “community” that cares for your product or service. As an additional benefit, it creates a clear and concise picture of the environment a Scrum initiative is working in and for.

Tactical work

The tactical work for your Scrum initiative is done by the cross-functional, multi-disciplinary product/service (development) team (in short: the team). In its role as a stakeholder the team works with the Product Owner on creating, understanding and updating the list of constraints. Team and Product Owner share their vision and they work together on the roadmap. However, the team works with the end user on ideas for features and creates the according user stories, implements the user stories into the application, runs the sprints and so on. The Product Owner works with the team on the tactical level to enable and facilitate decisions but he/she shall not heavily influence tactical decisions of the team.
Using this refined understanding of the role of the Product Owner, the usage of constraints and the way stakeholder can influence the Scrum initiative on a regular basis will enable Scrum-teams to become more productive because it channels information to the right people and gives them  authority.
 
Literature
[1] If you are interested to know more about the Circle Way please have a look into this little 2-page document. It will tell you how to run a meeting using this process.