3. Before - QA engineer, business analyst, project manager @ bank (5 years)Agile experience – 1 year
4.
5. Development Operations Head of new products DEVELOPMENT New products, features Enhancements, Bugfixes, New functionality DB PMs Projects CTO Technical architecture RM Technical enhancements, architecture, environments
6. Presentation purpose Share experience: What was good and was not with SCRUM? Why did we switch to Kanban? What did we achieve and what are we missing?
7. WhySCRUMwasgood?(for us) Simple: split organization into teams, split work into prioritized list of small deliverables, split time into short fixed-length iterations, optimize the process by having a retrospective after each iteration; Clear: 3 roles prescribed, SCRUM master leads the process, process is visualized on the board, stand-up meetings; Light: no heavy documentation, no prescribed engineering practices.
8. What wasnot good in SCRUM (for us) Fixed scope of the sprint – cannot take high priority items as soon as they appear; Team growth and resource conflicts – how to split the team? How to share resources?; Several big projects planned – how to split? Why to split? Prioritized backlog – prioritization effort will only affect the next sprint.
9.
10. Can add new items whenever capacity is available;
15. WIPs are under control – depending on the item size and priority;
16.
17. Conclusions Both, SCRUM and Kanban are good, because they leave a lot of space for experiments: Size and number of teams; WIP limits; Length of 1 iteration; The less constraints you have, the more you can experiment, the more you can fail, the more you can win! Do not limit yourself to one tool; Non of the tools is perfect or complete, except “Do the right thing”