Agile Development: Fail Fast, Validate Faster
Is it okay to "fail" in the world of agile development?
For most, failing is something we would rather avoid altogether. For every platitude about getting back on the horse, usually expressed to someone reeling from a recent failure, there is an inherent value in the learning from the experience. The pain of this growth, most acute when still smarting from a recent misstep, does subside as we move on and dare to look back at what went wrong. How can we apply this to the world of Agile development?
Much has been written about the concept of failing fast (and often) and can come across sounding like a bunch of Silicon Valley buzzwords. In a commercial and professional sense, failure is not an option (consider the airline pilot), however when applied to the world of Agile Development, minimising the scope of the failure and maximising the speed to get to our first failure point is a way of mitigating risk by taking a risk.
Fail Fast does not necessarily mean succeed slowly in agile development. A client with a limited budget and a tight timeframe may not immediately warm to the idea of failing your way through a project to achieve the desired outcome. However there are some strategies that can be employed to surface impediments before they become major blockers and help clients to further clarify their understanding of what it is they’re trying to achieve.
The Simple Method to Failing Fast in Agile Development:
Make a drawing! One quick way to achieve a shared understanding is to make a simple diagram of a workflow or wireframe. This is a low-overhead way of failing fast. The most thoroughly written User Stories and Acceptance Criteria arguably will never be absorbed as quickly as a simple drawing. By visualising an idea or concept it becomes something more tangible for the client to help quickly identify if you’ve gotten the point and/or spark them to validate their own assumptions. Dropbox is a great example of a concept sold with little more than hand-drawn wireframes.
The Sneak Preview: PO's Feedback & Agile Development Pivoting
Rather than waiting until the end of a sprint or project to perform your slick demonstration of the entire end-to-end process, demo each piece of functionality as soon as it has been developed. This method usually requires a complicit Product Owner to be present yet is a powerful way to validate if you’re on the right track or need to re-tweak. If the Product Owner’s feedback indicates that the functionality is not what they had in mind, then there is still time to fix it ahead of the big demo day.
Upping the Ante in Agile Development: Delivering the Prototype
Prototyping can range in complexity from non-functional interfaces to an integrated working model. Time is more critical when creating a prototype but will have the advantage of more expediently;
- discovering what does and doesn’t fit
- accelerating the learning curve of any 3rd party software you’re unfamiliar with
- emerging a clearer picture emerges of how best to implement
- provide a forum to solicit immediate feedback
The earlier client validation is received, the sooner adjustments can be made in the approach to the solution, risks can be surfaced sooner and consensus can be reached making for a smoother, harmonious delivery.
To quote Llewellyn Falco, owner of Spun Laboratories, “Agile is not a way to prevent us from making errors – instead it’s a way of reducing the cost of those mistakes.” Whilst it is not uncommon for a client to have their own assumptions challenged when presented with your interpretation of their project, the faster you can elicit feedback from them, the less chance there is of going off track. Using these fail fast strategies can go a long way in avoiding a fail big scenario. And that goes a long way for your agile development. We in ProQuest Consulting have experienced it time and time again, and we continue to further improve our process in order to deliver better solutions in less time.
