Kanban at radical_fusion
Download as PPT, PDF4 likes1,437 views
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.
![Thank You! Questions? [email_address] @sammcafee http://radicalfusion.net](https://image.slidesharecdn.com/kanbanatradicalfusion-110310075821-phpapp02/85/Kanban-at-radical_fusion-30-320.jpg)
Kanban at radical_fusion
- 1. Kanban at RadicalFusion Sam McAfee, Co-Founder
- 2. About Me Moved to Bay Area in 1997. Freelanced as web developer starting in late 1999. Co-founded RF in 2002.
- 3. About Me Started as the only developer. Gradually morphed into... Lead Developer Project Manager Sales / Business Development Now, slowly moving back to coding again.
- 4. About RadicalFusion Founded in SF 2002. Moved to Oakland in 2008. Virtual, first 8 years. Opened office space in 2010.
- 5. About RadicalFusion Web development agency serving: Non-profits / Unions (because we care) Start-ups (because it's fun) Established companies (because we must)
- 6. About RadicalFusion Small team: 2 co-founders 5 engineers 1 business analyst 1 project manager outsource VD and UX (but hiring...)
- 7. 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!)
- 8. 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.
- 9. Early Agile Adoption Local, but virtual team though, so... No pair-programming, obviously No daily stand-ups No retrospectives (not "officially", anyway)
- 10. Maturing Agile Adoption Gradually 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. 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?
- 16. Enter Kanban... How did we find out about it? Searching for Agile resources online... Net Objectives Lean Software Development Taiichi Ohno Kanban!
- 17. 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
- 18. 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
- 19. 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.
- 20. 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.
- 21. 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
- 22. 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 .
- 23. 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.
- 24. Barriers to Kanban at RadicalFusion Team was not co-located. Projects were silos. Iterations were a false "cadence". Not measuring the right the metrics.
- 25. 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.
- 26. The Kanban Board First attempt:
- 27. The Kanban Board Second attempt:
- 28. The Kanban Board Current attempt:
- 29. 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.
- 30. Thank You! Questions? [email_address] @sammcafee http://radicalfusion.net