Or why I believe you should front-load your early sprints with prototyping.
As you’ve probably gathered, I’m a fan of prototyping.
There is a popular meme ‘A prototype is worth a thousand meetings’ and whilst a bit glib it holds weight. Rather than explain, a good prototype can show. Explanation is often open to interpretation, showing how things work, or how you intend them to work with something physical is less so.
The benefits of prototyping are multiple. Untested hypotheses are just assumptions even when backed by the best data. Prototyping both UX & functional, allow the team to rapidly prove (or fail) learn and move on, which is at the heart of what we are trying to do. After all you want to discover early if a feature is viable or not.
Don’t discount the benefits in checking shared understanding of requirements. I’ve been on a few projects where everyone’s reviewed a feature story, dutifully nodded worked out implementations details and then built something quite different from the intended feature.
From a pure cost benefit point of view, you want to focus your efforts on the right features, and only the right features. How many projects have you been part of where you ‘solutionise’ early, it all seems so simple on paper, only to realise too late its not going to work. Prototyping is no silver bullet, but it does allow you to apply early testing and rigor, usually to high ticket items, and discover quickly whether you’re on the right track.
There are many ways to prototype and I’m not going to step through them here, just find something that works for you. The ideal is that the prototype forms the framework (working code) for later iterations and improvements, but I accept that’s not always possible or in the case of a really contentious area and throwaway prototype – undesirable.Whatever you do do it early.
I define a contentious area as any feature where we have a high degree of uncertainty around approach\benefit\how to achieve the desired outcome; and it often comes with the baggage of interested parties having some very conflicting views.In other parlance your riskiest Items.
Conversely it is often the riskiest items that can have the biggest payoff if you get them right. This is where prototyping comes in, you need to embrace the challenge and prototype early and often, don’t be afraid to front-load your early sprints, it will definitely pay-off.
I cannot emphasise this enough, early is the absolute key here. When the team reviews and builds the high level feature set and story map, physically mark the contentious areas. Don’t fool yourself into thinking the team don’t know these, they do, they’re usually the elephant in the room. It’s imperative you discover and work on these early as they always have the potential to derail any project.
A sign of a mature team is the ability to openly discuss, critique and argue passionately about features, functions and design without it becoming a personal whinge-fest. This is something you should always encourage. A prototype can help the team to focus on a physical entity rather than someones idea and their interpretation of it. I’ve often observed that whilst disagreeing with a point of view, people are far more likely to work with and tinker with a prototype to try and demonstrate their point than dismiss it out of hand.
This whole process can sometimes sound like mini-waterfall, where we prescribe detailed solutions up-front, but it isn’t. We still leave plenty of room for the detail, design and improvements to emerge. With prototyping we are trying to fail fast, apply what we’ve learnt and move on, not prescribe the approach in minute detail, and don’t forget we’re focusing on the contentious areas only, not everything else.
You’re simply not facing into reality if you don’t tackle contentious areas up-front, it’s all about building a shared understanding of what you are trying to achieve and understand that these often pivotal features can inform and influence the rest of development. Why can’t this happen organically through the project? Well it certainly can, I just tend to find the later this happens the larger the potential impact on the project. And if you allow me to sully this post with a PM’s point of view usually an unfavourable expectation has already been set with Stakeholders.
Why not boil the sea and prototype everything? You could argue that development in Scrum is about prototyping everything. You build and iterate, but that’s a cheap answer. Some features just don’t need it; it’s not a free activity, focus on the areas that do need it.
Should prototyping be limited only to early sprints? Absolutely not, Prototyping is a very valid and key activity throughout the project, but I advocate focusing on the contentious areas early to get maximum benefit. After all nobody wants to code something no-one wants.
If theres any interest I’ll probably write a follow-up post on how we run different types of prototyping (its certainly not one size fits all) and how you can incorporate a design\discovery sprint until you get good at it!