Crack That Wip 2

33

description

Lean Kanban Conference Presentation, Miami FL May 2009

Transcript of Crack That Wip 2

  • 1. Linda M Cook Lean Kanban ConferenceMay 9, 2009 Miami, FL

2. This report is the story of two different teams at The Motley Fool and how they implemented Kanban.The 2 teams differ in the nature of the work they perform and their application of Kanban to improve their system delivery capabilities.The first team, SPOF, is the Infrastructure Team. They have limited project work, as most of their work is generated through a request system as individual units of work. They used Scrum in the past with good success, delivering a completely rebuilt Database Management Platform.The second team, Team 5, is a Development Team. They have been using Scrum for over a year. They used Scrumban to help them understand their WIP limits. 3. Props:Max Keeler VP Program ManagementJeff Lovett SPOF ManagerBrandon Ragan Network EngineerDave Haeffner QuanalystSPOF & Team 5 MembersSee their product offerings at www.fool.com. 4. The Infrastructure Team, aka SPOF, includes allthe support staff necessary to support theFools enterprise.Team member skills include emailadministrators, network engineers, webengineers, server engineers, desktopservices, database administrators, andmanagers. 5. Manage Project Risk Improve communication Increase collaboration Limit process waste 6. Built on the teams experience and understanding of Scrum Practices copied from Scrum: Daily Stand-up Added the question Is there something we should change? Whiteboard for Project Tracking Limited use of a weekly cycle, not iterations Conducted limited retrospectives 7. Eliminated the Scrum practices that did not add value for SPOF No Planning Ceremony No Review Ceremony No PO or ScrumMaster No User Stories No Estimates Added queue limits 8. Continuous Planning no planning ceremony Track tasks, not stories No time tracking Track dates, initially BOD, WIP, Test, Done, switched to BOD and Done only within the first few weeks Captured all tasks in a spreadsheet and tracked flow rate each week, total tasks completed each week Cycle started and ended on Wednesdays Initially conducted retrospectives each week for 30 minutes, within two months switched to monthly retrospectives 9. Initially, the team had 2 active projects, VMWare and SAN Migration Tasks should be able to be completed within 4 12 hours Tasks smaller than this were grouped sometimes Larger tasks were tabled until they knew enough about the task to break it into smaller pieces Queue Limits were set across Backlog, WIP, and Test & Review Project Board was organized in priority order from left to right No documentation on the initial process or practices 10. Kanban talk about fixed size backlog Set an order point the point when more planning is needed 11. Tasks were defined as the work was known or understood, with placeholders created for large items or items that needed some discovery Tasks were Pooled next to the Project Board for ease of reference and pulling into the work queue Team was self-contained and did not require support from others in the organization to prioritize work once the strategic direction was set When the backlog fell below queue levels, team leads would spend a few (~5) minutes pulling items from the pool and putting them in the backlog queue Blockers were highlighted with pink stickie notes for visibility, dated and had a person associated with the blocker. The pink stickie was attached to the associated task until it was resolved. 12. Not an iteration cycle Used as a basis to measure flow and monitor how changes to the queues improved or slowed task completion time Tracked number of tasks completed each week to support right sizing Weekly checkpoint meetings were used primarily to review summary of each project Provided an opportunity to change the priority of the projects 13. The first 2 projects were completed much quicker than originally thought practical Group decided that the Kanban process was helpful in several ways Visibility of the tasks gave everyone a sense of when they would need to complete work Daily Stand-ups generally brought focus to the projects and helped the team focus on the projects at least some portion of their day 14. Group cheer at the end of each standup, all hands to the center and shout Kanban Not everyone showed up every day for the stand-up and it did not seem to disrupt the flow of information Changes in the process and practices occurred rapidly the first 8+ weeks, then slowed 15. It took several weeks to get the sizing right for tasks, first the tasks were generally large, swinging to very small and then started to normalize Test and review was not a part of the standard practice and was added Folks learned the value of the test and review very quickly 16. Flow rate stabilized at 4.15 days within 3 months Once the team found out how well they could track their work with Kanban, most work efforts followed Kanban Standard practices were documented and posted next to the project board This helped new team members get accustomed to the process Gave visibility to the entire tech team about the active projects in SPOF Development teams began tracking the Kanban board to see if their work requests were being addressed 17. Used spreadsheet to capture the tasks by project and the associated BOD and Done dates One of the team leaders created a small VB app to capture tasks instead of the spreadsheet Later, another team member created an electronic board to track all project and task activity Now the team uses the electronic project board exclusively, Digaboard 18. Daily facilitator role conducted by each of the SPOFers Every 2 weeks they draw a name from a hat for a new facilitator Facilitators role: arrive at the meeting place a few minutes before thestand-up and login to the Digaboard application Ensure each project is reviewed each day Updates can be made real-time to Digaboard withmany changes made by a simple drag and drop 19. ProjectsCompleted 17 Tasks Completed 564 Average Days/Project82 Average Tasks/Project 31.11 Average Days/Task 4.11 20. Kanban is used for a significant portion of their work Process is very stable one year later Retrospectives work best when the team is given a survey to complete before the retrospective meeting and then the survey questions are the starting point for the review Digaboard application is being made available as Open Source in the near future, a beta version is almost ready 21. From Scrum to Scrumban Team using Scrum for over a year Developing New Product Line During a Sprint Retrospective the team made 2 observations They were trying to get too much done at the sametime There was no clear point when QA should get involvedin the stories Team talked about Kanban in the past and decided to pilot the practice for the next few sprints 22. Got started using Corey Ladass book Scrumban as a guide They decided to : Define a process for the work Define transition criteria for each step Define a reasonable WIP limit for each step The team began tracking defects 23. Started: Today: Backlog Backlog Ready Specify In Progress Ready QA In Progress Done QA UAT Done 24. To leave Specify you need a test plan To leave WIP the story needs to be functional, on the Integration Server and test plans passed To leave QA the story needs to pass Regression Tests, exploratory test, and boundary tests To leave UAT the customer (story owner) must experience and approve the storyNote: Adherence to the rules were applied basedon the story 25. Ran Kanban for approximately 5 months Tweaked workflow Tweaked WIP Limits Initial queue limits were based on the number of cards Switched queue limits to story points to better account for variability of stories 26. 70605040Velocity 30Defects 20100 12 14 16 18 20 22 24 26 28 30 32 34 27. Continued Teams Learning Limiting WIP was high altitude training Forced the team to slow down and work through their problems Once the pressure was eased, the team felt liberated and functioned at a higher level than before the WIP limits Quality Improvements Provided clear guidance for when the QA resource could plug-in to the process Provided a clear way to handle defects Defects reduced by 94% Removed Planning Waste The Just In Time planning for stories cut planning time from 6 hours to 2 hours Velocity Improved just over 35% 28. After 5 months the team decided they had a good handle on their WIP limits, so they discontinued setting queue limits Their story continues to evolve 29. }