Every project has a backbone of facts and known goals. Usually there is a known code base, a set of business requirements of where the project needs to go, perhaps some usability information, feedback from customers, previous test cases and other assorted artifacts that help set the project in motion. But projects always contain a large set of unknowns, either technical or usability based.
How will this service interact with another service?
What does it mean to move from an on-premisis to a cloud solution?
Will the users understand this new interaction?
How do items outside of our control, like a changing device ecosystem or new user-centric features developed outside of the project, impact what we’re doing?
This uncertainty is what quickly paralyzes projects, encourage repetitive meetings and lead to companies building “silo” solutions without efficient group collaboration. This specific uncertainty is precisely so dangerous because it is often misunderstood. Every project carries with it unknowns and risks, and it becomes the approach teams use that determine if it will be successful or a failure.
Successful projects have the path forward known early, are easy to communicate and understand, and produce continual demonstrations of their progress.
Failing projects become so rigid that they refuse to engage and adapt to the world around them… or are so flexible and course-changing that nothing significant is ever accomplished. In both cases, they are extremely complicated to communicate to others.
Enter the concept of failing fast.
“Failing fast” is not Agile. Or Lean. Or Pull Planning. Or of any other recently documented process. Failing fast a way forward when facing the unknown. It’s a strategy of how to take that first step when where that first step leads isn’t straightforward. The point of “fail fast, fail often” is not to fail of course; it’s to learn what you don’t know, turn risks into action plans and to deliver quality faster.
Failing Fast has become synonymous with startup culture, partially as a strategy and partially out of pragmatism. Larger companies have similarly come to understand that despite cash reserves and a dominant position in the market there is still significant benefits to determining the longterm viability of a product or strategy, rather than proceeding cautiously and investing years in what may be the wrong outcome. Successful companies want to stay successful, and they jealously guard themselves against the nimble upstarts that want their position.
In schools what we didn’t know was understood as we entered the classroom. Students are present to learn, and the psychology behind the need for the lesson and transfer of knowledge is accepted as given. In the workplace, the waters become murkier. There is an unspoken expectation (real or not) that workers must somehow understand the unknowns from the moment they step into the door. This is impossible and unrealistic, but this simple misunderstanding drives behavior that leads people away from ever admitting to a “fail fast” strategy, and instead struggle against or ignore the unknowns until too late.
Success of projects is often dictated by being able to quickly surface the risks, the problems and the uncertainty… in short, all of the negative aspects of a project that many reject talking about in the first place. It is hard to lean into a belief that to be run a successful project you must first understand how you can fail, but it is this basic risk assessment, or failing fast, that is the best strategy a team can have.
What “Failing Fast” can provide:
- Visibility into new initiatives earlier, giving the opportunity for other groups to participate.
- Vet existing solutions and increase the chances of reuse rather than rebuild.
- Receive feedback from your customers rather than yourself.
- Discover system vulnerabilities your testing isn’t equipped to handle earlier.
- Pivot from incorrect architectural decisions before heavy investment is made.
- Provide more accurate schedules and predictability into the development process.
- Understand gaps in team knowledge or capability quickly, and create the opportunity to retrain or educate.
But “Failing Fast” can also be misunderstood. Failing fast does mean simply “going faster” or “working harder” as much as “understanding risks and being iterative”. Generally speaking, understanding risks and having better data at the start of a project does lead to a quicker schedules… but that isn’t the primary goal of a “fail fast” strategy. If leaders believe that by implementing “fail fast” automatically generates a reduction in costs with higher efficiency they are misleading themselves and setting themselves up for disappointment.
What “Failing Fast” is not:
- A way to get employees to work faster/longer hours in order to produce more output.
- Removing the need for proper testing or product management.
- An opportunity to reduce headcount by quickly identifying failing employees.
- Removing quality testing as a requirement and shifting that burden to the end-customers.
- Standardize all development into a single, monolithic process.
- Living in perpetual “beta” mode.
At the end of the day, “failing fast” can be summed up as obtaining knowledge you don’t currently have, faster. It pushes teams to create simple proof of concepts designed to prove (or disprove) the goals of the project. To reveal that which is unknown and not able to be discovered in a meeting room or a JIRA ticket or a story review. To push team members to explore other options, particularly the ones already in their company, as a means to achieving the goal.
I always advocate strongly for teams to adopt a “fail fast” approach to avoid paralysis, software fragmentation or iteration by committee. It does require a cultural change in a company, but can be explored and implemented with minimal disruption to an existing organization.
In the end, who doesn’t want to better understand their risks and how to move past them?
