For most organisations the cheapest and easiest place to significantly improve time-to-market and end-to-end speed is in the fuzzy front-end. Smith & Reinertsen (1991) popularized the term to refer to the period from when an idea or opportunity is first revealed, to when a team is assembled to start work on realising the idea. The Fuzzy Front End usually consists of various tasks that are often done infrequently and in large batches, such as: strategic planning, budgeting, approval and allocation of people and other scarce resources. It is usually “fuzzy”, since the process is often unstructured, unpredictable and largely uncontrolled. In bigger organisations, great ideas can wallow in the fuzzy front end for years before they finally get the necessary political capital to become urgent and jump through all the necessary hoops – even though the cost of delay has typically not changed at all.
It’s easy to point out the problem. What can we actually do about it? Here’s five things to try:
1. Speed up prioritisation
The first thing needed is a way to quickly capture and triage ideas and opportunities, as they are revealed. How quick? A good goal would be to triage all incoming ideas or requirements (preferably evaluating the Cost of Delay and duration) in less than a week.
Once the requirements are triaged, they can then safely wait in an ordered list, sorted from highest priority to lowest. The balance to strike here is to make the triage fast and simple enough that it can handle all incoming demand efficiently. Attempting to do more analysis than is necessary to compare options will waste too much resource on lower-value opportunities. It will also slow things down significantly.
The bias in the triage process needs to be heavily weighted in favour of speed over any pretence of precision. The trap to avoid is the desire to “approve” or “reject” ideas at this point. This is unnecessary – simply focus on quickly sorting and ordering potential options as they arrive into a Dynamic Priority List (DPL).
2. Have one safe waiting place
The demand for product development capacity exceeds demand in every single organisation I’ve seen, so attempting to either scale capacity to meet demand, or squeezing demand in isn’t going to work. Generally speaking, long queues are bad – but not this one. This one has a very specific job to do and it is the only place like it in the whole end-to-end system. Ideas, strategies, initiatives, features and all manner of things we might want to do flow in here. This is where they are quickly sorted and put into a rough order – preferably in order of Cost of Delay Divided by Duration (CD3).
This priority order should be allowed to change dynamically as new ideas and opportunities are constantly flowing in. What makes this the only safe waiting place, is that it is cheap for options to get there and wait until capacity becomes available. We don’t want to spend a lot of time and effort getting to the DPL. The tendency to avoid at this point is to overanalyse and seek certainty through more analysis. To combat this, a good rule of thumb is that the information collected during the reveal/triage process should fit on one side of A5 paper. Think of it kind of like a user story – a placeholder for a later conversation. The objective is simply to quickly work out what the idea is roughly worth, how urgent it is, and roughly how long it would block scarce capacity in development.
There’s no restriction on the size of things in the DPL. Trying to restrict the size of ideas and stuff flowing in would just push analysis work upstream (and typically off the page). Think of the DPL as being the all-you-can-eat buffet with lots of options – different shapes, sizes, temperatures to suit every taste. (A Rodízio may be a better analogy). What the DPL should not contain is things that are ingredients (like flour). Everything should have some value, whether that be value to the organisation or customer, information value or option value.
3. Pull from downstream
This is just like in Toyota’s Lean Production System and is probably familiar to anyone reading this. To others may be unfamiliar, this can be very counterintuitive at first. In essence, don’t think about your system from high-level strategy down to releases. Rather, think about it backwards: from the point where you’re releasing an iteration or increment of your product or service to the market or end users. You want the system to operate with continuous flow as a guiding principle. This means you won’t be allocating resources (or people), they will be allocating themselves.
From a fuzzy front end perspective, the critical thing is to make sure that those who are refining ideas only pull from the DPL when they have capacity. Where this tends to get messy is when budgets and approvals are done on an infrequent basis – which drives the whole system in the opposite direction.
4. Limit analysis-in-progress
Don’t overproduce analysis – it goes stale quickly and clogs up the system, or worse. They need to be feeding the development teams Just-In-Time, using small buffers to control the flow. It can also be useful to limit analysis by putting a time-box on the amount of analysis: 2-weeks is a reasonable rule of thumb.
Something to specifically avoid here is attempting to document the analysis in order to “handover” to a downstream development process. Don’t do that. It’s much better to have at least one person who was involved in the original refining of the work available to guide the work all the way through the build, right to the point of measuring the result. The reason this matters is that the critical feedback loop that we want to speed up is actually Idea to Information. The speed of this loop determines how fast we learn. Cutting this mid-way through the build-measure-learn cycle slows down our learning. By following the work all the way through, they will also be best placed to understand the trade-off decisions that are made along the way and be in a position to quickly respond to feedback as the solution is developed and put in front of real users.
5. Breakdown incrementally
Strategic planning is highly perishable. The trap to avoid here is having the walls littered with the thousands of user stories that can come out of a single strategy or initiative. The hierarchical breakdown of work before it gets near the development team not only causes delays, it is also wasteful, since a lot of what gets analysed at this point is either not used, or needs to be substantially redone based on new information. Not all of those stories are of equal value either, with a power-law distribution of value.
Instead, no matter the size of the strategy or initiative, find one increment that a team could go and build something to either deliver value or generate more information.
Then build on that, incrementing and iterating your way around the parts of that cloud that are the most valuable. At any point, you should have the option to stop and still have delivered something valuable.
I’ve helped design and implement the changes I’m suggesting above in a number of organisations to help discover, nurture and speed up the delivery of value. You can read about one of them in the Experience Report we wrote for Agile2013 conference. If you want some help doing the same in your organisation, let me know.