Many organizations don’t maximize the success they could have with Scrum by focusing the Sprint Review on the following:
While all those things are either mentioned in the Scrum Guide or seen as “good practices” in many organizations, in my opinion, all of them miss the opportunity of getting the best out of a given Scrum event: to inspect and adapt the product and continuously focus on what to do next in order to maximize delivery value.
Here are my top 4 suggestions regarding the Sprint Review:
Let me elaborate more on each of the above points.
Scrum suggests integrating stakeholders in the Sprint Review, but often, I only see developers presenting the product increment to the Product Owner and sometimes Product Owners from other teams. This is often a sign that the team is a component team that only focuses on some technical parts of a given system that need to be integrated with work from other teams, which automatically leads to waterfall development. This can only be changed by changing your organizational design to create feature teams that implement end-to-end customer requirements, as suggested in LeSS. But even when having feature teams, I’ve seen many organizations do Sprint Reviews without actual customers or end-users because they weren’t sure about how to find, motivate and involve the right people. If you build an internal product (like a CRM system), the customers should be the people using that system. This means it shouldn’t be difficult to find and motivate them to join your Sprint Review. If you’re building a market-facing product, then you usually have a marketing department (if people are not integrated into the teams) as well as a selected group of first adopters that love your product and use it extensively – If you don’t, you might want to reconsider if it’s worth investing more in product development. It shouldn’t be hard to integrate at least a few different individuals from those groups in your Sprint Review.
The Sprint Review should be an opportunity for everyone involved in product ideation, creation, delivery, and consumption to assess if the right product (features) has/have been worked on and delivered. This is one of the most important parts of empirical process control. There is no value in delivering in short iterations if you don’t deeply analyze whether you’re working on the right things and change direction if you notice that you aren’t. To assess this properly, you need to look at the actual data, such as how many actual users you have, how often the new features are consumed, and most importantly, whether the recently developed product features lead to the desired impact. I personally like to use techniques such as impact mapping for this, but at minimum, it’s a good idea to prepare insightful data about the product usage for everyone attending the Sprint Review. This can be prepared by the Product Owner or delegated to some other Product Managers, but obviously, the Product Owner needs to be on top of the numbers to make important product decisions. Also, if there are official release timelines that have been communicated, the Sprint Review is a chance to manage expectations with the stakeholders. On top of that, look at providing feedback on budget numbers, which the Product Owner, as the one responsible for the ROI of the product, should be managing. Any other key insights regarding the market change and opportunities that are valuable to everyone involved in product ideation, creation, delivery, and consumption can be announced in the Sprint Review.
This is another thing that I see a lot of teams struggling with. Yes, it’s great to empower and motivate your developers to present newly implemented features to customers and stakeholders the, but these demos have severe drawbacks:
Instead of having developers present the newly implemented features, I suggest giving everyone participating in the Sprint Review a chance to experience the features as hands-on as possible. You can achieve this by (1) handing over participants a device, (2) giving the link to the software/application, or (3) putting some paper / digital prototypes on a (virtual) whiteboard. You can include a short description of how to access the features you want to get feedback on and any other questions that help you get valuable feedback.
This approach has various advantages:
Next to allowing the participants to experience the Increment of the Sprint as hands-on as possible, you also want to give them a chance to provide as much feedback as possible. I prefer to do this by making sure that plenty post-its and pens are lying around next to the device or the paper prototypes, or, if I do this virtually, I have the team(s) create screenshots of the app screens, or whatever there is to review, on a virtual whiteboard where participants can directly leave feedback. You can also add additional questions (like what features are currently missing or whether they would expect the functionality to work differently) to get valuable feedback. You’ll be amazed at how much feedback you get compared to when you are “just doing a demo”.
But the crucial part only starts after you’ve received all the feedback. Because, as I mentioned earlier, there is not much value in doing an iterative and incremental development if you don’t constantly adapt the backlog and make sure you’re working on the items that, based on the latest feedback and current understanding, are supposed to deliver the highest value to the company/customers. So, you want to distil all the feedback and come to a decision on what critical feedback you have and want to act upon right away (maybe already in the next Sprint), what important feedback there is that you want to discuss and reevaluate in a future Product Backlog refinement, and what feedback isn’t important for now. You can do this by grouping all of the feedback together and separating the groups into different categories. Ultimately, it should be the Product Owner who makes the final decision on the prioritization, but the more you involve all participants in reviewing, grouping, and differentiating the feedback, the more they will better understand the customer needs and purpose of the product.
With just a few changes, you’ll get more highly interactive events where every product creator/developer interacts directly with customers/users of the product and understands how the current product meets its purpose and what they need to implement next to solve the customer’s problems or help them achieve a better outcome with the product they are creating.
If you want to experience a Sprint Review where all the above mentioned suggestions get demonstrated, sign-up for our Lean Sherpas LeSSons Learned Newsletter. We allow our customers and clients to join our own Sprint Reviews and watch us in action.
Viele Organisationen verpassen leider die Chance das Beste aus dem Sprint Review zu machen indem sie sich während dieses Scrum Events auf Folgendes konzentrieren:
Während all diese Dinge entweder im Scrum Guide erwähnt sind oder in vielen Organisationen als „gute Praktiken“ angesehen werden, verpassen sie meiner Meinung nach alle die Gelegenheit, das Beste aus diesem Scrum-Event herauszuholen: das Produkt zu inspizieren und anzupassen und darauf zu schauen, was als nächstes getan werden muss, um den Lieferwert zu maximieren.
Hier sind meine Top 4 Vorschläge zum Sprint Review:
Hier etwas mehr zu den einzelnen Punkten:
Scrum schlägt vor, Stakeholder in das Sprint Review einzubeziehen, aber oft sehe ich nur Entwickler, die das Produktinkrement dem Product Owner und manchmal Product Ownern anderer Teams präsentieren. Dies ist oft ein Zeichen dafür, dass das Team ein Komponententeam ist, das sich nur auf einige technische Teile eines Systems konzentrieren, die in die Arbeit anderer Teams integriert werden müssen, was automatisch zu einer Wasserfallentwicklung führt. Dies kann nur geändert werden, indem Sie Ihr Organisationsdesign ändern, um Feature Teams zu erstellen, die Ende-zu-Ende-Kundenanforderungen implementieren, wie z.B. in LeSS vorgeschlagen. Aber selbst mit Feature-Teams, erlebe ich in vielen Organisationen, dass Sprint Reviews ohne tatsächliche Kunden oder Endbenutzer durchgeführt werden, weil man oft nicht weiss, wie man die richtigen Personen findet, motiviert und einbezieht. Bei der Entwicklung eines internen Produktes (wie ein CRM-System), sollten die Endnutzer diejenigen sein, die dieses System verwenden. Das bedeutet, dass es nicht schwierig sein sollte, diese zu finden und zu motivieren, an dem Sprint Review teilzunehmen. Bei der Entwicklung eines marktorientierten Produktes, gibt es üblicherweise eine Marketingabteilung (wenn diese Leute nicht in dem Teams integriert sind) sowie eine ausgewählte Gruppe von Erstanwendern, die Ihr Produkt lieben und ausgiebig nutzen. Sollte das nicht der Fall sein, wäre es vielleicht gut darüber nachdenken, ob es sich weiterhin lohnt, in diese Produktentwicklung zu investieren. Es sollte nicht schwer sein, zumindest ein paar verschiedene Personen aus diesen Gruppen in dem Sprint Review zu integrieren.
Das Sprint Review sollte eine Gelegenheit für alle sein, die an der Produktidee, -erstellung, -lieferung und -nutzung beteiligt sind, zu beurteilen, ob das richtige Produkt (mit den richtigen Features) geliefert wurden. Dies ist einer der wichtigsten Teile der empirischen Prozesskontrolle. Es hat keinen Wert, in kurzen Iterationen zu liefern, wenn man nicht gründlich analysiert, ob die richtigen Sachen geliefert werden, und die Richtung andernfalls geändert wird. Um dies richtig einzuschätzen, müssen man sich die tatsächlichen Nutzungsdaten ansehen, z. B. wie viele tatsächlich das Produkt benutzen, wie oft die neuen Funktionen konsumiert werden und vor allem, ob die kürzlich entwickelten Produktfunktionen zu der gewünschten Wirkung geführt haben. Ich persönlich nutze gerne Techniken wie Impact Mapping dafür. Aus diesem Grund ist es eine gute Idee, aufschlussreiche Daten über die Produktnutzung für alle Teilnehmer des Sprint Reviews vorzubereiten. Dies kann vom Product Owner vorbereitet oder an andere Produktmanager delegiert werden, aber natürlich muss der Product Owner den Überblick behalten, um wichtige Produktentscheidungen treffen zu können. Auch wenn es offizielle Veröffentlichungszeitpläne gibt, die kommuniziert wurden, ist das Sprint Review eine Gelegenheit, die Erwartungen mit den Stakeholdern zu managen. Darüber hinaus sollten Sie Feedback zu Budgetzahlen geben, die der Product Owner als derjenige, der für den ROI des Produkts verantwortlich ist, verwalten sollte. Alle anderen wichtigen Einblicke in Bezug auf die Marktveränderung und Möglichkeiten, die für alle an der Produktidee, -kreation, -lieferung und -nutzung Beteiligten wertvoll sind, können im Sprint Review bekannt gegeben werden.
Das ist eine andere Sache, womit sich viele Teams schwer tun. Ja, es ist großartig, Ihre Entwickler zu befähigen und zu motivieren, Kunden und Stakeholdern neu implementierte Features zu präsentieren, aber diese Demos haben schwerwiegende Nachteile:
Anstatt Entwickler die neu implementierten Funktionen präsentieren zu lassen, schlage ich vor, allen Teilnehmern des Sprint Reviews die Möglichkeit zu geben, die Funktionen so praktisch wie möglich zu erleben. Sie können dies erreichen, indem Sie (1) den Teilnehmern ein Gerät übergeben , (2) den Link zur Software/Anwendung geben oder (3) einige gedruckte/digitale Prototypen auf ein (virtuelles) Whiteboard stellen . Sie können eine kurze Beschreibung hinzufügen, wie Sie auf die Funktionen zugreifen, zu denen Sie Feedback erhalten möchten, sowie alle anderen Fragen, die Ihnen dabei helfen, wertvolles Feedback zu erhalten.
Diese Vorgehensweise hat verschiedene Vorteile:
Sie möchten den Teilnehmern nicht nur ermöglichen, das Inkrement des Sprints so praktisch wie möglich zu erleben, sondern ihnen auch die Möglichkeit geben, so viel Feedback wie möglich zu geben. Ich mache das, indem ich darauf achte, dass neben dem Gerät oder dem Papierprototypen reichlich Post-its und Stifte herumliegen, oder wenn ich das virtuell mache, lasse ich das/die Team(s) Screenshots der App-Bildschirme erstellen, oder alles, was es zu überprüfen gibt, auf einem virtuellen Whiteboard, wo die Teilnehmer direkt Feedback hinterlassen können. Sie können auch zusätzliche Fragen hinzufügen (z. B. welche Funktionen derzeit fehlen oder ob sie erwarten würden, dass die Funktionalität anders funktioniert), um wertvolles Feedback zu erhalten. Sie werden erstaunt sein, wie viel Feedback Sie bekommen, verglichen mit „nur einer Demo“.
Aber der entscheidende Teil beginnt erst, nachdem Sie alle Rückmeldungen erhalten haben. Denn wie ich bereits erwähnt habe, hat es wenig Wert, eine iterative und inkrementelle Entwicklung durchzuführen, wenn Sie das Backlog nicht ständig anpassen und sicherstellen, dass Sie an den Elementen arbeiten, die auf der Grundlage des neuesten Feedbacks und des aktuellen Verständnisses dem Unternehmen/den Kunden den höchsten Wert liefern. Sie möchten also das gesamte Feedback destillieren und zu einer Entscheidung kommen, welches kritische Feedback Sie haben und sofort (vielleicht bereits im nächsten Sprint) darauf reagieren möchten, welches wichtige Feedback es gibt, das Sie in einem zukünftigen Product Backlog Refinement weiter besprechen möchten und welches Feedback derzeit nicht wichtig ist. Sie können dies tun, indem Sie alle Rückmeldungen zusammenfassen und die Gruppen in verschiedene Kategorien unterteilen.
Mit nur diese 4 Änderungen erhalten Sie ein interaktives Event, bei denen jeder Produktersteller/-entwickler direkt mit Kunden/Benutzern des Produkts interagiert und versteht, wie das aktuelle Produkt seinen Zweck erfüllt und was er als Nächstes implementieren muss, um die Probleme des Kunden zu lösen oder bestimmte Ergebnisse besser zu erzielen.
Um ein Sprint Review zu erleben, bei dem alle oben genannten Vorschläge demonstriert werden, abonieren Sie unseren Lean Sherpas LeSSons Learned Newsletter. Wir ermöglichen unseren Kunden und Auftraggebern, an unseren eigenen Sprint Reviews teilzunehmen und uns in Aktion zu erleben.
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.