• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
From Scrum to Kanban
 

From Scrum to Kanban

on

  • 4,515 views

Switching my Scrum team to Kanban. Why we did it, how we did it and what we learned.

Switching my Scrum team to Kanban. Why we did it, how we did it and what we learned.

http://fragile.org.uk

Statistics

Views

Total Views
4,515
Views on SlideShare
3,537
Embed Views
978

Actions

Likes
4
Downloads
83
Comments
0

6 Embeds 978

http://fragile.org.uk 811
http://blog.jaffamonkey.com 140
http://tracks.roojoom.com 17
http://webcache.googleusercontent.com 5
http://feeds.feedburner.com 3
http://translate.googleusercontent.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • High light non scrums
  • What is a mainainter? Talk about 2nd line support. Talk about devops
  • Something about expectations of actually being live. Talk about importance of lead time.
  • Will self post it wall?
  • Entire team does everything, an idea for number of post its, move on a daily basis
  • AslakHelloy < name Aslak on the slide or at the end, rate of doing work

From Scrum to Kanban From Scrum to Kanban Presentation Transcript

  • From Scrum to Kanban
    Neil Johnson
  • ScrumKanbanLessons Learned
  • “The only thing that really matters is the quality of the team. Everything else is an optimisation.“
  • ScrumKanban Lessons Learned
  • 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
  • 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
  • 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
  • Scrum was great but we had two problems with it….
  • 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
  • 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
  • ScrumKanbanLessons Learned
  • 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
  • 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
  • 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
  • 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
  • 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
  • A simple example
  • A more complicated example
  • The post its
  • How to measure lead time and optimise the process?
  • Cumulative Flow Diagram
    Aslak Hellesøy
  • Lead Time
  • ScrumKanban Lessons Learned
  • 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
  • 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
  • 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.
  • 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’
  • ScrumKanbanLessons Learned
  • 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.
  • And Finally…..
    Contact
    • neil@fragile.org.uk
    • http://fragile.org.uk/
    • @neilisfragile
    References
    • http://open.bekk.no/2009/11/03/cumulative-flow-diagrams-with-google-spreadsheets/
    • http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf