Crack That Wip 2
Download as PPTX, PDF2 likes700 views
The document summarizes two teams at The Motley Fool and how they implemented Kanban systems. The first team, SPOF, is an infrastructure team that used Kanban to improve communication and limit waste. They tracked tasks on a spreadsheet and digital board. The second team used Scrumban to transition from Scrum by defining workflow stages and work-in-progress limits, which reduced defects and improved velocity over time. Both teams found Kanban helped with process improvement.
Crack That Wip 2
- 2. Linda M Cook Lean Kanban Conference May 9, 2009 Miami, FL
- 3. 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.
- 4. Props: Max Keeler – VP Program Management Jeff Lovett – SPOF Manager Brandon Ragan – Network Engineer Dave Haeffner – Quanalyst SPOF & Team 5 Members See their product offerings at www.fool.com.
- 5. The Infrastructure Team, aka SPOF, includes all the support staff necessary to support the Fool‟s enterprise. Team member skills include email administrators, network engineers, web engineers, server engineers, desktop services, database administrators, and managers.
- 6. Manage Project Risk Improve communication Increase collaboration Limit process waste
- 7. Built on the team‟s 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
- 8. 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
- 9. 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
- 10. 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
- 11. Kanban – talk about fixed size backlog Set an order point – the point when more planning is needed
- 12. 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.
- 13. 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
- 14. 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
- 15. 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
- 16. 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
- 18. 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
- 20. 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‟
- 21. Daily facilitator role conducted by each of the SPOFers ◦ Every 2 weeks they draw a name from a hat for a new facilitator ◦ Facilitator‟s role: arrive at the meeting place a few minutes before the stand-up and login to the Digaboard application Ensure each project is reviewed each day Updates can be made real-time to Digaboard with many changes made by a simple drag and drop
- 22. ProjectsCompleted 17 Tasks Completed 564 Average Days/Project 82 Average Tasks/Project 31.11 Average Days/Task 4.11
- 23. 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
- 25. 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 same time There was no clear point when QA should get involved in the stories ◦ Team talked about Kanban in the past and decided to pilot the practice for the next few sprints
- 26. Got started using Corey Ladas‟s 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
- 27. Started: Today: ◦ Backlog ◦ Backlog ◦ Ready ◦ Specify ◦ In Progress ◦ Ready ◦ QA ◦ In Progress ◦ Done ◦ QA ◦ UAT ◦ Done
- 28. 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 story Note: Adherence to the rules were applied based on the story
- 29. 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
- 30. 70 60 50 40 Velocity 30 Defects 20 10 0 12 14 16 18 20 22 24 26 28 30 32 34
- 31. Continued Team‟s 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%
- 32. 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…
- 33. }