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.

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