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.
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
17.
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
19.
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
24.
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
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
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…