Essential Kanban Condensed Guide V0.9.3
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 27
| Download | |
| Open PDF In Browser | View PDF |
Preamble Essential Kanban - Condensed Guide Copyright © 2015 by Lean Kanban Inc. All Rights Reserved. This book has been shared with you for the purpose of feedback and review. Please do not share this file with others, nor print copies of it, without the express permission of the authors. Access to the electronic format of this book does not grant the right to produce printed copies of it. Printed copies can be obtained via edu.leankanban.com. Edition: Draft 0.9.3 Date: 14th November 2015 About this guide This guide provides a distillation of the “essence” of Kanban - what it is and how it can be used - in a condensed form. It is the summary of a fuller guide, Essential Kanban Guide, which is still to be published (Anderson, 2016a). About Draft 0.9.3 Some feedback from initial drafts of the Condensed Guide requested more detail or diagrams to explain the key concepts. For the most part we have prioritized brevity over completeness in this guide, because the full guide is where the further explanation will appear. However since this draft is being distributed for review before the full guide is available, we have included some material here that will in due course migrate to the full guide. This will eventually enable the Condensed Guide to be the short summary of concepts in the briefest form. David J Anderson, Seattle, WA Andy Carmichael, Southampton, UK Conventions The Glossary contains the definitions of a number of commonly used terms that are used in Kanban. At least the first time a term in the Glossary appears in the text of the Guide it is highlighted, e.g. Delivery Rate. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 2 What is Kanban? Kanban is a method for defining, managing and improving services delivering knowledge work, such as professional services, creative industries and the design of physical and software products. The method is based on the concept of a kanban system - a delivery flow system that controls the amount of work in progress using visual signals. The visual signals are referred to as kanbans1. They prevent too much or too little work entering the system, thereby improving the flow of value to customers. The kanbans, and the policies associated with them, create a pull system, where work is “pulled” into the schedule when other work is completed, rather than “pushed” when new work is requested. The focus of Kanban is the delivery of services by an organization - one or more people collaborating to produce (usually intangible) work products. A service has a customer, who requests the work or whose needs are identified, and who accepts or acknowledges delivery of the completed work. Even where there is a physical product from services, value resides less in the physical item itself, and more in its informational content (the software, in the most general sense). Kanban Values Kanban is a values-led method. It is motivated by the belief that respecting all the individuals that contribute to a collaborative enterprise is necessary, not only for the success of the venture, but for it to be worthwhile at all. Kanban’s values may be summed up in that single word “respect”. However it is useful to expand this into the set of nine values2 (including respect) that encapsulate why the principles and practices of Kanban exist: 1 The plural of kanban in Japanese is kanban, however we use the plural “kanbans” in this English text. 2 (Burrows, 2014) Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 3 1. Transparency: the belief that sharing information openly improves the flow of value. Using clear and straightforward vocabulary is part of this value. 2. Balance: the understanding that different aspects, viewpoints and capabilities must be balanced with each other for effectiveness. Some aspects (such as demand and capacity) will cause breakdown if they are out of balance for an extended period. 3. Collaboration: working together. The Kanban method was formulated to improve the way people work together, so collaboration is at its heart. 4. Customer Focus: knowing the goal for the system. Every kanban system flows to a point of realising value - where customers receive a required item or service. It is the natural point of focus in Kanban. 5. Flow: the realisation of work as a flow of value, whether continuous or episodic. Seeing flow is an essential starting point in the use of Kanban. 6. Leadership: the ability to inspire others to action through example, words and reflection. Most organisations have some degree of hierarchical structure, but leadership is needed in Kanban at all levels to achieve value delivery and improvement. 7. Understanding: primarily the self-knowledge of oneself and one’s organisation in order to move forward. Kanban is an improvement method, and knowledge of one’s starting point is foundational. 8. Agreement: the commitment to move together towards goals, respecting and where possible accommodating differences of opinion or approach. This is not management by consensus but a dynamic co-commitment to improvement. 9. Respect: valuing, understanding and showing consideration for people. Appropriately at the foot of this list, it is the foundation on which the other values rest. These values embody the roots of Kanban in seeking to improve services delivered by collaborating teams. The method cannot be applied faithfully without embracing them. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 4 The Foundational Principles of Kanban There are six foundational principles of Kanban which may be divided into two groups: the change management principles and the service delivery principles. The three change management principles of Kanban are 1. Start with what you do now ○ understanding current processes, as actually practiced ○ respecting existing roles, responsibilities, and job titles 2. Agree to pursue improvement through evolutionary change 3. Encourage acts of leadership at every level, from individual contributor to senior management The three service delivery principles of Kanban are 1. Understand and focus on your customers’ needs and expectations 2. Manage the work; let people self-organize around it 3. Your organization is an ecosystem of interdependent services, steered by its policies; reflect regularly on their effectiveness and improve them. Describing Flow Systems Kanban is used to define, manage and improve systems which deliver services of value to (internal or external) customers. As Kanban is applied principally to knowledge work, where the deliveries consist of information in various forms rather than physical items, the processes can usually be defined as a series of knowledge discovery steps, and associated policies, such as shown in a diagram like this, depicting a flow system where work items flow through various stages of a process, ordered in this case from left to right. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 5 As well as visual signals to limit work in progress, kanban systems have identified commitment and delivery points. The commitment is an explicit or tacit agreement between customer and service that: 1. the customer wants an item and will take delivery of it, and 2. the service will produce it and deliver it to the customer. Before the commitment point there may be a set of outstanding requests (or a pool of ideas) which may or may not be selected, and a process which has the purpose of selecting items from these options. Kanban applied to processes prior to the commitment point is sometimes referred to as Discovery Kanban3. The delivery point is where items are considered complete. The time that an item is in process between the commitment and delivery points is referred to as the Lead Time for the item. The number of items that are within the system under consideration at any point in time is known as the Work in Progress or WiP. The rate at which items are being delivered is known as the Delivery Rate. This is calculated from the reciprocal of the time between the latest delivery and the one before or, for an average Delivery Rate over a given period, by dividing the number of deliveries by the length of the time period. In a flow system that is not trending4 (and in which all items that are selected are delivered) there is a simple relationship between the average 3 4 Or “Upstream Kanban”. See (Steyaert, 2014). Or between two consecutive points of zero WiP. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 6 of these metrics over a specific period. It is known as Little’s Law5: Delivery Rate = WiP Lead Time The overline denotes arithmetic mean. We may wish to use Little’s Law to examine the flow metrics of other parts of a kanban system - not just between the commitment and delivery points - in which case rather than Lead Time, use Time in Process or TiP6 for the period an item is in the process under consideration. More specific terms such as Time in Development, Time in Test, Time in System or Time in Queue may also be used. The term Throughput is used rather than Delivery Rate if the end of the process under consideration is not the delivery point7. An alternative formulation of Little’s Law using these terms is thus: Throughput = WiP TiP Little’s Law provides an important insight into kanban systems: in order to optimize the Lead Time for work items, we must limit the Work in Progress. This is one of the Core Practices of Kanban. The Core Practices of Kanban The Core Practices of Kanban define essential activities for those managing kanban systems. There are six of them: 1. 2. 3. 4. 5. 6. Visualize Limit work in progress Manage flow Make policies explicit Implement feedback loops Improve collaboratively, evolve experimentally 5 6 (Little, 1961) (Maccherone, 2012). Note some authors use Cycle Time (CT2) for this quantity. See the Glossary for the definitions of CT1 and CT2, and an explanation of why Cycle Time is not a recommended term in the Kanban method. 7 A further distinction may be drawn between Throughput and Delivery Rate even if the point at which it is measured is identical. Throughput includes all items that depart from the system under consideration, whether they were delivered, aborted/discarded, or moved back to a point prior to the system under consideration. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 7 These practices all involve: ● seeing the work, and the policies that determine its processing; then ● improving the process in an evolutionary fashion - keeping and amplifying useful change; reversing and learning from ineffective change. Visualize A Kanban Board such as in the diagram above is one, though not the only way, to visualize work and the process it goes through. For it to be a kanban system rather than simply a flow system, the commitment and delivery points must be defined, and visual signals (kanbans) must be visible to limit the work in progress at each stage between these points. The act of making work and policies visible, whether through a wall board, electronic displays or other means, is an important journey of collaboration to understand the current system and find potential areas for improvement. Policies too are important to visualize, for example by placing summaries between columns of the what must be done before items move from one column to the next. Board Design varies greatly between kanban systems depending on their context of use. It is not part of the method to constrain how they are designed. Software tools designed to support Kanban may introduce practical constraints, for example the common pattern of a two dimensional grid, with panels displaying information about each work item. The columns represent steps in a process, and some of the columns have horizontal partitions (called swimlanes, if they cross two or more columns) to distinguish states of items within the steps. However it is interesting to note that physical boards without such constraints often find other creative ways to display information of importance to the team, as well as connections to the boards of other services. Design of the card or panel that describes the work item is another important aspect of visualization. It is also vital to highlight visually when items are blocked by dependencies on other services or for other reasons. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 8 Limit work in progress Introducing and respecting limits on WiP changes a “push” system into a “pull” system, where new items are not started until work is completed, or on rarer occasions abandoned. Too much partially complete work is wasteful and expensive, and crucially it lengthens lead times preventing the organization from being responsive to changing circumstances and opportunities. Observing, limiting and then optimizing the amount of work in progress is essential to success with Kanban, as it results in improved lead time for services, improved quality and a higher rate of deliveries. By contrast ineffective management behavior focuses on maximizing usage of people and resources, by trying to ensure that everyone is “busy” with a ready supply of work so that no idle time occurs. As a result people may feel overwhelmed with the amount they have to do, only accept tasks they have been explicitly instructed to carry out, and lose sight of the service they provide and how it contributes to the overall goals of the organization and its customers Manage flow The flow of work in a kanban system should maximize the delivery of value, minimize lead times, and be as smooth (predictable) as possible. These are sometimes conflicting goals and, since the deliverables are usually complex, empirical control through transparency, inspection and adaption is required. Bottlenecks, where flow is constrained by one particular subprocess, and blockers, where there are dependencies on other services, are particularly important to take note of and manage The relationship with the consumers of the service, the customers, is a key aspect of managing flow. Different service levels may be defined for kanban systems to guide this: ● ● ● ● Service Level Expectation: what the customer expects Service Level Capability: what the system can deliver Service Level Agreement: what is agreed with a customer Service Fitness Threshold: the service level below which the service delivery is unacceptable to the customer. Make policies explicit Explicit policies are a way of articulating and defining a process that Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 9 goes beyond the workflow definition. A process expressed as workflow and policies creates constraints on action, is empowering within the constraints, and results in emergent characteristics that can be tuned by experiment. The process policies need to be sparse, simple, well-defined, visible, always applied, and readily changeable by those providing the service. The behavior of complex systems, though they may be guided by simple policies, is not possible to predict with certainty. What may appear as intuitively obvious policies (e.g. “the sooner you start, the sooner you’ll finish”), may produce counterintuitive results. For this reason it is a core practice to make the policies that apply to services explicit, and also for there to be a visible and straightforward mechanism to question and change policies when they are considered counter-productive. WiP Limits are one type of policy. Others include capacity allocation and balancing, the “Definition of Done” or other policies for work items exiting stages of a process, and replenishment policies for the selection of new work when capacity is available. The use of classes of service is another policy example. Implement feedback loops Feedback loops are an essential part of any controlled process and particularly important for evolutionary change. Improving feedback in all areas of the process is important. Kanban defines seven specific feedback opportunities, or cadences. Cadences are the cyclical reviews that drive evolutionary change and effective service delivery8. The seven cadences are shown in the accompanying diagram with suggested frequencies for the reviews in typical systems: 1. Strategy Review: defining in context the concept of “fit for purpose” and sensing the external environment, in order to provide direction to services 2. Operations Review: understanding the balance between and across services, deploying resources to maximise the delivery of value to customers’ expectations 3. Risk Review: for understanding risks to effective delivery of services, for example through blocker clustering 4. Service Delivery Review: examining and improving the effectiveness of a service (this and subsequent cadences apply 8 Cadence may also refer to the period between reviews, for example one working day or one month. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 10 to a single service) 5. Replenishment Meeting: for moving items over the commitment point, and overseeing the preparation of options for selection in the future 6. The Kanban Meeting: the (usually) daily coordination, selforganization and planning review for those collaborating to deliver the service. It often uses a “stand-up” format to encourage a short energetic meeting with the focus on work item completion and unblocking issues. 7. Delivery Planning Meeting: monitoring and planning deliveries to customers Implementing the seven cadences does not imply adding seven new meetings to an organization’s overhead. Instead the reviews and meetings should initially be part of existing meetings and adapted in context to fulfill their goals. At smaller scale, a single meeting may cover more that one of the cadences. There are ten feedback loops in the cadence network diagram, showing information flow and requests for change between the reviews. These facilitate decision-making at each level. Improve collaboratively, evolve experimentally Kanban is fundamentally an improvement method. Often transformation programmes are started with the aim to change processes to a new Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 11 predefined approach. In contrast Kanban starts from the organization as it is now and uses the lean flow paradigm (seeing work as a flow of value) to pursue continuous and incremental improvement. There is no end point of such change processes since perfection in an ever-changing fitness landscape is unattainable. Kanban harnesses an evolutionary process to allow beneficial change to occur within an organization, protecting it from another natural process in evolution, extinction. Organizations cannot opt out of evolution. It either works for them or happens to them. But they can choose to encourage the change to occur within, rather than finding it is unable to respond to existential threats from without. Kanban facilitates this. The evolutionary process involves: copying with differences; selecting for fitness; keeping and amplifying useful change while rejecting or reversing ineffective change. Sometimes it is useful to use models, and the scientific method to validate or invalidate the application of the models in context. Sometimes using empirical and pragmatic approaches is appropriate, to find the greatest fitness for purpose with the current environment. Introducing Kanban to Organizations It is straightforward to start using Kanban: recognize that your work involves a flow of value from the request for an item to its delivery to your customer; visualize the work and the process for delivering the work; then continually improve the process by applying the values, the principles and the practices9. All through this process you will be applying Kanban, even while the characteristics of your systems are barely different from your starting point. Clearly this means there are organizations applying Kanban that do not yet even have a kanban system (a system that limits work in progress with visual signals), or whose kanban systems have not yet matured, for example to an effective balancing of demand with capability through feedback loops, or optimal value delivery through classes of service. Such systems may be referred to as protokanban systems since they are systems being transformed by Kanban, though not yet compliant with all of its practices. Protokanban systems can bring great benefit to organizations - for example in making work visible - but they should not be viewed as end-points in process transformations. 9 (Carmichael, 2013) Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 12 For these reasons the Kanban method defines an approach for introducing Kanban (STATIK) and a test for assessing your progress with Kanban (the Litmus Test). Systems Thinking Approach to Introducing Kanban (STATIK) Systems Thinking10 is a way of understanding how a system behaves as a whole rather than through analysis of component parts in isolation. It is a key influence in the definition of the steps needed to introduce Kanban in an organization. The steps in this process are not necessarily sequential, but iterative, using learning from one step to inform and influence the others in a collaborative environment. The steps are Step 0: Identify Services For each service… Step 1: Understand what makes the service fit for purpose for the customer Step 2: Understand sources of dissatisfaction with the current system Step 3: Analyze demand Step 4: Analyze capability Step 5: Model workflow Step 6: Discover classes of service Step 7: Design the kanban system Step 8: Socialize the design and negotiate implementation STATIK is applicable to just one service. When more than one service has been set up, Kanban practices and cadences are applied to balance demand and flow across the multiple services, and continually improve. The ordering of the steps may vary in practice and it is normal to revisit steps in the pursuit of further improvement. The Kanban Litmus Test The Kanban Litmus Test is designed to help organizations assess their progress with Kanban and suggest areas that may yield effective improvements. It consists of a series of questions in four groups, where the lower numbered questions are pre-requisites for those that follow. 1. Establishing a kanban system a. Is the customer interface (the approach to scheduling and selecting customer requests for service) based on a pull 10 See for example (Meadows, 1972). Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 13 system with limited work in progress? b. Are the commitment and delivery points clearly defined and records available of Lead Times and Delivery Rates? 2. Service Delivery a. Does the relationship with the customer allow commitments to be made based on a service level agreement or understood service level expectation? b. Are these commitments based on probabilistic forecasting of the kanban system’s observed Lead Times and Delivery Rates? 3. Value and risk management a. Does the service delivery business model use classes of service appropriately, based on an understanding of business risks (for example the cost of delay) to facilitate selection decisions and inspire queuing discipline policies for work items? Are you understanding clusters of customer expectations and probing for new classes of service? b. Is there capacity in the system to hedge risks from different sources of demand and different types of work, for example by diverting resources to priority tasks in periods of high demand? c. Are interdependent services aggregated and coordinated, to increase system liquidity and enable system leveling in the light of risks and variability? 4. Management behavior a. Is management behavior consistent with the deferred commitment pull system approach of Kanban? b. Are WiP limits respected by management at system level, not just at personal level (such as per person WiP limits to reduce multi-tasking)? Kanban Roles Kanban is and remains the “start with what you do now” method, where initially no one receives new roles, responsibilities or job titles. So there are no required roles in Kanban and the method does not create new positions in the organization. However two roles have emerged from common practice in the field and are now defined in the method itself. It is the purpose of the roles that is important, rather than assigning someone to a job title, so it may be helpful to think of the roles as “hats” people wear in carrying out these functions. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 14 The two roles are: ● Service Request Manager: responsible for understanding the needs and expectations of customers, and for selecting and ordering work items accordingly (alternative names for the role: Product Manager, Product Owner, Service Manager) ● Service Delivery Manager: responsible for the flow of work in delivering selecting items to customers (alternative names for the role: Flow Manager, Delivery Manager or even Flow Master) Forecasting and Metrics Forecasting accurately when services will be delivered to customers has long been a difficult management problem. Two methods of forecasting are considered: “effort-plus-risk estimating” and probabilistic forecasting. Effort-plus-risk approaches operate by breaking down a large piece of work (like a project) into very small items, and then summing the effort estimates for these small items. Either an acceptable date or the team size is agreed, and the other variable determined by ensuring the product of the required lead time and team size is larger than the estimated effort by a sufficiently large factor to account for risks and profit. Often this involves a “risk factor” of between 2 and 10. This method has often proven spectacularly unsuccessful on all sizes of project, but particularly large and critical ones. It is surprising it still is the dominant method of running projects. Kanban systems, once established, provide the opportunity for an alternative approach based on the flow of value (encapsulated in smaller work items than typical projects), delivered through established teams. Probabilistic forecasting works by using a simple model of existing, or similarly structured new teams, where some data has already been gathered on item size variability, lead times and delivery rates. Using a Monte Carlo method11, which runs scenarios multiple times, percentage likelihood of a range of completion dates can be generated. Providing this to planners encourages a better approach to balancing cost and risk with schedules and commitments. Designing appropriate service level agreements with customers is also enabled by collecting actual data from kanban systems and applying statistical analysis and probabilistic forecasting. 11 (Magennis, 2011) Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 15 Flow systems can provide a wide range of flow metrics which are important to the managers of these systems12. The minimum starting point is to collect data on Lead Time, Delivery Rate, WiP and cost (usually primarily the effort in person-days consumed by the service). A Run Chart: showing a scatter plot of the Lead Time for items on their delivery dates Important types of graphs for monitoring flow systems include: scatter plots of Lead Times - Run Charts - and charts showing the cumulative number of arrivals and departures of items from a process, or parts of a process - Cumulative Flow Diagrams (CFDs). A Cumulative Flow Diagram: showing the cumulative number of items committed and delivered by date 12 See for example (Vacanti, 2015) Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 16 Expanding the Application of Kanban How do you scale Kanban? There is a simple answer to this question: by applying Kanban in a context of greater scale. Once kanban systems are established for one or more services, consider three dimensions in which they can grow in your organization. Width-wise growth: Encompass a wider scope of the lifecycle of the work items by upstream and downstream expansion of the end-to-end workflow. For example, if the original service modeled only the development team’s process, exploring what happens before the items enter development, and after the team consider that the items are “done”, will result in a wider scope of the process, and potentially more effective areas for improving the service to customers. Height-wise growth: Consider the hierarchy of items that make up deliveries, each level of the hierarchy potentially having differing flow characteristics. For example a “user story” is a small part of the functionality of a software product “feature”. Features may be considered as part of a software release. Kanban may be used at each of these levels with differing workflows and policies at each level . This dimension uses the “scale-free” nature of Kanban - the same principles and practices apply whatever the size of the work item, even though the nature of work at the different scales results in very different systems and policies. Four specific levels are often identified: 1. Personal - use of Personal Kanban13 for an individual or small team to foster efficient and effective working 2. Team - understanding the team’s work as a service and applying Kanban practices to optimise predictable flow of value 3. Product - Product management requires effective management of options for enhancements, and flow of customer-valued changes for competitive advantage. The work items should be considerably larger than at the team level, but much smaller than typical projects. 4. Portfolio - Kanban can support the investment level decisions concerning which new and existing projects need greater or less capability/capacity to deliver change. Portfolio management is therefore not a variant of project 13 (Benson, 2011) Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 17 management with much bigger projects, but a completely different discipline more aligned with the management of financial portfolios. Depth-wise growth: A deep implementation of Kanban needs not only greater depth of understanding, but depth of penetration through the full set of services required by the organization to deliver value. Depth-wise growth connects multiple services at the same level through feedback loops (cadences) that balance the capacity across the services. Services may provide a specific function (legal, IT, or accounting services for example) or be aligned around the deliveries that require widely differing skillsets within them (new product development, or film and television services) but the challenge in the extended Kanban ecosystem is to achieve balance and flow across all the interdependent services. A note of caution - the values, principles and practices are defined in summary in a scale-free manner. However examples, explanations and advice may well be tailored to specific assumptions concerning scale and context. The complexity is always greater at larger scale so particular care must be taken not to carry over assumptions from one scale to a larger one, or indeed between differing contexts of flow systems with very different characteristics. An important recent development in the evolution of Kanban and its application across large organizations is Kanban Enterprise Services Planning (Kanban ESP). This has a management training syllabus to provide managers with the knowledge and confidence to apply Kanban in networks of potentially hundreds of interdependent services. While Kanban ESP is outside the scope of these guides, they do provide foundational material for Kanban ESP. Learning More About Kanban This condensed guide summarizes the principal elements of Kanban which are defined and explained in more depth in the companion volume Kanban: The Essential Guide (Anderson, 2016a). The goal of the guides is to provide the essence of the method in a compact and accessible form, and to point the way forward for students of the method to discover more and participate in its ongoing evolution. What follows is a list of the publications that complete the current definition of the method, including rationale, examples and case studies. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 18 The seminal publication on the method, Kanban – successful evolutionary change for your technology business (Anderson, 2010 and 2016b), provides the background, examples and rationale for the practices of the method. It is an essential companion to the guides. Kanban From the Inside (Burrows, 2014) defines, amplifies and explains the values of Kanban and how its principles and practices flow from them. It also usefully tracks influences and sources for many of Kanban’s practices, and discusses its relation to other approaches such as Lean, Theory of Constraints and Agile. Kanban Change Leadership (Leopold, 2015) explains how to establish a culture of continuous improvement in Kanban implementations. Coaching Kanban (Anderson, 2016c) provides feedback from a number of significant implementations of Kanban with commentary from leading coaches of the method. Together these materials provide the foundational knowledge base for those wishing to understand the method. In addition to these sources, the full guide (Anderson, 2016a) has a more extensive bibliography of the many books describing current Kanban practice and the principal sources and precursors of the Kanban method. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 19 References Anderson (2010) David J. Anderson, Kanban – Successful Evolutionary Change For Your Technology Business, Blue Hole Press. Anderson (2015) David J. Anderson, Lean Kanban Incorporated. Kanban Enterprise Services Planning: Scaling the Benefits of Kanban. London Limited WIP Society, October 2015. http://www.slideshare.net/agilemanager/ enterprise-services-planning-scaling-the-benefits-ofkanban-54207714 Anderson (2016a) David J. Anderson and Andy Carmichael, Essential Kanban. To be published. Lean Kanban University Press. Anderson (2016b) David J. Anderson, Kanban –Successful Evolutionary Change For Your 21st Century Organization. 2nd Edition. To be published. Blue Hole Press. Anderson (2016c) David J. Anderson, ed. Coaching Kanban. To be published. Blue Hole Press. Benson (2011) Jim Benson and Tonianne DeMaria Barry. Personal Kanban: Mapping Work, Navigating Life. Seattle, WA: CreateSpace Independent Publishing Platform. Burrows (2014) Mike Burrows. Kanban from the Inside: understand the Kanban Method, connect it to what you already know, introduce it with impact, Blue Hole Press. Carmichael (2013) Andy Carmichael, Shortest Possible Guide to Adopting Kanban. Improving projects. http://xprocess.blogspot. co.uk/2013/05/how-to-adopt-kanban.html. Hopp (2005) W.Hopp and Mark L. Spearman. 2005. Factory Physics. 3rd ed. United States: McGraw Hill Higher Education. Leopold (2015) Klaus Leopold and Siegfried Kaltenecker, Kanban Change Leadership: Creating a Culture of Continuous Improvement, Wiley. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 20 Little (1961) Little, John D. C. A Proof for the Queuing Formula: L = ΛW. Operations Research 9(3): 383–87. Maccherone (2012) Larry Maccherone. Introducing the Time In State InSITe Chart. http://maccherone.com/publications/LSSC2012IntroducingtheTimeInStateInSITeChart.pdf. Carnegie Mellon University, LSSC. Magennis (2011) Troy Magennis. Forecasting and Simulating Software Development Projects. www.focusedobjective.com, Focused Objective. Meadows (1972) Donella H. Meadows, Dennis L. Meadows, Jørgen Randers and William W. Behrens III. The Limits to Growth. Universe Books. Reinertsen (2009) Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas Publishing. Shook (2014) John Shook and Chet Marchwinski, eds. Lean Lexicon: A Graphical Glossary for Lean Thinkers. 5th Edition. United States: Lean Enterprise Institute, Inc. Steyaert (2014) Patrick Steyaert. Discovery Kanban. Okaloa. http://www.discovery-kanban.com Vacanti (2015) Daniel S. Vacanti. Actionable Agile Metrics for Predictability: An Introduction. Leanpub. Wikipedia (2015) Monte Carlo Method. 2015. Wikipedia. https://en.wikipedia.org/wiki/Monte_Carlo_method Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 21 Glossary Abort: To discard a work item after the commitment point. Alternatives: abandon. Related terms: commitment point, discard Blocker clustering: A risk analysis technique using records of issues that have blocked work items, and grouping them by common cause. Cadence: A review providing feedback from one or more services. Cadence may also refer to the time period between reviews. Classes of service: categories of work item that may warrant different policies for selection and processing based on different relative value, risk or cost of delay. Commitment point: the point in a kanban system at which the commitment is made to deliver a work item. Before this point work done supports the decision whether or not to deliver the item. After this point it has been confirmed that the customer wants and will take delivery of the item, and that the service will deliver it. Related terms: abort, discard Cost of delay: a measure of the impact of delaying an item14. May also refer to cost of delay rate (cost per unit of time). Measured in: monetary currency, units of effort (e.g. person-days) Cumulative Flow Diagram (CFD): a chart showing the cumulative number of arrivals and departures from a process, or parts of a process, over a time period. Cycle Time (CT1, CT2): The time taken for a “cycle”. This is an ambiguous term which should not be used in Kanban without qualification or further definition. It may be applied to the time between two items emerging from a process15 (CT1), for example the period between releases of new builds of software, or to the time between starting and completing an item16 (CT2), for example the time taken to develop a product feature. Measured in: units of time Alternatives: For CT1 use its reciprocal - Delivery Rate or Throughput; for CT2 use Lead Time or Time in Process Deferred commitment: separating the request for work from the commitment to do work, so that the system operates as a pull system. 14 15 16 (Reinertsen, 2009) Lean Lexicon (Shook, 2014) Factory Physics (Hopp, 2005) Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 22 Delivery point: the point at which an item is considered to be delivered or complete. Related terms: commitment point Delivery Rate: The number of work items emerging complete from the system per unit of time. Measured in: work items per unit of time Alternatives: Completion Rate Related terms: Throughput Discard: To stop work on an item and remove it from the process. Note that an item is “discarded” in this sense even if it might be worked on in the future, for example if the work item is moved back to a queue prior to the process under consideration. The term is not specific about when in the process the item is discarded, however in a kanban system it applies particularly to items discarded prior to the commitment point, since after this point the term abort is applicable. Related terms: abort, commitment point Discovery Kanban: the application of Kanban to finding the most advantageous work to do in the context of innovation and change17. Alternative: Upstream Kanban Fitness landscape: a term borrowed from evolutionary biology to visualize, as a multi-dimensional landscape, the fitness of an entity with different traits to the prevailing environment. Flow system: a system characterised by the entry and departure of items. It is a way of viewing knowledge work and the flow of items from the request or idea through to delivered value. Kanban (1): a method for the definition, management and improvement of services that deliver knowledge work. Alternative: The Kanban Method Kanban (2): a kanban is a visual signal that is used in kanban systems to limit work in progress. Kanban ESP: Kanban Enterprise Services Planning18 an approach to the management of large networks of services, applying Kanban at each level of management and within each service. Kanban system: a kanban system is a flow system with defined commitment and delivery points, and with kanbans that limit work in progress. Knowledge work: work that is primarily using and developing knowledge. 17 18 Discovery Kanban (Steyaert, 2014) Anderson (2015) Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 23 Lead Time: the elapsed time it takes for a work item to move from the commitment point to the delivery point. Measured in: units of time Related terms: Time in Process (TiP) Little’s Law: a simple relationship between the attributes of queues and flow systems. For kanban systems it may be expressed as: Delivery Rate = WiP or as Lead Time Throughput = WiP TiP where the overline indicates the arithmetic mean over a period. The system must be statistically “stationary” for the period, or between two consecutive points of zero WiP. Monte Carlo methods: a broad class of computational algorithms that rely on repeated random sampling to obtain numerical results. (Wikipedia, 2015) Options: options represent the right - though not the obligation - to carry out an action or use a resource. Like financial options they have value and an expiration period during which their value reduces to zero. They are important in Kanban since work items before the commitment point represent options of this type. Alternatives: Real options Probabilistic Forecasting: An approach to forecasting outcomes from a flow system, using data of previous delivery rates and lead times combined with a Monte Carlo or similar method. Protokanban: refers to a flow system or process where the Kanban method is being applied, but which does not yet show characteristics of a mature system, for example where work in progress is not controlled between the commitment and delivery points. Pull system: a method of scheduling work only when capacity exists to complete it, in contrast to scheduling it as soon as work is requested. Run Chart: a scatter plot of Lead Times with data points representing the Lead Time of items on their delivery date. Alternatives: Control Chart Service: one or more people collaborating to produce (usually intangible) work products for a customer, who requests the work, and who accepts or acknowledges delivery of the completed work. Throughput: the number of work items exiting from the system per unit of time, whether completed or discarded. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 24 Measured in: work items per unit of time (e.g. items per working day) Alternatives: Throughput Rate, Departure Rate, Processing Rate Related terms: Delivery Rate Time in Process (TiP): the time that a work item remains in the system or subprocess under consideration prior to being either completed or discarded. More specific terms may be derived by replacing “Process” with the particular part of the process of interest, for example Time in Development, Time in Test, Time in Queue. Measured in: units of time Alternatives: Lead Time (when referring to the time in process from the commitment to delivery point), Time in System Related terms: Cycle Time (CT2), Lead Time Work in Progress (WiP): the number of work items which have entered the system but which are not yet either completed or discarded. Measured in: count of work items Related terms: Throughput, Delivery Rate, TiP Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 25 About The Authors David J Anderson @lki_dja dja@leankanban.com David J Anderson is an innovator in management thinking for 21st Century businesses. He leads a training, consulting, events and publishing business making new ideas accessible to managers across the globe. He has 30+ years experience in the high technology industry starting with games in the early 1980s. He worked at IBM, Sprint, Motorola & Microsoft as well as a number of startup businesses. He is the pioneer of both the Kanban Method and Enterprise Services Planning. David is the author of three books: Kanban – Successful Evolutionary Change for your Technology Business; Lessons in Agile Management: On the Road to Kanban, and Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results. Andy Carmichael @andycarmich andycarmichaeluk@gmail.com Andy Carmichael is a coach, consultant and business builder who has been at the forefront of process change in software development teams for many years. His clients include major players in finance, software engineering, utilities and telecoms - as well as a number of startups and SMEs - all of whom share the goals of gaining competitive advantage through increased business agility. He is active in the Kanban and Agile communities and is a Kanban Coaching Professional. Andy has edited and co-authored three books: Object Development Methods, Developing Business Objects and Better Software Faster. When not engrossed in technical work, he enjoys singing, golf and entertaining, particularly when his large grown-up family comes home to visit. Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3 edu.leankanban.com Copyright © 2015 by Lean Kanban Inc. All Rights Reserved.
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.4 Linearized : Yes Encryption : Standard V2.3 (128-bit) User Access : Extract Tagged PDF : Yes XMP Toolkit : Adobe XMP Core 5.6-c011 79.156289, 2014/03/31-23:39:12 Create Date : 2015:11:13 13:26:40-05:00 Metadata Date : 2015:11:13 13:26:43-05:00 Modify Date : 2015:11:13 13:26:43-05:00 Creator Tool : Adobe InDesign CC 2014 (Windows) Instance ID : uuid:1fd9d073-d72f-49dd-a1be-a709313d4f02 Original Document ID : xmp.did:c7fdfdb3-bf70-b246-b6a3-0f172a53fc85 Document ID : xmp.id:33fed360-b54a-a041-b1dd-b0dc9060d446 Rendition Class : proof:pdf Derived From Instance ID : xmp.iid:caa9c769-8521-4147-8bc0-ae92c26b9cc6 Derived From Document ID : xmp.did:a4a82a96-06a9-8b44-9a73-a72ae2fdea5c Derived From Original Document ID: xmp.did:c7fdfdb3-bf70-b246-b6a3-0f172a53fc85 Derived From Rendition Class : default History Action : converted History Parameters : from application/x-indesign to application/pdf History Software Agent : Adobe InDesign CC 2014 (Windows) History Changed : / History When : 2015:11:13 13:26:40-05:00 Format : application/pdf Producer : Adobe PDF Library 11.0 Trapped : False Page Count : 27 Creator : Adobe InDesign CC 2014 (Windows)EXIF Metadata provided by EXIF.tools