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?• sam@radicalfusion.net• @sammcafee • http://radicalfusion.net