The document describes how a software company called Polopoly created a "Task Force Team" (T3) to handle urgent bugs, support issues, and project requests outside of regular Scrum sprints in order to reduce pressure on development teams. T3 uses a Kanban system inspired by Toyota's "just-in-time" approach to pull work continuously and limit work-in-process. The T3 board and workflow aims to visually signal needs and drive autonomous work without micro-management. This approach helped protect Scrum teams and provide a sustainable process for responsive work.

1. ksse@polopoly

2. How we re-did the despair section to a task
force team

4. Polopoly – Web Content Management

5. Polopoly – the enterprise
 Software product company
 Enterprise web content management
 Demanding customers: DN, Expressen, SVT, NRK, SJ...
 Product development
 Support
 Professional services
 Started Scrum-ing 2008

6. Problem with Scrum
"No Interference, No Intruders, No Peddlers
- No person outside the team can change the scope or nature of
the work the team is doing during the sprint"
(Schwaber & Beedle)‫‏‬

7. Scrum – the dome

8.  The team commit builds on trust
 A closed door politics
 A Scruming team can only respond to external
changes between sprints: the door is only opened
every fortnight

9. All is not calm outside

10. Things happens all the time
 Bugs in released software
 Difficult support questions
 Projects needing help

11. A lot of despair

12. What to do?
 As a ScrumMaster you should protect the team(s).
 What to do when you can not handle all the panic
yourself?
 We wanted to create a taskforce team: T3

13. To Serve and Protect

14. Requirements
 Always ready to serve
 Small stories handled one at a time
 JIT planning
 Protect the other teams
 Staffed from different departments (doing service)‫‏‬
 Constantly learning and self-organizing
 But it could not be Scrum. No batch and deliver at all
 We had to find another model/process

15. The Toyota Way: Teams

16. From Scrum to Lean - looking at Toyota
 Sort of like a plant at Toyta
 One vehicle at a time
 Signaling needs for an item with a kanban system
 The Scrum board becomes a signaling system for JIT
planing and delivery

17. Kanban

18. KSSE
 We found a small bunch of people working with defining a
process like this for software engineering
 Kanban System for Software Engineering
 Kanban System for Sustaining Engineering
 Focus: Use the visual signaling system as an engine to
drive the process

19. Kanban properties (infoq)‫‏‬
 Physical: It is a physical card. It can be held in the hand, moved, and put into or onto
something.
 Limits WIP: It limits WIP (Work-In-Process), i.e. prevents overproduction.
 Continuous Flow: It notifies needs of production before the store runs out of stock.
 Pull: The downstream process pulls items from the upstream process.
 Self-Directing: It has all information on what to do and makes production autonomous in a
non-centralized manner and without micro-management.
 Visual: It is stacked or posted to show the current status and progress, visually.
 Signal: Its visual status signals the next withdrawal or production actions.
 Kaizen: Visual process flow informs and stimulates Kaizen.
 Attached: It is attached to and moves with physical parts supplied.

20. T3 kanban board
Emerg-
ency 7 Work
slot queues In Wait
max State
12 tp
DOD:ed
this week
To be
planned
Work
In
Done
Process

21. Story card

22. T3 wiki (DOD)‫‏‬

23. Takt
 We still have a daily Scrum to go through last days work
and speak about what is coming
 We have a retrospective every week to get a feeling of
closure often

24. TODO
 Measure Cykle time better
 Better work with impediments
 Probably more ... inspect and adapt

25. Read more...
•http://del.icio.us/peter.antman/kanban