Sprint Review: Bottom - Bottom
"We lay down, we lit lights, in the Universe we are the only ones." It seems that this line from the song of the Splin group can be safely recognized as the soundtrack of the introduction of the Sprint Review practice in Dodo Pizza.
Disclaimer: in an article, Anton describes the first version of a viable sprint review. We already have a more advanced one, but about it in the next series.
The first attempt to launch the sprint review practice at Dodo Pizza failed miserably.
Maybe you think that scrum pizza chain practices are generally useless. However, one of the main advantages of Dodo Pizza is, oddly enough, its own IT system, which manages all processes in 495 pizzerias of the network in 12 countries.
80+ developers and analysts are working on this system today (and more than two hundred will come over time ). As a fast-growing startup, we strive for maximum efficiency, therefore, we use many of the “flexible development” frameworks: Scrum, LeSS, extreme programming.
But what is this scrum, you ask, without sprint review? And you will be right.
As you know, sprint review sets the rhythm for the team and motivates to complete work by the end of the sprint. More importantly, it helps create a valuable product that a business needs, and not just do backlog tasks. So, in any case, they write in books.
However, for some reason this approach did not work for us. For example, at one of the first sprint review we showed Dodo Pizza franchisees from Kazakhstan their new site - dodopizza.kz. The feedback was inspiring: the partners said that the site looks gorgeous, and against the background of competitors it will seem like a masterpiece.
When we rolled it out, it turned out that a lot of things were missing in it. That is, we spent time on sprint review, but actually didn’t get a useful feedback from partners.
In general, soon we quietly stopped such sprint reviews.
After a few months, I decided to try again. By that time, we already had eight teams working on the same backlog in the LeSS framework. We tried to follow all the rules of Large Scale Scrum, and the lack of sprint review was one of the violations.
I prepared in advance for the fact that at first everything will be bad, and you will need to look for the correct format using the trial and error method. After each review, I asked participants to rate the event on a scale of 1 to 10 (Bottom - Omnische). At first, the ratings were very low, closer to the "bottom". However, we didn’t give up, experimented, and somewhere in a couple of months they began to shift to the Ognist.
That's what we changed
We realized that you need to spend no less time on preparation than on the sprint review itself - or even more. The whole event takes two hours, and I get ready for three hours. After all, it is necessary to coordinate goals with the teams, arrange with partners, managers of the management company, employees of pizzerias and other guests, book conversations, make a poster, find facilitators, instruct, draw up and draw a schedule, hang up flip chats to collect feedback, etc. Without all this, there will simply be chaos.
Do not show unfinished
At first, we showed half-finished features. But we realized that this is how we deceive teams and, most importantly, customers. Once we showed the CEO of a geoservice company that caches map data. Then at the next review it was shown again - only with fixed bugs. When we came in for the third time and showed the same service, but already on the combat website, the CEO had a natural question: “What the hell are you showing the same thing for the third time?”
Now at sprint review we show only what is posted on the combat site. If something is almost ready - there are only bugs to fix, test and lay out bugs - we do not show.
Negotiations instead of open space
LeSS authors recommend a sprint review in the form of a "bazaar". All teams must show their work in one large room, and those interested can go to stations that interest them. We tried it several times, it turned out noisy and fussy.
Laptop screens are small, nothing is visible on them, noise from neighboring stations makes it difficult to concentrate, and the constant movement of people creates chaos. Therefore, now in the conference room everyone gathers only at the beginning and at the end. The main action takes place in the meeting rooms, where each team presents its work. There, equipment, large screens, you can sit comfortably, remote participants are connected and there is a place for collecting feedback.
Transitions are prohibited!
At first, our stakeholders moved freely between teams. But it was annoying. Imagine that you started to tell something and in ten minutes a new person joins the group and asks questions about what you just talked about.
Start answering - the rest are bored. Ignore - the person is upset. Therefore, we decided to prohibit movement between groups. I chose the topic that interests you - sit in the meeting room for twenty minutes until the next break.
We realized that the composition of the "guests" is of great importance. Nothing motivates a developer like appearing on a sprint review CEO. Especially when you need to show him some technical thing-trick like a service in a cube or transfer Auth to .Net Core. We have to explain why we are doing this. Fedor Ovchinnikov, CEO of Dodo Pizza, energizes and knows how to cheer up everyone and outline the horizons of the company's development in three minutes. Well, when we show client features, for example, a half-pizza constructor in a mobile application, we now call external guests, as a rule, acquaintances and friends from Facebook.
It is easy to hold a meeting when everything is in one room. But we have many remote employees in Syktyvkar, Nizhny Novgorod, Kazan and Goryachy Klyuch. It is also important for them to attend.
At first, the "remote workers" complained that they were hard of hearing and almost did not see anything. Now we take care of them as well as offline participants. There are items in the sprint review preparation checklist that remind us to check the connection and set up the equipment. We are broadcasting on Slack, and more recently, we have been streaming the event on our youtube channel Dodo Pizza .
When it began to seem that everything was good and there was nowhere to improve the format, we asked ourselves the question: are we not doing garbage? A sprint review is a rather expensive event (if you look at it cynically - in terms of the number of participants, their salaries and hours spent). Are we using these two hours as productively as possible? As a result, we decided to completely refuse to collect feedback during the sprint review.
In the format of such an event, it cannot be done deeply and qualitatively (recall a case with Kazakhstan). In addition, we collect most of the significant and high-quality reviews during the sprint, attracting everyone interested, from internal customers to users ... You will be surprised, even the Scrum Guide does not say that feedback should be collected on the sprint review: "During the Sprint Review , the Scrum Team and stakeholders collaborate about what was done in the Sprint. " Team and stakeholders, not users. Interact, not collect feedback. A completely different meaning.
Open the "kitchen"
Not all stakeholders are deeply immersed in the development process. But everyone wants to know what is going on there. It is for these purposes that we decided to reorient the sprint review.
We still show the work done, but in addition to this, the teams tell the story behind the new features. What was the purpose? What happened during the sprint? What distracted us or prevented us from reaching our goal? What measures have we taken to save the goal? This helps: in this way it becomes clear to managers, for example, why “hiding the client’s email with a check in stars” is a very difficult task (“half an hour of a programmer’s work”, as managers thought). Conversely, such a dialogue helps developers think in terms of “customers” and their problems, rather than in terms of the specific solutions they are working on.
This is perhaps the main thing that we have changed in our approach. Progress is evident, but as always, there is still something to improve. The experiments are ongoing.
The main thing that we understood is that we don’t need to get hung up on the formats proposed in the Scrum manuals. You need to try, make mistakes and experiment. There are no universal solutions - you need to look for those that work in your situation.
Therefore, I want to warn you in the end: do not copy our format. He works well with us because he was born as a result of many experiments. Look for your approach - and you will succeed. It certainly won’t be worse.