The whole systems view and deliberate discovery
The focus of Lean is on delivering value. The purpose is to deliver value for the business that pays for it.
Value of the product is not in the delivery but in the use of the product. We not only need to build the product right but make sure that we build the right product. But how do we know what is the right product? How do we know what the customer values? How do we know who are the customers?
Discovery is the process of finding out the customers, customer needs, business value and how customer needs can best be addressed by the system we want to build. In Jeff Patton’s words: Delivery is about the building of a product; Discovery is learning about the outside world and our product in it.
Discovery and delivery are the yin and yang of product development. They are inseparable. No delivery without discovery; no discovery without delivery. Often we are overly focused on delivery (and especially efficiency of delivery) and discovery is skipped or cut short. When we short-cut discovery we run the danger of taking wishes (what the user says he/she needs) for the actual needs (what the user really needs) and spending much money in building the wrong product.
As Dan North puts it: “Methodologies, practises and patterns for delivery are all well and good, but they don’t take into account the single biggest limiting factor to successful delivery. … Surely it makes sense to invest effort in firstly discovering which aspects of delivery we are most critically ignorant of (i.e. both where we are ignorant and where that ignorance is hampering throughput), and further to invest in reducing that ignorance – deliberately discovering enough to relieve the constraint and allow us to proceed.” He uses the term deliberate discovery to stress the fact that discovery should not just be left to happenstance.
Deliberate discovery is a learning process. It consists of:
1. Forming a hypothesis: postulating customer needs and business value
2. Validating the hypothesis: validating the assumptions we made about customer needs and business value
The front-end of discovery (forming a hypothesis) is found upstream of development; the back-end of discovery (validation) is found downstream of development. All-in-all discovery + delivery gives us a complete picture of the end-to-end value stream.
Kanban at the whole systems level
The purpose of introducing Kanban at the whole systems level is to evolve towards a steady flow of value towards customers. Discovery Kanban relates to the use of Kanban in both the discovery front-end and the discovery back-end. Delivery Kanban obviously relates to the use of Kanban in delivery (traditional Kanban so to speak).
In order to come to a steady flow of value, the balance between discovery and delivery is a critical point of attention.
Too much discovery upfront leads to a large inventory of requirements, too many unvalidated assumptions about user needs, and push of work into development. Development is perceived as the bottleneck. This has been the main focus of Kanban and the Kanban community.
In reality, it is equally often the case that development is starved because of too little time has been spent in the discovery upfront. Development just starts and invents its own requirements or it starts with the few requirements it already has. In such case up-front discovery is the actual bottleneck.
Lets have a closer look at the front-end of the discovery kanban to illustrate this last point.
Discovery kanban: front-end
The front-end of a project is often mistakingly depicted as a process of refinement. We start with top-level goals that are refined into detailed requirements. This is a mistake and an indication of a lack of understanding of the front-end process. Discovery is not a convergent process. It is a divergent – options creating – process.
A more correct representation of discovery is found below. The discovery starts with fragmented narratives. The different narrative fragments represent the different wishes of different stakeholders: “we want the system to do this”, “we want to serve these customers”, … Often narratives are anecdotal and they may be conflicting. The purpose of the front-end of discovery is to move from fragmented narratives to a shared coherent model.
Let’s illustrate with a concrete example with user stories. User stories are typically not derived in a top down fashion. To the contrary. Typically we start from the bottom up. Users write user stories from their individual perspective (fragmented narratives). User stories are collected in a story map (a concept or sketch) that relates the different stories to each other and to higher level goals (or activities). The story map is constructed in a workshop format to ensure that users (and other stakeholders) develop a shared view. As we move towards development, stories gain detail – e.g. by splitting stories and adding acceptance tests – and a more comprehensive model is created.
With this understanding of the discovery front-end flow, it is easily visualized on a Kanban board.
While delivery kanban and discovery kanban have more or less the same properties they are subtly different.
Unlike the delivery kanban system, the discovery kanban system does not manage a flow of work. It manages a flow of options. In the delivery kanban we limit the work in progress in order to push choice upstream (put the risk where it belongs). In the discovery we need to ensure minimal options in order to ensure that we have a choice. The purpose is to ensure that at each moment we have a minimal set of options ready for replenishment of the input queue of development (making sure that development is not starved from well prepared requirements).
To sum it all up, the core properties of discovery kanban can be expressed as follows:
1. Visualize options
2. Ensure minimal options
3. Manage Flow
4. Make Process Policies Explicit
5. Improve Collaboratively