At Userled we love demo driven development. It keeps us moving at pace and continuously improves our direction.
We call it.. DEDRDE ! (We don’t)
Demos (duh!), every two weeks. It works best in teams working with fortnightly sprints or cycles.
In sprint planning we ask ourselves the question:
“what do we want to demo at the end of this cycle?”
The answer to this is completely up to the team, but it might be a combination of the following:
I first fell for demo-driven development at my previous job. We had the privilege of building a Mastercard issuer processor from scratch, with funding and talent already in place and only the problem left to tackle.
To be honest, we had no idea where to start.
Demo driven development allowed us to break down an overwhelming task, solving it piece by piece like a huge jigsaw puzzle.
We discovered, learnt and built together, celebrating each other’s efforts and constantly gaining satisfaction from our progress. We moved at astounding speed.
Without this, we would have spent weeks reading documentation, siloing disjoint knowledge and failing to apply it in context.
We would have written design docs, discussed and debated, and we probably would have built the wrong solution in a far longer time.
Demo driven development delivered.
We love feedback. We’re grateful to have an incredible community of users and design partners who work with us hand in hand to build the right product.
As an early stage start-up we feel the pressure! To enter the market, and to achieve product market fit as soon as possible - our success depends on it.
We believe demo driven development will take us there.
It enables us in every way; to navigate discovery, to resolve known unknowns and to realise unknown unknowns.
Most importantly it allows us to receive critical feedback - quickly and regularly.
But that’s not all.
Not only does it facilitate feedback and shape our product, it also provides structure to the whole team. In an environment full of ideas and potential tangents, direction and focus is absolutely critical.
Finally, it spreads knowledge, and allows us to celebrate every win - from the small fixes to the big releases.
It rocks our world.
Demo driven development best suits the discovery phase, where uncertainty is high, assumptions are rife, and experimentation is the only way to forge direction.
As teams grow and their products mature, it is natural to see a change in the way people want to work.
Maybe the most pressing features aren’t easy to demo, or are unsuitable for a non-technical audience. Perhaps too much tech debt has been allowed to accrue, or a tight feedback loop is no longer worth the cost of a high pressure delivery cadence.
Signals like these suggest that demo driven development is no longer the right choice.
Retrospectives are essential here.
Personally I find that fortnightly retros allow for teams to identify the need for change early, nipping frustrations in the bud.
Have you ever used demo driven development? What do you think?