Goals for using Kanban
At the formation meeting of the Lean Software and Systems Consortium, Dean Leffingwell challenged me with the question, “What are the goals when choosing to use Kanban?” I struggled to articlulate an answer off the top of my head as I hadn’t thought about it that way. I found just a week later that I had to answer Dean’s question in order to complete Chapter 5 of my Kanban book manuscript, “Getting Started with Kanban.” A later part of this chapter appeared a few days ago on my blog, How to Start with Kanban. The remainder of this post is yet another extract from Chapter 5…
The Primary Goal for our Kanban System
We are doing Kanban because we believe it provides a better way of introducing change. Kanban seeks initially to change as little as possible. So change with minimal resistance must be our first goal.
Goal 1. Improved performance through process improvements introduced with minimal resistance
Secondary Goals for our Kanban System
We’ve learned that Kanban allows us to deliver on all 5 elements of the Recipe for Success. However, we might want to word the goals slightly differently from the wording in the recipe and some of the points in the recipe need to be expanded to reflect that one point can help us deliver on more than one goal.
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. These policies can include quality criteria. If, for example we set a strict policy that user stories cannot be pulled into acceptance test until all other tests are passing and bugs resolved, then we are effectively “stopping the line” until the story is in good enough condition to continue. With a new team doing Kanban we may not have such a strict rule but there should be some policies relating to quality that focus the team on developing working code with low numbers of defects.
Goal 3. Deliver a predictable cycle time by controlling the quantity of work-in-progress
We know that WIP is directly related to cycle time and that there is also a correlation between cycle time and a non-linear growth in defect rates So it makes sense that we want to keep WIP small. It makes our life easier if we simply agree to limit it to a fixed quantity. This should make cycle times somewhat dependable and help us to keep defect rates low.
Goal 4. Give team members a better life through improved work/life balance
While 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. Staff retention is important. As the population of software developers ages, they care more about the rest of their lives. Many lament wasting their 20s locked up in an office slaving over a piece of code that failed to reach market expectations and became obsolete a short period later.
Work/life balance isn’t only about balancing the number of hours someone spends at work with the number of hours they have available for their family, friends, hobbies, passions and pursuits. It is also about providing reliability. For example, a team member with a passion for art wants to take a painting class at the local middle school. It starts at 6.30pm and runs every Wednesday for 10 weeks. Can your team provide certainty to that individual that they’ll be free to leave the office on-time each week in order to attend the class?
Providing a good work life balance will make your company a more attractive employer in your local market. It will help to motivate employees and it will give your team members the energy to maintain high levels of performance for months or years. It’s a fallacy that you get top performance from knowledge workers when you overload them with work. It might be true tactically for a few days but it isn’t sustainable beyond a week or two. It’s good business to provide a good work/life balance by never overloading your teams with too much work.
Goal 5. Provide slack by balancing demand against throughput
While the 3rd element of the Recipe for Success - Balance Demand against Throughput - can be used to avoid overloading team members and allow them a reliable work/life balance, it has a second effect. It creates slack in the value chain. There must be a bottleneck in your organization. Every value chain has one. The throughput delivered downstream is limited to the throughput of the bottleneck, regardless of how far upstream it might be. Hence, when you balance the input demand against the throughput, you create idle time everywhere in your value chain with the exception of the bottleneck resource.
Most managers baulk at the idea of idle time. They’ve generally been trained to manage for utilization (or “efficiency” as it is often called) and inherently it feels like changes can be made to reduce costs if there is idle time. This may be true but it is important to appreciate the value of slack.
Slack can be used to improve responsiveness to urgent requests and to provide bandwidth to enable process improvement. Without slack team members cannot take time to reflect upon how they do their work and how it might be done better. Without slack they cannot take time to learn new techniques, to improve their tooling or their skills and capabilities. Without slack there is no liquidity in the system to respond to urgent requests or late changes. Without slack there is no tactical agility in the business.
Goal 6. Provide a simple prioritization mechanism that delays commitment and keeps options open
Once a team is capable of focusing on quality, limiting WIP and delivering often, and balancing demand against throughput, they will have a reliable, trustworthy, software development capability: an engine for making software! A “software factory” if you will! Once this capability is in place it would behoove the business to make optimal use out of it. To do this requires a prioritization method that maximizes business value, and minimizes risk and cost. Ideally a prioritizations scheme that optimizes the performance of the business (or technology department) is most desirable.
The software engineering and project management fields have been developing prioritization schemes since software projects began perhaps 50 years ago. Most of the schemes are simple. For example, “High, Medium, Low” provides three simple classifications. None of these have any direct meaning for the business. Some more elaborate schemes came into use with the arrival of Agile software development methods such as MoSCoW (“Must have”, “Should have”, “Could have”, “Won’t have.”) Other methods such as Feature Driven Development featured a modified and simplified version of the Kano Analysis technique popular amongst Japanese companies. Yet others advocated strict enumerated order (1, 2, 3, 4, ...) by business value or technical risk. The challenge with this latter scheme is that it often creates a conflict between the high risk items that should be prioritized first and the high value items that should also be prioritized first.
All of these schemes suffer from one fundamental problem. In order to respond to change in the market and evolving events, it is necessary to reprioritize. Imagine for example you have a backlog of 400 requirements prioritized in a strict enumerated order 1 to 400 and you are doing incremental delivery with an Agile development method in one month iterations. Every month you have to reprioritize the remaining backlog of up to 400 items.
In my experience, asking business owners to prioritize things is challenging. The reason for this is simple: there is so much uncertainty in the marketplace and the business environment. It’s hard to predict the future value of one thing against another, when something might be needed and whether something else might be more valuable to have earlier. Asking a business owner to prioritize a backlog of technology system requirements is to ask them a very hard set of questions of which the answers are uncertain. When people are uncertain they tend to react badly. They may move slowly. They may refuse to cooperate. They may become uncomfortable and dysfunctional. They may simply react by thrashing and constantly changing their minds, randomizing project plans and wasting a lot of team time reacting to the change.
What is needed is a prioritization scheme that delays commitments as late as possible and provides a simple question that is easy to answer. Kanban provides this by asking the business owners to refill empty slots in the queue while providing them a reliable cycle time and due date performance metric.
We already have 6 lofty and valuable goals for our Kanban system and for many businesses that might be enough. However, I and other early adopters of Kanban have discovered that two other even loftier goals are both possible and desirable.
Goal 7. Provide a transparent scheme for seeing improvement opportunities enabling change to a more collaborative culture that encourages continuous improvement
When I first started to use Kanban systems, I believed in transparency on the work-in-progress, the delivery rate (throughput) and the quality because I understood that it built trust with customers and more senior management. I was providing transparency onto where a request was within the system, when it might be finished and what quality was associated with it. I was also providing transparency into the performance of the team. I did this to provide customers with confidence that we were working on their request and when it might be completed. In addition, I wanted to educate senior management on our techniques and performance and build their confidence in me as a manager and my team as a well formed professional group of software engineers.
There is a second order effect from all of this transparency that I hadn’t predicted. While transparency onto work requests and performance is all very well, transparency into the process and how it works has a magical effect. It lets everyone involved see the effects of their actions. As a result people are more reasonable. They will change their behavior to improve the performance of the whole system. They will collaborate on required changes in policy, personnel, staff resourcing levels and so forth.
Goal 8. A process that will enable predictable results, business agility, good governance and the development of what the Software Engineering Institute calls a “high maturity” organization
For most senior business leaders that I speak to, this final goal really represents their wishes and expectations for their business and their technology development activities. Business leaders want to be able to make promises to their colleagues around the executive committee table, to their board 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.
In addition, they recognize that the world today is fast paced and change happens rapidly: new technologies arrive; globalization changes both labor markets and consumer markets causing huge fluctuations in demand (for product) and supply (of labor); economic conditions change; competitors change their strategies and market offers; and market tastes change as the population ages and becomes wealthier and more middle class. So business leaders want their business to be agile. They want to respond to change quickly and take advantages of opportunities.
Underlying all of this they want good governance. They want to show that investors’ funds were spent wisely. They want costs under control and they want their investment portfolio risk spread optimally.
To do all of this they’d like to have more transparency into their technology development organizations. They’d like to know the true status of projects and they’d like to be able to help when it is appropriate. They want a more objectively managed organization that reports facts with data, metrics and indicators not anecdotes and subjective assessment.
All of these desires equate to an organization operating at what the Software Engineering Institute defines as Maturity Level 4 on its 5 point scale of capability and maturity in the Capability and Maturity Model Integration (CMMI). Level 4 and 5 on this scale are known as the “high maturity” levels. Very few organizations have achieved this level of maturity regardless of whether they have sought a formal SCAMPI appraisal or not. It is no wonder then that most senior leaders of large technology companies are frustrated by the performance of their software engineering teams. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban
Posted by David on 05/18 at 09:57 AM
Kanban •
Permalink
Lean & Kanban (UK) 2009 Sep 27-29 London
My friends Rob Hathaway (who gave a really great presentation at Lean & Kanban 2009 Miami) and Jason Smith (of Indigo Blue in London) together with Karl Scotland (EMC Consulting) are organizing a European version of our Miami conference. It’s called Lean Kanban (UK) 2009 and it’s in London at the Royal Society for the encouragement of the Arts (RSA) on September 27th - 29th. The list of speakers is impressive with confirmed key notes from Don Reinertsen and Mary Poppendieck as well as an appearance from John Seddon who is a well known Lean advocate in the UK and experienced introducing Lean to Healthcare and Government sectors. Other speakers include Hal Macomber of the Lean Project Institute who uses Lean techniques in construction project management plus leading Kanban thinkers such as Corey Ladas, Kenji Hiranabe and Jeff Patton.
On-line registration opens soon. You can pre-register today by calling Indigo Blue directly. Places are filling up. Our event in Miami created quite a buzz. Numbers are limited to just 200. Do not miss out. Kanban has a lot of momentum in London and we fully expect the event to sell out early. I hope to see you in London in September.
Use conftag #lkuk09 when discussing the event on TwitterTechnorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban
Posted by David on 05/18 at 12:49 AM
Kanban •
Lean •
(0)
Trackbacks •
Permalink
Friday, May 15, 2009
How to Start with Kanban
A long series of theads on the Kanbandev Yahoo! group brought me to the realization that we’ve (I and the main Kanban protagonists like Corey Ladas and Karl Scotland) have really failed to articulate a lot of the basics required to get started. I posted this short summary to the list but it is so useful it needs a wider audience. So here it is without any explanation. By all means post questions in the comments. I may blog specifically about individual steps at some later date.
To do Kanban…
Start with the process you are doing now. Then…
1. Map the value stream
2. Define some point where you want to control input - define what is upstream of that point and who the upstream stakeholders are
3. Define some exit point beyond which you don’t intend to contorl - define what is downstream of that and who the downstream stakeholders are
4. Meet with the upstream and downstream stakeholders - might be one big meeting, might be lots of little meetings. Discuss policies around capacity of the bit of the value stream you want to control and get agreement on a WIP limit and an input coordination mechanism such as a regular prioritization meeting (with the upstream partners) and a release/delivery coordination mechanism such as a regular software release (with the downstream partners)
5. Create a board/card wall to track the value stream you are controlling
6. Optionally create an electronic system to track and report the same
7. Agree to have a standup meeting every day in front of the board with the team (invite upstream and downstream stakeholders but don’t mandate their involvement)
8. Agree to have a regular operations review meeting for retrospective analysis of the process (invite upstream and downstream stakeholders but don’t mandate their involvement)
9. Educate the team on the new board, WIP limits, and pull system. Nothing else in their world should have changed. Job descriptions are the same. Activities are the same. Handoffs are the same. Artifacts are the same. Their process hasn’t changed other than you are asking them to accept an WIP limit and to pull work rather than receive it in a push fashion
10. Start using the new “Kanban” process Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban,
Posted by David on 05/15 at 09:55 AM
Kanban •
(0)
Trackbacks •
Permalink
