Scrum(Kan)ban at Blue Yonder

Scrum(Kan)ban at Blue Yonder

Talk given at the meetup of the Limited WiP Society Karlsruhe, Germany. The talk is about Scrum, Kanban and the transitions between the two grounded in practical experience.

Ddc662a7e19a52cb87fec6cce98e987c?s=128

Manuel Bähr

May 10, 2016
Tweet

Transcript

  1. Dr. Manuel Bähr | @manuelbahr Head of Platform Scrum(Kan)ban at

    Blue Yonder
  2. Leading SaaS provider of predictive applications in retail. 2

  3. Decisions beat insights, any time. Prof. Dr. Michael Feindt -

    Founder of Blue Yonder
  4. Supply Chain Pricing Marketing Predictive Applications for Retail

  5. Our Customers

  6. Blue Yonder grew from 30 to 150 people in the

    period 2011-2015 Still not a large corporation and thank god no bureaucracy. Highly dynamic market situation (big data & analytics) I am talking about long-term product development Context 6
  7. Our Agile Journey 2014 Stopped doing fixed-time iterations as an

    experiment. 2008 Creative chaos. 2011 Established Scrum in one team. 2013 Somehow ended up with component teams. 2015 Re-org to group teams around products and not components. 2012 More teams using Scrum.
  8. Inspect the Transitions 8

  9. Chaos vs Scrum Introduction of Scrum felt hugely effective due

    to the alignment of individuals and focus on the customer
  10. Combined Scrum with strong engineering practices Continuous Integration, Clean Code,

    zero bug policy, code review, design review … Scrum offers no protection otherwise

  11. Scrum vs Kanban - Starting Point Experienced no (need for)

    long-term predictability in Scrum Frustration on failure to reach sprint goal vs pressure to cut on quality towards sprint end In-sprint reviews and releases to achieve continuous delivery Activities around sprint planning are not adding value
  12. Scrum vs Kanban - The Change Removed fixed iterations Story

    Review and estimation on demand One Kanban Board for Stories one for Tasks Keep everything else (Retro, Daily, Backlog …)
  13. All stages except „In Progress“ are just waiting queues. Limit

    these to reduce waste. Limit „In Progress“ to improve cycle time WiP Limits 13
  14. Developers don’t want to go back! Higher release frequency possible

    Limiting the backlog is hard, but valuable Sprint Planning time invested in story refinement Purpose of estimation reduced to reveal conflicting interpretations of a story Scrum vs Kanban - Results 14
  15. Evolved into a set of component teams (scrum, kanban) Typical

    problems emerged (Watch a Craig Larman talk!) But what is the alternative? Feature teams? Team members are either specialists or generalists. Why support only one type? Scaling - Starting Point 15
  16. Dev team size limited in Scrum Due to fundamental rules?

    In Kanban mode only the daily stand-up and retrospective require all team members Scaling - Team Size 16
  17. 23 people in 3 component teams switched to 2 product

    teams with Kanban mode + Scrum practices Single backlog for each product Refinement and story review on demand. Estimation in T-Shirt sizes Feature areas of the product established to group stories around topics and not components Scaling - The Change 17
  18. + Very small loss in throughput during the change -

    Cooperation between component devs not enforced (like in feature teams). Potentially delayed team formation? + Developers are generally happy after the change + Priorities don’t stop at artifact borders + Cross component work happens Decision making in large groups is hard. Be it several feature teams or a single large team. Scaling - Results 18