scrum bangalore 12 march 7 2015 - avinash rao - accelerating scaled agile using scrum ban - at...
TRANSCRIPT
Our Agenda
The joys of Agile Offshore
The problem statement
Defining ‘our’ Scrum and Scrum-Ban
Outcomes from both streams, & work profile
Post-Script
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
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
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
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
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
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
Baseline Waterfall
Estimates are based on (past) WF projects
We picked 2 weeks worth of work equivalent for each iteration
11
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
14
Additional insight into the effort - Scrum
15
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
core
Incidental
NVA
Lost benefit of Early completes!
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)
17
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 …
19
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
20
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
21
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!
22