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.

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. }