Something we often create as part of our discovery phases of work is what’s known as a ‘walking skeleton’. It’s a term that’s little understood outside software development, but it can be an incredibly powerful tool for demonstrating the viability of a piece of architecture. So what is it? In essence, it’s a very simple, yet working, proof of concept that executes an end-to-end process to demonstrate how something may work in practice. It is a ‘skeletal’ version of a system – bare bones functionality will be included only – but it is executable, hence ‘walking’.
How is it different to a Minimum Viable Product (MVP)?
MVPs are usually customer-facing products that feature all the functionality required for users to complete their tasks. They can then be built on further using an agile framework, with new features and updates being rolled out in a regular schedule (usually weekly) based on both the development roadmap and customer feedback. Walking skeletons are not customer-facing, they are merely for internal use to test concepts and show the viability of ideas.
At what stage of a project is a walking skeleton created?
Very early, usually as part of the discovery phase, but they can also be created throughout the life of a project as more development ideas are generated to ensure only the fittest make it onto the roadmap.
How do you then build meat onto the skeleton?
Once complete, the skeleton is then fleshed out iteratively; in general, the features are built up to a point where it is transformed into an MVP or beta. It is often helpful to move the skeleton onto a more traditional MVP quickly so that you can start testing user interactions and refine them as necessary. Usually, this bit doesn’t take very long, particularly if you have a set of “tolerant” users who can deal with beta-level product testing.
How have 67 Bricks used them with clients?
Most recently, we have used this approach with our partners at De Gruyter while developing their new content platform. Using this approach built trust between the team at 67 Bricks and De Gruyter, not least because the development work was completed in a few months and the resulting site was fast and stable.
What are the benefits of the walking skeleton?
Using walking skeletons as part of your development plan can reduce the number of unseen issues later down the line. By developing architecture piece by piece and slowly layering on more features it’s easier to test for and solve any arising errors. And if things do go wrong, or new requirements are unearthed, they allow the development team to iterate rapidly and change their approach.
They can also be a fantastic help to bring non-technical stakeholders on board with a project – instead of describing what it is you want to create for your users (and therefore need budget for!), you can show them in a very quick and cost-effective way.
Finally, if you have competing priorities, building walking skeletons can show you which ones have the most impact on your users, helping you to decide which areas to develop first.
Have some ideas you’d like to test? Get in touch with our team to see if a walking skeleton would work for you.