Agile suggest that teams should fail-fast to enable quick learning from mistakes. Learning from failure is one approach, you can also learn early and fast from successes, by doing experimentation, or by using a plan for knowledge acquisition.
In the blog post stop failing so fast, Sami Honkonen explains why the goal is not to fail but to succeed:
Failing fast doesn’t actually mean you should aim to fail fast. Failing fast is easy. It’s failing fast and well within the context of trying to succeed that matters. If you’re not even trying to succeed your experiments are meaningless.
Experiments can help you to learn and increase the chance on success, as Sami describes:
When we learn to deal with mistakes productively they become a tool. To test an idea (or an assumption within an idea), we design an experiment, we act confident that the assumption is true and give it a shot as if we already knew it will work. If it does work, perfect. If it doesn’t, we learn from it. Rinse and repeat systematically.
Jerry Neumann states that you can't learn from failure, you can only learn from success:
Any complicated system is too complicated to learn from failure. Yes, you can learn a few tricks, like: "don't spend all your money on fancy chairs" or "don't hire your college drinking buddies as EVPs of Business Development." But you can also spend your life learning about every mistake every startup founder ever made in all of recorded history and I guarantee that when you start your company you will discover all new mistakes to make. (…)
You should be spending your time trying to learn from success. The successful entrepreneurs I have known have had the ability to look at a failure, any failure, and pull out the couple of things that were done right. These are what they focused on.
“We learn as much from our successes as from our failure and I suspect we learn much more” said Bruce Nussbaum. In his blog post stop fetishizing failure he proposes a “play mode” to deal with problems and to learn:
Failure is usually associated with problem-solving. There’s an assumption that there is one right problem with one right answer and if you can’t get it, you fail. But what if you don’t even know what the problems are and there are lots of ways of dealing with them? I prefer the Play mode of dealing with challenges. When you play, there are rules but they change as you play the game. There are different outcomes to playing a game, different ways of winning. When something doesn’t work, you try another. You do work arounds. Is that Failure? I don’t think so.
Michael Plishka shared his thoughts on playing as a way to learn faster in his blog post innovation – it was never about failure. His view on learning from failure is:
Failure, as Nussbaum points out in the above article, is indeed painful and can be limiting. There is a finality to the term failure that is unforgiving. When a bridge ‘fails’ it goes down and people get hurt. When there’s a power ‘failure,’ electricity simply isn’t there. Failures are an absence of success, and as voids they carry no information other than there’s no success to be found there.
And his view on learning from success is:
Success (…) is (…) not educational at all if things work and we don’t know why they work. We’ll go along happy as larks thinking all is well until things go bad.
If we don’t learn from failure nor from success, how do we learn? Michael wrote:
We learn from probing, through curiosity, tinkering, experimenting. The instant we allow there to be voids of ’failure’ and ‘success’, there is no possibility for learning, for growth. It’s only when we step back and ask, “Where am I going? How will I get there? How does this event help or hinder the journey?” that design/innovation can occur.
Al Shalloway reminds us that failure is not a goal, and suggest to focus on learning quickly in his blog post why I hate “fail fast” and “good enough”:
No matter how you speak about it, failure has a negative connotation. We don’t set out to fail No one is proud of failure, although we may be proud of overcoming failure. The mere term “fail fast” implies we don’t want to fail slow – we want to get through the failure as soon as possible. The truth is, what we really mean, is to learn fast. To correct quickly if we are off course. That we don’t even consider going off course a failure. With this attitude we actually never fail. Fail fast is not our goal. Learn fast is.
In stead of having failures and learn from them, you can plan to learn as Alistair Cockburn describes in his report how “learn early, learn often” takes us beyond risk reduction where he explores approaches to learn earlier during product development:
The problem is not that learning doesn’t happen in the ordinary approach, the problem is that the learning comes at integration and again at sales, i.e., late. These are often the first moments when the team members are forced to put their ideas together, and the first time that the customer, user or buyer gets to see the new system.
He mentions four categories of knowledge that projects need to acquire to reduce risks during development.
- What is the right thing to build.
- How much it will cost to develop.
- Whether adequate people are on the team, and how they best work together.
- Where their technical ideas are flawed.
To support learning earlier, activities need to be included in the project plan. Alistair describes how this impacts the project plan:
The old-style, and still frequently used, project plan is a list of the tasks to be performed to construct the system. An effective, rapid and low cost planning method of this type is “Blitz Planning” [AC-bp]. This conventional project plan still provides a good starting point, serving to peek ahead at what is involved in developing the system and delivering approximate size and difficulty for the effort.
The more recent, agile-style project plan is simply a list of all the features or user stories [W-us] to be built in a single list, usually with the highest business value item placed at the top of the list (see above for the reasons this may not be the best order to place them in).
The knowledge-acquisition approach, on the contrary, starts with a brainstorming of the four categories of knowledge needing to be acquired, along with the starting set of features to be delivered, making five categories of possible work efforts. These are artfully interleaved into a sequence of work assignments designed to reduce risk, deliver crucial information, and develop product capability in an “optimal” way.
What have you done to learn early and fast?