Spirit of Kanban
•Download as PPTX, PDF•
6 likes•2,341 views
An internal presentation to Voxeo employees about the Kanban approach to Software Development - designed for newbies! For cleaner formatting (and access to the talk-track), download the powerpoint format or try the PDF.
![Spirit of Kanban Rev 0.1 2011-07-01 [Voxeo]](https://image.slidesharecdn.com/spiritofkanban-110725193241-phpapp01/85/Spirit-of-Kanban-1-320.jpg)
More Related Content
What's hot
What's hot (20)
Similar to Spirit of Kanban
Similar to Spirit of Kanban (20)
Recently uploaded
Recently uploaded (20)
Spirit of Kanban
- 1. Spirit of Kanban Rev 0.1 2011-07-01 [Voxeo]
- 2. What (on earth)is this talk about ?
- 3. Blah Blah Blah … Kanbanis an approach to managing workflow and organizational improvement that holds great promise for Voxeo, but is not yet widely used or understood by Voxeons. Kanbanprovides a simple method for visualizing, measuring and optimizing the flow of work within an organization. Its principles can be applied in almost any context, from your personal or team to-do list to the organizational product pipeline. This presentation will outline how to get started with Kanban, describe how Kanban is already being used at Voxeo, and encourage discussion of where else we might like to try using Kanban to make Voxeo a better place to work.
- 6. Are you ready for a paradigm shift in how you manage projects and organize your time ?
- 9. Focus Execute Measure Iterate
- 12. Ad Hoc
- 15. Punch List
- 17. Planned
- 27. Agile
- 28. Agile Manifesto Individuals & interactions Working software Customer collaboration Responding to change Processes and tools Comprehensive documentation Contract negotiation Following a plan These preferred over but not instead of these
- 32. Scrum is Hard to Do Well Adoption is widespread – Agile and Scrum are now mainstream May be embraced as a pendulum swing or reaction to traditional PM Requires a level of continuous discipline that many organizations find difficult to sustain Sometimes becomes a cover for ad-hoc processes, de-emphasizing discipline, focus, quality, engineering best practice Can require many, many (many) meetings (particularly at scale)
- 33. Kanban
- 35. There is no time-box
- 37. Visualize Work Flow Limit Work InProgress Measure & Manage Flow Optimize Cycle-time
- 38. Visualize Work Flow Backlog In Progress Done Task Task Task Task Task Task Task
- 39. Visualize Work Flow Backlog In Progress Done Task Task Task LOWPRIORITY HIGH Task Task Task Task
- 40. Limit WorkIn Progress Backlog In Progress Done 4 3 Task Task Task Task Task Task Task
- 41. Limit WorkIn Progress Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task
- 42. Limit WorkIn Progress Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task
- 43. Limit Work In Progress Backlog In Progress Done 4 3 Task Task Task Task Task Task Task
- 44. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task
- 45. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task
- 46. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task
- 47. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task
- 48. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task Task
- 49. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task Task Task
- 50. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task Task Task
- 51. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task Task Task
- 52. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task Task Task Task
- 53. Measure & Manage Flow Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task Task Task Task Cycle Time
- 54. Optimize Cycle Time Backlog In Progress Done 4 3 Task Task Task Task Task Task Task Task Task Task Task
- 55. Optimize Cycle Time Backlog In Progress Done 4 5 Code Test 3 2 Task Task Task Task Task Task Task Task Task Task Task Task
- 56. Optimize Cycle Time Backlog In Progress Done 4 5 Code Test 3 2 Task Task Task Task Task Task Task Task Task Task Task Task
- 57. Optimize Cycle Time Backlog In Progress Done 4 5 Code Test 3 2 Task Task Task Task Task Task Task Task Task Task Task Task
- 58. Optimize Cycle Time In Progress Backlog Done 5 4 Code Test 3 2 Task Task Task Task Task Task Task Task Task Task Task Task
- 59. Optimize Cycle Time In Progress Backlog Done 8 4 Code Test 3 5 Task Task Task 3 Test Queue 2 Task Task Task Task Task Task Task Task Task
- 60. Optimize Cycle Time In Progress Backlog Done 8 4 Code Test 3 5 Task Task Task 3 Test Queue 2 Task Task Task Task Task Task Task Task Task
- 61. Optimize Cycle Time In Progress Backlog Done 8 4 Code Test 3 5 Task Task Task 3 Test Queue 2 Task Task Task Task Task Task Task Task Task
- 62. Optimize Cycle Time In Progress Backlog Done 8 4 Code Test 3 5 Task Task Task 3 Test Queue 2 Task Task Task Task Task Task Task Task Task Task
- 63. Kanban in real life
- 67. Kanban At Voxeo
- 68. Focus Execute Measure Iterate
- 70. Project or Team Kanban
- 76. Stop starting ! Start finishing
- 77. To Learn More http://www.personalkanban.com http://agilemanagement.net/ http://www.limitedwipsociety.org/ http://refcardz.dzone.com/refcardz/getting-started-kanban
Editor's Notes
- This talk is designed to communicate the basic spirit (or underlying principles) of the Kanban approach to managing workflow within an organization……so why is there a picture of Nelson Mandela (or is it William Shatner, or <your name here>)? Bear with me….DISCLAIMER: I have freely pillaged the internet in search of appropriate artwork and in my research about Kanban – this material is presented with thanks and apologies for those with true creativity. Please don’t sue me – contact me directly and I will be glad to acknowledge or pull down your content as necessary.
- Some of you are here today with no idea what Kanban means – this talk is perfect for you (and not so much for aficionados or anyone already familiar with Kanban or Lean, or Project Management for that matter).
- No-one will actually read this, so…let me try this a different way…
- Kanbankinda falls under the heading of Project Management, but not in any traditional sense…
- Kanban really addresses the broader subject of understanding and improving the way we work together – the systems, processes, people and tools that make things happen – the way that work items flow through those systems - and dealing with the complexity inherent in doing so
- In many ways, Kanban takes traditional thinking about time management and project management and turns it on its head…
- So get ready!
- SoKanban is a shiny new paradigm – a new way of thinking about how we work….but on the other hand, it might seem familiar….
- Does anyone remember seeing these? The Voxeo Leadership Team has been pounding on these as priorities for 2011 – and as we’ll see, they tie in quite nicely with theKanbanapproach…
- But let’s start by thinking about the evolution of project management – Kanban did not emerge from a vacuum, but can be understood as a progression in our thinking about how to work together in the age of information…
- NOT that each new approach is necessarily better than the last – each has their place and should not be thought of as a panacea or silver bullet
- In the beginning, the project was a shapeless void – people pretty much did what seemed like it most needed attention, for whatever reason…
- …but this quickly gets hectic and unmanageable; more than a few tasks, or more than a handful of people and chaos inevitably ensues.
- So naturally, we decide that it is time to get organized…
- And this often takes the form of a punch-list
- A punch list is a simple way of ordering and sharing the list of stuff that needs to get done; but still, it quickly becomes apparent that we need to assign tasks to people, understand the timeline and establish dependencies between tasks…
- This brings us to the more traditional planned project that we are used to in the world of software development…
- Look – a checklist with a timeline, resources, dependencies and constraints! It’s called a Gantt chart.
- Pretty soon we notice a pattern in our project plans, and define standards for the phases that projects should go through – these are established as our project management process…
- This is all great, but as we do this more and more, we realize something important: the earlier we plan, the less accurate our plan is (even when sophisticated estimation models and historical data are used, which often they are not) – so when we define a nice project plan up front, we get the least accurate plans. This is called the Cone of Uncertainty (and it is actually worse, more random than depicted here). This is particularly acute in knowledge-based projects such as software development, and is the fundamental challenge that gives rise to the ubiquitous death march projects so familiar in the world of IT. When things don’t work out as planned – and they never do – what happens?
- The other thing that was realized a long time ago, is that projects do not follow a nice linear one-pass path from inception to production – in reality, we iterate through a series of activities and releases to get to the desired end-point (this diagram is from a paper by Barry Boehm in 1981)
- For this reason, all the standard Project Management standards embrace this concept of iteration: PMI, RUP, MSF, Prince2, etc…
- But there is a another problem: projects do not exist in a vacuum. Organizations must juggle a large number of projects, decide on their relative priority, how to allocate resources to them, track how much they cost and keep them aligned with business strategy. This can quickly get complicated…
- And we end up with increasingly complicated projects and processes that attempt to take all this into account. The trouble is, almost no-one can keep all this in their head - projects and organizations become bloated – people follow rules and stop using their brains – and it is just no fun.
- Dilbert captures the consequences nicely…
- And how about this - have you ever felt like Zombie PMs and their endless meetings are robbing you of your Joie de Vivre?
- This was the context for the emergence of the agile approach to software or product development
- In 2006, some well-known figures in the word of software outlined a new way of thinking about projects…Ref: http://http://agilemanifesto.org/
- A number of different approaches emerged from this thinking – perhaps the most famous is Scrum
- Scrum provides a simple system for iteratively delivering software in the context of fluid requirements through a series of sprints…
- And can be integrated into a broader, iterative agile planning framework
- The trouble is – well, read this slide :-) So this brings us to…
- Ta-da!
- Enter the Kanban Ninja! Kanban presents a (ninja-like) shift in the way we think about managing workflow...
- Kanban asks us to think differently about organizing our work – and (typically) eliminates the (first order) concept of a timeline or timebox, Huh?
- But what does it all mean? Let’s start with the basics…
- These are the core principles of Kanban – now we’ll seewhat they look like in practice using a very simple example
- Here is a typical Kanban visualization of the work going in a particular system (an individual, team or project); tasks are represented by cards in columns that indicate the basic sequence of activities that must take place for a task to be considered complete. In this case, you have a list of items that are waiting to happen, some stuff that is actively in progress, then a stack of items that are done. The idea is that work visibly flows from left to right, representing the flow of value that is being delivered. For this reason, this visualization of the work flow is sometimes given a more fancy name – the value stream.
- These task lists are typically prioritized – and the workflow is usually a little more involved. However the idea is to start simple and then adapt and extend based on experience using the simple system – as we’ll see in the following slides.
- Once the workflow is made evident in this way, it usually becomes apparent that only a certain number of tasks can be accommodated (in each category, for each individual, and within the whole system). For this reason, and to encourage focus and dynamic flow (therefore productivity), limits are defined for the number of work items in the system (as represented here in red). These are referred to as WIP Limits (WIP: Work In Progress).
- This affects the flow of work since you are not allowed to start new work that exceeds the WIP limits.
- The whole (somewhat counter-intuitive) idea of limiting WIP is to INCREASE productivity and focus – if it does not, then consider adjusting WIP limits or refining the value stream (but then again, perhaps you are already perfect?)
- So now our system is nicely balanced – there are one or two items waiting for attention and we are productively working on a full complement of in-progress tasks. Let’s talk about how we might optimize this flow using the second principle…
- …measure and manage flow
- We complete an item that we were working on and it moves to the DONE column – leaving an open slot in the IN-PROGRESS column within our defined WIP limit
- So we start working on the highest priority item that was in the BACKLOG
- Of course, there is still room to add items to the backlog
- So, let’s do that….
- Until we have a full complement of items ready to go. Note: In this case, an item’s presence in the backlog indicates that it is defined to the point of being actionable – the WIP limit reflects the fact that definition work might be required, but also that it is not useful (confusing, distracting) to have too many items queued up. A longer list of lower priority and not as well defined items might exist elsewhere. There are different ways to model this, but let’s go with that for now…
- So what happens when we complete an item and move it to the DONE column?
- Now we can move an item from the BACKLOG to IN-PROGRESS
- …and repopulate the BACKLOG column
- That gives you a sense of what it looks like to model the full flow, from the point at which an item is added to the backlog until it is done. This is referred to as the CYCLE TIME – and this the fundamental metric used to understand the performance of a system (and predict work completion). In addition to measuring and limiting WIP, the other metric you may hear mentioned is LEAD TIME. For now, we’ll keep it simple and go with CYCLE TIME as the metric that it makes sense to optimize…
- Which brings us to our fourth and final core principle: OPTIMIZE CYCLE TIME.
- Imagine this:We realize that tasks that are IN PROGRESS fall into two basic categories – stuff that is being coded and stuff that is being tested. Our sense is also that there are folks on the team who could be productively testing even though our complement of coding tasks is full. We adjust the board to reflect this explicitly and increase the overall number of items based on this new division of labor. Now, in addition to three tasks that are being coded, we have room for a couple of tasks that are being tested.This legitimately increases the amount of work that can be active within the system, hopefully without affecting focus. This already holds the promise of improving cycle time, since it may allow more work to flow through the system. We won’t know until we try it and measure the results – but let’s see what often happens next…
- A coding task is completed and ready for test. In our previous simpler model, IN PROGRESS items flowed directly to the DONE state, which has no WIP limit. In our refined model, we want to move the item from the CODE to TEST sub-category.
- But wait! That would exceed the WIP limit for the TEST category – those folks are all busy testing previously coded items...Unfortunately, that in turn means that a new item cannot be pulled in from the backlog, since that would exceed the WIP limit for the CODE subcategory – and that seems wrong, since a coder is really available. The lingering complete item in the CODE column is artificially (and incorrectly) blocking the flow. Kanban is particularly good at identifying bottleneck by visualizing them on the board. Sometimes the bottlenecks reflect a problem with representation of the workflow; sometimes they reflect real problems with the actual workflow.
- How do we resolve this? We could just increase the WIP limit in the CODE column (and the IN PROGRESS category) – but that doesn’t seem quite right, because there is a task that affecting the WIP limit that is not actually being worked on. So let’s try something different – we’ll need to create a little space….
- … to make room for a test queue!
- So this allows us to unblock the flow by moving an item to the test queue…
- …and pull an item from the backlog to be coded. Yay!
- This in turn frees up a spot on the backlog, so that another item can be prepared for action. A few notes on this simple example: the real idea is to accurately reflect (and resolve bottlenecks affecting) the real workflow (not just have fun with visualizations) ;-) resist the temptation to over-engineer the workflow – but most will evolve as bottlenecks and optimizations emerge turns out (not really by accident) that the concept of QUEUE-ing and the resultant PULL dynamic are key drivers of optimization (which is related to something called the Theory Of Constraints or TOC) – follow the references to learn more about this if you are curious about the theoretical underpinnings another closely related Kanban (or Lean) priority is to ELIMINATE WASTE – where WASTE is understood as a mismatch between available resources and available work; bottlenecks and queues are a key indicators of waste in the value stream Finally, a more complete Kanban board also includes explicit work rules (for instance, around when tasks are complete and ready for the next stage in the workflow), and provisions for dealing with interrupts (by allowing for differentiated Class Of Service, or tagging/arranging cards into horizontal swim-lanes - and – CRUCIALLY - visualizing the impact).
- So much for the theoretical example – how mightyou use Kanban in your daily work?
- A great place to start is a simple Kanban reflecting your personal work items – this can be created in a few minutes using a whiteboard and post-it notes.
- A whiteboard approach can also be extended to the work of your team or project – this is a nice, annotated real-world example.
- A number of popular tools provide direct support for Kanban-style visualization – Atlassian JIRA with GreenHopper is probably the dominant example of a general purpose tool of this kind.
- Okay Mister Kanban – if Kanban is so great - show me how we are or could be using Kanban here at Voxeo!
- As we mentioned at the outset – and I hope is obvious by now - Kanban aligns very well with our stated priorities for execution: FOCUS: Limit WIPEXECUTE: Visualize Work Flow (and get work moving from BACKLOG to DONE) MEASURE: Measure and Manage Flow ITERATE: Optimize Cycle Time
- Here are three quick examples…
- Individuals can and do use Kanban to optimize their personal workflow – start out with simple paper/whiteboard approach or use a free online tool like: http://www.personalkanban.com
- The Voxeo Engineering team has defined its Software Development Life Cycle (SDLC) with Kanban (and Scrum) in mind – check it out on the Wiki at http://evolution.voxeo.com/wiki/corp:engsdlc
- Product Delivery is using a tool called LeanKitKanban to model the delivery team goals – feel free to request access (read-access is free).
- That seems like enough for a first dose: Any questions?
- Remember: Kanban is about enhancing the flow of work through a system…
- …and improving focus and execution – so STOP STARTING and START FINISHING – and enjoy using Kanban!
- http://www.personalkanban.comApplying Kanban to your personal task listhttp://www.agilemanagement.net/ David Anderson website addressing Kanban and Agile Managementhttp://www.limitedwipsociety.org/Kanban Community Websitehttp://refcardz.dzone.com/refcardz/getting-started-kanban Handy-dandy detailed summary of Kanban for Software Development