Demo or Die
Was lesson no. 1 at my Scrum Master training led by Stuart Mitchell last summer. He was not joking.
The catchy words brought a gentle smile to my face back then and only made sense right after I joined the high-profile healthcare app: Babylon Health. Our rapidly growing and truly exceptional company has a no smaller challenge than global scaling which is supported by continuous improvements across our tribes to fail fast and succeed faster (than our competitors).
Part of my Agile Delivery Manager role here is to pinpoint the falling points on old processes and craft new ones where needed. To do that, I needed to dig deep and see how the teams work together to avoid implementing useless methods no-one will ever follow or benefit from.
While digging, I realised there is no channel for people to see what is being shipped in other teams hence no opportunity to receive feedback or collaborate further and my Delivery Manager alarm immediately went off.
The alarm made me remember the lesson I learnt long ago in my career:
misalignment causes confusion and confusion is setting co-operation up to failure.
This is not my made up rule. We (as Homo sapiens) have an ability that enables us to dominate this planet and that is being able to co-operate flexibly in large numbers. This is what Agile allows us to do effortlessly but only when it’s processes are adjusted to the company’s needs.
As a start, we need to make sure we realise that our product’s success depends on how well the teams are aligned and how early they can get feedback from the internal/external stakeholders.
To achieve that? We need to aim for transparency among the teams and (in this case) reach product alignment with introducing regular demos.
We need to allow information to flow through the company at ease and show every Babylonian what awesome stuff we’ve achieved again. Impact isn’t just about deploying a system; it’s about understanding how that system or idea will be used and collect feedback on it.
Ok so how do you do that? What’s the magic?
First, everyone needs to be there.
It’s your responsibility, no one else will take care of it. Either you are an engineer or a product manager, you matter. Your story matters. And it’s your chance to show the world what you’ve achieved. It’s Demo time.
Demonstrate value.
Recap the goal of the sprint and what you’ve been focusing on. We found showcasing the outcomes squad after squad on a biweekly Monday session works the best, but you might wanna try out an engineer after engineer approach if you work at a smaller company.
Reiterate the purpose.
Never let the Demo start without saying what is it for. In a company growing as super fast as Babylon (last Monday we had 24 newcomers strolling through the office. And that was only on Monday) you kinda need to be sure all the new people are on board as to why they are sitting there at the first place.
Don’t be afraid to change the process
if something doesn’t work. Adjust it to the people as they are the key. Maybe do a retro about your first demo. The most important thing is that everyone should feel responsible and comfortable sharing. If you reach that sweet spot, you succeeded.
If you don’t, you might end up with a demo like this:
Think of it as a step out of your comfort zone.
Two minutes where everyone gets the chance to work on their public speaking skills, that’s a win-win for the engineers, the product managers and the whole company in the long run.
The outcome?
A transparent, seamlessly aligned and happy team setting the company up for success.
(Side note: If this is all new to you, and you are looking for the basics of the sprint demos, visit this link here to read more about it.)
Want more? Follow us here on Medium or me at LinkedIn to see how the agile team at Babylon conquers the challenges of a scaling startup.
