Mapping the Value Stream
Kanban is applied to large projects and maintenance teams. David uses the simpler maintenance team construct to describe the basics from value stream mapping, cadences, and policies to metrics and reporting.
1. Start with a team
Map their value stream and not the organization's. Their value stream is made up of the fundamental steps that make up their day to day work. Document what is and not what should be. The team may feel the need for you to document the formal process they are supposed to follow, the "standard," avoid this. Also, avoid documenting an "ideal" process.Everything from which the team members and other partners, participants, and stakeholders derive their self-esteem, professional pride and ego should be left unchanged. The main target of change will be the quantity of WIP and the interface to and interaction with upstream and downstream parts of your business.
2. Establish your process's boundaries
Set the boundaries based on the steps within team's control. For example, you may control analysis, design, coding and testing but not requirements definition, deployment to higher environments etc. Set WIP within these boundaries. Experience shows that imposing these visualizations, limits etc. on partners tends to fail. Beginnings are sensitive times so tread lightly until you've built trust through performance improvement.3. Identify the team's work item types and demand levels
Identify the inputs to the entry point boundary set in step 2 then add those you generate. These inputs may be atomic, like a production defect, or hierarchical say a feature and its stories. You might generate refactoring work, maintenance tasks, blocking issues etc.
Determine the typical demand for each of the types. For example, you may see that 60% of your work is change requests, 10% maintenance, and 30% text changes.
4. Visualize the flow of work using a card wall
Start with a model of the activities the team performs. Models may range from statecharts to boxes and lines with stick people drawn on a white board. Avoid modeling roles as work though they may overlap e.g. develop and test. Cross functional team members often help each other and so activities are typically more stable as teams mature.
The norm is to document the flow of work from left to right on the card wall. If some of the work steps don't have a specific order i.e. can be done in different sequences, then don't force one. There are a variety of approaches to handle this as well as concurrent work and demand groupings (see the example pictures below). Finally, buffers and queues may also be shown. We'll look at WIP limits later.
Anatomy of a card
The work process step, the work item, the person(s) working the card are there. Levels of service, SLA's, and other concepts are referenced. We'll them discuss later.
A central cultural point: why?
The overall goal here is to create the conditions of team empowerment. The relevant information needed to make day to day "management" decisions is visible. The process, who's doing what, what's blocked, what should be given priority, what to work on next etc. is all covered. Given this information, the majority of day to day decision making can be owned by the team.They are organizing their own work or as Dave puts it: Kanban, by empowering team members to make their own scheduling and prioritization decisions, shows respect for individuals and a trust in the system (or process design.) A well-designed work item card is a key enabler of a high-trust culture and a Lean organization.
Kanban Cadences
Kanban cadences, while similar to Scrum\XP cadences, are more loosely coupled. Prioritization (estimating stories, planning), Development Lead Time (think coding, testing, demoing), and Delivery (release planning, go-live) run a bit more in parallel than in sequence. In scrum and XP the sprint or iteration generally sets the cadence of coordination meetings: sprint planning, daily scrum, sprint review, sprint retrospective. A kanban cadence is not based on a time-boxed sprint or iteration. A kanban cadence is based on the continuous flow of work across the value stream - regardless of the steps in the process. To limit coordination costs its meeting cadences are optimized to the flow of work.
Kanban and Scrum\XP share the heartbeat of the daily stand up and address similar concerns but do so in subtly different ways. To simplify the summary I'll draw a few more parallels than the book does so less explanation is needed. Don't let the comparison mislead you - remember kanban is not a really a delivery process, it is a means of improving delivery processes. So, don't expect it to cover everything you'll need to stand up a "kanban" team. The distinction is a bit nebulous.
The Pull Signal
A team uses a kanban board to coordinate pulling cards across their value stream or process. The board below is one example. The number at the top of each column indicates the kanban limit for that step of the process. When a team member sees the number of cards in a column fall under its limit, they pull a card from the previous step and begin working on it. This is the pull signal of the kanban pull system.
In this case, the color of the cards are showing working item type and the class of service applied to the card. For this team, the delivery date SLA along with who's doing the work is also captured.
A big visual board makes it easy for the team to understand and manage their work. An electronic version of the board makes tracking metrics easier. Teams may opt to use both a physical and an electronic version of the board and attach the work item number from the electronic version to each card. Teams who only use an electronic board typically have a big screen or projection TV to ensure they can always see and read the board.
Multi-location or distributed kanban teams are common and rely on an electronic board. Teams, including distributed teams, often prefer a physical board as it is larger, more configurable, and easier to see and use. Keeping the boards in synch must be managed. Having "sticky buddies" to move cards on the physical wall(s) across locations when they change is one way of keeping things in synch. For example, if Patricia is working from home Ian may move her card for her after she messages him in Slack or some other chat system.
Daily Stand Up, After Meeting, Issue Log Reviews
David's kanban recommends a daily stand up. Like a typical scrum meeting, it is intended to be short and focused on coordinating the day's work. Since the board is intended to signal card pull status, blockers, timeliness etc. the meeting doesn't typically answer the three questions "what you've done, what you'll do, impediments?" Instead, a facilitator may walk the board from right to left (the direction of pull), bring attention to items of note, focus on blockers etc. This approach allows the meeting to scale to larger teams e.g. 50 people, while still being effective and taking ten to fifteen minutes to complete.
The after meeting is similar to the common practice of agile team's to only dive into specific details after the stand-up. It is different in that there is a common practice to discuss issues, blockers here rather than in iteration retrospectives. The retrospectives described in the book are more at an organizational or project level. The focus on continuous improvement remains aided by Issue Log Reviews.
Issue log review and escalations should happen frequently, such as on a weekly or bi-weekly cadence. In this review the team and relevant impacted stakeholders go through all open issues, discusses who owns them, progress made, alternatives etc.
Input Queue Replenishment Meeting
The Input Queue Replenishment Meeting is similar to an iteration or sprint planning meeting. While the meeting doesn't focus on a Sprint Goal it does bring team members and stakeholders together to pick items from a card backlog to place into the system. Stakeholders might include product owners, business people, architects, technical managers etc. The estimation may happen prior to or in this meeting. The goal is to ensure the most valuable work is prioritized to be done first.
Establishing the Replenishment Meeting's Cadence
The cadence of this meeting is critical as its frequency reflects the pace of work moving through the system. Given kanban's goals of reducing delivery cycle time, WIP etc., the recommendation is to meet as frequently as reasonable e.g. commonly weekly. This implies at least some work completes each week.
An entire chapter is dedicated to this topic. The focus is on recognizing and appropriately managing the coordination and transaction costs of prioritization, estimation etc. The context of the discussion is a case study in which a team provided small enhancements, bug fixes via maintenance releases.
The team served 7 strategic business units. Coordination was complex and time-consuming. This cost was high due to reduced time to market and hours spent by executives, managers, etc. prioritizing work. Transaction costs were high as the team estimated a large number of backlog items for each replenishment meeting. Data analysis showed a majority of requests were of a similar size so estimation was often not value added. The variability in size allowed a majority of the requests to meet a delivery SLA the business was comfortable with. They stopped estimating.
The team's delivery performance improved the business' became familiar with the delivery process and concepts. Over time they agreed upon a set of value driven policies that significantly reduced their need to meet and discuss prioritization. Mature organizations in some circumstances are able to establish equitable policies, e.g. round robin access to the input queue, which may reduce coordination costs to near zero.
Release Planning Meeting
The release planning meeting is a direct analog to typical Agile release planning meetings. Its cadence is tied to the business' desired frequency of releasing features to customers. Note that this book was released at about the same time as Continuous Delivery by Farley and Humble. So there is no clear distinction between deployment and release in the book.
Establishing the Release Cadence
Kanban emphasizes a regular release cadence to deliver value and build trust with business partners and other stakeholders. Coordination costs, transaction costs, and likely business value of releases, modeled as release efficiency, determines the cadence.
Coordinating every software delivery has costs. It’s necessary to get people together to discuss the deployment (or release), manufacture, packaging, marketing, marketing communications, documentation, end-user training, reseller training, help-desk and technical support training, installation documentation, installation procedures, staff on-call, on-site schedules during deployment, and so on, and on. Planning the release of a piece of working software can be incredibly complex, depending on the nature of the business domain and the type of software. Upgrading a website can be quite trivial compared to upgrading firmware deployed in military equipment spread across the globe, or satellites in orbit, or fighter aircraft, or the nodes in a telephone network.
Transaction costs: In software development, the transaction costs of delivery can also be physical in nature. Some firms, such as Microsoft, still “release to manufacture” (RTM) and print physical media, such as DVDs, and box them up and ship them to distributors, retailers, and other partners. With embedded software, it may be necessary to manufacture a set of chips, or, at least, to “blow” the software code into firmware using technology like EE-PROM. The chips, if necessary, would then need to be physically mounted into the hardware that they control.
The process may involve simply copying files to a server or 1000 servers. No one size fits all but all deployments have costs.
Release Efficiency Cost Model:
Delivery Efficiency% = 100% x (Total Cost – (Coordination Cost + Transaction Cost) ) / Total Cost of Software Release
In this example, our efficiency percentage is
100% x ($ 1,500,000— $ 500,000) / $ 1,500,000 = 66.7%
To be more efficient we have to (a) increase the time between deliveries, or (b) reduce the coordination and transaction costs. Choice (a) is the typical choice of twentieth-century Western business. It is the choice that values “economy of scale”: Do things in larger batches in order to amortize the costs over longer periods of time. Choice (b) is the typical choice of late twentieth-century Japanese businesses and businesses pursuing Lean Thinking. Choice (b) focuses on reducing waste by reducing coordination and transaction costs in order to make the batch size efficient— in this case, to make the time between releases efficient.
How much efficiency is enough? This really is an open question. Each business will have separate views on suitable numbers for efficiency, and a lot will depend on the value to be delivered.
Release Efficiency Value Model:
The value model is more complex as the value may be intangible and hard to quantify.
Delivery Efficiency% = 100% × (1 - (( Transaction Costs + Coordination Costs) / (Margin + Transaction Costs + Coordination Costs)))
For our working example, this would produce an efficiency percentage of
100% × (1-( $ 500,000 / ($ 500,000 + $ 500,000))) = 50%
Release Cadence Takeaway
The key point is not to require every release decisions to be driven by a potentially complex formula. The point is to do sufficient analysis to make an informed decision and then to continuously improve your ability to deliver value and reduce waste.
Reducing coordination and transaction costs is at the heart of Lean. It is waste elimination in its most potent form. It allows smaller batches to become efficient. It enables business agility. Reducing coordination and transaction costs is game changing. However, do not simply focus on reducing them. Reduce them with a goal in mind— to make more frequent deliveries of working software and thereby deliver more value to your customers more often.
Part Three
Part Three
No comments:
Post a Comment
Please no spam, advertisements, or unrelated personal discussions.