Some months ago I placed an order for several books at Amazon. A few hours later, I got an email from Amazon informing me that one of the books was no longer available and that I could either get the order without the book or cancel it. I decided to cancel it because the missing book was the one I wanted most.
What happened here? Amazon had been analyzing my order and their capability before committing to deliver it. This phase is what we call The Fuzzy Front End. When you place an order to Amazon they are not committing to deliver it until they send you the email confirming it is being shipped, before that point either Amazon or you can cancel the order.
In manufacturing The Fuzzy Front End is not that fuzzy. Some sort of economic and market analysis are made, then designs. When designs are ready you send it to the shop floor for manufacturing. This is where the real commitment happens, when most people and resources are allocated for building or producing something.
But in software development and other knowledge work The Fuzzy Front End is really fuzzy. Many people tell me “we are doing Scrum”, and I say “Yes, you are doing Scrum, but your company spends one year before an idea gets into the Sprint Backlog of a development team! Very agile!”
The Fuzzy Front End
Each month of delay has a quantifiable cost of delay. Our goal is to find opportunities to buy lead time for less than this cost. These opportunities appear throughout the development process. There is, however, one place that we consistently find the least expensive opportunities to achieve large improvements in the time to market. The Fuzzy Front End.
When markets are predictable and the cost of delay is low it might make sense to adding checks, stage gates and a lot of analysis to this stage. However, in fast moving markets when the cost of delay is high quick decision making shortens your planning horizon. On projects with a high cost of delay errors in opportunity selection may be much less expensive than starting a project late.
Why is the Fuzzy Front End so important?
- It is a lengthy stage. In many companies the Fuzzy Front End is guilty for more than half of the time-to-market
- It is full of cheap time-compression opportunities. The idea that to improve time-to-market we must improve development processes is still widespread, but I’d recommend to analyze front-end processes first of all. This is the place where buying time is cheaper
- This stage usually consumes a small amount of the development budget, but it constitutes a large portion of available cycle time. The most important cost of the Fuzzy Front End is the Cost of Delay, not the cost of the people assigned to the project.
The Market Clock
The market clock is unforgiving. It keeps on ticking whether we are working on the project or not, and with each passing minute we pay the cost of delay. This cost keeps accumulating steadily even when nobody is working on the project.
The Urgency Paradox
This is tendency of the urgency of product development to be highest at the point in time when the market opportunity is lowest. Early in the life of a project there seems to be little urgency. Although the market opportunity is greatest at this time, the opportunity is not too apparent and there is little fear of competition. But, when the opportunity gets into a team’s backlog pressure starts increasing. And all efforts are put into sub-optimizing development while this is a tiny part and probably the most efficient of the whole process.
What is going on during this stage?
During this fuzzy phase organizations are trying to determine to what extent they want to commit to develop an idea. In agile companies the Product Owner with specific help from the development team is going to be dealing with this phase. The more bureaucratic the organization the longer and more people involved in this phase: product management, finance, engineering, project management, marketing, sales, …
For instance, if you are doing Scrum the Fuzzy Front End would include anything that happens to an idea before it gets into a Product Backlog, plus all the work done before it gets into a Sprint Backlog of a team (Commitment Point).
What I find in many companies, even those adopting Agile, is that their discard rate is close to zero. So, there is little value in the front-end process.
Typical tasks done at the Fuzzy Front End:
- Epic Definition
- Splitting Epics into User Stories
- Refine understanding
- Calculate Cost of Delay
- Solution alternatives
- Cost estimate
- Business case
- Technical risk assessment
- Market risk assessment
- Economic risk assessment
- Financial projections
- Market research
- Product specification
- UX research
- Visual Design
- Go/No-Go decision
How can you improve the Fuzzy Front End?
In Kanban we refer to The Fuzzy Front End as Upstream Kanban or Discovery Kanban. You name it. But, if you want to improve you need to apply the six core practices of Kanban to your front-end processes and link it to your development processes.
This is a consequence of the previous one. By getting metrics you can improve a system, if you don’t measure it won’t spontaneously improve.
We begin by measuring the duration of the front end, because Lead Time is the parameter of greatest economic importance here. To measure Lead Time, we must agree on what marks the beginning and end of the Fuzzy Front End.
- The idea must be documented as an opportunity
- The technology to implement the idea must exist somewhere in the world
The second condition is important because it marks the critical distinction between product development and technology development.
The real end of the Front End is when substantial numbers of people start charging time to it. So, when the team has been fully staffed, since little will happen without a team in place.
Create Technology and Marketing Infrastructure
Too often technology development and market research are unnecessarily on the critical path of product development. This causes these activities to add enormous delay costs to the project.
If new technology has to be developed, it is wise to make this a separate phase of the project.
We can use a similar approach for market research. Instead of viewing market research as an activity that occurs as an early step of product development, view it as an ongoing activity. To understand our customers, their preferences, our product applications, competitor products and market trends should be an ongoing activity. We need to develop a base of market information independent of any specific new products.
Make somebody responsible for this portion of the development cycle. What happens in big companies is that a lot of people from different areas are involved in this phase. So, no one is really responsible.
Scrum solved this issue by giving most of this responsibility to the Product Owner, but still many things happen that are outside of the control of the Product Owner.
Customer Lead Time and System Lead Time
In Kanban adoptions we differentiate between Customer Lead Time and System Lead Time (Local Lead Time).
- Customer Lead Time is the time the customer cares about. The time from when the order is placed until the delivery is done.
- System Lead Time or Local Lead Time is the development time, from commitment point until delivery. If you are doing Scrum, this will be the elapsed time between a ticket gets into Sprint Backlog until it gets delivered to Production.
Teams typically worry about their Local Lead Time, but who cares about Customer Lead Time? This is one of the issues I find in many companies, there is a pressure for teams to deliver, but nobody cares about all the stuff that takes place before.
At some point, someone will be asking: “When is it going to be done?” or “Can we get this by date X?”. And we have to be able to answer to that properly. If your system is unpredictable and you are not gathering proper metrics you won’t be able to answer to that. And estimates with story points is not an option 🙂
In my next post I will be talking about predictability in Kanban systems and how you can stop estimating and start forecasting.
If you need help, contact me!
The content of this blog post is in part extracted from three books by Donald Reinertsen. If you work in Product Development, Software Development, Marketing or Engineering you must read these books:
- Managing the Design Factory
- Developing Product in Half the Time
- The Principles of Product Development Flow: Second Generation Lean Product Development