Making Process Policies Explicit
What are process policies?
In your business, there is a set of consecutive steps, that - carried out correctly - produce an article, be that physical object, a software package, or a different kind of digital data. That repetitive process and the quality of its execution are often what makes or breaks a company. Where processes tell us what to do, policies tell us how to do it. They guide the team on how to make decisions, helping them advance the process in the best possible way.
It may be crucial to make an initial, blunt distinction between what comes to most of our minds when we see the word “policy”, and what Kanban policies should be. A Kanban policy is not your 30-pages long jargon-filled document stashed away from the team’s view (and interest). In its final form – it should be common knowledge on how each stage of work has to look before it can move on to the next. Of course, when a policy is being first announced, it will be written down, and will likely stay that way, for future review and new team members, but in general, a well-written, sensible process policy will – with time – become a routine of the team members, and will be working as their advocate, helping them maintain their flow, rather than working against them.
Have you ever walked onto a shop/office floor where it was evident that people have no idea what’s happening? Compare that to watching a Formula 1 pit crew, and how strikingly obvious their definite way of working is - everyone knows what’s the most important thing to do, and does it. It’s beautiful, efficient, and predictable – in the best possible meaning of the word. You want your business process to be guided by policies as relevant and effective as those of the F1 pit team.
Why do we need process policies?
Project managers are not interested in people being busy. They’re not even interested in people being busy with the right activities. What they want is for the team to be busy with the right activities, performed in the correct way and at the right time, to produce the required result. A Kanban board in itself can make process policies explicit, and seeing it lets the team glean a lot about how the process flows.
Next to each process stage name, there is an “info” icon, giving the team clues as to how to approach work. For example, the Testing lane policy is that once the Coding team is done with their work, they are to join the testing team and help inspect the new code, thereby improving throughput.
Keeping process policies on view is brilliant, as it makes good governance and correct working practices second nature. Practice makes perfect - but in this case, the reality is, that practice makes permanent. If a team is practicing the wrong way of working, then it will become their habit, an unwritten policy! Therefore, stating transparent, clear policies ensures that team members practice working well and that they understand the meaning behind each step of the process. It’s not as though making everyone aware of each stage’s demands will make them able to complete them alone, what matters is that the common understanding breeds quality awareness and easier error/impediment detection by all members of the team.
Policing what matters, in a visible way
The policies need to reflect what is important to your company. In the same way that the Golden Gate Bridge both appears to be, and is strong, your policies should outline what is important to the company, in an immediately noticeable way. Seeing where the team is getting stuck should prompt a question if better ways of working can be introduced, and how the board could be updated to reflect that. The policies and procedures should define which tasks the company is willing to ignore, for the benefit of applying more focus on the key ones; what trade-offs in speed or quality the company is prepared to accept, and in what circumstances.
Stating policies and procedures explicitly frees up the team’s mind space. When we’re able to get into a state of flow, work can become almost effortless. People who need to constantly remind themselves how to work, and have no easy way of accessing this information, will never get into a state of flow. Making explicit policies accessible to the team has the potential to remove a lot of frustration and exhaustion, and hence, to improve their performance.
Mike Tyson said Everyone has a plan until they get punched in the face, meaning that when people hit a major crisis point, the best-laid plans can be quickly forgotten. Clearly stating your policies may prevent the wheels from coming off when things go wrong. Be sure to make the guidelines on how to proceed in common workflow scenarios accessible to the entire team.
However, be cautious of attempting to police too much and all at once – as an ill-considered policy introduced at the wrong stage and time could in and of itself create an impediment. A general rule could be to not introduce more than 1 new policy at a time, to allow for its effects to be measured before other rules are applied, and – of course - not to bring in policies that the involved workers have no means of controlling or even investigating.
Example If a software development team deploys some of their code to a pre-production environment, and some to the production site, they cannot expect a staging-server access limited testing team to be able to assess 100% of the code. The process should visibly split the items that can be tested in pre-production from those that cannot. That will shorten the waiting time required to find out that a given item could not have been tested on the staging server, where the testers were looking for it. You can learn more about the cost of waiting for set process steps to finish here.
Here are some ideas for process policies and procedures:
- Are your team members familiar with the flow of work, where an item starts, and where it finishes?
- Does the team know what are the quality-check steps, and the definition of “done” at every stage?
- Does the team know how to expedite an item that becomes urgent - and what does that mean for the team and the process?
- Does the team know how to handle unplanned work, how to fit it into their process?
- How should team members handle defects found in the production process, do they stop want they are working on and fix the bug, or do they queue up the defective item at the beginning again.. etc.
Practice can make perfect!
Data drawn from flow measurement, showing the root cause of most problems, should be the source of your explicit process policies. Every time a feedback loop completes, there’s an opportunity for the process to be improved. After a few productive feedback loops, the team can become empowered by knowing what makes them successful. They’ll know what behavior to focus on, and which habits need to stop, and in this continuous learning and improvement, the concept of Kaizen can be realized.
Other than a smoothly flowing process, it is this evolutionary improvement opportunity that may be the key reason why working on having good, explicit process policies in place matters so much in your Kanban practice.
Any process can be made more efficient, you just first need to know exactly what policies and behaviors drive it, and work on them.