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...o Lead Developero Project Managero 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:o Non-profits / Unions (because we care)o Start-ups (because it's fun)o Established companies (because we must)
About RadicalFusion
• Small team:o 2 co-founderso 5 engineerso 1 business analyst o 1 project managero outsource VD and UX (but hiring...)
Early Methodology
• 2002 to 2004: Waterfallo Constantly exceeding estimateso Frequent disputes with client over scope o 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:
o Iterations instead of phases o Test-driven developmento Gradual adoption of design patterns
• No particular style. Hybrid of Scrum, XP, FDD and others.
Early Agile Adoption
• Local, but virtual team though, so...o No pair-programming, obviouslyo No daily stand-upso 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.o Release Planning with stories, epicso Iterations built-into work-flowo Tracks Burn-down, velocity automatically
• Used tool to enforce the processo Not very Agile, true.o But virtual teams are hard to manage!
Early Tool Use: Version One
• Too "Enterprisey" for uso Most projects were 1 release anywayo Cluttered UIo Features overkill: maybe used 10% of ito Pricey!
Later Tool Use: Pivotal Tracker
• A friend showed us Pivotal in 2009.o Simple UIo Story-board look and feelo Lots of automatic time-sensitivity (velocity, iterations).
Later Tool Use: Pivotal Tracker
• Did not fit our process very well:o Hard to track builds, tests from other systemso Hard to manage acceptance criteriao Poor tracking, reporting features
Pivotal vs. VersionOne
• Both tools have limitations:o VersionOne is too complexo 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...
o Net Objectives o Lean Software Developmento Taiichi Ohnoo Kanban!
Enter Kanban...
• Kanban is part of Lean. Lean must be properly understood in order to make use of Kanban.
• Applying Lean Principles:o Value stream mappingo Cycle time o Queues and Bottleneckso Work in Process (WIP) Limitso Measuring Progress o Stop the Line
Value Stream Mapping
• Visual representation of how value flows through your production process.
• Start with origin of concept or ideao Customer requesto Feature ideao Infrastructural requirement
• End with consumption of the resulto Request processedo Feature deliveredo 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.
o How long are your queues?o Can you reduce the size of the queue?o Figure out what the bottle-neck is and eliminate it.
WIP Limits
• Multi-tasking is evilo Teams and individuals can easily become overloadedo Partially completed work = wasteo Items wait longer in the queue = more waste
• Focus on just one thing at a time• Our approach:
o No more than x items worked on at a time, where x = team size / 2.
o Everything can be paired on. Pairing = better codeo No-one works alone (unless it really only makes sense to
do so).o Thus Lean encourages better Agile practices
Measuring Progress
• Measure the right things. o Measure cycle time.o Measure queues.o Measure WIP.o 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:o Broken builds trigger a "swarm".o Fix defects first, then continue feature development.o Adjust the process immediately, when not working.o 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:o Estimates are not part of Kanban, but clients want them
anyway.o Fixed-scope contracts are a reality.o Keeping work-item sizes relatively uniform.
Thank You!
Questions?• [email protected]• @sammcafee • http://radicalfusion.net
Top Related