Downloaded 29 times
![Thank You! Questions? [email_address] @sammcafee http://radicalfusion.net](https://image.slidesharecdn.com/kanbanatradicalfusion-110310075821-phpapp02/75/Kanban-at-radical_fusion-30-2048.jpg)
Uploaded bySam McAfee
Kanban at radical_fusion
RadicalFusion, co-founded by Sam McAfee in 2002, evolved from a waterfall methodology to agile and, more recently, to a kanban approach to improve efficiency and manage workflows. The transition to kanban involved implementing lean principles, emphasizing metrics such as cycle time and work-in-progress limits, and overcoming challenges like team co-location and client expectations for estimates. Despite initial hurdles, the adoption of kanban has facilitated better team collaboration and streamlined processes in their virtual development environment.
More Related Content
Similar to Kanban at radical_fusion
Kanban at radical_fusion
- 1. Kanban at RadicalFusionSam McAfee, Co-Founder
- 2. About Me Movedto Bay Area in 1997. Freelanced as web developer starting in late 1999. Co-founded RF in 2002.
- 3. About Me Startedas the only developer. Gradually morphed into... Lead Developer Project Manager Sales / Business Development Now, slowly moving back to coding again.
- 4. About RadicalFusion Foundedin SF 2002. Moved to Oakland in 2008. Virtual, first 8 years. Opened office space in 2010.
- 5. About RadicalFusion Webdevelopment agency serving: Non-profits / Unions (because we care) Start-ups (because it's fun) Established companies (because we must)
- 6. About RadicalFusion Smallteam: 2 co-founders 5 engineers 1 business analyst 1 project manager outsource VD and UX (but hiring...)
- 7. Early Methodology 2002to 2004: Waterfall Constantly exceeding estimates Frequent disputes with client over scope High defect rates, poor code quality Inexperienced developers (namely, me!)
- 8. Early Agile AdoptionStarted 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.
- 9. Early Agile AdoptionLocal, but virtual team though, so... No pair-programming, obviously No daily stand-ups No retrospectives (not "officially", anyway)
- 10. Maturing Agile AdoptionGradually added: Automated builds Continuous integration Automated acceptance tests
- 11. 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!
- 12. 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!
- 13. 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).
- 14. 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
- 15. Pivotal vs. VersionOneBoth tools have limitations: VersionOne is too complex Pivotal is too simple Considering moving away from online tools entirely! What will we do then?
- 16. Enter Kanban... Howdid we find out about it? Searching for Agile resources online... Net Objectives Lean Software Development Taiichi Ohno Kanban!
- 17. Enter Kanban... Kanbanis 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
- 18. Value Stream MappingVisual 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
- 19. Cycle Time Howlong 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.
- 20. Queues Between stepsin 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.
- 21. WIP Limits Multi-taskingis 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
- 22. Measuring Progress Measurethe right things. Measure cycle time. Measure queues. Measure WIP. Measure value produced, if possible. Use the feedback you get to optimize the whole process .
- 23. Stop the LineEmpower 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.
- 24. Barriers to Kanbanat RadicalFusion Team was not co-located. Projects were silos. Iterations were a false "cadence". Not measuring the right the metrics.
- 25. Barriers to Kanbanat 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.
- 26. The Kanban BoardFirst attempt:
- 27. The Kanban BoardSecond attempt:
- 28. The Kanban BoardCurrent attempt:
- 29. Barriers to Kanbanat 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.
- 30. Thank You! Questions?[email_address] @sammcafee http://radicalfusion.net