Accelerating Scaled Agile Using Scrum-Ban

Avinash Rao

Scrum Bangalore – March 2015

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

The Experiment – Set Up

6

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

The Experiment – Results

10

Baseline Waterfall

Estimates are based on (past) WF projects

We picked 2 weeks worth of work equivalent for each iteration

11

Outcome from Scrum

12

Outcome from Scrum-Ban

13

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!

Additional insight into the effort – Scrum-Ban

16

0%

10%

20%

30%

40%

50%

60%

core

Incidental

NVA

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

Picture Abhi Baaki Hai Mere Dost …

18

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

Questions?

23