#booksummary
Title::  Kanban - Successful Evolutionary Change for Your Technology Business
Author:: Anderson, David J.
Rating:: 4
Category:: #AgileAndCollab
Summary:: 
RelatedBooks:: 
Link:: https://www.goodreads.com/book/show/8086552-kanban
Published:: 2010
Read:: 2020-12-30
Image::

kanban as a Complex Adaptive System for Lean is intended to catalyze a Lean outcome within organization. Complex adaptive systems have initial conditions and simple rules that are required in order to seed complex, adaptive, emergent behavior.

5 Properties of kanban:

1. Visualize workflow

2. Limit Work in Progress / WIP;
3. Measure and Manage FLow;
4. Make Process Policies Explicit;
5. Use Models to Recognize Improvement Opportunities

kanban is acting as a permission giver in the software development profession, encouraging teams to devise context-specific process solutions rather than dogmatically following a software development lifecycle process definition or template.

Recipe for success for kanban with 6 steps, presents guidelines for a new manager adopting an existing team. Following the recipe enables quick improvement with low levels of team resistance. These six steps are:

1. Focus on Quality
2. Reduce Work-in-Progress
3. Deliver Often
4. Balance Demand against Throughput
5. Prioritize
6. Attack Sources of Variability to Improve Predictability
   I want to acknowledge here the direct influence of Donald Reinertsen, who gave me the first two and the last steps in the recipe, and the indirect influence of Eli Goldratt, whose writings on the Theory of Constraints and its Five Focusing Steps greatly influenced steps four and five.

Kaizen or continuous improvement is very important in kanban. Kaizen culture is one in which individuals feel empowered, act without fear, affiliate spontaneously, collaborate, and innovate. Kaizen culture has a high degree of social capital and trust between individuals, regardless of their level in the corporate hierarchy.

Kanban WIP Limits enable “stop the line” behavior. Kanban WIP limits and Classes of Service empower individuals to pull work (Pull System) and make prioritization and scheduling decisions without supervision or direction from a superior.

Increased levels of empowerment increase social capital and trust among workers and managers.

Issue management, escalation, and resolution is a core discipline in improving the performance of a team and should be addressed early in the development of the team. Escalation paths and policies should be clearly defined.

kanban decouples Delivery Cadence from both development lead time and prioritization cadence. Efficiency and cadence can be increased by focusing on reducing the transaction and coordination costs.

Prioritization Cadence means an agreed-upon regular interval between meetings to prioritize new work into the input queue for development.

Learning/Kanban/Prioritization of new work requests such as user stories involves coordination of many people from various functions. All of this coordination has a measurable cost.

Prioritization Cadence can be established by encouraging those involved in prioritization decision making to meet as regularly as is reasonable based on the transaction and coordination costs involved.

Efficiency and Prioritization Cadence can be increased by focusing on reducing its transaction and coordination costs. Frequent Learning/Kanban/Prioritization meetings build trust. Scheduling regular prioritization meetings reduces coordination costs and is particularly useful in lower-maturity organizations. Ad hoc or on-demand prioritization can make sense for high maturity organizations with established high levels of trust and with low transaction and coordination costs associated with the policies for prioritization decision making.

With a kanban system, most or all stations in the workflow have Kanban WIP Limits. This has a potential advantage because impediments caused by unexpected, unanticipated variability may cause an upstream step to become a temporary bottleneck. The local WIP limit with the Kanban system will stop the line quickly, keeping the system from clogging and becoming overloaded. When the impediment is removed, the system will then restart gracefully.

WIP limits should be agreed upon through consensus with Upstream Kanban and Downstream Kanban stakeholders and senior function management. Unilateral declaration of Kanban WIP Limits is possible but may prove difficult to defend later, when the system is placed under stress.

Bottlenecks should be buffered, kanban is empirical process. All Kanban WIP Limits should be adjusted empirically, and the capacity can be allocated across work item types

Kanban Classes of Service should be clearly, visually displayed. They offer a shorthand method for optimizing customer satisfaction. A set of management policies should be defined for each class of service. Only classes of service related to riskier items should involve wasteful activities such as estimation.

Kanban Classes of Service are typically defined based on business impact. The most common example is 4 classes of services, but you may have more, although more than 6 is not recommended. Too many become too complicated to administer and operate. Those Classes of Service are: Expedite; Fixed Delivery Date; Standard Class; Intangible Class.

Example for Policies for Class of Service for Kanban Classes of Service: Expedite Class; Fixed Delivery Date Class; Standard Class and Intangible Class
- Expedite Class Policies for Expedite Class
- Expedite requests use white cards.
- Only one expedite request is permitted at any given time. In other words, the Expedite class of service has a WIP limit of 1.
- A qualified resource must pull Expedite requests immediately. Other work will be put on hold to process the expedite request.
- At any point in the workflow, the WIP limit may be exceeded in order to accommodate the expedite request. Capacity is not being held in reserve for expediting.
- If necessary, a special (off-cycle) release will be planned to put the expedite request in production as early as possible.
- Fixed Delivery Date Class Policies for Fixed Delivery Date Class
- Fixed delivery date items use purple cards.
- The required delivery date is displayed on the bottom right-hand corner of the card.
- Fixed delivery date items receive some analysis and an estimate of size and effort may be made to assess the flow time. If the item is large it may be broken up into smaller items; each smaller item will be assessed independently to see whether it qualifies as a fixed delivery date item
- Fixed delivery date items are held in the backlog until they are selected for the input queue, close to the ideal point in time at which they can be delivered on time given the flow-time estimate.
- Fixed delivery date items are pulled in preference over other, less risky items. In this example, they are pulled before standard or intangible class items.
- Fixed delivery date items must adhere to the WIP limit.
- Fixed delivery date items queue for release when they are complete and ready for release. They are released in a regularly scheduled release just prior to their required delivery date.
- If a fixed delivery date item gets behind, and release on the desired date is at risk, its class of service may be promoted to an expedite request.
- Standard Class Policies for Standard Class
- Standard class items use yellow cards.
- Standard class items are prioritized into the input queue based on an agreed-upon mechanism, such as democratic voting, and are typically selected based on their cost of delay or business value.
- Standard class items use first in, first out (FIFO) queuing as they are pulled through the system. Typically, when given an option, a team member pulls the oldest standard class item if there is no expedite or fixed date item to choose in preference.
- Standard class items queue for release when they are complete and ready for release. They are released in the next scheduled release.
- No estimation is performed to determine a level of effort or flow time.
- Standard class items may be analyzed for order of magnitude in size, typically, small (a few days), medium (a week or two), and large (perhaps months).Classes of service should be clearly, visually displayed by using, for example, different colored cards to represent the class of service or different swim lanes on the card wall.
- Large items may be broken down into smaller items. Each item may be queued and flowed separately.
- Standard class items are generally delivered within x days of selection with a due date performance of m percent.
- A typical standard class service-level agreement might offer a 30-day lead time with 80 percent due-date performance. In other words, four out of five requests should be delivered within 30 days.
- Intangible Class Policies for Intangible Class
- Intangible class items use green cards.
- Intangible class items are prioritized into the input queue based on an agreed-upon mechanism, such as democratic voting, and are typically selected based on some longer-term impact or cost of delay.
- Intangible class items are pulled through the system in an ad hoc fashion. Team members may choose to pull an intangible class item regardless of its entry date, so long as a higher-class item is not available.
- Intangible class items queue for release when they are complete and ready for release. They are released in the next scheduled release or are held to be assembled with other items.
- No estimation is performed to determine a level of effort or flow time.
- Intangible class items may be analyzed for size. Large items may be broken down into smaller items. Each item may be queued and flowed separately.
- Typically, an intangible class item is put aside in order to process an expedite request.
- It may not be necessary to offer a service-level agreement with intangible class items. If it is necessary, it should be a significantly looser agreement than that offered for standard class items, for example, 60 days with 50 percent due-date performance.

• Kanban Classes of Service enable self-organization, empower team members and free up management time to focus on the process instead of the work. They also change customer psychology.

• If Kanban Classes of Service are used properly and combined with a regular delivery cadence, very few complaints are likely to be received, even if a significant portion of items miss their target lead time.

• In kanban epic level user stories or customer requirements were often written at a level such that they made sense to release to the market. Were the product already in maintenance, these requests may have been processed and released individually. Sometimes the Kanban community refers to this level of requirements as a “Minimum Marketable Feature - MMF” There is some confusion, asMinimum Marketable Feature - MMF was defined by Denne and Cleland-Liang in their book Software by Numbers, and their definition isn’t strictly adhered to. Anderson, David J. would prefer a definition of a Minimum Marketable Release - MMR that describes a set of features that are coherent as a set to the customer and useful enough to justify the costs of delivery.

• kanban supports at least three types of Continuous Improvement Methods: Constraint Management (bottleneck removal), Waste Reduction, Variability Management (as well as SPC - Statistical Process Control and the Learning/Kanban/System of Profound Knowledge by Deming, William Edwards

• kanban enables the identification of bottlenecks and a full implementation of the Five Focusing Stepsfrom the Theory of Constraints.

• kanban enables visualization of wasteful activities and can be used to enable a full Lean initiative within the software, system, product development, or IT organization.

• Kanban Bottlenecks constrain and limit flow of work. They come in 2 varieties: Capacity Constrained Bottleneck (unable to do more work); and Non-Instant Availability Bottleneck (limited capacity due to limited, but usually predictable availability).

• We manage Kanban Bottlenecks by using Five Focusing Steps and implementing exploitation and subordination actions and protection and elevation. Exploitation should always be pursued first, before elevation is attempted.

  • It is not unusual for a tactical set of exploitation and subordination actions to be implemented while a plan for a strategic change to elevate a constraint is implemented over a longer period of time
  • Exploitation, protection, and subordination actions are often easy and cheap to implement, as they primarily involve policy changes. Hence, maximizing the throughput of a bottleneck by fully exploiting it can be viewed as tactical process improvement.
  • 1. Increasing the capacity at a bottleneck is known as elevation action. Elevation may involve adding resources, or automation, or policy changes that make a previously non-instantly available resource instantly available (these usually cost money and take time to implement).
  • 2. Exploitation actions typically involve policy changes that control the work done by the bottleneck resource. Classes of Service can be used as exploitation actions.
  • 3. Protection actions usually involve adding a buffer of WIP in front of the bottle- neck. This is true for capacity-constrained resources or non-instant availability resources.
  • Subordination actions are actions taken elsewhere in the value stream to enable the desired exploitation or protection actions. Subordination actions are typically policy changes.

---

#bookreview
BookTitle:: Kanban Successful Evolutionary Change for Your Technology Business
BookAuthor:: Anderson, David J.
BookRating:: 5/5
BookThemes:: Systematic overview over Kanban, service classes, practical implementation and more
BookTakeaways:: On the book page
BookTags:: Agile Lean Kanban
BookRelatedBooks:: Personal Kanban - Mapping Work, Navigating Life
BookLink:: https://www.goodreads.com/book/show/8086552-kanban
BookDateRead:: 2022-08-15