Go For The Win

The “fail fast, fail often” mantra may NOT lead to a win in the world of digital transformation. Just like in soccer, your company must focus on the desired outcome (scoring goals) to win.

The mantra “fail fast, fail often” is a rallying cry for technologists pushing organizations to become more Agile, more Lean, and to push teams to deliver faster. What is being delivered and how valuable it is long term, however, tends to get lost in the shuffle and “fail fast, fail often” can lead to a big fail when there isn’t a clear goal in mind. 

The 2019 FIFA Women’s World Cup was held in France and if you’ve watched any of the games, one of the statistics talked about is time of possession. During the course of a game, teams will drive forward to test an opposing defense, then pull back, sometimes all the way to the goalkeeper, and try again. However, as soon as the defense has adjusted and passing lanes are open the offensive side is on the attack again working towards the desired outcome: Score a goal.

Fail fast, learn often may not lead to a win in the world of digital transformation. You don't win if you aren't focused on taking shots at the goal. The first step is defining the desired outcome.
Fail fast, fail often may not lead to a win in the world of digital transformation. You don’t win if you aren’t focused on taking shots at the goal. The first step is defining the desired outcome.

In April 2018 Sunnie Giles, a Forbes.com Contributor, posted an article: How To Fail Faster – And Why You Should. She states, “In today’s complex business environment, where things are changing constantly, speed of execution is a lot more important than perfect execution.” She points to a concept of iterations creating positive autocatalytic feedback loops which eventually leads to radical innovation. This is a pretty common view from many leadership teams on how they want to push their organizations forward.

Radical Innovation

The words “radical innovation” stuck out when I read the article. I have had the privilege to work with a number of organizations throughout my career. In some cases, the leadership inside the organization coveted innovation and spent a significant amount of time and money building up innovation teams. The opportunity to drive the business into adjacent markets, new markets entirely, or to refine their existing market offerings to expand the organizations hold on a market. More often than not, the “radical innovation” introduced by leadership was either cut off from the rest of the organization or was actively under attack by more established parts of the organization and in the end, not effective in achieving the original business objectives.

Teams get locked into playing possession and lose focus on moving down the field and scoring a goal.

7/2/2019 World's Cup Score: England Vs. USA
Above is an illustration of losing focus. In last week’s game, England had more possession, more passes, and better passing accuracy, but because they didn’t attack they lost the game.

Why? Executives jockeying for power, friction between “the way we’ve always done it” vs. “the new way we want to do it now,” shrinking budgets, changes in priority to shore up existing market share. A large number of different factors all branching from a common thread: a lack of focus on the desired outcome. Teams get locked into playing possession and lose focus on moving down the field and scoring a goal.

Four Steps to Fail Fast AND Achieve the Desired Outcome

How do you prevent getting locked into playing possession? At Trility, we break the process down into four distinct stages: 

1. Discover
2. Definition
3. Implementation
4. Evolution 

Each stage in the process has a clearly defined outcome to help ensure stakeholders can see the value along the way. Often companies are eager to jump straight to the Implementation stage and the “fail fast, fail often” mindset can achieve the discover and define stages – thus the desired outcome along the journey. However, unless you know where the goal is your team is just playing possession.

Don’t Forget the “V” in MVP

Security, operational readiness, reproducibility, and scalability are all important parts of any product, which helps validate the viability of a product. Unfortunately, in the race to production these items fall by the wayside and show up on the backlog.

Securely develop products

Minimum Viable Product, or MVP, is a common term used by business leaders and product owners to help drive quick, iterative, product development to get products released to market faster. The goal is to release just those core features necessary to put the product in front of customers to learn about customer needs and validate assumptions prior to larger investments in a new product. Release quickly, release often, and adjust the product based on feedback from customers.

Product teams today do a great job of focusing on the M, Minimal. Constantly asking the team and business stakeholders when new feature requests are made, “Is this a requirement for MVP?”, helps prioritize development efforts and keep the team focused on making a timely and relevant release. Business stakeholders on a regular basis can see the features being developed during frequent demos and can provide direct feedback which goes back through the same intake process grounded by the same question focused on releasing the MVP. When the cycle is managed by a proactive Product Owner, it can be an extremely efficient way to get ideas from a napkin at lunch to a product in front of customers.

Where Product teams struggle is with making sure the V, Viable, is taken into consideration as a team. Security, operational readiness, reproducibility, and scalability are all important parts of any product which helps validate the viability of a product. Unfortunately, in the race to production these items fall by the wayside and show up on the backlog. When the team does release the product and receive customer feedback, they’re often stuck in a challenging position of either picking up the items in the backlog tagged as After MVP or continuing to refine the product to keep customers engaged. As it should, the focus remains on the customer and meeting the business objectives for the product. The weight of the backlog eventually causes cracks in the team, cracks in the product, and a new round of questions for business stakeholders to consider regarding whether to refactor, rewrite, or sometimes, a new MVP to fix the problems from the previous MVP.

Continuous Integration, Continuous Deployment, Security by Design, Test Driven Development, Performance Testing, Infrastructure as Code – these are all terms many development teams are familiar with and actively promote inside organizations today. However, many of these items are the first things added to the backlog during MVP development when teams are racing against the clock. We need to do a better job as Engineers communicating to business stakeholders that each of these items are individually, and collectively, an important part of making a product viable.

We can still meet the needs of a minimal product by constraining the conversation in each case to the product being developed. The product may not have a need to support a thousand requests a second for the MVP, but we should ensure performance testing frameworks are in place and exercise the product on a regular basis so issues can be discovered early and often during the development process. The product may only require a small amount of simple infrastructure to be deployed to support the MVP, but the infrastructure should be built and deployed in code alongside the rest of the product so as needs change the foundation is already in place to support rapid growth. The product may not have a requirement to support a security standard for the MVP, but the application should be built following a set of standard security practices and validated regularly with automated testing to support a growing customer base. 

Viable – the ability to work successfully and securely.

Product teams need to ensure when MVP is defined, the product’s ability to work successfully after release is front and center during the development process. Minimal helps you get to the first release; Viable ensures you make it to the second.