5. Working environment
• Software as a Service
• Services sold on their reliability and availability
• Industry is still very young, continual innovation is
essential
• Teams are cross functional
• All members responsible for design,
implementation, deployment and maintenance
• Easy access to Product Development/Business
6. Before Kanban we used Scrum (kinda)
• Scrum practices
• Time boxed iterations of 2 weeks
• White board and post its to track status
• Daily stand ups
• Fortnightly retrospectives
• Not Scrum
• Deploy multiple times an iteration
• No formal product owner
• No end of iteration demo
7. What we liked about Scrum
• A sense of rhythm and points to reflect on our
working practices
• Better visibility over tasks that were dragging
on
• A highly visible feedback loop to help improve
our estimations
9. The iteration deadline felt artificial
• No expectation from business of a post
iteration demo
• High dependence on outside parties
• Frequently over/undershoot due to external
dependencies
• Time box limited choice of tasks in case of
undershoot
10. Not flexible enough mid iteration
• A 2 weeks iteration promises, on average, a 3 week
delay
• The team is responsible for 2nd line support,
operations and maintenance
• We can assign a maintainer role to shield the team
from day to day requests, though this is not always
sufficient
• Need a process that actively embraces the notion
unplanned work
12. Scrum vs Kanban comparison
• In common:-
• Both are Lean and Agile
• Both use pull scheduling
• Both use transparency to drive process
improvement
• Both focus on delivering working software as soon
as possible
13. Scrum vs Kanban comparison
• Differences
• Kanban less prescriptive than Scrum
• Kanban does not prescribe fixed iterations
• In Kanban Lead Time is the principle metric, in
Scrum it is velocity
• Kanban limits Work in Progress directly, Scrum
does this indirectly through sprint planning
14. Why Kanban?
• Retain our discipline and structure
• Limit work in progress rather than work per
time
• Improve responsiveness, through reduction in
Lead Time
• Can accommodate unexpected work without
modifying the system
• Always able to work on the next most
important or risky task
15. Kanban fundamentals
• Visualise the workflow
• Split the work down into small pieces
• Represent each work item on a post it and put on the board
• Use named columns to express where the work item is in the
workflow
• Limit Work in Progress
• Assign explicit limits to how many items may be in progress in
each workflow state, or set of states
• Measure the lead time (average time to complete one
item)
• Optimise the process, aiming to make the Lead Time as small
and as predictable as possible
16. The Board
• Should reflect your real working practices
• Placement of the board is crucial
• Work in progress limits drive behaviour
• Start with loose, achievable limits and expect
to fine tune
• Expect the board to change state on a daily
basis
24. Lessons Learned
• Benefits
• Greater flexibility in our work flow
• We no longer feel that we are fighting our process
• Better able to embrace and support unexpected
work items
• Negatives
• Greater discipline is required in ensuring that all
tasks are completed in a timely manner
25. Lessons Learned
Protect yourself. If you make the team better able
to take on ad-hoc tasks, you must track the
impact and the load.
I have found the following categorisations to be
effective
• Planned Product Development work
• Planned Engineering work e.g. large scale refactoring
• Unplanned Product work e.g. one of reports, small
tweaks to behaviour
• Unplanned engineering work e.g. urgent bug fixes
26. Lessons Learned
• Further observations
• Adoption was almost completely painless
• Due to day to day interaction, the board takes on
a much more important role than it ever did under
scrum
• The team is more confident in deciding what to do
next
• Our stand ups have become much more focused
• Our retrospectives are no longer coupled to the
period of our iteration.
27. Is Kanban for you?
You may find value in Kanban over Scrum if:-
• The team has support, maintenance or Dev Ops
responsibilities
• Time boxed iterations make little sense in your work
flow
• Your priorities change rapidly
• Your organisation is unable to easily support Scrum
roles
You may also want to consider hybrid approaches such as
‘Scrumban’
29. Wrapping up
• Scrum provided us with structure and discipline
• Kanban provided a better model for our work
flow by embracing the unexpected and doing
away with iterations
• Limiting work in progress makes it easier to
consider team level task prioritisation
• Ad-hoc work stacks up, categorise all work items
• Kanban is a tool, as is Scrum. Use the right tool
for the job.
