How to Use Process Policies to Speed Up Your Team's Delivery
Before you begin playing a game of basketball, it’s important to know the rules. Imagine trying to play without them - how would you know how to award points? How would you know what counts as a foul vs. what doesn’t? If the two teams disagreed on something - how would you settle the dispute fairly? Without clear, previously agreed-upon rules, settling disputes would take forever. Games would be slow to play and painful to watch.
It seems obvious - if you want to work as a team, you need rules. But often, work teams operate without clear rules - leading to communication breakdowns, frustration, and resentment. Like in a game of basketball, operating without clear rules makes it far more difficult - and far more tedious - to get anything done.
For many, the word “policies” conjures up images of employee manuals and handbooks - required reading when beginning a new job. While those types of policies are necessary, they aren’t what we’re talking about here. Process policies are rules your team creates together to help your system operate more smoothly. Unlike your company’s HR policies, these are policies you create, reference, and revise in your daily work.
Process policies can help everyone use the Kanban board in the same way - which can make your Kanban system a more effective vehicle for increasing speed. In this post, you’ll learn how to use process policies to help your team move faster and get more done.
Why Do We Need Process Policies?
You might say, “Our team works pretty well together. Everyone communicates and we always clear up issues fairly quickly. Do we need process policies?”
Yes - every team can benefit from establishing clear process policies. Process policies help to minimize confusion, keep progress moving, and prevent delays in project delivery. They can help prevent delays and disruptions before they happen.
Here are a few common scenarios from a development team that demonstrates where process policies can help keep work moving.
- You just finished coding a new feature. What do you need to do to make it ready for QA and minimize the possibility of rework?
- You run into a blocker. Who needs to know? How are you going to seek resolution? While you’re waiting, do you start new work or not?
- Someone in sales comes rushing over with a “critical” new feature request from a customer. What’s your policy for prioritizing this new work?
- You’re working on a feature, and have an awesome idea to make it even better. How do you avoid scope creep and keep to the definition of done?
Let’s break down each of these to learn how process policies can help your team keep work flowing.
A Policy for Lane Requirements to Reduce Rework
Scenario: You just finished coding a new feature. What do you need to do to make it ready for QA and minimize the possibility of rework?
Every process has steps. Our natural tendency is to finish the work we have to do in a certain step, and then push it onto our coworkers for the next step. In this example, a developer sends a new feature over to QA for review. Most of the time, QA will send features back for the same 2-3 reasons.
What if, before we sent a feature to QA, we could go through a checklist that helps us spot any issues? This would save your QA engineer time by helping to prevent commonly occurring problems, while also saving you time by preventing you from having to rework it. This small change can have a major impact on your team’s flow, and therefore, productivity.
To reinforce this, add a process policy to your “Build” lane that says that all features must be reviewed for certain requirements before moving onto the QA lane.
A Policy for Blockers to Control WIP
Scenario: You run into a blocker. Who needs to know? How are you going to seek resolution? While you’re waiting, do you start new work or not?
Blockers are usually external factors that prevent work from moving forward in our process. Blockers are inevitable, but need to be accounted for so that they do not interfere with our overall system’s productivity.
Often, we fail to communicate blocked work to the rest of our team. A card will sit in a lane for days or weeks, unable to move forward. Blocked work clogs up our system, so it’s important to get it moving as quickly as possible. Often, when we encounter a blocked card, we’ll decide to pull more work into the system. But additional work might further delay progress - so it’s important to have a policy that helps us know when we should or should not pull new work.
To prevent blockers from getting in your way, add a process policy to your board that answers these questions:
- Who needs to know?
- How are you going to seek resolution?
- While you’re waiting, do you start new work or not?
If you use LeanKit, be sure to use the blocked cards feature, which allows you to visualize blocked cards with a red icon and provide an explanation for why it’s blocked that everyone on the team can view. Visualizing blocked cards can help keep them top of mind for your team.
If your team hosts daily standups, make a point to always discuss the status of blocked work. Ask, “Is there anything we can do to get this work unstuck?” This will also help keep blocked work top of mind across the team, so you can keep work moving forward.
A Policy for Prioritizing Unplanned Work to Keep Everyone Focused
Scenario: Someone in sales comes rushing over with a “critical” new feature request from a customer. What’s your policy for prioritizing this new work?
We all want to be the hero. When someone from another team asks you to drop what you’re doing, it’s because they’re trying to deliver on a promise to a customer. Of course, that’s your goal as well - but prioritizing “shiny” work like this over existing work can derail organization-wide initiatives. You figure it won’t hurt to spend an hour or two on this feature request… but three days later, your team is still waiting on the work you already had in progress. Your manager asks, “Why are you working on this?” “Because so-and-so asked me to,” isn’t a justifiable response.
Adding a process policy for prioritizing work can help keep everyone focused on the work that matters most. In this scenario, a policy that says all work must get prioritized by a product manager before moving forward would have prevented the miscommunication.
A Policy to Prevent Scope Creep
Scenario: You’re working on a feature, and have an awesome idea to make it even better. How do you avoid scope creep and keep to the definition of done?
Scope creep always starts with good intentions. You begin working on a feature, and you realize that if you just spend a little more time on it, you can double the bells and whistles included in this release. This is problematic for several reasons:
- You don’t know if these extra bells and whistles are desired by your customers.
- You don’t know if these extra bells and whistles are more important than other work in your backlog.
- There might be a cost of delay on work in your backlog that makes it especially important for you to begin working on it ASAP.
Adding a process policy that dictates what to do when your wheels start turning can save you from accidentally diving into a black hole of scope creep. Your policy might say: Define scope of work before beginning work. If opportunities for scope creep arise, discuss them with the team during daily standup before spending any time on them.
Respect Your Process!
Process policies help teams get more done by eliminating opportunities for confusion, frustration, and communication breakdowns. They can help keep communication high and progress moving. Use process policies to smooth out the kinks in your Kanban system.
In LeanKit, it’s easy to add process policies to your board. You can learn how by following this guide in our Knowledge Base. Learn more ways to increase your team’s speed of delivery by reading these posts: