Involving users and customers in product development is a central pillar of the agile movement. Two of the 4 agile values are "people and interactions before processes and tools" and "customer collaboration before contract negotiation". In Scrum, one of the most popular agile frameworks for product development, the Sprint Review is the only "official" event where developers and users/customers interact and collaborate. This article provides an overview of the purpose of the Sprint Review in Scrum and describes a practical example of designing a modified Sprint Review in Large-Scale Scrum (LeSS) with multiple teams working remotely.
At the heart of Scrum is empirical process control, which distinguishes it from other agile frameworks. Instead of having a detailed defined process, Scrum uses short cycles for creating small shippable product slices, and after each cycle, it allows to inspect the product as well as the process and adapt both as necessary. The Sprint Review allows for the continuous inspection and adaptation of the product while the Sprint Retrospective does that for the process.
In the Sprint Review, the users/customers and other stakeholders inspect with the Product Owner and Team(s) the Product Increment, and the Product Backlog is adapted as necessary. This is done by allowing everyone to hands-on explore new items and discuss what’s going on in the market and with users. It is also the best moment to create or reaffirm the shared understanding of the participants whether the Product Backlog still reflects the needs of the users/customers and the market and to make changes to the Product Backlog in order to maximize the value delivered. Transparency, next to inspection and adaptation, is key for empirical process control, and therefore calling the event “Sprint Demo” and focusing just on a one-sided presentation without hands-on use of the product misses the point of the Sprint Review in Scrum or LeSS.
The 2017 Scrum Guide is quite explicit on the contents of the Sprint Review. It includes the following elements (quote):
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
The 2020 version of the Scrum Guide is much shorter on the Sprint Review, as in general, it is shorter and less prescriptive. The new Scrum Guide says:
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
LeSS (like Scrum) is a “barely sufficient” framework for high-impact agility. It addresses the question of how to apply Scrum with many teams working together on one product. For more on the LeSS framework please visit https://less.works.
In LeSS there is one rule regarding the Sprint Review (quote):
In addition, there are two guides and a couple of experiments related to the Sprint Review:
This guide suggests keeping the cycles for creating new product slices as short as possible (and reasonable), sharing as much information about the customer market as possible, and discussing together what to do next, in order to maximize learning.
This guide suggests performing the first part of Sprint Review like a science fair: A large room with multiple areas, each staffed by team representatives, where the items developed are explored and discussed together with users, teams, etc. Beware: The Review Bazaar is not the full Sprint Review but only the first part! The second part of the Sprint Review consists of the critical discussions needed to reflect and decide on what to do next.
The guide provides some clear tips on how to organize the bazaar in a series of steps (quote):
After the bazaar, the most important steps of the overall meeting follow:
The second LeSS book provides some experiments related to the Sprint Review, like using video sessions, including diverge-converge cycles in large video meetings or experimenting with multisite Scrum meeting formats and technologies. In this article I put my focus on a detailed example of the experiment “Remote Sprint Review” and als combine many ideas from other experiments.
A LeSS rule related to the LeSS structure states that “Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived”.
In current times, almost no team can work co-located, as every member is forced to work (most of the time) from home. So many teams are experimenting with different ways on how to do LeSS events remotely. Here is an approach of a Review Bazaar that we have done at one of my clients, Yello Strom AG. In the following description, I will share the steps that we used, and afterward, I will share what I still believe can be improved.
I would like to start with an important remark regarding the organizational setup: We did not use LeSS at this client, as the goal of the area I worked with was a bit different than the system optimising goal in LeSS. Nevertheless, our Sprint Review with multiple teams was very similar to how I would run a Sprint Review in LeSS.
In order to be very specific in the way we have performed the Sprint Review, I will give a brief introduction to the organizational setup, which is different from LeSS, but beware that I would not recommend this setup if you are working with multiple teams on one product. At the end of the article, I will describe the differences in the way I would perform the Sprint Review in LeSS.
The client, Yello Strom AG, is a German electricity and gas provider, a subsidiary of EnBW. The area that I worked with at Yello Strom AG was responsible for innovation and discovering new business models. It consisted of 4 teams, each focusing on a different product.
There was one team that was creating a revolutionary app that allows people to understand the difference between driving an internal combustion engine car and an electric car. This app was designed to be able to recommend an electric car that fits your personal needs, taking into consideration how often you are driving each week, what kind of trips you are regularly doing, if you have a charging possibility at home, and many other things.
Another team was working on a user-generated platform that should allow people to share personal reviews of electronic products that they are using. A third team was setting up a new electricity pricing model for people with electric cars. And the fourth team was writing and creating content for different (media) channels, like blogs, YouTube videos, Instagram, or Twitter posts.
Each team had a Product Owner and the department had a so-called Business Owner. Each team had its own Product Backlog, some run 2-weeks Sprints, other 1-week Design Sprints, but every 2-weeks we performed this shared Sprint Review.
The tool that we used as a group to communicate was Microsoft Teams, which unfortunately at that time didn’t support break out rooms, so we had to make some workarounds in this regard.
As most interaction between the participants should happen visibly, we were using Miro as an “endless” whiteboard. Here is where the agenda of the event was shared, where teams were preparing screenshots of the product parts they wanted to discuss in order to allow the participants to add comments and feedback, and also where other participant interaction happened.
One of the most essential parts of a remote Sprint Review is the preparation. Team members should always prepare the Sprint Review well, in order to get the most out of this inspect-and-adapt event. But, as we will see, for a remote event there is not only the product (increment) that needs to be prepared but also ways to allow participants to share feedback effectively. Our teams had to plan on average about an hour each sprint to prepare the Miro board for the Sprint Review to make this meeting effective. In addition, also the PO usually prepared relevant information to share with the teams and the other participants.
Here is how the overall board looked like for one of our Sprint Reviews:
The next screenshot shows a typical Sprint Review agenda.
We had a time limit of no more than 2 hours, which worked for the most part, although sometimes I wish we had had a little more time.
Our agenda consisted of 8 blocks:
We usually started our event by mentioning separately the steps that were done during the sprint review and introducing changes to the process if they were decided in the previous event or Sprint Retrospective. We found that participants who attended this event for the first time benefited from an individual introduction to the process beforehand. This allowed us to keep the first item on the agenda short. This is also a good time to do a quick check-in, with participants typing a word into the chat box, posting a Giphy or perhaps a picture in an area of the whiteboard, for example.
This was followed by a few words from the business owner, where he could announce important company and department updates or introduce new hires.
The third item on our agenda was a short status overview reflecting where the teams were on their respective journeys. As mentioned earlier, we had 4 teams working on 4 different products and this was the opportunity for each team to verbally and visually share what was happening: updates on usage figures, market updates, impediments and the road ahead. Mostly this was done by the team POs and took no longer than 5 minutes per team.
As you can see in the screenshot below, we created a table on the board for this with 4 columns (Obstacles & Help Requests, Successes, Thanks, Next Steps).
After that (or sometimes during the updates) each team gave a short introduction to the product increments that had been prepared to be explored in the Review Bazaar.
Each team that had something new to share prepared one or more sections on the board with instructions on where to find the product increments and how to review them. Sometimes the instructions were supplemented with key questions for feedback. Most of the time the teams added screenshots of the new or updated parts of the product (website or app). This made it very easy for participants to link the feedback to a specific area of the product. For general remarks and feedback each team also created a section with 4 quadrants (What worked? / What made me confused? / What didn’t work? / Any new ideas?).
After about 45 minutes, the most exciting part of the review began. Participants started to move around the Miro board and explored the offerings. As mentioned earlier, the offerings were very diverse and the review was designed so that participants could choose which parts were most interesting to them and where they could contribute the most by rating what they saw and giving feedback.
The Content Team usually shared articles or YouTube videos that had been created and published in the Sprint. Next to the link to the actual article, the team added a screenshot and a feedback quadrant (see screenshot below).
In other cases, teams added a link to a new functionality on a web page or a whole new landing page. This could either be a link to the live system or to another (staging) environment, and general instructions for access were added.
As mentioned earlier, the feedback team usually prepared a section with screenshots of the new functionality or a web page and participants added post-it notes with comments right next to the sections. In addition to this, each board had a feedback quadrant for general feedback.
In some cases, it was a new functionality in a mobile app that was available for review. Here, teams usually prepared a more detailed description of how to install the app from a test server, sometimes by posting a link to a screen shot that included step-by-step instructions on how to install it. There was also a link to an MS Teams channel or a team member in Slack who could support participants if they had problems installing the app. Again, the team provided relevant screenshots from the app on a frame in Miro so that participants could write post-its directly to the areas they had feedback on. There was also a feedback quadrant for more general feedback.
In other cases, there were just mockups, wireframes, scribbles or even data sheets that the team had been working on in the previous Sprint. Also here they gave clear instructions on what type of feedback they needed.
In some cases, teams even prepared customer interviews for the Sprint Review. They asked participants to write their name in a timebox slot, and a team member who was skilled at conducting customer interviews had one or more participants experience the new functionality and answer questions.
The next step was to review and discuss the participant feedback. To do this, each team sat down with their product owner in their MS Teams channel and reviewed the post-its and discussed the written feedback as well as what they had observed during the interviews. This usually resulted in new PBIs being created and discussed in the next Product Backlog Refinement, as well as PBIs being updated or reordered in the Product Backlog.
The last step of our Sprint Review was a short time slot to retrospect the Sprint Review. The participants had the opportunity to leave feedback and ideas on how to improve the Sprint Review. In order to enable this, we used another area of the board, and the familiar four quadrants.
As mentioned already, this is not a typical LeSS Sprint Review, though the flow used might be very similar to the one in a LeSS Sprint Review. I will start by describing first the differences to LeSS.
Large-Scale Scrum (LeSS) offers, through its rules and principles, an organisational design that is optimised for adaptability at minimum cost and customer value. In LeSS, there are no “Team Product Owners” and no “Team Product Backlogs”. To avoid local optimisation by increasing efficiency at team level, there is a common product backlog. This ensures that optimisation takes place at system level. Usually this makes most sense when multiple teams are working on a product, creating a clear need for all teams to work together to support the development of the area of the product that is most critical for the best possible customer impact. And even in a situation where multiple teams are working on multiple products in parallel, LeSS prefers to work with a product backlog (and with a single product owner maintaining that product backlog) and broader product definitions because they
So, as long as there is a shared (overall product) vision that encompasses multiple products, the same customers or the same markets, and the same domain knowledge is relevant, there is a strong case for extending the product definition to multiple smaller products.
In our case, the department was exploring multiple innovative products with multiple teams, so working with a single product backlog would have made a lot of sense, especially because the exploration and delivery of the products would have been extremely fast and adaptable. It would have allowed the organisation to increase investment in the more successful product on the fly, rather than working with a defined group of people for a defined period of time on multiple products, only to discard some products at a certain point and train team members to develop the more successful product.
In the concrete example, the products were very different in terms of the technology used and most of the team members were contractors, so working with several product backlogs and several product owners (i.e. without LeSS) also worked well. The interaction between the teams was very good, the efficiency at team level was high and the most promising product could be identified.
In a real LeSS setup, you might want to run a few things differently. After check-in and before teams pitch their sessions, you could have just one block where the product owner communicates relevant changes in usage numbers, specific customer feedback and updates from the market.
You could include an area on the board where important numbers and other success stories (e.g. go-live of a functionality) are shared, but I would remove both the “impediments” and the “next steps”, or at least I wouldn’t discuss them at the beginning of the sprint review. The best time to discuss impediments would be during an overall retrospective (with all teams) and I prefer to discuss next steps at the end of the Sprint Review and incorporating all the feedback from it, not at the beginning.
After the Remote Review Bazaar, the teams sort and group the input they received and summarise it. The product owner familiarises himself with this summary by moving back and forth between the areas on the Miro board or between the teams’ breakout rooms. Then all teams discuss with the product owner what feedback should be incorporated in the upcoming sprints and how this can be done. Often this leads to the creation of new items that will be defined in the next Backlog Refinement, the change of priorities of existing items or even the removal of items. This step in the Sprint Review is very important because it sets the direction for the development. It is advisable to plan enough time for this in Sprint Planning.
In my experience, the Retrospective of the Sprint Review can be shortened by only providing a section for feedback on the board, or even omitting this section completely, and discussing the feedback in an overall Retrospective if needed.
Here you can see what an agenda might look like:
I hope this article gives you an idea how to facilitate a Remote Sprint Review with multiple teams. I’d love to hear your feedback and/or questions.
Notes:
Robert Briese regularly takes participants of his pCLP (Provisional Certified LeSS Practitioner) courses to such a Sprint Review, so if you are interested in experiencing this event live you can join one of his courses or feel free to write him.
Die Einbindung von Nutzern und Kunden in die Produktentwicklung ist ein zentraler Pfeiler der agilen Bewegung. Zwei der vier agilen Werte sind: "Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge" und "Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen." In Scrum, einem der beliebtesten agilen Frameworks für die Produktentwicklung, ist der Sprint Review das einzige "offizielle" Ereignis, bei dem Entwickler und Benutzer/Kunden interagieren und zusammenarbeiten. Dieser Artikel gibt einen Überblick über den Zweck des Sprint Review in Scrum und beschreibt ein praktisches Beispiel für die Gestaltung eines modifizierten Sprint Review in Large-Scale Scrum (LeSS) mit mehreren verteilten Teams.
Das Herzstück von Scrum ist die empirische Prozesskontrolle. Durch sie unterscheidet sich Scrum von anderen agilen Frameworks. Anstelle eines detailliert definierten Prozesses verwendet Scrum kurze Zyklen zur Erstellung kleiner auslieferbarer Produktteile und erlaubt darüber hinaus, sowohl das Produkt als auch den Prozess nach jedem Zyklus zu inspizieren und beides bei Bedarf anzupassen. Während das Sprint Review die kontinuierliche Überprüfung und Anpassung des Produkts ermöglicht, tut die Sprint Retrospektive dies für den Prozess.
Im Sprint Review inspizieren die Benutzer/Kunden und andere Stakeholder gemeinsam mit dem Product Owner und dem/den Team(s) das Product Increment und passen bei Bedarf das Product Backlog an. Dies geschieht, indem jeder die Möglichkeit hat, neue Elemente praktisch zu erforschen, und darüber zu diskutieren, was auf dem Markt und bei den Benutzern vor sich geht.
Das Sprint Review ist der ideale Zeitpunkt, um ein gemeinsames Verständnis der Teilnehmer zu schaffen. Es gilt zu bekräftigen, ob das Product Backlog weiterhin die Bedürfnisse der Benutzer/Kunden und des Marktes widerspiegelt oder Änderungen zur Wertmaximierung vorzunehmen sind.
Transparenz ist neben der Überprüfung und Anpassung der Schlüssel für die empirische Prozesssteuerung, und daher verfehlt auch die Bezeichnung „Sprint Demo“ mit einer Fokussierung auf eine einseitige Präsentation ohne praktische Anwendung des Produkts den Sinn des Sprint Reviews in Scrum oder LeSS.
In Bezug auf den Inhalt des Sprint Reviews war der Scrum Guide 2017 ziemlich explizit. Er enthielt folgende Ausführungen:
Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog, das die wahrscheinlichen Product Backlog Items für den nächsten Sprint definiert. Das Product Backlog kann auch insgesamt angepasst werden, um neuen Möglichkeiten gerecht zu werden.
Der Scrum Guide 2020 ist im Allgemeinen und auch im Speziellen deutlich kürzer und weniger präskriptiv. In Bezug auf das Sprint Review heißt es:
Während des Events überprüfen das Scrum Team und die Stakeholder, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Basierend auf diesen Informationen erarbeiten die Teilnehmer gemeinsam, was als nächstes zu tun ist. Das Product Backlog kann auch angepasst werden, um neuen Möglichkeiten gerecht zu werden. Das Sprint Review ist eine Arbeitssitzung und das Scrum Team sollte es vermeiden, es auf eine Präsentation zu beschränken.
LeSS ist (wie Scrum) ein „gerade noch hinreichendes“ Framework für hochwirksame Agilität. Es befasst sich mit der Frage, wie sich Scrum mit vielen Teams, die gemeinsam an einem Produkt arbeiten, anwenden lässt. Mehr über das LeSS-Framework finden Sie unter https://less.works.
In LeSS gibt es eine Regel bezüglich des Sprint Reviews:
Darüber hinaus gibt es zwei Guides und einige Experimente, die sich auf das Sprint Review beziehen:
Dieser Ratgeber schlägt vor, die Zyklen für die Erstellung neuer Product Slices so kurz wie möglich (und sinnvoll) zu halten, möglichst viele Informationen über den Kundenmarkt auszutauschen und gemeinsam zu besprechen, was als nächstes zu tun ist, um das Lernen zu maximieren.
Dieser Leitfaden schlägt vor, den ersten Teil des Sprint Reviews wie eine Wissenschaftsmesse durchzuführen: Ein großer Raum mit mehreren Bereichen, die jeweils mit Teamvertretern besetzt sind, in denen die entwickelten Elemente gemeinsam mit Benutzern, Teams usw. erkundet und diskutiert werden. Aber Vorsicht! Der Review Bazaar ist nur der erste Teil des Sprint Reviews. Der zweite Teil besteht aus kritischen Diskussionen, die für die Reflexion und die Entscheidung über die nächsten Schritte notwendig sind.
Der Guide gibt einige klare Tipps, wie Sie den Review Bazaar in einer Reihe von Schritten organisieren können:
Nach dem Review Bazaar folgen die wichtigsten Schritte des Meetings:
Das zweite LeSS-Buch bietet einige Experimente in Bezug auf das Sprint Review, wie z.B. die Verwendung von Videositzungen, einschließlich Diverge-Converge-Zyklen in großen Videomeetings, oder das Experimentieren mit Multisite-Scrum-Meeting-Formaten und -Technologien. In diesem Artikel lege ich den Fokus auf ein ausführliches Beispiel des Experiments „Remote Sprint Review“ und kombiniere es mit vielen Ideen aus anderen Experimenten.
Eine LeSS-Regel, die sich auf die LeSS-Struktur bezieht, besagt, dass „jedes Team (1) selbstverwaltend, (2) funktionsübergreifend, (3) co-located und (4) langlebig ist“.
In der heutigen Zeit kann fast kein Team co-located arbeiten, da jedes Mitglied gezwungen ist, (die meiste Zeit) von zu Hause aus zu arbeiten. Daher experimentieren viele Teams mit verschiedenen Möglichkeiten, wie man LeSS-Veranstaltungen aus der Ferne durchführen kann. Hier ist ein Ansatz für einen Review Bazaar, den wir bei einem meiner Kunden, der Yello Strom AG, durchgeführt haben. In der folgenden Beschreibung werde ich die Schritte, die wir verwendet haben, mit Ihnen teilen, und im Anschluss daran erläutern, was meiner Meinung nach noch verbessert werden könnte.
Ich möchte mit einer wichtigen Bemerkung zum organisatorischen Aufbau beginnen: Wir haben bei diesem Kunden nicht mit LeSS gearbeitet, da sich Ziel des Bereichs vom Systemoptimierungsziel in LeSS unterschied. Trotzdem war unser Sprint Review mit mehreren Teams sehr ähnlich zu dem, wie ich ein Sprint Review in LeSS durchführen würde.
Um die Art und Weise des Sprint Reviews genau zu beschreiben, möchte ich Ihnen eine kurze Einführung in den organisatorischen Aufbau geben. Bedenken Sie bitte, dass ich diesen Aufbau für die Entwicklung eines Produkts mit mehreren Teams nicht empfehlen würde. Am Ende des Artikels beschreibe ich, wie Sie ein Sprint Review in LeSS durchführen könnten.
Der Kunde, die Yello Strom AG, ist ein deutscher Strom- und Gasversorger, ein Tochterunternehmen der EnBW. Der Bereich, mit dem ich bei der Yello Strom AG gearbeitet habe, war für Innovation und die Entdeckung neuer Geschäftsmodelle zuständig. Er bestand aus 4 Teams, die sich jeweils auf ein konkretes Produkt konzentrierten.
Es gab ein Team, das eine revolutionäre App entwickelte, die es den Menschen ermöglicht, den Unterschied zwischen dem Fahren eines Autos mit Verbrennungsmotor und einem Elektroauto zu verstehen. Diese App sollte in der Lage sein, ein Elektroauto zu empfehlen, das u.a. zu den persönlichen Bedürfnissen passt, die Anzahl und Art der Fahrten pro Woche und die Lademöglichkeiten zuhause berücksichtigt.
Ein anderes Team arbeitete an einer nutzergenerierten Plattform, die es Menschen ermöglichen sollte, persönliche Bewertungen zu elektronischen Produkten zu teilen. Ein drittes Team erstellte ein neues Strompreismodell für Menschen mit Elektroautos. Und das vierte Team schrieb und erstellte Inhalte für verschiedene (Medien-)Kanäle, wie Blogs, YouTube-Videos, Instagram oder Twitter-Posts.
Jedes Team hatte einen Product Owner und die Abteilung hatte einen sogenannten Business Owner. Jedes Team hatte sein eigenes Product Backlog, einige nutzen 2-Wochen-Sprints, andere 1-Wochen-Design-Sprints. Alle 2 Wochen führten wir dieses gemeinsame Sprint Review durch.
Das Tool, das wir als Gruppe zur Kommunikation nutzten, war Microsoft Teams, das zu diesem Zeitpunkt leider noch keine Breakout-Räume unterstützte, so dass wir in dieser Hinsicht einige Workarounds schaffen mussten.
Da die meiste Interaktion zwischen den Teilnehmern sichtbar stattfinden sollte, nutzten wir Miro als „endloses“ Whiteboard. Hier wurde die Agenda der Veranstaltung geteilt, hier bereiteten die Teams Screenshots der Produktteile vor, die sie besprechen wollten, um den Teilnehmern die Möglichkeit zu geben, Kommentare und Feedback hinzuzufügen, und hier fand auch die sonstige Interaktion zwischen den Teilnehmern statt.
Einer der wichtigsten Teile eines Remote Sprint Reviews ist die Vorbereitung. Die Teammitglieder sollten das Sprint Review immer gut vorbereiten, um das Beste aus diesem Inspektions- und Anpassungs-Event herauszuholen. Aber, wie wir sehen werden, muss für ein Remote-Event nicht nur das Produkt (Inkrement) vorbereitet werden, sondern auch Möglichkeiten, wie die Teilnehmer effektiv Feedback austauschen können. Unsere Teams mussten im Durchschnitt etwa eine Stunde pro Sprint einplanen, um das Miro Board für das Sprint Review vorzubereiten, damit diese Besprechung effektiv ablaufen konnte. Darüber hinaus bereitete auch der PO in der Regel relevante Informationen vor, um sie mit den Teams und den anderen Teilnehmern zu teilen.
Hier sehen Sie, wie das Gesamtboard für eines unserer Sprint Reviews aussah:
Der nächste Screenshot zeigt eine typische Sprint Review Agenda.
Wir hatten eine Zeitbeschränkung von nicht mehr als 2 Stunden, was in den meisten Fällen funktionierte, auch wenn ich mir manchmal wünschte, wir hätten etwas mehr Zeit gehabt.
Unsere Agenda bestand aus 8 Blöcken:
Üblicherweise begannen wir unsere Veranstaltung damit, die Schritte, die während des Sprint-Reviews durchgeführt wurden, separat zu erwähnen und Änderungen am Ablauf einzuführen, sofern diese im vorherigen Event oder der Sprint Retrospektive beschlossen wurden. Wir stellten fest, dass Teilnehmer, die zum ersten Mal an dieser Veranstaltung partizipierten, im Vorfeld von einer individuellen Einführung in den Ablauf der Veranstaltung profitierten. So konnten wir den ersten Punkt der Tagesordnung kurz halten. Dies ist auch ein guter Zeitpunkt, um ein kurzes Check-In zu machen, indem die Teilnehmer bspw. ein Wort in das Chat-Feld tippten, ein Giphy oder vielleicht ein Bild in einem Bereich des Whiteboards posteten.
Es folgten ein paar Worte des Geschäftsinhabers, bei dem er wichtige Firmen-Updates und Abteilungs-Updates ankündigen oder neue Mitarbeiter vorstellen konnte.
Der dritte Punkt auf unserer Agenda war ein kurzer Statusüberblick, der widerspiegelte, wo sich die Teams auf ihrer jeweiligen Reise befanden. Wie bereits erwähnt, hatten wir 4 Teams, die an 4 verschiedenen Produkten arbeiteten, und dies war die Gelegenheit für jedes Team, verbal und visuell mitzuteilen, was gerade passierte: Updates in Bezug auf Nutzungszahlen, Markt-Updates, Hindernisse und das weitere Vorgehen. Meistens wurde dies von den Team-POs durchgeführt und dauerte nicht länger als 5 Minuten pro Team.
Wie Sie auf dem Screenshot unten sehen können, haben wir dafür eine Tabelle auf dem Board mit 4 Spalten erstellt (Hindernisse & Hilfsanfragen, Erfolge, Danke, Nächste Schritte).
Danach (oder manchmal während der Updates) gab jedes Team eine kurze Einführung zu den Produktinkrementen, die zur Erkundung im Review Bazaar vorbereitet worden waren.
Jedes Team, das etwas Neues mitzuteilen hatte, bereitete einen oder mehrere Abschnitte auf dem Board mit Anweisungen vor, wo die Produktinkremente zu finden waren und wie sie getestet werden konnten. Manchmal wurden die Anweisungen durch Schlüsselfragen für das Feedback ergänzt. Meistens fügten die Teams Screenshots von den neuen oder aktualisierten Teilen des Produkts (Website oder App) hinzu. Dies machte es für die Teilnehmer sehr einfach, das Feedback mit einem bestimmten Bereich des Produkts zu verknüpfen. Für allgemeine Anmerkungen und Feedback erstellte jedes Team außerdem einen Abschnitt mit 4 Quadranten (Was hat funktioniert? / Was hat mich verwirrt? / Was hat nicht funktioniert? / Irgendwelche neuen Ideen?).
Nach etwa 45 Minuten begann der spannendste Teil des Reviews. Die Teilnehmer begannen, sich auf dem Miro Board zu bewegen und die Angebote zu erkunden. Wie bereits erwähnt, waren die Angebote sehr vielfältig und das Review wurde so gestaltet, dass die Teilnehmer auswählen konnten, welche Teile für sie am interessantesten waren und an welchen Stellen sie den größten Beitrag leisten konnten, indem sie das das Gesehene bewerteten und Feedback gaben.
Das Content-Team teilte in der Regel Artikel oder YouTube-Videos, die im Sprint erstellt und veröffentlicht wurden. Neben dem Link zum eigentlichen Artikel fügte das Team einen Screenshot und einen Feedback-Quadranten hinzu (siehe Screenshot unten).
In anderen Fällen fügten die Teams einen Link zu einer neuen Funktionalität auf einer Webseite oder einer ganz neuen Landing Page hinzu. Dies konnte entweder ein Link zum Live-System oder zu einer anderen (Staging-)Umgebung sein, und allgemeine Anweisungen für den Zugriff wurden ergänzt.
Wie bereits erwähnt, bereitete das Team für das Feedback in der Regel einen Bereich mit Screenshots der neuen Funktionalität oder eine Webseite vor und die Teilnehmer fügten Post-it-Notizen mit Kommentaren direkt neben den Bereichen hinzu. Zusätzlich dazu hatte jedes Board einen Feedback-Quadranten für allgemeines Feedback.
In einigen Fällen handelte es sich um eine neue Funktionalität in einer mobilen App, die zur Überprüfung zur Verfügung stand. Hier bereiteten die Teams in der Regel eine detailliertere Beschreibung vor, wie die App von einem Testserver aus zu installieren war, manchmal durch das Posten eines Links zu einem Bildschirmausschnitt, der eine Schritt-für-Schritt-Anleitung zur Installation enthielt. Außerdem gab es einen Link zu einem MS Teams-Kanal oder einem Teammitglied in Slack, das die Teilnehmer bei Problemen mit der Installation der App unterstützen konnte. Auch hier stellte das Team die relevanten Screenshots aus der App auf einem Frame in Miro zur Verfügung, damit die Teilnehmer Post-its direkt zu den Bereichen schreiben konnten, zu denen sie Feedback hatten. Darüber hinaus gab es einen Feedback-Quadranten für allgemeineres Feedback.
In anderen Fällen gab es nur Mockups, Wireframes, Scribbles oder sogar Datenblätter, an denen das Team im vorherigen Sprint gearbeitet hatte. Auch hier gaben sie klare Anweisungen, welche Art von Feedback sie benötigten.
In einigen Fällen bereiteten die Teams sogar Kundeninterviews für das Sprint Review vor. Sie baten die Teilnehmer, ihren Namen in einen Timebox-Slot zu schreiben, und ein Teammitglied, das darin geübt war, Kundeninterviews zu führen, ließ einen oder mehrere Teilnehmer die neue Funktionalität erleben und Fragen beantworten.
Der nächste Schritt war das Review und die Diskussion der Teilnehmer-Feedbacks. Dazu setzte sich jedes Team mit seinem Product Owner in ihrem MS Teams-Kanal zusammen und überprüfte die Post-its und diskutierte das schriftliche Feedback sowie das, was sie während der Interviews beobachtet hatten. Dies führte in der Regel dazu, dass neue PBIs erstellt und im nächsten Product Backlog Refinement besprochen, sowie PBIs aktualisiert oder im Product Backlog neu geordnet wurden.
Der letzte Schritt unseres Sprint Reviews war ein kurzes Zeitfenster zur Rückschau auf den Sprint Review. Die Teilnehmer hatten die Möglichkeit, Feedback und Ideen zur Verbesserung des Sprint Reviews zu hinterlassen. Um dies zu ermöglichen, nutzten wir einen anderen Bereich des Boards und die bekannten vier Quadranten.
Wie bereits erwähnt, handelt es sich hier nicht um ein typisches LeSS Sprint Review, obwohl der verwendete Ablauf sehr ähnlich sein könnte. Wo liegen die Unterschiede?
Large-Scale Scrum (LeSS) bietet durch sein Regeln und Prinzipien ein Organisationsdesign, das auf Anpassungsfähigkeit bei minimalen Kosten und Kundennutzen optimiert ist. In LeSS gibt keine „Team Product Owner“ und keine „Team Product Backlogs“. Um lokale Optimierung durch Effizienzsteigerung auf Teamebene zu vermeiden, gibt es ein gemeinsames Product Backlog. Das sorgt dafür, dass die Optimierung auf Systemebene stattfindet. In der Regel ist dies am sinnvollsten, wenn mehrere Teams an einem Produkt arbeiten, was eine klare Notwendigkeit schafft, dass alle Teams gemeinsam die Entwicklung des Bereichs des Produkts unterstützen, der am kritischsten für die bestmögliche Kundenwirkung ist. Und selbst in einer Situation, in der mehrere Teams parallel an mehreren Produkten arbeiten, bevorzugt LeSS die Arbeit mit einem Product Backlog (und mit einem Product Owner, der dieses Product Backlog pflegt) und breiteren Produktdefinitionen, da sie
Solange es also eine gemeinsame (Gesamtprodukt-)Vision gibt, die mehrere Produkte, die selben Kunden oder die selben Märkte umfassen, und das gleiche Domänenwissen relevant ist, spricht vieles dafür, die Produktdefinition auf mehrere kleinere Produkte auszuweiten.
In unserem Fall erforschte die Abteilung mehrere innovative Produkte mit mehreren Teams, so dass die Arbeit mit einem einzigen Product Backlog viel Sinn ergeben hätte, insbesondere weil die Erforschung und Lieferung der Produkte extrem schnell und anpassungsfähig gewesen wäre. Es hätte der Organisation erlaubt, die Investitionen in das erfolgreichere Produkt „on the fly“ zu erhöhen, anstatt mit einer definierten Gruppe von Leuten eine definierte Zeit an mehreren Produkten arbeiten, nur um dann ab einem bestimmten Zeitpunkt einige Produkte wegzuwerfen und die Teammitglieder in der Entwicklung des erfolgreicheren Produkts zu schulen.
Im konkreten Beispiel waren die Produkte in Bezug auf die verwendete Technologie sehr unterschiedlich und die meisten Mitarbeiter Freiberufler, so dass auch die Arbeit mit mehreren Product Backlogs und mehreren Product Ownern (also ohne LeSS) auch gut funktionierte. Die Interaktion zwischen den Teams war sehr gut, die Effizienz auf Teamebene war hoch und das erfolgversprechendste Produkt konnte identifiziert werden.
In einem echten LeSS-Setup würden Sie vielleicht ein paar Dinge anders durchführen wollen. Nach dem Check-in und bevor die Teams ihre Sitzungen pitchen, könnten Sie nur einen Block haben, in dem der Product Owner relevante Änderungen der Nutzungszahlen, spezielles Kundenfeedback und Updates vom Markt kommuniziert.
Sie könnten einen Bereich auf dem Board vorsehen, wo wichtige Zahlen und andere Erfolgsgeschichten (z.B. Go-Live einer Funktionalität) geteilt werden, aber ich würde sowohl die „Hindernisse“ als auch die „nächsten Schritte“ entfernen, oder zumindest würde ich sie nicht zu Beginn des Sprint Reviews diskutieren. Der beste Zeitpunkt, um Hindernisse zu besprechen, wäre während einer Gesamt-Retrospektive (mit allen Teams) und die nächsten Schritte bespreche ich lieber am Ende des Sprint Reviews und unter Einbeziehung des gesamten Feedbacks daraus, nicht am Anfang.
Nach dem Remote Review Bazaar sortieren und gruppieren die Teams den Input, den sie erhalten haben, und fassen ihn zusammen. Der Product Owner macht sich mit dieser Zusammenfassung vertraut, in dem er zwischen den Bereichen auf dem Miro Board oder zwischen den Breakout-Räumen der Teams hin- und her wechselt. Anschließend besprechen alle Teams mit dem Product Owner, welches Feedback in den kommenden Sprints eingearbeitet werden soll und wie dies geschehen kann. Häufig führt dies zur Erstellung von neuen Items, die im nächsten Backlog Refinement definiert werden, zur Veränderung von Prioritäten bestehender Items oder gar zur Entfernung von Items. Dieser Schritt im Sprint Review ist sehr wichtig, denn er gibt die Richtung für die Entwicklung vor. Hier empfiehlt es sich, genügend Zeit im Sprint Planning einzuplanen.
Nach meiner Erfahrung lässt sich die Retrospektive des Sprint Reviews verkürzen, indem man lediglich einen Abschnitt für Feedback auf dem Board vorsieht, oder diesen Abschnitt sogar vollständig weglässt, und das Feedback bei Bedarf in einer Gesamt-Retrospektive bespricht.
Hier sehen Sie, wie eine Agenda aussehen könnte:
Ich hoffe, dieser Artikel gibt Ihnen eine Idee, wie Sie ein Remote Sprint Review mit mehreren Teams durchführen können. Über Feedback und/oder Fragen würde ich mich sehr freuen.
Hinweise:
Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.
Robert Briese nimmt regelmäßig Teilnehmer seiner pCLP-Kurse (Provisional Certified LeSS Practitioner) zu einem solchen Sprint Review mit. Wenn Sie also eine solche Veranstaltung live erleben wollen, können Sie an einem seiner Kurse teilnehmen oder ihm schreiben. Mehr über Robert erfahren Sie unter https://less.works/profiles/robert-briese oder auf seiner Firmenwebsite https://www.leansherpas.com.
Robert is the CEO of Lean Sherpas and one of 25 certified LeSS Trainers globally and one of the few with hands-on experience in LeSS and LeSS Huge. As a change agent for 15+ years, consulting and coaching, he has worked with over 30 companies, including DAX-listed global brands such as Adidas, BMW, BP, Dr. Oetker, Henkel, Hilti, Hugo Boss, SAP, Volkswagen, and ZF.
From 2015 to 2016 he led a LeSS adoption at a Global Player in the Software Industry, scaling development from 3 to 7 teams and coaching the development and the management team on how to lead a scaled agile organization. In 2018 he contributed to significant improvements in product delivery at one of the biggest LeSS Huge adoptions in the world at BMW AG. Working with over 30 teams, including large groups of over 400 employees, he led them to deliver bi-weekly product increments consisting of hardware and software.
Robert ist der CEO von Lean Sherpas und einer von weltweit 25 zertifizierten LeSS-Trainern und hat praktische Erfahrung sowohl mit LeSS als auch mit LeSS Huge. Als agiler Berater und Coach hat er in den letzten 20 Jahren mit über 30 Unternehmen zusammengearbeitet, darunter DAX-notierte Weltmarken wie Adidas, BMW, BP, Dr. Oetker, Henkel, Hilti, Hugo Boss, SAP, Volkswagen und ZF.
Von 2015 bis 2016 leitete er eine LeSS-Einführung bei einem Global Player in der Softwarebranche, skalierte dabei die Entwicklung von 3 auf 7 Teams und coachte das Entwicklungs- und Managementteam bei der Führung einer skalierten agilen Organisation. Im Jahr 2018 trug er bei einer der weltweit größten LeSS-Huge-Implementierungen bei der BMW AG zu signifikanten Verbesserungen in der Produktentwicklung und -auslieferung bei. In Zusammenarbeit mit über 30 Teams und mehr als 400 Mitarbeitern führte er sie dazu, alle zwei Wochen Produktinkremente, bestehend aus Hardware und Software, zu liefern.
Konstantin Ribel and Craig Larman discuss how BMW's driverless driving team was built based on LeSS Huge, and the successes and problems encountered along the way.About the conferenceLeSS attempts to define what is just necessary for large-scale development. It avoids adding additional roles
Konstantin Ribel und Craig Larman erörtern, wie das BMW-Team für fahrerloses Fahren auf der Grundlage von LeSS Huge aufgebaut wurde und welche Erfolge und Probleme auf dem Weg dorthin aufgetreten sind.Über die KonferenzLeSS versucht, das für eine groß angelegte Entwicklung gerade noch Notwendige zu definieren. Es vermeidet das Hinzufügen von zusätzlichen Rollen, Artefakten oder Prozessen, da es die Nachteile dieser Zusätze erkennt.Sehen Sie das Original hier -> www.infoq.com
Watch Konstantin Ribel discuss organizational behavior and performance and how LeSS can help manage organizational complexity. The orginal Video is viewable on the TC LeSS YouTube Channel. The original video can be seen on the TC LeSS YouTube Channel.
Sehen Sie, wie Konstantin Ribel über organisatorisches Verhalten und Leistung spricht und wie LeSS helfen kann, die organisatorische Komplexität zu bewältigen. Das Originalvideo ist auf dem TC LeSS YouTube Channel zu sehen.