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.

Interview: Was macht ein ScrumMaster?

Meine Kolleginnen und Kollegen unterstützen unter anderem als ScrumMaster die Teams von Kunden. Worum sich ein ScrumMaster gerade kümmern sollte, hängt von der Phase ab, in der sich ein Team befindet – und zum Team gehört auch der Product Owner. Wie sich die Rolle des ScrumMasters im Laufe der Zeit verändert, erzählt Christoph Schmiedinger anhand seiner eigenen Erfahrung.

Scrum Roles

Scrum in its traditional form defined by Ken Schwaber and Jeff Sutherland consisted of only three parties: Scrum Master, Product Owner and Development Team. However, early on it was clear to me that the framework is not completed with only these three roles.  
Join me in my how-to video to find out which additional roles I include in the Scrum framework.

The Role of the ScrumMaster

There are many misconceptions about which key tasks are included in the role of a ScrumMaster. In this video, I illustrate the different functions which a ScrumMaster must fulfill. However, it is important that a ScrumMaster does not get sidetracked by his many tasks, but remains focused on his most important function. 
Do you want to find out more? Watch my video about the role of a ScrumMaster! 

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.

ScrumMaster in a nutshell

Wenn wir uns in unseren Trainings der Rolle des ScrumMasters widmen, taucht in den Gesichtern der Teilnehmer meistens ein Ausdruck auf, der so viel sagt wie: „Das ist ja ziemlich klar“ oder „Diese Rolle kenne ich doch am besten, ich bin ja selbst jeden Tag ScrumMaster“. Doch bei der Diskussion über die umfassenden Aufgaben des ScrumMasters fällt auf: Das tägliche Doing in Worte zu fassen, ist gar nicht so leicht. Ein wirklich tiefes Verständnis seitens unserer Trainingsteilnehmer oder Projektmitglieder zu schaffen, ist aber eine wichtige Aufgabe. Auch wir Berater schärfen die Rolle des ScrumMasters durch unser tägliches Handeln nach und erfahren dabei selbst immer wieder aufs Neue, welche Herausforderungen diese Rolle mit sich bringt.
Die oberflächlichen Begriffe zu nennen, ist simpel: Ein ScrumMaster ist Leader, Facilitator, er ist Team Coach, Change Agent und Trainer. Er ist für die Produktivität des Teams zuständig. Diese Aspekte gehen weit tiefer als die Begrifflichkeiten – das liegt auf der Hand. Aber was bedeutet das konkret für den Alltag? Was muss ein ScrumMaster können? Was steckt hinter den Rollen?

Leader

Eine Rolle, die der ScrumMaster einnimmt, ist die laterale Führung des Teams. Selbstorganisierte Teams brauchen Führung, ganz besonders zu Beginn der Arbeit mit agilen Management-Frameworks. Dabei geht es konkret um das Verständnis verschiedener Führungsansätze: Es wird zum Beispiel zwischen Leadership im Sinne von „das Team befähigen und inspirieren“ (transformationale Führung) und „Führen mit Anreizsystemen und klaren Ansagen an das Team“ (transaktionale Führung) unterschieden. Ein ScrumMaster muss diese Führungsansätze kennen, verstehen und in der jeweiligen Situation richtig anwenden können. Er muss auch wissen, dass Laissez-faire keine Art der Führung ist. Wichtig in diesem Zusammenhang ist, zu Beginn des Auftrags zu klären, unter welchen Bedingungen der ScrumMaster an das Team herantritt und mit ihm arbeitet. Dazu gehört eben auch, dem Team gewisse Dinge vorzugeben, in denen der ScrumMaster in diesem Fall der Experte ist.

Team Trainer

Als Trainer vermittelt der ScrumMaster seinem Team die theoretischen Grundlagen. Er muss aber nicht nur die Methode kennen, er versteht auch die Probleme seiner Kunden und deren Branche. Er besitzt das nötige Domänenwissen und kann mit seinem Know-how über die Branche neue Lösungswege aufzeigen. Das bedeutet auch, dass er dem Kunden mit seinem Wissen immer eine Nasenlänge voraus ist. Er muss nicht besser entwickeln können als ein Entwickler, aber er muss wissen, wie entwickelt wird und was die Herausforderungen dabei sind.

Team Coach

In der Rolle des Team Coaches bringt der ScrumMaster das Team durch geschickte Fragestellungen von A nach B. Als Team Coach liegt sein Hauptfokus darauf, die Gesamtleistung bzw. das Können des Teams zu verbessern. Er erkennt und fördert Potentiale des Teams. Dabei können sowohl Stärken als auch Schwächen und Defizite im Team aufgedeckt werden, an denen gearbeitet werden muss.

Facilitator

Als Facilitator begleitet er das Team durch den Prozess und bringt eine Vielfalt an Methoden mit, mit der er Veränderung initiiert, begleitet, unterstützt und fördert. Die Moderationsskills an sich sowie Facilitation-Methoden wie Open Space, Appreciative Inquiry, The Circle Way oder Dynamic Facilitation sind dem ScrumMaster ebenfalls bekannt. Darüber hinaus muss er einige Soft Skills besitzen, um in seiner Rolle wirksam zu werden. Die Haltung, andere Sichtweisen zu akzeptieren und hinzunehmen sowie Authentizität auszustrahlen und das Team begeisternd durch den Prozess zu führen, zählt ebenso dazu, wie die ständige eigene Weiterentwicklung.

Change Agent

Und schließlich ist der ScrumMaster ein Change Agent im Unternehmen. Er trägt den Change ins Unternehmen und sorgt für Verständnis auf Seiten der Organisation (z.B. auch beim Betriebsrat und HR). Die große Herausforderung, neben seinen bisher genannten Fähigkeiten, noch die Grundsätze und Modelle des Change-Management-Ansatzes zu verstehen und je nach Situation einordnen zu können, vollendet das Bild dieser komplexen und anspruchsvollen Rolle, die eine hohe Kompetenz und Flexibilität zur ständigen Weiterentwicklung abverlangt.
Auch wenn die Ansprüche an die Rolle des ScrumMasters in allen Facetten wohl unmöglich zu jedem Zeitpunkt ausgefüllt werden können, bringt dies zugleich die Herausforderung mit sich, ständig weiter an sich selbst zu arbeiten. Die unterschiedlichen Tools und Methoden sind ein Handwerk. Und ein Handwerk kann man bekanntlich lernen. Für mich heißt das ganz konkret, dass die Rolle des ScrumMasters nicht nur für die betreffende Person selbst, sondern für die Organisationen in ihrer Gesamtheit ein unglaubliches Entwicklungspotential bereithält.

Foto: CC0 Creative Commons – pixabay, ulleo

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: Die Rollen in Scrum

In den letzten Jahren sind mir in zahlreichen Gesprächen immer wieder die vielen Ideen dazu aufgefallen, welche Rollen es in Scrum gibt. Von einigen habe ich gehört, es gäbe den ScrumMaster, den Product Owner und das Team – möglicherweise noch ein paar Stakeholder.
In diesem Video erkläre ich euch meine Sichtweise auf das Thema Rollen. Aus meiner Sicht gibt es mindestens 6 Rollen und wenn man will, kann man die Rolle der Stakeholder als 7. Rolle einführen. Doch das nur am Rande – die Erklärung dazu wird es in einem anderem Video geben. Nur soviel: Wer verstehen will, wie man Scrum am besten skaliert, kommt um die Idee der Small World Networks nicht herum. Dazu braucht man wiederum ein klares Bild der Rollen in Scrum und davon, wie sie zusammenspielen. Dieses kurze Video soll uns dabei unterstützen, ein gleiches Bild der Rollen in Scrum zu entwickeln.
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.

Führung als Team: Frommer Wunsch oder realistische Perspektive?

Viele Unternehmen, gerade auch High Performance Unternehmen, sind heute vernetzt strukturiert. Sie  haben schlankere Hierarchien und arbeiten verstärkt mit unterschiedlichen Formen der Projekt- und Teamarbeit. Die Hierarchien gewinnen eine neue und andersartige, oft geringere Bedeutung. Die klassische Führung mit ihrer starken Betonung des heldenhaften Einzelkämpfers an der Spitze mit seiner  “Alle mir nach”-Attitüde hat sich abgenutzt und ist auch als Modell wenig sinnvoll für selbstorganisierte Teams. Oft wird dieser Widerspruch thematisiert im Sinne von “Wir da unten sollen als Team zusammenarbeiten, aber die da oben sind lauter Einzelkämpfer” (und oft in deutlich wahrnehmbarer Konkurrenz zu einander). Gerade für die Führung agiler Unternehmen (aber nicht nur für diese) ist die Installation von Führungsteams eine effektive Alternative. Führungsteams sind kollektive Steuerungs- und Entscheidungsfunktionen in Unternehmen. Sie verteilen Macht, Kompetenz und Verantwortung auf mehrere Schultern. Trotzdem wird dem Führungsteam im Management aus einer tradierten Vorstellung von Führung heraus immer noch mit einer gewissen Skepsis begegnet und/oder man belässt es bei schnell durchschaubaren Lippenbekenntnissen. Dabei bietet diese Führungskonstellation durchaus höchst überlegenswerte Möglichkeiten.
Führungsteams können

Führungsteams bewegen sich in der Regel weit mehr als Mitarbeiterteams in einem Spannungsfeld zwischen Individualität und Kooperation, zwischen persönlicher und geteilter Verantwortung. Daraus ergeben sich Problemfelder, die es zu beachten gilt:

Grundsätzlich gilt, dass Teams, welcher Art auch immer, nicht per se bessere Leistungen bringen als einzelne Spezialisten. Vielmehr braucht Teamarbeit spezifische Bedingungen, um den allseits gewünschten Synergieeffekt im Sinne von Effektivität und Effizienz leisten zu können:

Führungsteams sind zweifellos  eine wirkungsvolle, aktuelle Alternative zu klassischen Formen der Führung für Unternehmen. Aus meiner Erfahrung als Moderator und Entwickler diverser Führungsteams konnte ich erkennen, dass dort, wo Führungsteams optimal kooperieren und ihre Führungsaufgabe gemeinsam bewältigen, auch die gemeinsame Erfolgswahrnehmung hoch ist. Vor allem aber ist persönliche Zufriedenheit, Gelassenheit und Motivation bei den Führungskräften in der Regel ausgeprägter vorhanden und wahrnehmbar. Auch die Rückmeldungen von kollektiv geführten Mitarbeitern deuten auf eine verbesserte sachliche Arbeitssituation und ein angenehmeres Miteinander hin, diese positive Wirkung nach unten ist sehr hoch einzuschätzen.
In der Regel geht die Initiative zukünftig als Führungsteam zu agieren von der ranghöchsten Position im System aus. Hier kann man CEO, CTO, Bereichs- und Abteilungsleitern nur genug Mut wünschen, sich darauf einzulassen, ein Führungsteam zu kreieren. In einem gut gestalteten Teamentwicklungsprozess kann in den meisten Fällen dann auch die evtl. noch vorhandene Skepsis des einen oder anderen Führungsteammitgliedes gezielt bearbeitet und abgebaut werden.