How to Manage Discovery and Delivery Work on a Kanban board?

On a Kanban board, you have

• 

  a definition of workflow,

• a start point,
• a finish point,
• a cycle time (how long does the work take to get from the start point to the finish point),
• throughput (what is the rate of items being delivered across the finish point per time period, e.g. per day, per week, per sprint),
• work item age (what is the elapsed time from which a work item has started, but has still not yet finished),
• Work-In-Progress (WIP) (all the items that are within the starting point and the finish point).

Types of Work on a Kanban board

You could argue, on a Kanban board we have:

• discovery work;
• development work; and
• delivery work.

Discovery Work

Discovery work would be, for example, research to figure out whether this is the right thing to build for the customer. Maybe we are doing some experiments or some prototyping. It is very wise to do experiments when we have insufficient evidence so we can harvest the proposed value because at the end of the day, our work items are bets at best. They are ill-informed opinions at worst if you do not experiment. You could just fill your funnel with stuff to develop and maybe there is no evidence you should actually develop it. So discovery is about discovering value, it is about learning.

Development Work

Development is about building the product, making the product.

Delivery Work

Delivery is about getting that work that we have made and giving it to the customer.

The 4 Time Horizons You need to think about on your Kanban Board

You could argue there are four time horizons.

1. Discovering the “next best thing”.
2. Developing what we now have evidence is the right thing to do.
3. Delivering the stuff that we have got to a stage that is ready for a customer to consume.
4. Looking back at those previous releases that we had, those deployments that we had to the markets, did they actually make a difference? Did we change customer behaviors? Do we reap some organizational value? Do we improve our reputation as an organization? Do we improve employee satisfaction? Do we reduce our plastic footprint? Do we reduce our carbon footprint? And so on.

The question is…what do you do with this work?

Kanban vs Scrum: the approach to the backlog

In Kanban, the backlog is optional. Unlike in Scrum, where there is a product backlog, which is mandatory, it is an artifact.

In Kanban, the backlog is optional. You can also have a funnel, which is like the backlog for a backlog. This is another optional container that you might have on your definition of workflow.

Managing the Time Horizons

There are multiple patterns available for managing these four time horizons. The thing is that we are managing WHAT type of work it is as opposed to WHO is doing the work.

In a modern team that is trying to practice agility, I would hope that people are trying to learn other skills. The reality is that the people who do discovery have a lot of work to do and there are usually fewer people who have the skill to do that discovery. What I often find is the people who do discovery are often coaching, mentoring, teaching, and willing volunteers who want to learn how to do that discovery.

For example, someone doing development might be invited to a customer interview to just take notes and gain an appreciation of what the customer/ end-user wants.

Another example is a developer who might be asked to do some low-fidelity prototyping. Perhaps maybe even practice their skills doing customer interviews because we need to be careful: either avoid loaded questions or as Indy Young would say, maybe just do some deep listening. Listening to where the customer wants to go with the conversation.

John Carter (the inventor of the BOSE noise canceling headphones) said in the test shop that they had in BOSE, when they had people come into the music store they were purely just observing where the customer goes, not pointing them to new innovation. They were just seeing if they pick it up, what they do with it, what did they discover. Lo and behold, instead of discovering that customers wanted to improve the sound fidelity, they liked the whole idea of noise cancellation. Noise canceling headphones were discovered by accident, through an accident of innovation.

So we are trying to have as many innovation accidents as possible, because in reality that is where most innovation comes from (and also through twisting previous inventions for a new purpose).

Discovery is never finished: How do we navigate this?

The challenge is that there is so much of that discovery work and discovery is never finished because the people who do discovery also were involved in doing usability testing as the work is going through development, for example. They also analyze what is going on after the work has been released to the market to see how people are interacting and what or where they are dropping out. So maybe helping product managers to look at the customer analytics and understand what is going on.

In a dynamic trio, for example:

• a technical person;
• a design person; and
• a product manager

could get together to talk about, okay, what do we understand we need to do here? What do we need to discover next? What do we need to deliver next?

So how do you manage all of this?

You could have, for example, columns for:

• discovery;
• development;
• delivery;
• getting feedback.

“Measure and Tweak” is a column name that I quite like.

The thing is that not every item that goes through discovery will go through development because we will probably discover that most of the items should not be built.

We know, for example, from several editions of the Chaos Report from the Standish Group that two-thirds of what we build is never/rarely used. So we want to discover as much of that as possible before we build something. If not, we are just filling the development funnel and the delivery funnel with work that might not be valuable.

Another pattern that I have seen is, instead of having columns for those stages (which assumes that there a sequential process), maybe having swim lanes for those. This is because some work might go back from development into discovery, and some might go from measure and tweak back into discovery.

REMEMBER: On a Kanban board, we do not want work items moving backwards.

The use of swim lanes can avoid that problem.

Using good heat map reporting, you would be able to see where the work is spending most of its time.

Split work-items

In terms of work items, I tend to separate discovery work items from development work items. You could argue that development and delivery could be combined because we want to get some value.

There is value in discovery because remember, value is also about learning. So, as long as the discovery results in some learning about something being good or bad, validation of some hypothesis, meeting some people matching our personas, for example. Perhaps you are not into personas, but you have talked to some people, you have run some experiments. What did you learn?

There is value in that learning.

I have no problem with work items being there for discovery. And then there would be other work items maybe for development/delivery.

As long as each work item is valuable, that is fine.

So I talked about split items, and now I will be talking about combined.

Combined work-items

You could also have work items that have all:

• the discovery work;
• the development work; and
• the delivery work on the same item.

With subtasks for the individual discovery, development, and delivery tasks, for example.

Each of those subtasks in themselves contributes to the delivery of value, but in and of themselves are not valuable. So the entire work item itself is valuable.

The problem that I see with that approach is that it leads to what I refer to as execution bias, where there is almost a kind of path of least resistance to continue to develop and deliver, even though we might not have evidence that we are on the right track. So we want to visualize as many signals as possible. We want to see what options we have. That maybe is building up some evidence that we should develop and deliver them.

We want to see what is going on in development and delivery. We want to also see what are we measuring and tweaking and what are we learning. So we are getting that learning cycle, that empirical loop of deciding what to do next based on what we learned last.

Often what you will discover is the outputs that we deliver to achieve outcomes are not the same as maybe what you might have expected. So it is important when you are setting goals and a direction of travel for the teams that they are outcome-oriented.

• What change in behavior are we looking for in terms of the customer, end- user, or consumer?
• What business value metrics, customer value metrics, or end-user value metrics are we looking to move the needle on that would demonstrate that we know we made a difference, either better or worse?

Concluding Remarks

Remember the value can be positive or negative. There are just two sets of patterns for combining discovery, development, delivery, measuring and tweaking. I would love to hear your ideas on other approaches.

The only limit is your imagination.