Kanban at RadicalFusion Sam McAfee, Co-Founder
About Me <ul><ul><li>Moved to Bay Area in 1997.  </li></ul></ul><ul><ul><li>Freelanced as web developer starting in late 1...
About Me <ul><ul><li>Started as the only developer. Gradually morphed into... </li></ul></ul><ul><ul><ul><li>Lead Develope...
About RadicalFusion <ul><ul><li>Founded in SF 2002.  </li></ul></ul><ul><ul><li>Moved to Oakland in 2008.  </li></ul></ul>...
About RadicalFusion <ul><ul><li>Web development agency serving: </li></ul></ul><ul><ul><ul><li>Non-profits / Unions (becau...
About RadicalFusion <ul><ul><li>Small team: </li></ul></ul><ul><ul><ul><li>2 co-founders </li></ul></ul></ul><ul><ul><ul><...
Early Methodology <ul><ul><li>2002 to 2004: Waterfall </li></ul></ul><ul><ul><ul><li>Constantly exceeding estimates </li><...
Early Agile Adoption <ul><ul><li>Started hiring other developers around 2004.  </li></ul></ul><ul><ul><li>Started incorpor...
Early Agile Adoption <ul><ul><li>Local, but  virtual  team though, so... </li></ul></ul><ul><ul><ul><li>No pair-programmin...
Maturing Agile Adoption <ul><li>Gradually added:  </li></ul><ul><ul><li>Automated builds </li></ul></ul><ul><ul><li>Contin...
Early Tool Use: Version One <ul><ul><li>Started using Version One in 2006. </li></ul></ul><ul><ul><ul><li>Release Planning...
Early Tool Use: Version One <ul><ul><li>Too &quot;Enterprisey&quot; for us </li></ul></ul><ul><ul><ul><li>Most projects we...
Later Tool Use: Pivotal Tracker <ul><ul><li>A friend showed us Pivotal in 2009. </li></ul></ul><ul><ul><ul><li>Simple UI <...
Later Tool Use: Pivotal Tracker <ul><ul><li>Did not fit our process very well: </li></ul></ul><ul><ul><ul><li>Hard to trac...
Pivotal vs. VersionOne <ul><ul><li>Both tools have limitations: </li></ul></ul><ul><ul><ul><li>VersionOne is too complex <...
Enter Kanban... <ul><ul><li>How did we find out about it?  </li></ul></ul><ul><ul><li>Searching for Agile resources online...
Enter Kanban... <ul><ul><li>Kanban is part of Lean. Lean must be properly understood in order to make use of Kanban.  </li...
Value Stream Mapping <ul><ul><li>Visual representation of how value flows through your production process. </li></ul></ul>...
Cycle Time <ul><ul><li>How long does it take one item of work to get from initial concept to delivery to the customer? </l...
Queues <ul><ul><li>Between steps in the value stream, items sit in a queue. </li></ul></ul><ul><ul><li>Items of work spend...
WIP Limits <ul><ul><li>Multi-tasking is evil </li></ul></ul><ul><ul><ul><li>Teams and individuals can easily become overlo...
Measuring Progress <ul><ul><li>Measure the right things.  </li></ul></ul><ul><ul><ul><li>Measure cycle time. </li></ul></u...
Stop the Line <ul><ul><li>Empower the team to halt the production line if a defect is discovered. </li></ul></ul><ul><ul><...
Barriers to Kanban at RadicalFusion <ul><ul><li>Team was not co-located. </li></ul></ul><ul><ul><li>Projects were silos. <...
Barriers to Kanban at RadicalFusion <ul><ul><li>Opened an office. Co-located the team. </li></ul></ul><ul><ul><li>Set up t...
The Kanban Board <ul><li>First attempt: </li></ul>
The Kanban Board <ul><li>Second attempt: </li></ul>
The Kanban Board <ul><li>Current attempt: </li></ul>
Barriers to Kanban at RadicalFusion <ul><ul><li>Still face some challenges: </li></ul></ul><ul><ul><ul><li>Estimates are n...
Thank You! <ul><li>Questions? </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><ul><li>@sammcafee  </li></ul></ul>...
Upcoming SlideShare
Loading in …5
×

Kanban at radical_fusion

1,842 views

Published on

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

http://youtu.be/RkV1WgeQX8A

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,842
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
29
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Kanban at radical_fusion

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

×