Become a Better Product Owner with Kanban

In order to improve delivery outcomes such that they are predictable and up to the speed required by our customers, demand needs to be balanced to capability. The Kanban Method helps us to do this. Regardless of whether you are doing Scrum, partial Scrum, Water-Scrum or however else your organization describes how it is organizing people and work, the Kanban Method can help you. Regardless of whether you call yourself a Product Owner, Product Manager, etc., the Kanban Method can help you. What really matters with Kanban is that you are taking responsibility to improve delivery outcomes in your organization at whatever level of leadership, authority and influence you may have. If this is true, then the Kanban Method is for you.

But let’s say you’re a “Scrum Product Owner” and you’re still not convinced. The next few paragraphs, then, are for you and so let’s start with Scrum. In Scrum, the Product Owner is responsible for managing the Product Backlog. The Product Backlog is the artifact from which the Scrum Team selects items to deliver in the next Sprint (time-boxed delivery iteration). According to the Scrum Guide the Product Owner “is responsible for maximizing the value of the product resulting from the work of the Development Team”. This essentially boils down to making good decisions about what work to start next, what work to start later and what work to start never.

However as a “process framework”, Scrum does not provide Product Owners with any explicit, pragmatic guidance on how to manage the Backlog. The Kanban Method, on the other hand, does. We will get to it by starting with a model used by Agile experts to describe the Product Backlog in Scrum.

Product-minded “Agilists” often describe the Product Backlog as an “Upside-Down Funnel” with big fuzzy ideas at the bottom and more refined, desirable and urgent items rising to the top. Each Sprint, the Scrum Team selects items from the top to work on. This is a helpful concept. Indeed, considerably more useful than thinking of the Backlog as a single-dimensional ordered list (still an alarmingly common way that it is described).

The Kanban Method offers a similar yet dramatically more explicit approach to modelling the backlog. The simplest way to begin shifting our thinking towards this approach is to imagine the “Upside-Down Funnel” model rotated 90 degrees clockwise so that the broad end of the funnel is on the left and the narrow end is on the right. Then, we can translate the funnel model into the model of the workflow (the set of process steps that already exist in every organization) in order to make the process more transparent, explicit and manageable.

Upstream processes exist in every organization but are often opaque — “The Fuzzy Front End”. Upstream Kanban seeks to uncover, clarify and maximize the value of this work. The work of managing the Product Backlog is essentially Upstream or “Front End” process management. That is, the process of marshalling options from the inception of an idea to the point at which the business is ready to begin the relatively much more expensive process of translating a risk-hedged option into a viable product or service.

Every professional services organization has limited capability for doing work — do you know the limits of your organization’s capability? Decisions are made about what to start next, what to start later and what to start never. How does this currently happen in your organization? Are these decisions informed by capability? Are the policies that govern such decisions explicit? Organizations that continually satisfy the needs of their customers know how to answer these questions. When we know our capability, we can balance the demand coming into our process such that the capability is not overburdened. Non-overburdened systems are known as pull systems. Pull systems have explicit limits to the amount of work that can be in progress at any given time.

How can we begin to apply the Kanban Method to the Upstream work in our organizations in order to make better decisions about how to allocate the limited capability of our organization?

We start with the Kanban principles:

Understand current processes

Agree to pursue evolutionary change

Encourage acts of leadership at all levels

Understand and focus on customer needs & expectations

Manage the work, let people self-organize around it

Evolve policies to improve outcomes

Then, we apply the Kanban principles with the Kanban practices. We will elaborate on a few examples below.

Principle: Understand current processes

Practice: Visualize

• Model the workflow — what is the discovery/upstream process? What are the “milestones” or “gates” for moving a project/product/feature closer to “ready to start”?
• Account for and make visible all work-in-progress (WIP) — how many projects currently reside in this process and where? What would be reasonable maximum and minimum limits for each stage?

Practice: Make policies explicit

• What are the policies or criteria that projects need to satisfy such that they are “allowed” to move to the next stage? How are decisions made about what projects get worked on in order for them to move to the next stage? How are decisions made to discard project ideas at any given stage?

Principle: Evolve policies to improve outcomes

Practice: Improve collaboratively, evolve experimentally

• Seek out and facilitate collaboration with customers, stakeholders and the delivery group towards the evolution of the upstream process and better decision-making (for the business) about what to start next, what to start later and what to start never.

Practice: Implement feedback loops

• On a regular cadence, review the mapping of the workflow, ticket design and policies to identify potential systemic improvements.

Practice: Limit WIP and manage flow

• WIP limits are essentially a representation of current capacity. WIP limits and other explicit policies, when applied appropriately, ensure a balanced and responsible approach to capacity allocation management. “Capacity for what?”, you might ask. This can be defined as “Capacity for work such that the capability of the system is fit for the purposes of customers”. Customers have fitness criteria and thresholds. The most common of these are time-related. “How long do I have to wait?” and “How often will I get what I need?” are two of the most common questions asked by customers. They have to do with speed and predictability. Predictability of capability is only possible with a pull system. Real commitment is only possible with a pull system. A pull system is a WIP-limited system. By adjusting WIP limits, a pull system can be calibrated such that the capability becomes fitter for customer purpose. Little’s Law is the mathematical law that underpins this powerful calibration principle.

There is significantly more to explore than we have been able to cover in this brief introduction. For some, this will be enough to get started. For others, further elaboration, conversation, training and coaching may be required. What each will require will depend largely on context.