As consultants, a part of what we do is to give confidence, train and coach our clients in order for them to succeed in achieving their goals.

Succeeding can mean several things. Sometimes, it can be getting a project done or to implement new methodologies and ensure everyone in the team, department, group adheres to it. Other times it can be trying to build a product to innovate and open new business perspectives.

As part of OCTO’s consultants we recommend our clients to fail fast, learn and apply the learning.

How many times have we heard: “you can fail but it would be bad”, “innovate guys but we cannot fail”, “do what you want but we need to deliver this by this date”, “experiment as much as you’d like but this is a hard deadline” or similar sentences?

Failing should not be a problem when you have failed quickly and have learnt and understood why it occurred. Humans learn the fastest when failing, we stumble before being able to walk, we fall several times when learning to ride a bike before learning how to balance. XP Programming was created by people who failed several projects and were sick of it. Researchers often fail before moving forward in their findings.

At school we learn to learn and I think that in Software Engineering we should learn to fail and recognise it quickly and to learn from it.

Often it is a good thing to work with people who accept that you fail or experiment.

However, many organisations impose hard deadlines or request for the ‘perfect’ product in the first iteration which contradicts the idea of experimentation where failure is part of the process.

Then, how can we get out of this way of thinking: fail fast or experiment as much as you want but don’t make any mistakes in the end and meet this deadline?

Focus on a small problem not at risk for the business

First, a good practice is to understand what you are trying to create, what problem you are trying to solve and for who. To be able to do it you can either inspire yourself on the Lean Startup approach or run a framing with your users as well as your stakeholders and your team. Once you start understanding, try to split what you would like to produce in chunks and identify what could be the simplest version.

Being very focused on fixing a specific problem can help to sweep risks.

Then, you can try methodologies or technologies on some of these small subsets of product that are not risk for the stakeholders.

This will allow your team to experiment, measure and learn from their advancement while not facing business’ risks and not having too much pressure on the team.

Milestones and scope

Another good practice is to add intermediary milestones. These milestones would be short term realisable goals that would help to retrospect on what is being tested. Your goal in order to innovate and experiment should be to validate your hypotheses with your users.

There are potential scenarios:

• what is being developed is completed and successful - the stakeholders as well as the team will gain confidence. For future improvements in your product you should take into account your customers’ feedback.
• deadlines not met - some adjustments could be made and some learnings applied.
• it cannot be completed at the moment - the stakeholders and the team can very well decide to change plans.

These short milestones will help setup an incremental approach to build your product and step by step the minimum scope to fix your problem should be achieved.

Once you have reached the minimum solution and have validated your hypotheses, then you can continue to make your product grow.

A way to move the lines and be able to experiment is to give power to the team on the prioritization of what needs to be done as well on the set of features we wish to deliver.

The team may want to reduce the scope of features judging it adds complexity without enough business value to justify it.

Often, by working on a solution with a lot less risks for the business and by fixing short milestones we tend to focus on minimum marketable features. Doing so can help innovate and discover that our product might end being something completely different.

Risks are everywhere

Something that must be reminded is also the normal risks of the current projects in your organisation as well as the risks of not innovating. We often forget that the current processes and methods have risks too.

Highlight the journey, the learnings and the outcome instead of focusing on the output

On top of that you need to empower the people in your team. To do it, it is better to emphasise the journey instead of focusing on the result. If you learn and produce an outcome with real value but have failed on the way it is more positive than producing a result without real added value. Moreover, it is important to look at things on the bright side to keep the motivation and insist on what has been learnt as a team and for each person of the team.

Playing down failures is helpful to make the people working together confident and reach a state where what they will produce is the best they can.

We could also imagine that while experimenting the team needs to learn and be able to measure this learning as objectively as possible. The more the team learns the more it will be efficient over time. Putting some objectives on the learning curve of your team could also help it to experiment and improve.

Conclusion

Innovating and make your team experiment is a task that requires a lot of trust, energy and margin.

There are a lot of unknowns on these projects and difficulties appear from the very start of these projects with an underlying negative and paradoxical communication. This communication highlight some company culture issue that will make experimenting difficult.

Key takeaways

• try to focus on some very precise problem to solve
• fix short term realisable milestones where could be decided to stop or continue the project
• incremental milestones
• being able to reduce the scope in order to focus on innovation and experimentation
• KPIs on learnings and value gained knowledge
• play down failures