“Ugh, our demos have become so dry!…”, is a comment that was captured during one of our retros recently, “…and for no good reason! We’re proud and excited about the value we’ve created!”. Of course, we understand sprint review demos are an opportunity in Scrum to showcase the work that was done in the last period of time, and celebrate the outcome. Easy right? Not always. As an action from this retro I thought I’d ponder this over the week looking for some clues as to what was going wrong and how we might improve next time…
There are a few common contributing factors to making this not as straight forward as it should be:
- A wide audience with varying care-levels of what you’re doing — This is common when working with clients in a service orientation. Often, the client wants to bring a wide variety of stakeholders — and voyeurs — who dip in and out of the project or don’t have the level of context to appreciate what is changing and why.
- “Seventeen-thousand-four-hundred-and-twenty-second sprint fatigue” — It’s easy to get stuck in a rut both as the sprint team and as the wider audience when you get to the point of going through the motions. You’ve been working on a particular initiative or theme for some time and it starts to feel like you’re just reporting on progress.
- Maintenance-heavy sprints — People want bugs to be fixed YESTERDAY, but naturally find it difficult to get excited about it when they are fixed… If you have a bunch of these in the sprint, it can be quite dry going through each one.
- plus more no doubt…
Our particular situation was a combination of all the above… challenge accepted!
Even though the common advice is to keep the sprint review relatively informal and relaxed, depending on your audience and what you’re working on, you run the risk of it being ill-prepared for and coming across as boring or inaccessible. We all know that Agile is about minimising the focus on how much work was done and ultimately focussing on the value that was achieved but how to do this whilst not just resorting to reading backlog items out of JIRA?
Much to think about…
Where does the wine come in?
The rest of the week continued, and that Friday we had an organised company wine tasting event in the office. We’re lucky at Pixel Fusion to be based in Auckland, New Zealand which is on the doorstep of some incredible vineyards and we often invite one of our favourites — Man’o’war of Waiheke Island — to come into the office and run a tasting for us.
We reach out to them each year, and the same guy comes back each time and runs it. Josh is his name. We like Josh because he makes what could be a really dry (see what I did there?) experience, really interesting and engaging, and ultimately a great night for the team to relax, have some fun and get into some vino.
For each wine, he could just tell us about the varietals, confound us with snobby remarks about the “… hint of wild gooseberry on the nose that comes from the minerals in the imported soils… blah blah…”, the rest of the tasting notes and of course what, in his professionally esteemed opinion, we should be feeling about the wine.
But instead, he tells us about the part of the vineyard this particular grape is grown on. He tells us about only being able to pick the grapes on that side of that island when it’s high tide because you can’t get access to it otherwise. He tells about that the old guy “Dave” who lives next to the vineyard. He owns and operates the barge they use to ferry the grapes across at midnight, after high tide and Josh is buggered if he knows what they’re going to do when Dave passes away. He shares stories about the master wine-maker hard at work and some of the unorthodox things he’s tried to get the best out of the grapes, and he talks about the crappy Holden station wagon they use to get around the farm.
He talks about their successes, their failures, a selection of the trials and tribulations they’ve gone through this particular harvest and everything that makes that wine more than just a bit of tasty liquid in your glass. Then and only then does he bring it back to the wine itself. You almost forgot you were holding it but when you look down at it, you look at it differently to when you did as he poured it for you. He then invites you to taste it, helps you describe it a bit and asks us what we think and how it compares to the last one. It makes for a more engaging, compelling experience.
You feel you know so much more about the drop of liquid in that glass. You WANT to appreciate it and enjoy it (Hopefully! No amount of storytelling can save a shit wine!).
All in all, from the perspective of time, the preamble is 90% and the tasting is just 10%, but the appreciation is so much greater for it.
It was after the wine-tasting, when a group of us were still chilling, drinking a bit more wine (as you do), and a colleague and I were reflecting on the week. The subject of the sprint demos came up and we started discussing our thoughts since then on how we could improve the situation, and it struck me — a few wines down I’ll admit, but isn’t that when the best ideas come out? — that we’d just experienced a demo of sorts. Josh had taken us through what he and his team over at Man’o’war had been doing since the last time we saw him. How the wines had improved, what had changed, what was the same, and we got insight into that process and a little taster of the new vintage of wines they’d been working on.
Now imagine a sprint review demo with the same kind of story-telling approach — but probably with less alcohol. You’re there to celebrate the delivery of improved customer or user value — just like that new vintage wine selection — in all of its glory. Each wine in the collection has its own back story- a different journey that results in a unique appreciation, much like each story in your sprint backlog that you’re itching to demonstrate. You’re there to celebrate what it took to bring that customer value to life, and the journey you and your team have undertaken to get there.
So share the journey! Show them the lifecycle of concept to completion for a piece of user value.
Share the highs, like that customer you met who surprised you with that amazing bit of insight that changed everything. Or when you found a simpler way to get information from system A to system B that cut out all that needless code and risk around data integrity. Give the audience some insight into why you get excited by the opportunity to work on some of these stories. Share with them the things that make all those challenging days (and nights) worthwhile.
Take them on that journey. From research with real users, to co-design sketching workshops — like that one Jimmy your lead engineer was in who couldn’t sketch to save his life, bless him — right through to the negotiation with the Engineering team on what could be implemented in that sprint.
These are glimpses into a world that they might not be able to fully comprehend but will be help them fully appreciate the constant prioritisation, important decision making and user & QA testing that goes into delivering value in a short sprint cycle.
Then, and only then, is your audience ready to fully appreciate the transformation of “before this enhancement was in my life”, to after! Show them the goods, let them revel in their detail, guide them as they get wrapped up in the journey of their creation!
All this to say — and I think we knew this all along but got lost in the mechanical repetitiveness — that the sprint review demo should be a celebration of the journey, and everything that took place to make it come together in the realisation of increased value you and your team has brought to the product and the business. It’s also an opportunity for others to appreciate your team’s craft, professionalism and relentless dedication.
So go have yourself a glass of wine and take another look at your sprint backlog with your team before your next review and start thinking about what you can be doing now to capture the little things that will add to the story you have to tell at the end.