In our Measure and Manage the Flow article, we discussed how keeping a stable flow of work is essential to keeping an effective Kanban system. One way to achieve a stable flow is by enforcing Work-in-Progress limits (WiP limits), which is one of the properties of Kanban. But apart from using WiP limits, there is another Kanban property that helps teams establish a stable flow of work. This is through using process policies.
Process policies act as guidelines as to how a team should perform their work. These policies govern the team’s process and serve as boundaries for the execution of their work. We can also think of process policies as checklists, which are used by the team to define how work can be pulled from one process lane to another.
Why we need Process Policies
The goal of using Kanban as a project management system is to create a stable flow of work. In order to establish stability, there needs to be a consistent application of things. Rules, procedures, and ultimately, policies help in achieving a level of consistency and standard when it comes to process execution.
Teams need policies and procedures to govern their execution for order and consistent application of the process. Enforcing policies enables teams to operate at a level of desired quality. It establishes a common understanding among team members on how they work on items that flow through their Kanban system.
Samples of Kanban Process Policies
Process policies can be defined at a high-level or step-level. High-level policies apply to the process as a whole, while step-level policies apply to specific steps or lanes within your Kanban.
To illustrate this, consider a software development process and the policies might be applicable.
For high-level policies, think of scenarios that impact the software development process as a whole and brainstorm how to manage these scenarios. Below are sample scenarios along with questions to help formulate high-level policies:
- Handling the Backlog – Who can add items to the backlog? Who will prioritize the backlog?
- Handling Impediments – When a team member is blocked, how will the team handle the impediment? Should it be escalated to someone? Can the team member get new work while waiting for a resolution?
- Handling New “Critical” Requests – A new feature request is sent by the marketing team in an attempt to appease or satisfy customer demand. From their point of view, these are critical. How would you handle these types of requests? Who will be responsible for prioritizing these requests and communicating with stakeholders?
- Resolution of Issues/Defects – How will the team make sure that bugs are prioritized alongside feature requests? Who is responsible for prioritization? What is your SLA for bug resolution?
- Handling Scope Creep – While an item is being worked on, a stakeholder sent a request for additional specifications to its initial requirements. How would you handle changes to requirements for items that are already being processed?
As for step-level policies, the main question you need to answer is, “what would make an item ready to be pulled by the next step?”
For example, in the Coding step of our development process, we have a policy which states code review must be completed before endorsing the item for testing. We could also say, unit test must be present to consider the item “done”. For the Testing step, we can have a policy which states that the test plan must be documented and discussed with the team before testing can start.
Don’t forget that your WiP limits act as policies themselves. These can be added to your step-level policies if WiP limits are defined per lane in your Kanban.
Make your process policies visible
Stating your process policies explicitly and making them visible remind the team of rules to be followed for a sustainable flow of work. This will increase productivity by reducing the think-time needed for decisions.
If you’re using a physical Kanban board, place high-level policies on one side of the board and step-level policies within their respective columns. If you’re using a Kanban software like Kanban Zone, you can easily define and include your policies on the board.
Having process policies makes it easier for teams to scale their Kanban practice. If no policies have been established, hold a brainstorming session with your team. The activity should be a team effort with everyone agreeing on the policies. This will make the policies easier to enforce without creating conflict.
Remember that these process policies are not meant to be cast in stone. As you refine and evolve your process to be more effective, review your process policies as well.