Book: Priming Kanban

A manager recommended “Priming Kanban: A 10 step guide to optimizing flow in your software delivery system” by Jesper Boeg. It’s a short read with many good points. Here are my notes:

• What is Kanban?
  • “Visualize Work”: “Visualize every step in your value chain from vague concept to releasable software.”
  • “Limit Work-in-Progress (WIP)”: “Set explicit limits on the amount of work allowed in each stage.”
  • “Make Policies Explicit”: “Make the policies you are acting according to explicit.”
  • “Measure and Manage Flow”: “Measure and Mange Flow to make informed decisions and visualize consequence”
  • “Identify Improvement Opportunities”: “Create a Kaizen culture where continuous improvement is everyone’s job.”
• You should
  • “Start with what you do now”
  • “Agree to pursue incremental, evolutionary change”
  • “Respect the current process, roles, responsibilities & titles”
• “functionality being pulled through the system, based on capacity rather than pushed based on forecasts or demand.”
• “Kanban is built on the concept of evolutionary change. Start by understanding how your current software delivery system works. When you have managed to visualize, measure and manage your flow, improve it one step at a time by relieving the largest bottleneck. This is quite different compared to e.g. Scrum, where you will often start out by redefining roles, process and artefacts. This makes Kanban ideally fitted for use on top of existing proces- ses, which can be anything from Scrum to Waterfall and perfect in situations where organizational structures inhibit radical change.”
• “while most projects will benefit from using Kanban, it is not a sub- stitute for e.g. Scrum. Scrum is in most cases a perfect starting point when adopting Kanban. “
• “Kanban is about using Lean principles to optimize existing processes in an evolutionary way, and therefore cannot and should not be compared to Scrum, XP, Crystal, FDD or whatever method you are using.”
• “The first step towards visualizing your workflow is to understand how your current system works.”
• “Often, you will end up with at least two types of stages: ‘Activity’ stages, where active work is being performed, and ‘Buffer’ stages, where work is waiting to be released/developed, etc.”
• “Don’t go any further before you have managed to visualize all the work you do. If information is hidden and some tasks are completed outside of your workflow system, there is little chance that you will ever be able to make informed decisions about how best to optimize.”
• Benefits of visualizing your workflow:
  • “Focus on ‘The Whole’”: “It becomes visible exactly how your work affects others, and vice versa.”
  • “Transparency”: “Everybody knows exactly what is going on and no information is hidden. “
  • “Identifying waste”:”You naturally start to question why you are doing things the way you are”
• “Cycle time = WIP / Throughput per unit of time”
• Cycle time = “the time it takes from when a feature is se- lected for implementation until it is working in production”
• Work in Progress (WIP): “ome include all items on the backlog in WIP, while others consider only the items selected for implementation.”
• “This means that given a system with 100 user stories in progress (WIP) and a throughput of 2 user stories per week, the average cycle time is 100/2 = 50 weeks or almost a year. Reducing this to 25 weeks can be done by either doubling throughput to 4 user stories per week or by reducing the number of user stories in progress to 50. In most cases, it is initially much easier to reduce WIP than increasing throughput.”
  • Note: One positive side effect of reducing WIP is reducing context switching, which further improves cycle time
• “Fast feedback cycles are also a great way to minimise risk, since decisions are validated continuously and quality issues are exposed immediately.”
• How to set WIP limits:
  • “One way is to observe your system and set the limits just loose enough for your current workflow to continue unhindered. Then, identify your bottleneck and adjust one limit at a time.”
  • “A more radical approach is to set your limits on activity columns tighter than you expect your system to be able to handle and buffer each stage. Then, you observe where work builds up, and gradually loosen until work flows through the system.”
  • “Limits that are too tight will block the flow and will make people idle for too long or will simply be ignored without serious discussion, while limits that are too large will increase cycle time and will make work items idle for too long.”
• “Start by adding the procedures you are using at the present time and add/ remove/change them when you discover new and better ways of ensuring quality. Every bug is a chance to reflect on how it managed to get into your system.”
• “Change them; do not break them”
  • “When implementing Kanban, it is essential that everybody commits to adhering to the agreed policies (initially they just describe your current process) and that it takes a team decision to change them.”
  • “Remember, when you want to break a policy, it is often for good reasons and that is the perfect starting point to initiate a needed discussion.”
• Cadence
  • “One cadence where code is deployed to a preproduction system to obtain initial feedback (internal release cadence)”
  • “One cadence where the new version is deployed to the actual production environment (external release cadence) “
• “The more features you bundle together in a release, the cheaper the cost per feature (lower transaction cost), but also a higher holding cost, since each feature will have to wait longer getting deployed, thus resulting in a loss of business value, outdated feedback, uninformed decisions and lower user involvement.”
• “The continuous deployment movement has shown us that it is possible to deliver reliable versions to production 50 times a day for systems handling millions of dollars. This can only be done by having a fully automated deployment procedure and a whole suite of unit, integration and regression tests, which is, of course, an investment, but is one that allows you to work in batch sizes of a few lines of code.”
• “‘your software delivery system only has a certain capacity’. If you try to press your system beyond its capacity, it will lead to lower quality, unsustainable pace, higher maintenance costs, or all of the above.”
• Cumulative flow diagram (CFD)
  • The width of WIP is Time in Queue
  • The height of WIP is Quantity in Queue
  • “If the width of a part of the WIP area increases, it could be a sign that a bottleneck is occurring.”
  • “If the gradient of the ‘backlog’ area is steeper than the gradient of the ‘done’ area, it is a clear sign that you are adding more work to your system than your current capacity.”
• “Keeping the total number of bugs between 0 and 20 is a good policy for most projects.”
• “Blocked items should always be visible on the board, and tracking the status over time is usually a good way of kno- wing whether the team is moving in the right direction.”
• Cost of Delay (COD)
  • “COD describes the reve- nue or expected cost saving lost by choosing NOT to work on a given item.”
  • “In reality, the COD will often be weighted by Cost of Implementation (COI), deadlines, time and other factors.”
• “I usually compare a back- log to an unused top floor of a house. If you put everything up there that you are reluctant to throw out, you have very little chance of finding the few things you actually need when you need them. Therefore, keep the backlog clean and make sure it is not growing out of control.”
• “In a Kanban system, the way of doing it is referred to as “Classes of Service”, which simply mean that we will treat things differently according to their specific characteristics.”
• “Using classes of service gives you the opportunity to handle each item in a rational way, according to its economic impact, instead of resolving to panic and fire fighting. It also means we can make different promises to our custo- mers, depending on the class of service we are handling.”
• Agile Decision filter
  • “Are we making progress with imperfect information?”
  • “Are we encouraging a high trust culture?”
  • “Are we treating WIP as a liability rather than an asset?”
• Lean Decision filter
  • “Value trumps flow”
  • “Flow trumps waste elimination”
  • “Eliminate waste to improve efficiency”
• Optimize flow
  • “Are you working with the right WIP limits?”
  • “Can you find a way of making the size of user stories smaller?”
  • “Is there a way to identify features that explode in size, before they are introduced into your system and end up blocking capacity for long periods of time?”
  • “Can you level out the size of user stories to create a more continuous flow?”
  • “Can you train for flexibility to avoid silos and easier relieve bottlenecks?”
  • “Have you got adequate buffers in place to handle variation?”
  • “Are you looking at optimizing the whole and not individual stages?”
• “Removing non-value adding work is by far the most effective way to relieve a bottleneck.”
• “If you know that there is a bottleneck in your system, it is also good to intro- duce an appropriate buffer in front of it to make sure that the bottleneck is rarely drained.”
• Kent Beck said, “if you have got a problem that cannot be fixed by working overtime for a week, you have a problem that cannot be fixed by working overtime anyway”.
• “If you treat your different classes of service the same way every time and measure the consequence of your improvement efforts, chances are that cycle time, quality and cost will only improve over time.”
• Based on metrics collected on team’s performance on various class os service can enable establishment of service level agreements (SLA)
• “For many customers, this information [SLA] is highly valuable in terms of prioritization and in experiencing that these numbers hold true, this gives an amount of trust and collaboration far beyond what most have experienced in prior projects. Also, this will show the direct benefit of breaking work down into smaller sizes, both in terms of risk, cost and cycle time.”

Advertisement