Culture Change and Example Goals for Kanban Adoption
Major managed change initiatives, including Agile, follow a pattern:
- Conduct current state assessment
- Select new process (e.g. RUP, Agile)
- Train people and transition to the new process
- Assess adoption and results
- Declare victory
With Kanban, there is:
- No planned initiative i.e. the to be state is not yet known
- No assessments, and
- No declaration at the end that, “Now we are Agile!”
- Ideally, there is no end.
Although our main goal with Kanban is to introduce change with minimal resistance, there must be other goals. These other goals should reflect genuine business needs such as high-quality, predictable delivery. The goals listed here are intended as examples. The specific goals for your organization may differ. Step 1 in your process should be to agree on the goals for introducing Kanban into your organization.
The Primary Goal: Goal 1 - Optimize Existing Processes
Optimized existing processes through the introduction of visualization and limiting work-in-progress, while respecting coordination and transaction costs, to catalyze changes. As existing roles and responsibilities do not change, resistance from employees should be minimal.
The Secondary Goals: Goal 2 Deliver with High Quality
Kanban helps us focus on quality by limiting work-in-progress and allowing us to define policies around what is acceptable before a work item can be pulled to the next step in the process.
Goal 3 Improve Lead Time Predictability
We know that the amount of WIP is directly related to lead time and that there also is a correlation between lead time and a non-linear growth in defect rates. So it makes sense that we want to keep WIP small. It makes our lives easier if we simply agree to limit it to a fixed quantity. This should make lead times somewhat dependable and help us to keep defect rates low.
Goal 4 Improve Employee Satisfaction
Although employee satisfaction often gets lip service in most companies, it is seldom a priority. Investors and senior managers all too often take the view that resources are fungible and easily replaced. This reflects a cost-centric bias in their management or investment approach. It doesn’t take into account the huge impact on performance that comes with a well motivated and experienced workforce.
Goal 5 Provide Slack to Enable Improvement
When you balance the input demand against the throughput, you create idle time at every point in your value chain except at the bottleneck resource. Without slack:
- There is no liquidity in the system to respond to urgent requests or late changes.
- There is no tactical agility in the business
- Team members cannot take time to reflect upon how they do their work and how they might do it better
- They cannot take time to learn new techniques, or to improve their tooling, or their skills and capabilities
Goal 6 Simplify Prioritization
Once a team is capable of focusing on quality, limiting WIP, delivering often, and balancing demand against throughput, they will have a reliable, trustworthy, software development capability: an engine for making software! How do we use this power?
To do this requires a prioritization method that maximizes business value and minimizes risk and cost.
Software and Project management use many techniques: MoSCow, Kano, force ranked sequential prioritization by business value and technical risk. Reprioritizing hundreds of requirements, stories etc. is hard. The business value of often uncertain. Evaluating value vs. technical risk can create counterproductive conflict. Asking people complex questions answered using uncertain criteria is problematic:
- They may move slowly or refuse to cooperate.
- They may become uncomfortable and dysfunctional: thrashing and constantly changing their minds, randomizing project plans, and wasting a lot of team time reacting to the changes.
What is needed is a prioritization scheme that delays commitments as long as possible and that asks a simple question that is easy to answer.
Kanban provides simple prioritization by:
- asking the business owners to refill empty slots in the queue while...
- ... providing them with a reliable lead-time and due-date performance metric.
Goal 7 Provide a Transparency on the (holistic Kanban) System Design and Operation
Build trust and confidence with customers and senior management with transparency into:
- Work-in-progress, the delivery rate (throughput)
- Where a request is within the system and when it might be finished, and its quality
- The team's techniques providing predictable performance (shared with management)
There is a second-order effect from all of this transparency that I hadn’t predicted. Transparency into the process and how it works has a magical effect. It lets everyone involved see the effects of their actions or inactions. As a result, people are more reasonable they:
- Change their behavior to improve the performance of the whole system.
- Collaborate on required changes in policy, personnel, staff resourcing levels, and so forth.
Goal 8 Design a Process to Enable Emergence of a “High-Maturity” Organization
For most senior business leaders that I speak to, this final goal really represents their wishes and expectations for their businesses and their technology development organizations. They seek predictability above all else, coupled with business agility and good governance.
Business leaders want to be able to make promises to their colleagues around the executive committee table, to their boards of directors, to their shareholders, to their customers, and to the market in general, and they want to be able to keep those promises. Success at the senior-executive level depends a lot on trust, and trust requires reliability. Above all else, senior leaders want risk managed appropriately so that they can deliver predictable results.
12 Steps To Getting Kanban Change Started
- Agree on a set of goals for introducing Kanban.
- Map the value stream (the sequence of all the actions the development organization carries out to fulfill a customer’s/ stakeholder’s request). (See chapter 6.)
- Define some point where you want to control input. Define what is upstream of that point and who the upstream stakeholders are (explained in chapter 6). For example, do you wish to control requirements arriving at the design team pre-production? The upstream stakeholders might be product managers.
- Define some exit point beyond which you do not intend to control. Define what is downstream of that and who the downstream stakeholders are (explained in chapter 6). For example, maybe you don’t need to control the delivery fulfillment of the product.
- Define a set of work item types based on the types of work requests that come from the upstream stakeholders (explained in chapter 6). Do you have some item types that are time-sensitive and others that are not? If so, then you may require some classes of service (explained in chapter 11).
- Analyze the demand for each work item type. Observe the arrival rate and variation. Is the variation seasonal or event-driven? What risks are associated with this type of demand? Should the system be designed to cope with average or peak demand? What is the tolerance for late or unreliable delivery of this type of work? Create a risk profile for the demand. (Explained in chapter 6.)
- Meet with the upstream and downstream stakeholders— this might be one big meeting, or it might be lots of little meetings. (Explained in more depth later in this chapter.)
- Discuss policies around capacity of the piece of the value stream you want to control and get agreement on a WIP limit (explained in chapter 10).
- Discuss and agree on an input-coordination mechanism, such as a regular prioritization meeting, with the upstream partners (explained in chapter 9).
- Discuss and agree on a release/ delivery-coordination mechanism, such as a regular software release, with the downstream partners (explained in chapter 8).
- You may need to introduce the concept of different classes of service for work requests (explained in chapter 11).
- Agree on a lead-time target for each class of service of work items. This is known as a service-level agreement (SLA) and is explained in chapter 11.
Kanban's Different Kind of Bargain
Traditional project management makes a promise based on the triple constraint of scope, schedule, and budget. After some element of estimation and planning, a budget is set aside to provide resources, and a scope of requirements and schedule are agreed upon.
Agile project management typically sets resources, and schedule and may set high-level project scope but does not identify all of the details, allowing them to vary. Teams then deliver on a cadence, weekly to monthly. They commit to scope for each cadence with the understanding that scope may be reduced if they can not meet the commitment.
Kanban does not offer a commitment on a certain amount of work delivered on a certain day. It offers a commitment against the service-level agreements for each class of service, underpinned with a commitment to reliable regular delivery, transparency, flexibility on prioritization and processing, and continuous improvement on quality, throughput, frequency of delivery, and lead time. Kanban offers to a commitment to a level of service, balancing risk through aggregation across a larger quantity of items.
Because the customer recognizes an ongoing, long-term relationship, if the customer is willing to measure the service level rather than hold the team to precision on any one item, the system can be made to work.
The traditional approach to forming a commitment around scope, schedule, and budget is indicative of a one-off transaction. It implies that there is no ongoing relationship; it implies a low level of trust. The Kanban approach is based on the notion that the team will stay together and engage in a supplier relationship over a long period of time.
Striking the bargain
To establish this new stakeholder relationship we need to discuss and agree with them on the five critical system elements of WIP, prioritization, delivery cadence, classes of service, and lead time. Without this agreement, day to day pressures will likely cause the organization to revert to its old ways. Build a mutual understanding of these items and their value. These practices work synergistically and need to be addressed together.
The upstream conversations
Discussing WIP:
- Context switching costs
- Lead time reduction e.g. recognize and address bottlenecks
- Quality improvement e.g. cost of poor quality
- How we address special situations e.g. handling expedited items without destabilizing the system
Discussing prioritization:
- Frequent, short meeting matching the cadence of work completion
- Simple question: pick an item for the open slot and a class of service
Adding downstream stakeholders
Discuss deployment and release:
- Impact of coordination and transaction costs
- Release cadence of the business domain
- Deployment vs. customer release
Discuss lead time and classes of service:
- Leverage empirical analysis to set context
- Discuss usefulness of targets vs commitment: e.g. buffers needed to reliably meet every commitment
- Identify work items types with high costs of delay and how to address them with classes of service without destabilizing the system
- Discuss addressing uncertainty and its organizational impacts by using aggregate service level measures and targets rather than item by item approach
The exit criteria for your partner discussions is this: You have a consensus on WIP limits along the value stream; you have an agreement on prioritization coordination and the method to be used; you have a similar agreement on delivery coordination and method; and you have a definition of a set of service-level agreements that include a target lead time for each class of service.
Part 6
Part 6
No comments:
Post a Comment
Please no spam, advertisements, or unrelated personal discussions.