Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Intro to Kanban

118 vues

Publié le

It's actually more than a board.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Intro to Kanban

  1. 1. @scrumhive
  2. 2. @scrumhive Colleen Johnson • CEO & Founder of ScatterSpoke • LeanKanban Accredited Kanban Trainer • Kanban Coaching Professional • Former AgileDenver Board of Directors • Co-chair 2016 & 2017 Mile High Agile Conference • Member Agile Uprising Board of Directors • Mama to three amazing kiddos @scrumhive
  3. 3. @scrumhive • Toyota Production Systems “TPS” 1948 • Ridding the system of WASTE o MURI~ overburden o MURA~ inconsistency o MUDA~ waste • Just-in-time “JIT” Production • KAIZEN~ continuous improvement • Respect for People Origins of Lean Thinking
  4. 4. @scrumhive Kanban has two meanings: Both meanings are incorporated into the Kanban Method: Kanban written in Kanji (Chinese characters) 看板 means “sign” or “large visual board” Kanban written in Japanese alphabet, hiragana, かんばん means signal cards(s) Kanban Has Two Meanings
  5. 5. @scrumhive 1. Start with what you do now 2. Agree to pursue evolutionary change 3. Initially, respect existing roles, responsibilities and job titles 4. Encourage acts of leadership at all levels Kanban Principles
  6. 6. @scrumhive Start Finishing Stop Starting
  7. 7. @scrumhive 1. Visualize work 2. Limit work-in-progress 3. Manage flow 4. Make policies explicit 5. Implement feedback loops 6. Improve collaboratively, evolve experimentally Kanban Practices
  8. 8. @scrumhive Visualize Work Number One: • Start with your existing process • Don’t copy an existing Kanban flow • Use VERBS • Focus on activities at each stage • Avoid Roles • Avoid Hand offs • Avoid ”Holding Tanks” • Surface blockers quickly
  9. 9. @scrumhive (Okay, this part really is just a board)
  10. 10. @scrumhive Work Item Types • What type of requests come to your team • Tech Debt • User Stories • Prod Defect • Consider how you treat your work types as separates “classes of service” • Expedited • How will you visualize these differences? • Card color, Swim lanes, Sticky Dots
  11. 11. @scrumhive Fit-for-Purpose • Our process is never final, it is always adapting to fits the needs of the business • AKA, not one size-fits-all • Identifying opportunity, trying something different, and iterating on solutions
  12. 12. @scrumhive Limit Work in Progress Number Two: • Determine rate of Departures and Arrivals • Consider total number of contributing team members • Look at each phase of the workflow • Make blockers painful • Focus on minimizing multi-tasking • Measure and experiment!
  13. 13. @scrumhive To Do 2 Dev 3 Code Review 1 QA 2 Deploy 6 Signal of Capacity
  14. 14. @scrumhive To Do 2 Dev 3 Code Review 1 QA 2 Deploy 6 swarm to remove blockers Stop the Line
  15. 15. @scrumhive To Do 2 Dev 3 Code Review 1 QA 2 Deploy 6 Set limits the team agrees to follow
  16. 16. @scrumhive Work Done Doing Work is Less valuable than
  17. 17. @scrumhive Manage Flow Number Three: • Know your target cycle time • Making aging work visible • Always look to finish first • Amplify blockers • Revisit priority daily
  18. 18. @scrumhive Kanban Metrics • Lead Time: the duration for a work item from beginning to end, including process time and wait states. • Cycle Time: the duration for a work item to move from point A to point B. • Through Put: the count of work items processed per a specific amount of time. • Work in Progress: the total amount of work you have committed to but have not completed at any given time • Flow Efficiency: the ratio between working time and the cycle time (expressed as a percentage)
  19. 19. @scrumhive To Do 2 Dev 3 Code Review 1 QA 2 Deploy 6 Tracking Cycle Time
  20. 20. @scrumhive Sample Data Screenshot from ActionableAgule
  21. 21. @scrumhive First Out FIFO, First In
  22. 22. @scrumhive Predictability can only come from limiting WIP Littles LAW: Cycle time = WIP Throughput Why WIP Matters
  23. 23. @scrumhive Sample Data Screenshot from Kanbanize
  24. 24. @scrumhive Forecasting Accurate Dates • Real data includes all variability • Use Actionable Agile to get your 85% target • Take pressure off the team to guess • Save time and skip story pointing
  25. 25. @scrumhive Sample Data Screenshot fromJira
  26. 26. @scrumhive Make Policies Explicit Number Four: • Criteria required for work items to move forward •Exit Criteria •Definition of Done • Agreed to by the entire team • Make these visible at standup • Review them at retrospectives
  27. 27. @scrumhive Review AC Tech arch Unit tests Code Reviews Regression Automation Demo Docs Exit Criteria on Display
  28. 28. @scrumhive Kanban Daily Meeting • Walk the work right to left • Did we cover all of the policies? • What is close to being done? • What is the highest priority to pull? • What is aging or stuck? • What is blocked?
  29. 29. @scrumhive Not the People Manage the Work,
  30. 30. @scrumhive Implement Feedback Loops Number Five: • Daily Standup • Replenishment Meeting • Operations Review • Cross Team • Delivery Planning Meeting • Service Delivery Meeting • Customer View • Retrospective
  31. 31. @scrumhive To Do 2 Dev 3 Code Review 1 QA 2 Deploy 6 Data Driven Decision Making
  32. 32. @scrumhive Improve Collaboratively, Evolve Experimentally Number Six: • There’s always ALWAYS room for improvement • Adopt a Kaizen mindset • Leverage data to make targeted improvements • Experiment! Try something different and measure • Never skip the retrospective
  33. 33. @scrumhive What’s Different? • We make targeted improvements to our system based on data and metrics from our current performance • AKA, not guessing • Blending internal process and external delivery
  34. 34. @scrumhive Plan-Do-Check-Act • PLAN: Plan your improvements, including setting goals. • DO: Put in place the actions required for improvement. • CHECK: Measure your success relative to your baseline. • ACT: Adjust or tweak your changes PLAN: Identify the Issue DO: Fix the Problem CHECK: Measure the Fix ACT: Adjust the Fix
  35. 35. @scrumhive Where do I start? 1. Focus Efforts on Priority 2. Manage Work to Done 3. Amplify Obstacles to Resolution 4. Predict Delivery with Confidence 5. Improve Process with Data
  36. 36. @scrumhive Pain point: Team lacks focus • Constantly shifting priorities • Multi tasking and context switching • Meeting and planning overhead • Premature feature commitments • High stress for the team
  37. 37. @scrumhive Create Visibility • Transparency of work and priorities • Representation of varied work items • Clear ownership and status • Distribution of work load • Informed decision making
  38. 38. @scrumhive Pain point: Work is slow to complete • Long delivery times • Poor code quality • High volume of changes in flight • Introducing Technical debt • Overburdening with in the team
  39. 39. @scrumhive Self Managing Teams • Agree on workflow policies • Push towards cycle time targets • Swarm on work to finish faster • Create slack to respond to unplanned work • Find a sustainable pace of work
  40. 40. @scrumhive Pain point: Working around the blockers • Hidden Dependencies • Waiting for external teams • Abandoned code changes • High level of people management • Defect fixes are lowest priority
  41. 41. @scrumhive Resolve Blockers Faster • Focus standups on the work • Bring attention to stuck items • Make resolving blockers a top priority • Elevate cross team impediments
  42. 42. @scrumhive Pain point: Estimates are inaccurate • Missed delivery dates • Estimates based on limited knowledge • Pointing far ahead of working • Narrow focus of activities • Team members change
  43. 43. @scrumhive Forecast with Accuracy • Use existing data to forecast delivery dates • Forecast without story pointing or estimating • Forecast without full story definition • Track real time delivery probability • Give the team ownership of project tracking
  44. 44. @scrumhive Pain point: Abandoned Agile Practices • One-size fits all agile practices • Stories constantly carry over • Time spent backlog grooming • No time to fold in user feedback • Lack of continuous delivery
  45. 45. @scrumhive Process that Fits • Refined to fit the needs of the team • Changes made based on data • Measurable results and metrics • Ownership of the agile process
  46. 46. @scrumhive Benefits of Kanban • Less Resistance to Change • Reduces the amount of code changes in flight • Less Regression Testing • Better Quality • Minimizes multi-tasking/context switching • Reduces Overburdening • Creates Visibility of Blockers • Less Work in Progress results in Shorter Cycle Times
  47. 47. @scrumhive KanbanScrum Artifacts board, backlog, burndowns board , policies Ceremonies daily scrum, sprint -planning, sprint review, sprint retrospective daily stand up, review on set frequency, planning ongoing Iterations time boxed sprints (2-4 weeks) continuous flow Estimation yes, story points no, cycle time and throughput Teams must be cross-functional can be specialized Roles product owner, scrum master, team team and new roles as needed Teamwork collaborative as needed by task swarming to remove blockers Constraints work limited by sprint content work limited by workflow state Changes should wait for next sprint pulled in as needed Backlog list of prioritized and estimated stories just in time Comparison of Practices
  48. 48. @scrumhive Kanban at all Levels Enterprise Portfolio Team
  49. 49. @scrumhive #NoEstimates #NoPlanning #NoCommitments #NoBacklog #NoRoadmap #NoHeroics #NoHighBloodPressure* *diet and lifestyle outside of work cannot be guaranteed
  50. 50. @scrumhive

×