Eliminating proxy variables empowers team members to make dynamic, good-quality risk decisions.
You might have noticed that we have purged the use of the words “priority” and “prioritization.”
“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’s visualization is to find ways to capture and visualize the true risk information that the business is managing. Classes of service do this very well, so long as the policies that define what it means for an item to be of that class — and how an item of that class should be handled — are made very explicit.
“Priority” then becomes something that can be decided dynamically when a pull decision is made. Eliminating proxy variables empowers team members to make dynamic, good-quality risk decisions. It reduces the need for coordination meetings, and it improves transparency. It also obviates the role of middlemen who determine “priority.” This largely explains why a role such as Product Owner is generally not required with Kanban. *
“Prioritization” is also no longer required with Kanban. The act of prioritizing a backlog into some form of stack ranked list implies some amount of crystalball gazing to second guess the future. Such an activity is considered “waste” in Kanban. Backlogs should remain unordered list. Pull decisions should be made dynamically when a virtual kanban is available and is signalling capacity.
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 delivery schedule, or based on another dimension of risk being managed, such as market risk of change. We might choose to schedule table stakes features early.
This means that they will be given priority when we are replenishing the input queue early in the project. Scheduling is definitely an optional practice, whereas 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, again, I prefer the terms “selection” and “pull,” based on the policies in the classes of service package and the pull criteria (also known as “definition of done,” or “exit criteria”). 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”).
Using “priority” and “prioritization” is 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. Prioritization is an activity performed at a point in time that presupposes to predict the future. Kanban encourages deferred decision making and dynamic prioritization based on policies written to accommodate the risks being managed.
I am finding that by encouraging teams to abandon the use of words such as “priority” and “prioritization,” which are associated with an older paradigm, a mindset shift to a flow-based approach is easier to achieve. This mindset shift improves the quality of the kanban system design and risk management. Better risk management should lead to better satisfaction for all stakeholders.
* Where the role of Product Owner is observed in a Kanban implementation, it is generally an artifact of the process in use before Kanban was adopted. Under the core principles, “You start with what you do now,” and “Initially, respect current roles, responsibilities, and job titles,” if what you do now involves a product owner, that role is likely to continue for some time, until it is generally accepted that the role has been obviated, and a new role is found for the individual currently playing the product owner.
Sunday, March 20, 2011
Recent Comments