• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Kanban at radical_fusion

Kanban at radical_fusion



Sam McAfee talks about how they have applied Kanban and lean methodologies at RadicalFusion during the San Francisco Agile User Group meeting at Atlassian.

Sam McAfee talks about how they have applied Kanban and lean methodologies at RadicalFusion during the San Francisco Agile User Group meeting at Atlassian.




Total Views
Views on SlideShare
Embed Views



2 Embeds 2

https://twimg0-a.akamaihd.net 1
https://si0.twimg.com 1



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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Kanban at radical_fusion Kanban at radical_fusion Presentation Transcript

    • Kanban at RadicalFusion Sam McAfee, Co-Founder
    • About Me
        • Moved to Bay Area in 1997.
        • Freelanced as web developer starting in late 1999.
        • Co-founded RF in 2002.
    • About Me
        • Started as the only developer. Gradually morphed into...
          • Lead Developer
          • Project Manager
          • Sales / Business Development
        • Now, slowly moving back to coding again.
    • About RadicalFusion
        • Founded in SF 2002. 
        • Moved to Oakland in 2008.
        • Virtual, first 8 years.
        • Opened office space in 2010.
    • About RadicalFusion
        • Web development agency serving:
          • Non-profits / Unions (because we care)
          • Start-ups (because it's fun)
          • Established companies (because we must)
    • About RadicalFusion
        • Small team:
          • 2 co-founders
          • 5 engineers
          • 1 business analyst
          • 1 project manager
          • outsource VD and UX (but hiring...)
    • Early Methodology
        • 2002 to 2004: Waterfall
          • Constantly exceeding estimates
          • Frequent disputes with client over scope
          • High defect rates, poor code quality
        • Inexperienced developers (namely, me!)
    • Early Agile Adoption
        • Started hiring other developers around 2004.
        • Started incorporating Agile around the same time:
          • Iterations instead of phases
          • Test-driven development
          • Gradual adoption of design patterns
        • No particular style. Hybrid of Scrum, XP, FDD and others.
    • Early Agile Adoption
        • Local, but virtual team though, so...
          • No pair-programming, obviously
          • No daily stand-ups
          • No retrospectives (not "officially", anyway)
    • Maturing Agile Adoption
      • Gradually added:
        • Automated builds
        • Continuous integration
        • Automated acceptance tests
    • Early Tool Use: Version One
        • Started using Version One in 2006.
          • Release Planning with stories, epics
          • Iterations built-into work-flow
          • Tracks Burn-down, velocity automatically
        • Used tool to enforce the process
          • Not very Agile, true.
          • But virtual teams are hard to manage!
    • Early Tool Use: Version One
        • Too "Enterprisey" for us
          • Most projects were 1 release anyway
          • Cluttered UI
          • Features overkill: maybe used 10% of it
          • Pricey!
    • Later Tool Use: Pivotal Tracker
        • A friend showed us Pivotal in 2009.
          • Simple UI
          • Story-board look and feel
          • Lots of automatic time-sensitivity (velocity, iterations).
    • Later Tool Use: Pivotal Tracker
        • Did not fit our process very well:
          • Hard to track builds, tests from other systems
          • Hard to manage acceptance criteria
          • Poor tracking, reporting features
    • Pivotal vs. VersionOne
        • Both tools have limitations:
          • VersionOne is too complex
          • Pivotal is too simple
        • Considering moving away from online tools entirely!
        • What will we do then?
    • Enter Kanban...
        • How did we find out about it?
        • Searching for Agile resources online...
          • Net Objectives
          • Lean Software Development
          • Taiichi Ohno
          • Kanban!
    • Enter Kanban...
        • Kanban is part of Lean. Lean must be properly understood in order to make use of Kanban.
        • Applying Lean Principles:
          • Value stream mapping
          • Cycle time
          • Queues and Bottlenecks
          • Work in Process (WIP) Limits
          • Measuring Progress
          • Stop the Line
    • Value Stream Mapping
        • Visual representation of how value flows through your production process.
        • Start with origin of concept or idea
          • Customer request
          • Feature idea
          • Infrastructural requirement
        • End with consumption of the result
          • Request processed
          • Feature delivered
          • System in place
        • Map every step in between needed to produce it
    • Cycle Time
        • How long does it take one item of work to get from initial concept to delivery to the customer?
        • This is your cycle time.
        • Delays in a process represent waste.
        • The longer it takes to produce, the greater the risk of increased waste.
        • Your goal is to reduce cycle time.
    • Queues
        • Between steps in the value stream, items sit in a queue.
        • Items of work spend most of their time here.
        • Managing queues is critical to managing cycle time. 
          • How long are your queues?
          • Can you reduce the size of the queue?
          • Figure out what the bottle-neck is and eliminate it.
    • WIP Limits
        • Multi-tasking is evil
          • Teams and individuals can easily become overloaded
          • Partially completed work = waste
          • Items wait longer in the queue = more waste
        • Focus on just one thing at a time
        •   Our approach:
          • No more than x items worked on at a time, where x = team size / 2.
          • Everything can be paired on. Pairing = better code
          • No-one works alone (unless it really only makes sense to do so).
          • Thus Lean encourages better Agile practices
    • Measuring Progress
        • Measure the right things.
          • Measure cycle time.
          • Measure queues.
          • Measure WIP.
          • Measure value produced, if possible.
        • Use the feedback you get to optimize the whole process .
    • Stop the Line
        • Empower the team to halt the production line if a defect is discovered.
        • Examples in software:
          • Broken builds trigger a "swarm".
          • Fix defects first, then continue feature development.
          • Adjust the process immediately, when not working.
          • Ask for help.
    • Barriers to Kanban at RadicalFusion
        • Team was not co-located.
        • Projects were silos.
        • Iterations were a false "cadence".
        • Not measuring the right the metrics.
    • Barriers to Kanban at RadicalFusion
        • Opened an office. Co-located the team.
        • Set up the board to merge all projects into a single queue.
        • Moved to continuous deployment model.
        • Started tracking cycle time, wait time, and work time.
    • The Kanban Board
      • First attempt:
    • The Kanban Board
      • Second attempt:
    • The Kanban Board
      • Current attempt:
    • Barriers to Kanban at RadicalFusion
        • Still face some challenges:
          • Estimates are not part of Kanban, but clients want them anyway.
          • Fixed-scope contracts are a reality.
          • Keeping work-item sizes relatively uniform.
    • Thank You!
      • Questions?
        • [email_address]
        • @sammcafee
        • http://radicalfusion.net