The Folly of Fail Fast ... We are here to SUCCEED MORE!

Fail Fast is a popular phrase beloved by entrepreneurs and wannabe companies as well as by large serious outfits trying to modify their big corporation DNA.

"Fail fast" or alternatively "fail fast succeed faster" or "fail forward" or even "fail better" is trying to tell us that it is better to get customers to experience your product and to learn from their feedback and from your mistakes. These conclusions drive a rapid review and improve phase where you can make the necessary changes. In many cases a worthy message.

The message is that this is preferable to lengthy planning,  development and refinement cycles in the office that don't involve the customer. Tirelessly looking for the ultimate product or ideal user experience. In many ways the idea is very similar to some of the Agile philosophy.

I am a huge believer in meeting the customer early and often and subscribe to much of the logic about doing, learning and improving, but, I have some issues with the fail fast slogan and even with some of the fail fast concept.

Let's deal with the trivial one first. There are many cases where it just doesn't work, I hope that Boeing and Ford for example don't embrace fail fast! 

However, in a broader sense on any business there are times when you can't afford to fail, because it ruins the positioning and reputation or because of budget. Let's accept that quick customer engagement is not an excuse for bad product design and implementation. Sure work quickly, cut red tape, be passionate about delivery but do the job right.

Now for my bigger issue, failure means getting it wrong and messing up. This is never a healthy, positive message it just sets the wrong tone and is a poisonous attitude to bring to work. It suggests that sloppy poor incompetence is suddenly acceptable. We can do it wrong and fix it in the next development cycle - no problem, nothing happened. 

We should remember that "perfection is the enemy of good" (Voltaire) or "Give them the third best to go on with; the second best comes too late, the best never comes" (Watson-Watt on Developing Radar during WWII)" These principles mean that we need to do be quick and achieve "enough" or in Agile terms MVP (Minimal Viable Product) so there is often no practical room for the dogged pursuit of perfection. We need to develop something that is at least fit for purpose. But we are not embracing failure as an option - just limited success.

When I googled the phase fail fast I can across a Wikipedia entry about system resilience. This is a more positive message, we need to build our product and we need to succeed and survive even if things aren't quite right.

Let's embrace efficient working practices, early customer engagement and let our people know that sometimes things do go wrong; so do your best to prevent this, but we understand and accept that it may happen. It is unfortunate and undesirable but failure is not our philosophy nor is it our core competence. There will be no blame game as long as you have tried very hard to succeed. We are a success orientated company.

Let's just Work Fast and Succeed More

Optimal Length of Agile Sprints

Agile is a popular development methodology sometimes it seems to be the only method in use today.

At the core of Agile is to break work down into small chunks that can be managed by the scrum team in a short period of time known as the sprint.  Ideally the sprint delivers some or several useful functions that can be shown (demo) to stakeholders and ideally to customers in order to gain feedback and to change and improve as quickly as possible. This objective is often to deliver MVP or Minimal Viable Product although this is in our experience often beyond the realistic scope of a single sprint.

The idea is that the team commits to a given quanta of work that can be experienced by the customer and get quick feedback. It also allows flexibility to change direction or priorities of the overall development.

In our organisation one of the big questions is the ideal length of the sprints.  

To set the context most of our development does not get released to customers on a one or two sprint basis. We use sprints as a meaningful checkpoint and as a way of involving other teams, stakeholders, sponsors and management.

Previously we used three week sprints and in this specific business unit the custom has been sprints of two weeks.  We are now in the process of moving to three weeks; partially at my initiative.

The reasoning is that two week sprints are valuable when the output does get delivered to users and especially if it is user interface rich. Fast work and rapid feedback and intense market dynamics seem to fit in this context.

However for work that develops over time especially with a lot of infrastructure or core development then there are many disadvantages to short sprints.

Agile sprints have high overheads in each and every stage of  preparation, execution and post sprint analysis (Discovery, Pre-planning, Planning, Retrospectives etc.) There is also management overhead in driving an organisation with several projects each with short sprints and low capacity. Overall these overheads that amount to high costs that the organisation can not afford over time. Longer sprints have lower overhead and so are more efficient. Our analysis indicates that moving from two to three work sprints cuts most of the overhead linearly.

Shorter sprints present a challenge in trying to deliver real value (MVP or MVP-like) even more so if the team is quite small. It is perceived that the small capacity presents its own challenges in preparing and planning the sprint trying to customise the business needs to the limited time.

Another critical issue is the vulnerability to planned and unplanned absences. It only takes a couple of days vacation, course or sickness to wipe out the content of a sprint. Bugs, tricky integrations and environment issues have a similar disastrous impact.

Finally, short sprint cycles place a large demand on the Product Manager and his team. The cycle times are so short that there is never any time to pause and consider the bigger picture and to research new ideas and future directions. Again we think that there are almost linear savings available by increasing the sprint length.

Overall short sprints are considered expensive, hard to plan and prone to delay. Our analysis indicates that three  week sprints are a better balance of flexibility (Agility) and efficiency.