Scrum bangalore 12 march 7 2015 - avinash rao - accelerating scaled agile using scrum ban - at prowareness
0 likes1,421 views
The document discusses an experiment comparing Scrum and Scrum-Ban methodologies in offshore Agile teams, highlighting the challenges and effectiveness of each approach. It outlines the setup, results, and insights gained from the trial, noting that Scrum-Ban teams completed tasks in less time with better team dynamics. Feedback indicated that Scrum teams felt more constrained by hierarchy, whereas Scrum-Ban allowed for improved collaboration and productivity.
Scrum bangalore 12 march 7 2015 - avinash rao - accelerating scaled agile using scrum ban - at prowareness
- 1. Accelerating Scaled Agile Using Scrum-Ban Avinash Rao Scrum Bangalore – March 2015
- 2. Our Agenda The joys of Agile Offshore The problem statement Defining ‘our’ Scrum and Scrum-Ban Outcomes from both streams, & work profile Post-Script
- 3. Full disclosure I have strong opinions about how we structure Agile teams offshore Mini-waterfall-ing Too many iterations are filled with big-rocks Background on Lean, and I look for data everywhere … “How happy are you with your wife?” 3
- 4. Too many Offshore Scrum teams have this effort profile under pressure Given offshore Pyramids and resource mix Given ‘constant improvement’ Productivity targets 4 Iteration Timeline All-nighters to deliver Committed scope We need to slog at the end, Why start now? Analysis, LLD
- 5. Problem Statement Effective in an imperfect world where clients demand effectiveness but pay for efficiency Increase Throughput while preserving the team’s long term effectiveness (time spent, pressure) 5
- 6. The Experiment – Set Up 6
- 7. Scrum team set up Sized backlog items 2 week iteration, with LLD, development, integration, DoD readiness Team loaded with as much scope as we would have done in 2 weeks in waterfall, but with testing and readiness included 29 FPs for 2 weeks (16 hours / FP – planned productivity) 7
- 8. Scrum-Ban team setup Pick task from backlog, complete (complete!), move to next item Initial scope of 25 FPs identified (1/person) Don’t define complete scope to be delivered a- priori Planning, Standups, other ceremonies remain the same, one additional update of the Scrum- Ban board in the PM 8
- 9. Tooling Used a e-PostIt tool For Scrum, the posts have a due date Scrum-Ban chits move at actuals, and when complete, developer picks up the next task 9
- 10. The Experiment – Results 1
- 11. Baseline Waterfall Estimates are based on (past) WF projects We picked 2 weeks worth of work equivalent for each iteration 1
- 14. Comparison Scrum-Ban completed 25 FPs in 7 days v/s 29 FPs for 10 days 13.4 Hours per FP v/s 16 hours per FP (+16%) Scrum-Ban team then picked up additional work items (10 FPs) and completed in 2 weeks Some items were partially done, which credits the next iteration when complete 1
- 15. Additional insight into the effort - Scrum 1 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% core Incidental NVA Lost benefit of Early completes!
- 16. Additional insight into the effort – Scrum-Ban 1 0% 10% 20% 30% 40% 50% 60% core Incidental NVA
- 17. Scrum-Ban - Effect of structure on Team Dynamics Because the team did not size, there was less discussion cross-group on items - developers were focused on the task to be picked up Better levelling in the team (everyone’s a developer no matter their job designation) Exposed weak people ruthlessly (twice a day reviews to update the Board) 1
- 18. Picture Abhi Baaki Hai Mere Dost … 1
- 19. Pair Programming under duress A third team lost access to remote dev servers (credentials) Introduced to Pair-Programming – Virtue out of a Necessity 25 FP scope defined for the team Looser oversight, but Scrum-Ban board and Stand-Ups used Team wanted to meet EOD Day 3 … 1
- 20. Pair-Programming 25 FPs completed in 3 days (5.7 Hours / FP) Over 13 days (yes, the team decided to change some of the rules), team delivered 76 FPs production-ready (8.2 Hours / FP) Visible camaraderie, high-performing unit that we have retained 2
- 21. Caveats We have not continued Pair-programming By week 2, team complained of overheads Meetings Status reports Company overheads – too many email, etc We found the Pair-programming Scrum-Ban approach perfect for Tiger teams 2
- 22. Team Feedback – some observations Note: Reliably recorded by someone closer to the team’s median age Scrum teams reported being a closer unit than Scrum-Ban teams Hierarchy got in the way to Scrum teams more than scrum-Ban teams Pair-programming is fun! But please don’t send me so many meeting requests and emails … Module Leads set up their own Boards for future iterations! 2
- 23. Questions? 2