"Kanban is a strategy for optimizing the flow of value through a process" - Kanban Guides We want to create opportunities to make new and better decisions frequently. ## Origins Kanban is originally a task flow methodology developed as part of the Toyota Lean manufacturing system that's been adopted to Agile product development. The ProKanban.org community has tried to distill the essence of Kanban into [Kanban Guides](https://kanbanguides.org/) Product development is inherently uncertain so Kanban tries to make the process as simple as possible to be able to quickly adapt to change. Kanban applied to knowledge work came out of a company called Corbis in Seattle doing work in the sustaining eng team. Kanban then spread and was tweaked by each team and company that adopted some of the core practices. ## How to make meetings less terrible - Keep track of the 4 key metrics to assess where the flow isn't working well, in particular, work item age chart. You *can* bring up the kanban board but monitoring aging in your daily meeting will go a long way to helping manage flow. ## Expedite Lanes Kill Flow [FYK: How to Kill Your FLOW with EXPEDITE LANES](https://www.youtube.com/watch?v=6W7P-uPaJCI&list=PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6&index=13) "Class of service" ~ how items are treated once they're in your process (specifically, this doesn't apply to backlog items). Setting up an expedited flow is usually motivated with good intention. Claim "nothing will kill your flow faster". If you have a mechanism to expedite work it gets abused - whoever is the loudest gets to push more expedite work. You end up having to try and patch the system (e.g. aggressive WIP limits) to work around making sure expedite doesn't get abused. Sooner or later "everything becomes an expedite" and so nothing is an expedite and both cycle time and throughput balloon. Counterpoint. Once you're operating a very predictable process, you're probably retiring work every few hours of day so the question becomes "can this new thing just wait that long and become the next thing that's pulled off the top of the stack." Expedite lanes really impact your ability to continuously improve. Which do you optimize and improve, your ability to expedite or your ability to get regular work items done? At that point, you really have 2 processes you're trying to manage (e.g. oncall and development). You're assuming that you understand the value well enough up-front to prioritize one thing as expedite and another as not expedited. ## Right Sizing Issues [FYK: What Does It Really Mean to RIGHT SIZE Workin Kanban?](https://www.youtube.com/watch?v=_Jn67S4V5j4&list=PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6&index=9) You shouldn't try to make every issue the exact same size, that's a futile effort but you should try and find an overall not to big nor not too small issue size. The common place to have the "right sizing" discussion is Just-in-time i.e. when you're about to pull the work item into your process. But you need to continuously evaluate the sizing as it's flowing through your process because you'll learn about the task. This conversation should be really fast. "You don't drive out uncertainty about talking about the work, you drive out uncertainty by *doing* the work". The key indicator that issues are too big are Service Level Expectation (SLE) (it's the variability confidence interval) ## Resources - [Fixing your Kanban series - ProKanban](https://www.youtube.com/playlist?list=PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6) - [The secret history of Kanban and why it matters - Daniel Vacanti](https://www.youtube.com/watch?v=bJVjcVCqWew) --- - Links: [[Agile Software Development]] [[eXtreme Programming]] [[Test Driven Development]] [[Product Management]] - Created at: [[2022-07-10]]