Notes from Lean-Kanban training (part 2)

This is the second part of the Lean-Kanban post based on a training class I recently attended by David Anderson (aka @agilemanager). I recommend that you read Part 1 to get a better context.One of the key differences between Kanban and other agile methods (e.g. Scrum) is Kanban’s reliance on well defined process policies. Kanban requires that process policies are defined explicitly for each implementation. It is important to think of a process as a set of guidelines that govern behavior. These policies are under the control of management and can (and should) be periodically examined and modified especially as the organization matures.I think for most of us the term “policies” conjures up images of large binders with the words “Policies and Procedures” on a manager’s bookshelf that contained waterfall-style documentation that no one reads. That is NOT what Kanban means with policies but rather a minimal set of process rules that define how work efficiently flows through your process. Hear are a few examples of the type of questions that process policies answer:

1. What are the work in progress limits for each step of your process flow?
2. Can a work item be considered “DONE” without going through each step of your flow?
3. What are the various work item types in your process?
4. How do you reserve time from shared resources?
5. How does a work item get marked as “URGENT” and trump other items already in the work flow?
6. What should be the cycle time allowed for each class of service?

Rather than make teams less agile, process policies are meant to help a team stay focused on the task without having to repeatedly answer the same questions. For example, if you have established that pair-programming produces better quality results then make it a policy. It is through process policies that best practices are institutionalized.

Another important purpose these policies serve is make both management and knowledge worker trust one another and prevent the undesirable downward spiral into micro-management. Once a policy is established such as “all source code must comply with our StyleCop policies document” management no longer needs to “checkup” on whether the team is adhering to the coding standards and can focus on more pressing issues.

There is much more I could say about this topic but I would much rather engage in a conversation based on your comments.

In my next post I will talk about visualizing the work in progress through the Kanban board.