There is a myth around Fail-Fast agile concept that it is a license to fail as long as you are learning. Yes, it does seem like a fair trade-off - when your agile teams are failing they are also learning and improving. However, it should not be taken as an excuse to fail or take the failure itself lightly. We need to consider HOW we are failing. Fail fast cannot be attributed to the fact that the team just cannot code or test properly, that’s bad team formation and we need to hit the planning board. XP does not prescribe fail-fast, we don’t prepare for failure. The teams play full out to win and accept responsibility for the consequences. Fussing too much about failures and consequences can distract you from your goals. We need to remember that the only thing that all you can control is your own behaviour. You can't control others expectations but it is upto me to do my best and to communicate clearly.
There is always a COST attached to failure if not blame or stigma. Stigmatizing failure is a mistake and it won’t lead to any innovation. Whenever a sprint fails while trying something unique or experimental, it will help you learn and evolve. But make no mistake, the sprint has costed the client with no real product increment. Failure of a sprint will also take into account the cost perspective, let’s make it Fail-Fast Fail-Cheap.
Stigmatization of failure hinders innovation
It also matters WHEN you fail. Failure as part of initial sprints could be managed especially if you were anticipating it, considering the extent of experimentation you were going for. We need to experiment in a controlled environment while keeping cost in mind. Having said that, there are end-game sprints, for example, in the sprint which is going live, we cannot afford to fail. So, this makes it Fail-Fast Fail-First Fail-Cheap.
In the current market scenario, customer experience is the key. Businesses need to ensure that the quality is in sync or exceeds customer expectation. Hence, it is crucial to achieve First-Time-Right as the customer forms an opinion of a particular application as soon as he or she opens it. Customer loyalty resulting out of his or her first impression, once lost, is difficult if not impossible to regain. This means that businesses cannot afford to ship something that is incomplete; they have to get it first-time right.
Lessons learnt from failed sprints can empower the team
So that's a pretty good reason why assuring first-time right is so important for businesses and Fail-Fast Fail-First Fail-Cheap can be utilised to ensure quality and innovation. It would be a big problem if we are not able to capture the failures and leak this to releases. This is also why shift-left helps put quality at the forefront everyday activities, how everybody should look at quality as part of their everyday job. That's the reason why this and other aspects of shift-left are helping businesses deliver first-time right, every time.
SAFe is based upon Lean and Agile principles and encourages experimentationand continuously evolving design and architecture.
Out of the 9 principles of SAFe, my favourite happens to be Principle #3 – Assume variability; preserve options. This introduces a major paradigm shift when it comes to innovation and experimentation. This guides us to move from single option point-based approach to set based approach where we do not discard options and preserve them such that to their usage in potential solution space, keeping respect for the unknown. We get these options from what some may call as Failures from the past, in SAFe these are simply options that we have and if needed can be utilized down the line for our set based approach.
This is driven by the fundamental aspect of SAFe that is called as the Innovation and Planning iteration. SAFe puts forth innovation and planning as an iteration which provides a regular, cadence-based opportunity, at the end of every PI, for innovation and exploration and dedicated time to go beyond the delivery towards improved collaboration, and brings creativity to the table. Innovation Planning iterations, Ship-it days and Hack-a-thons promote spontaneous breakthroughs which can help teams identify and rectify challenges in their iteration objectives. Any experimentation, in terms of software, coding practices or even architecture, for the next iteration can be included in the IP iteration so as to reduce the unpredictability of the iteration. This will help teams keep a tab on the COST of failure due to experimentation.
As an Agile Coach, mentor and trainer, Ashish Mishra works with organizations to empower development teams to deliver value to their customers with dedication to quality. Ashish is a key member of the Temenos+Agility team, bringing his vast experience in enterprise transformation to the table.