Scrum vs. Wasserfall: Auch Agilität braucht Planung

Nach wie vor passiert es, dass wir im Projektalltag den Unterschied zwischen Wasserfall und Agilität erklären müssen. Viele Mythen ranken sich vor allem um die Frage: „Wird denn in Scrum überhaupt geplant, und wenn ja, für welchen Zeitraum?“ Bei den Erklärungsversuchen wird schnell klar: Die Unterschiede zum agilen Projektmanagement werden viel einfacher ersichtlich, wenn es ein Verständnis für das gibt, was Scrum nicht ist. Machen wir also einen kleinen Exkurs in die Welt des klassischen Projektmanagements, um diesem Unterschied auf den Grund zu gehen.

Wasserfall: Genaue Spezifikation vorab

Das Wasserfallmodell gilt als charakteristisch für das klassische Projektmanagement der vergangenen Jahre. Dabei werden sequentielle Projektphasen gebildet, die in einer klar definierten Reihenfolge verlaufen. Umgangssprachlich wird das Wasserfallmodell auch “Over-The-Wall-Ansatz” genannt: Es werden aufeinander aufbauende Teilergebnisse geliefert, die auf ein vorab vollständig spezifiziertes Projektziel einzahlen. Diese Teilergebnisse sind klar voneinander abgegrenzt und werden meist wie über eine Mauer in den nächsten Bearbeitungsschritt „geworfen“. Die Mitarbeiter sind bei dieser Vorgehensweise ausschließlich für einen kleinen Bereich des Gesamtprodukts verantwortlich – den Gesamtzusammenhang müssen sie nicht zwingend verstehen.

Scrum: Mit kontinuierlichem Feedback zum passgenauen Ergebnis

Agile Vorgehensweisen basieren auf einem iterativen und inkrementellen Ansatz, es wird mit Feedbackschleifen und Teilprodukten als Lieferungen gearbeitet. Schnelles Kunden- und Nutzerfeedback, kontinuierliche Verbesserung und das Liefern vollständig abgeschlossener Produktfunktionalitäten stehen dabei im Fokus der Entwicklung. Im Gegensatz zum Wasserfallmodell ist es eine Aneinanderreihung vieler PDCA-Zyklen, es gibt also ein kontinuierliches „Plan – Do – Check – Act“ entlang der gestellten Anforderungen. Das ständige Abgleichen des erreichten Status Quo spitzt das Ergebnis besser auf das zu, wofür der Kunde letztendlich wirklich bezahlen möchte. Somit kann es nicht vorkommen, dass lange Zeit in eine falsche Richtung gearbeitet wird, denn Änderungen in den Anforderungen und in der strategischen Stoßrichtung können kurzfristig berücksichtigt und umgesetzt werden. Sinnvoll wird diese Vorgehensweise gerade dann, wenn man sich in einem sehr dynamischen Umfeld befindet, in dem Anforderungen und Technologie noch unbekannt sind oder sich häufig ändern.

Wie plant man eigentlich agil?

Wenn wir nun also die Kollegen fragen, was sie am Wasserfall so sehr schätzen, berufen sich viele auf die Möglichkeit der langfristigen Planung. Das sei mit Scrum schließlich nicht möglich, dort würde nur in Sprints mit einem Horizont von zwei Wochen gedacht. Weit gefehlt. Natürlich wird auch in Scrum in Form eines Releaseplans ein Planungsausblick über eine längere zeitliche Einheit hinweg gewährleistet. Trotzdem wird in Sprints gedacht und der Releaseplan ist in Zwei-Wochen-Abschnitten getaktet. Ein massiver Unterschied zur Wasserfallplanung ist aber die Tatsache, dass es sich stets um eine lebendige Planung handelt und diese, je nach Umständen und Rahmenbedingungen, zu gegebener Zeit angepasst werden sollte. Gerade in dynamisch hochkomplexen Märkten können sich die Anforderungen innerhalb kurzer Zeit ändern, sodass eine agile Anpassung der Planung überlebenswichtig wird.
Denn im Vordergrund steht das Produkt, mit dem man einen möglichst hohen Geschäftswert erzeugen möchte. Die Frage lautet also: Welche Funktionalitäten müssen wir in den nächsten Sprints in jedem Fall entwickeln, sodass wir die richtigen Funktionalitäten und damit den maximalen Mehrwert bieten, mit dem wir Käufer gewinnen können?
Viel Erfolg in euren Projekten wünschen euch Jessica und Marcel!

Foto: CC0 Creative Commons – Pixabay, Pexels

Scrum for dating – one step at a time

Dating apps like Parship, Elite Partner, Lovoo, Badoo,Tinder (you name them) and some pseudo dating apps like Bumble and the inner circle are on the rise in Germany and internationally.
But what does the increase in those apps and platforms tell us? Are we more prone to fall at the mercy of algorithms and spreadsheets to e-meet people of the opposite or same sex? Or has dating actually become complex / difficult because we can’t estimate the outcome and might potentially make a trade-off?
No brainer, but individuals in the Northern hemisphere are increasingly becoming individualistic and self-centered. Keeping ourselves happy, creating memories, pursuing a healthy lifestyle is pretty far up on our priorities. Hence, why should one forgo these aspirations and deal with a complete stranger, where getting to know him or her means doing less of what we love to do. Getting to know someone takes TIME! Yap, the time we invest to get to know another self-loving, neo-liberal, weird, sometimes depressive yet longing for love and attention seeking person is scary but worth a contemplation.
How do we deal with this intricate situation? I believe that the Scrum methodology can unfold its power in any sort of complex situation.
The Stacey Matrix is a good tool to evaluate whether it is feasible to use an agile method like Scrum or not. Imagine being in a prospective and sustainable relationship is our vision, starting a relationship with a suitable and complementing partner is our end product. Deploying this to the Stacey Matrix, working on a prospective and sustainable relationship is WHAT we produce incrementally (product) and opening up and spending time are examples of how we want to reach the goal (functionalities).

Stacey Matrix

The Stacey Matrix for dating

In Scrum, a potentially shippable product (sub product) is incrementally produced in a timeboxed period and is called a “Sprint”. In each sprint we decide how many functionalities we want to implement in order to develop a potentially shippable product increment. Let’s go through a possible “Scrum Flow of Dating”.
Scrum Flow
Product Idea: I don’t want to be alone anymore
Product Vision: Being in a prospective and sustainable relationship OR I want to get married
The team: The Dating-Scrum team consists of the persons pursuing a relationship. In a heterosexual endeavor, the woman might collaborate with her female squad to solve occurring impediments ☺
Prioritized Product Backlog: All items (functionalities / requirements) written in the form of user stories necessary to reach the end goal. The items are prioritized according to the return of invest:

*Example User Story: We want to make ourselves available so that we can spend maximum time getting to know one another.
Release Plan: Wow, we could actually estimate what date the annual celebration will be. The day we will finally start officially dating as an approved couple.
Sprint Planning 1: We decide WHAT we want to do. Along our prioritized product backlog, we now choose the user stories we want to implement in our first sprint. These should be the user stories, which have the highest value for our endeavor – the “business value”. Hence, which functionalities will most likely deliver a high return of investment? For example, if we go on a short trip we might quickly find out the “highs” and the “lows” of the person in investigation. We have invested a concentrated piece of time and have a high outcome. Anyways, this could also go wrong. So, think of what functionalities you are best taking up in your first sprint. The selected items cumulate in the so-called “Sprint Backlog”.
Sprint Planning 2: We decide HOW we want to do it. Here, we take up each user story from the “Sprint Backlog” and deduce tasks as to how to implement the selected user stories. This is a technical meeting where we talk about how to do what. So, if we took the travelling user story again, we will write tasks such as: book flight, book hotel, decide on day and nighttime activities, plan budget, mobility, choose restaurants etc.
Sprint: We set a timebox in which we want to have implemented the selected user stories and hence have produced our first increment. A sprint should not be any longer than 1 month in order to ensure quick feedback cycles.
Daily: TALK DAILY. Communication is key!
Sprint Review: The Sprint Review is where we present what we have achieved in the Sprint. It’s the success meeting (hopefully) where we showcase our first potentially shippable product. Here, the team could showcase to each other, what they have learnt about each other during the holidays and how they feel more comfortable with each other. The new level of familiarization should be the product increment here.
Sprint Retrospective: The meeting which scrutinizes how the team worked together. This meeting does not focus on the product but solely on the working relationship. Hence, did the team like their communication while planning the vacation, what went well and what can be improved during the Sprint? What should we change or adapt? Or are we on the right lane in the way we work together reaching the common goal?
The Retrospective meeting closes a sprint and is also the prelude to the next sprint. We choose new product backlog items, write tasks, start the sprint, showcase the outcome and discuss our working relationship.
This mirrors the plan, do, check and act cycle.

Why is it beneficial to date agile?

In our fast-paced world, where time always comes at the expenses of other things that could have been done, I think that dating iteratively can be a promising model to pursue a sustainable relationship while managing our so important duty-stuffed life’s. It allows for adaption while pursuing a loving relationship. Key elements are the stipulation and constant reiteration of the common goal and the constant communication among the committed team. No concession should be made around these elements.
Foto: CC0 Creative Commons – pixabay, StockSnap

The Product Backlog – where does it come from?

The Product Owner has often been considered a bottleneck when creating a Product Backlog, as he was deciding which items would be included. Nowadays, new practices have been introduced to ensure that the Product Backlog is defined more efficiently.
Curious to find out how it’s done? Join me in my how-to video!

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.

Scrum 3.0 – A new picture

In its original version, Scrum has always been customer centric. However, the framework has evolved considerably over the last few years. In my next video, I explain how in “Scrum 3.0” the process is now driven reversely – not by the end user, but by the development team. 
Join me to find out more!

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

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! 

Scrum Meetings – Daily (Scrum)

A very important meeting is the Daily, where teams come together for 15 minutes every day, to discuss next steps on how to reach their sprint goal. It is no longer just about what have I done yesterday, what will I do today and what impediments are in my way…  
Find out how this meeting has evolved from its origins to a new agile version in my how-to video.