Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Kanban
Semelhante a Kanban (20)
Último
Último (20)
Kanban
- 1. Introduction To Kanban By Kunal Nair kunalnair1@gmail.com
- 2. What is Kanban • Japanese term for “signboard” • A process first introduced by Taiichi Ohno in mid 20th century for Toyota Production System. • Taiichi introduced Kanban cards as “order cards” • restock parts “just in time” • reducing the inventory of unused parts • improving production flow • Real World examples Introduction To Kanban
- 3. Benefits • Improved quality • Faster turnaround • Identification and elimination of bottlenecks • Reduction of wait time/ queue time • Improved teamwork • Reduction of waste • Self managed team Introduction To Kanban
- 4. Core Principles Introduction To Kanban Visualize your workflow Limit your Work In Progress (WIP) Manage flow Make Process Policies Explicit Improve Collaboratively - Kaizen
- 5. Littles Law • According to John Little, the MIT Professor, The total number of customers in a queueing system (L) is equal to the rate at which customers arrive and enter the system (λ) multiplied by the average time per customer in the queue (W). L = λW or W = L / λ • In software development this can be equated to Number of WIP items = Lead Time to complete a WIP Item Value added time spent on the WIP item Introduction To Kanban
- 6. Work In Progress (WIP) Introduction To Kanban Issue Reported (15 mins) Issue Prioritization (1 hour) Develop a Fix for the issue (2 hours) Test the fix/ patch (3 hours) Prepare fix for release (45 mins) Production Deployment (1 hour) 4 days wait 5 days wait 4 days wait 4 days wait 4 days wait Efficiency: 8 hours / 176 hours = 4.54% Limit WIP to 10 From Little’s Law: WIP = 176 / 8 = 22 items New Lead Time = WIP (10) * Value added time (8) = 80 hours New Efficiency = 8 hours / 80 hours = 10% Value added time - 8 hours Wait Time – 21 days/ 168 hours Lead Time – 176 hours
- 7. Work In Progress (WIP) cont. Introduction To Kanban Value added time - 8 hours Wait Time – 21 days/ 168 hours Lead Time – 176 hours WIP – 22 Items Efficiency – 4.54% Increase Throughput • Hire enough resources to reduce the Lead time to 80 hours • Lets assume that the value added time is still the same • New Efficiency = 8 hours / 80 hours = 10% Reduce WIP Items • Reduce WIP items to 10 • We know from Little’s law WIP = Lead Time / Value added time or Lead Time = WIP * Value added time • New Lead time = 10 * 8 hours = 80 hours • New Efficiency = 8 hours / 80 hours = 10%
- 8. Moving Beyond the “To Do” Lists Introduction To Kanban
- 9. Kanban Board Introduction To Kanban PRIORITY WORKFLOW WIP Limit
- 10. Getting Started • Establish your value stream – Backlog/ Design/ Dev/ Testing/ Deployment/ Complete • Make your backlog explicit • Prioritize your backlog • Limit your WIP • Have a column with blocked items • Retrospect/ Reflect on tasks to improve process after completion • Revisit Prioritization (JIT prioritization) every time you are done with a current task and have capacity to add new items to the Doing Introduction To Kanban
- 11. Prioritization – Time Management Matrix Introduction To Kanban Important Urgent Quality Quadrant Important But Non-urgent Quadrant of Waste Neither Important Nor Urgent Mission Critical Quadrant Important & Urgent Deception Quadrant Not important But Urgent
- 12. Microsoft Case Study 2004 Introduction To Kanban Product Owners PM 1 PM 2 PM 3 PM 4 DEV QA Backlog Deployment 155 days
- 13. Microsoft Case Study 2004 cont. Steps taken by the new manager • Visualize the work flow (diagram on prior slide) • Analyze existing policies • Estimation policy – new requests had to be estimated within 48 hours • Minor changes policy – took priority and had expedited dev & test phase • Prioritization policy – Backlog was prioritized once every month Introduction To Kanban
- 14. Microsoft Case Study 2004 cont. Changes enforced by the new manager 1. Stop estimating 2. Limit the Work-In-Progress 3. More Frequent Prioritization meetings Promised lead time of 4 weeks Introduction To Kanban
- 15. Microsoft Case Study 2004 cont. Revised Workflow Introduction To Kanban Product Owners PM 2 DEV QA Backlog Deployment 25 days PM 1 PM 3 PM 4 Input Queue WIP Limit - 8
- 16. Microsoft Case Study 2004 cont. Results • Immediate Results: • Lead time successfully reduced from 4 months to 4 weeks • Weekly meetings were smoother • Increased trust and collaboration between product owners and team • By late 2005 • Backlog completely eliminated • Lead time average reduced to 14 days • SLA was met 98% of the time. • Weekly prioritization meetings eliminated Introduction To Kanban
- 17. References • Kanban: Successful Evolutionary Change for Your Technology Business • The Principals of Product Development Flow Introduction To Kanban
Notas do Editor
- Real World Examples: Airline Tickets An airline ticket tells the passenger which gate to go to, what time the boarding would start , which seat to go to etc. Think how lost the passenger would be without knowing any such information Starbucks If you ever pay attention to the cashier taking your Starbucks order, he/she always writes your name, the coffee you ordered and always places them in a queue so that the barista knows exactly which order is next and what coffee to brew. Imagine how difficult and inefficient would it be to not have this information or have the person who takes the order make your drink. As a matter of fact, Starbucks is a perfect example of how exactly to implement the Kanban process. Supermarkets Another great example of successful Kanban implementation are the supermarkets where goods are stocked for the consumers to pull from the shelves (demand) and are restocked only when the shelves are empty or low on stock rather than the production of these goods.
- Visualize your workflow: The goal of Kanban is to make positive change to optimize the flow of work through the system hence it is imperative that you know the entire workflow from beginning till the end. Limit your WIP: As Kanban implements the pull system it is critical that the WIP is limited and new work is pulled into the next stage only when there is available capacity. These constraints will quickly illuminate problem areas in your flow so you can identify and resolve them. Manage flow: The idea of implementing Kanban is adding value. For that, you need to look at how value is currently flowing through the system analyzing problem areas in which value flow is stalled and then defining and implementing, changes. Make Process Policies Explicit: Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional and anecdotal. Ex: Having an explicit policy of unit testing and code review before the code can be pulled forward for the testing phase. Improve Collaboratively: Kaizen in Japanese means continuous improvement and Kanban method encourages small continuous, incremental and evolutionary changes
- In other words, Length of the queue = Average Wait Time * Arrival Rate (L = λW) Flipping this equation Average Wait Time = Length of the queue / Arrival Rate (W = L / λ) In software development this can be equated to WIP = Lead Time (throughput) / value added time or WIP = total time to compete 1 WIP / actual time taken to complete the WIP
- Imagine you have been tasked with increasing the efficiency of the above team to, lets say, 10% You can achieve it 2 ways Increase the throughput, ie. Hire more additional recourses to reduce the lead time to 80 hours Efficiency = 8/ 80 = 10% 2. Another approach would be to limit the WIP to 10 items which means that our new lead time would be: Lead Time = WIP (10) * value added time (8) = 80 hours Efficiency = 8/80 = 10% Hence limiting your WIP is so compelling and one of the most important principles of Kanban
- While one may think highly about a TO-DO list, it has many limitations we don’t think of Maintenance – How do we keep on editing and maintaining the TODO lists with time ? Scalability – Work OK for a small scale task list. How do we PRIORITIZE, highlight ROAD BLOCKS, scale it for my team, re-writing stuff every time we get a set of new tasks ? Outlook and Digital TO-DO – Digital TO-DO lists remove many of the manual overheads like re-writing, completing, flagging the tasks but they still are very poor with PRIORITIZATION, highlighting ROADBLOCKS and do not depict the WORK FLOW Enter Kanban boards
- Example of a simple Kanban Board PRIORITIZE, PRIORITIZE, PRIORITIZE: I cannot emphasize enough on the importance of prioritization. Imagine asking customer – can you please categorize the 100 requirements as High, Medium and Low and then realizing that the customer has marked 80 as high, 15 as medium and 5 as low making the expectations unrealistic. Hence the key is to Prioritize. Rather, the question should have been – Please prioritize these 100 requirements from 1 to 100. The above Kanban board prioritizes the tasks/ backlog items on the left most corner in the order of their priority (bottom to top) Visualize Flow – Establish the value stream: If you remember, a few slides ago, when we talked about the Principles of Kanban, we talked about visualizing the workflow. In the above Kanban board, the work items moves from left to right passing through each defined stage until they are moved to the completed stage. WIP: We also talked about limiting your WIP without which you would often find yourself overwhelmed with the tasks you are working on. The above board has the WIP limit set to 5
- Blocked Item: Have a dedicated area on your story board/ Kanban board for items which are blocked due to external factors. This helps you to make your work flow more productive. Ex: Imagine that your WIP limit is 3 and all 3 of those items are blocked due to external factors (waiting for external teams to develop components to be integrated / waiting for business line to provide clarifications/ waiting paint to dry). Suddenly you find that you have ample time but cannot add more items to the WIP due to the set WIP limit . In such scenarios, the blocked item comes in handy, but remember its not a procrastination block. It’s idea is to provide insight on the blocked items and determine the road blocks which we often oversee (covered in the case studies ahead) Its generally a good idea to have a WIP limit and deadline on the tasks in this column too so that you don’t end up with a bunch of tasks in the blocked status.
- According to Stephen Covey – keynote speaker the tasks can be prioritized by asking 2 simple questions: Is the task urgent? Is the task important Mission Critical Quadrant: This quadrant lists the tasks which are both urgent and important Ex: Production Issues, Last minute defect preventing the project from going live. These are the tasks one should consider while retrospection after task completion. The idea is to prevent such tasks rather than react to it. Quality Quadrant: This quadrant includes the tasks which are Important but not urgent Ex: Improving the performance of an application, Developing a coding standards document This quadrant is also referred as the quadrant of Kaizen (continuous improvement) as the tasks under this quadrant improve overall quality and efficiency – Investment into future Quadrant of Deception: This quadrant lists the tasks which are urgent but not important. Ex: Meetings/ Phone calls/ social interruptions etc. While not all meetings and phone calls can be categorized as “non-important” but all of them can we tweaked to minimize waste and maximize value Quadrant of Waste: This quadrant lists the tasks which are neither important nor urgent Ex: Idle Time/ Lunch, Surfing the internet etc. Some of these tasks are truly a waste but still required to recharge your battries
- Maintenance Team consisting of 1 manager, 3 developers and 3 testers. This team took work requests from 4 different Product Owners who acted as Customers Followed SDLC methodology Produced a generally good quality application Lead time for a new request was 5 months and backlog was ever growing A new manager was brought in when the backlog size grew to 80 items to address these issues
- Visualizing the work flow Rate of request - 7 new requests per month Backlog prioritization would happen once per month Average engineering effort per request – 11 days but lead time was 155 days meaning over 90% of this lead time was waste. Estimation Policy Effects Customer expected accurate estimates Required 1 day of developer and tester time which equated to 33% of available monthly team capacity Minor Changes Policy Effects Changes arrived without much warning Expedited delivery Requests were sporadic Minor Changes Policy Effects Each month around 75 items were prioritized and re-prioritized
- Stop Estimating: Recover team capacity for development and testing Eliminate variability caused by random intervals of incoming requests and estimates Limit WIP: Limit WIP for development and testing to 8 Add input queue between the backlog and development so that dev would always know about the next item to work on More Frequent Prioritization Weekly meetings Limit the items to added to the Input Queue to 3 making these meetings shorter and thereby eliminating redundancy of re-prioritization Ensured that the Input Queue would always be adequately filled
- After the initial success of reducing the lead time, the process was evolved making additional policy changes like Backlog items more that 6 months old to be purged Large tasks and requests to be flagged by the developers and testers and would require management to take a look at the request As soon as current item was completed, the team would notify the 4 product owners about WIP capacity via email and not wait until the weekly prioritization meetings This was achieved without making any significant changes to the development and testing process except: Limiting WIP Estimating process