Sunday, March 20, 2011

Banish “Priority” and “Prioritization”

Those of you who’ve attended my classes or workshops or talked with me at conferences this past year, or read the Kanban book very carefully will notice that I have purged the use of the words “priority” and “prioritization.” I’d like to explain why…

“Priority” is something that Don Reinertsen would refer to as a “proxy variable.” It is an artifact that masks real risk information such as “cost of delay”, required skills, technical impact, transaction cost information and so on.

Our goal with a kanban system visualization is to find ways to capture and visualize the true risk information. Classes of service do this very well so long as the policies behind what it means for an item to be of a class of service and how an item of a class of service should be handled, are made very explicit.

“priority” then becomes something that can be decided dynamically when a pull decision is required.

Eliminating proxy variables empowers team members to make dynamic, good quality risk decisions. It reduces the need for coordination meetings and improves transparency. It also obviates the role of middle-men who determine “priority.” This largely explains why a role such as Product Owner is much less necessary with Kanban.

The term “prioritization” is also no longer required with kanban systems. Prioritization is implied by the policies associated with a set of classes of service and how each class of service interacts with another. For example, Expedite takes precedence over Fixed Date, which may take precedence over Standard depending on the current position in the workflow and the likelihood of on-time delivery against the fixed date.

When we select something to replenish a slot in an input queue, I prefer the terms “selection”, “scheduling” and “replenishment” rather than “prioritization” as we aren’t prioritizing a set of things in a backlog, we are selecting something from a (usually) unprioritized backlog to place in our input queue. “scheduling” implies that we chose to “select” an item for queue “replenishment” based on some plan or deliveyr schedule. “Scheduling” is definitely an optional practice, where “selection” and “replenishment” are necessary to facilitate the flow in the kanban system.

When we select something to pull from an earlier stage in a workflow, I again prefer the term “selection” and “pull” based on a the policies in the classes of service package and the pull criteria (of “definition of done”).

So “priority” and “prioritization” go away. They are replaced with “risk profile” and “class of service” (to replace “priority”), and “selection”, “scheduling” and “replenishment” (to replace “prioritization”).

In Lean terms, I find “priority” and “prioritization” are wasteful. They encourage roles/positions for people who do mostly non-value-added coordination work, and they add to the transaction costs of flowing work through the system.

I am finding that by encouraging teams to abandon the use of words associated with an older paradigm, it facilitates a mindset shift into a Flow-based approach, and improves the quality of the kanban system and the resultant throughput, lead times, and customer satisfaction.