Commitment

Join me for my how-to video, in which I explain the basics of commitment. Why is it essential to define a goal, which we want to achieve as a team? And how will a voluntary mutual agreement affect the team dynamic? 
Find out by watching my video! 

Scrum Meetings – Sprint Planning #1

In this video I talk about the Sprint Planning #1 meeting, which is used to create a common understanding and a mutual agreement on what the team will accomplish. Further I explain why it is essential to decompose all user stories based on five critical aspects. 
Curious? Then come and join me in my agile how-to video! 

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 and multi-disciplinary teams

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

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

What is Scrum?

In this episode of “The Agile How-To”, we explore the basics of Scrum and where it originated around 20 years ago. To the contrary of what most people believe, Scrum is not a project management methodology! Scrum is more like a mindset. It is a framework which embraces the ideas behind being agile –to deliver fast results that meet the user’s needs.   
 Join me in my video journey, where I explain the basics of Scrum.

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.

Never give up your own claim!

Viele ScrumMaster sind satt. Sie bauen die schönsten Taskboards und halten die tollsten Meetings. Sie zeichnen die schönsten Definitions of Done und Happiness-Metriken. Sie bringen Kekse zum Meeting mit.
Aber ihre Teams liefern nicht.
Genau das ist das Problem: Wir halten uns ewig mit den richtigen Methoden auf. Wir quetschen alle Retromaten der Welt aus, um unseren Teams Scrum als Leckerli mit Zuckerguss präsentieren zu können. Vielleicht, um uns auch ein bisschen selbst zu verwirklichen. Doch wenn Teams nicht den Spirit leben, wenn Artefakte und „Make things visible“ nur zu Deko werden, wird der agile Grundgedanke verfehlt.
In Scrum geht es am Ende immer ums Liefern, nicht zwangsweise darum, dabei schön auszusehen.
Was bringt Ihrem Unternehmen auf lange Sicht mehr: Ein schöner Teamraum, wo alles ordentlich ist, oder ein ScrumMaster, der mutig und schonungslos alles transparent macht, was sein Team behindert? Nach einem anfänglichen Tal der Tränen sind viele ScrumMaster satt. Sie werden ruhiger und kämpfen nicht mehr für ihr Team. Das Impediment kann auch noch morgen gelöst werden. Den Workshop kann ich auch noch nächste Woche halten. Nein! Es geht darum, alles für sein Team zu geben.
Teams müssen liefern.
Das, und nur das ist die Aufgabe des ScrumMasters. Es ist eine verdammt schwere und unangenehme. Ein ScrumMaster ist dabei so etwas wie der beste Freund. Er hört zu, er lacht mit, er leitet dich in schwierigen Situationen, aber haut auch auf den Tisch und scheut nicht vor klarem Feedback zurück. Dafür gibt es vor allem die Retro oder das Review, aber auch One-on-One-Gespräche. Er kümmert sich um seine Mannschaft. Er kümmert sich um das agile Management.
Als ScrumMaster sollte man immer wieder überprüfen, wie man sich weiterentwickeln kann. Das ist eine Auswahl an Fragen, die mir geholfen haben, mich als ScrumMaster weiterzuentwickeln:

Vielleicht helfen diese Fragen dabei, den Spirit (wieder) zu finden, den die Arbeit als „Schäferhund“ ausmacht. Er ist bissiger und fürsorglicher zugleich.

Video: Schätzmethoden – Was ist Magic Estimation?

 
User Stories sind klein. Doch wie finde ich heraus, ob eine User Story klein ist?
In diesem kleinen Vortrag über Magic Estimation zeige ich euch, wie einfach es ist, User Stories der Größe nach zu schätzen. Dabei will man nicht absolut wissen, wie groß eine User Story ist, sondern man will sie relativ zu den anderen User Stories eingruppieren. Ich erkläre auch, was passiert, nachdem die Eingruppierung stattgefunden hat und nach welcher Vorschrift die User Stories zum nächsten Sprint zugelassen werden.
Dank “Magic Estimation” lassen sich übrigens sehr viele User Stories in nur wenigen Minuten schätzen.
 
Viel Spaß beim Anschauen — Boris
 

 

Video: Was ist eine User Story?

 
Mit den nächsten drei Videos bespreche ich einige Themen rund um das Schätzen von User Stories. Den Anfang mache ich gleich mit den User Stories selbst.
User Stories sind eigentlich recht einfach zu verstehen, wenn man sich darauf beschränkt, bei dem zu bleiben, was eine User Story ist: ein Versprechen auf eine nachfolgende Konversation. User Stories beantworten drei Fragen: WER braucht WAS WOZU? Es ist völlig unnötig, User Stories noch viel besser aufschreiben zu wollen oder sie vielleicht sogar so formulieren zu wollen, dass sie von jedem in jeder Situation verstanden werden.
Bis jetzt bin ich mit meiner Auffassung von User Stories in allen Projekten immer gut gefahren.
 
Viel Spaß beim Anschauen — Boris