Today (XING office in Hamburg, July 2015) our sprint review was different. It didn’t look like any meeting at all. If you would enter the team areas you wouldn’t see anything drastically different to our normal working mode: people are talking in small groups, several people are discussing something by looking at their mobile phones, several others are leaning over tables and looking onto screens. Nothing like a meeting.
But two weeks ago and also every two weeks for the last year or so, this event looked pretty much different. We all would sit in one of our large meeting rooms with 40-50 people attending. One person would speak on a stage for about 7 minutes and others would watch the presentation. Then someone maybe ask one or two questions. Then people would applause and switch to the next presenter.
This was our “standard” way we used to run joint sprint reviews for the 3 teams in our XING mobile cluster. Then since our review was well attended, we invited several other teams to join. In the end we began to have one of the biggest sprint reviews at XING. Huge success! Really?
But despite the high attendance of the guests including the C-level executives, the feedback we started to get from the teams was rather on the negative side: the reviews were taking too much time to prepare; it was stressful to speak in front of so many people; not all of the presentations were uniquely valuable and engaging… and so on and so forth. But the main negative signal we heard was rather strong: the teams were receiving close to zero feedback (applause won’t count)
That was a refreshening “aha” moment for me (an Agile coach) when I came to realize the fact. Especially because I was one of the people who had stood behind creation of the joint review format. As a quick history tour: two years ago when I joined XING each team had a dedicated Sprint Review. But the teams were not receiving equal attention from the stakeholders and management. Also it was quite challenging for the stakeholders to attend all teams’ review. So we decided then to merge the reviews. What we ended up having wa a gigantic Sprint Review that was well-attended by stakeholders and the top company people.
But somewhere on the way apparently we’ve lost an important piece: feedback on the product. That was definitely a learning path.
But why feedback is so important? Well. Scrum is based on the mantra “inspect-and-adapt”. And that’s for a reason. Software development is a complex process that requires empirical process control. Which in simple words mean: one can’t just simply plan software development and then go and execute the plan (that would be a defined process). Instead you need to go a small distance, then stop for a moment, look around and based on what you see decide how you adjust your route. That’s empirical.
And that’s what the Scrum teams are supposed to do when running Sprint Review (and also Sprint Retrospectives) in Scrum: stop, inspect what they did and decide how to adapt it in order to improve.
Now back to our situation. We did the stops. But we didn’t get enough of useful insights on where to go next. So why to have Sprint Review at all? In the end, I’m sure that question was on many people’s minds…
So what we did was following the advice from the Large Scale Scrum practitioners: do the Sprint Review Bazaar (we, being a German company, like the “Beer Fest” metaphor better).
So that what we did:
- Asked each teams to have a booth where they will welcome guests (a desk with some candies is good enough).
- Make sure the teams have at least 2 people at the same time at the booth talking to the guests.
- Cross the fingers and let the folks self-organize.
Benefits we gained:
- more interaction
- easy to try things out
- you can go into more details
- you can ask now much more questions
- cozy and intensive conversations
- less preparations needed
There are of course things to improve, so more experiments to come. Inspect and adapt, right?
But what has become obvious is that the “Beer Fest” style of Sprint Reviews is the way to go. At least for the next few sprints until we find an even better idea.
Write a comment