Improving performancethrough the

aggregation of marginal gains13th August 2015

Agenda

• What does `the aggregation of marginal gains` mean?• Could this improve the performance of our software

engineering team?

Sir Dave BrailsfordEx-Performance Director, British Cycling

General Manager, Team Sky

By utilising marginal gains, these teams saw considerable success..

British CyclingOlympic Medal Haul 2000 - 2012

Team SkyTour de France British Winners

2012 2013 2015

–Sir Dave Brailsford

“The whole principle came from the idea that if you broke down everything you could think of that goes into riding a bike, and then improved it by 1%, you will get a significant

increase when you put them all together”

Sleep posture is important for an athlete

The team replaced the mattresses + pillows in every hotel room theriders stayed in

We are not a professional cycling team.

We are a team. We have goals.

requirements

code

test cases

Product Owner

User

Release early, release often…We want the lightbulb (the Product Owner’s feature) to get round our

‘race track’ in the shortest possible time, but not at any cost. We want to:

1. Get a functioning lightbulb round the track (scope)2. In the shortest time possible (velocity)3. Without sacrificing the time for subsequent lightbulbs to get round

the track (quality)

What could our marginal gains look like?

requirements

code

test cases

Product Owner

User

What goes into the ‘code’ work product?

We review code

Not all diffs are created equal

Work to a maximum number of characters per line:

Ideally <80

Definitely <132

It’s much easier to interpret diffs during a code review

We debug code

Commit messages vary in their usefulness

Elliot Carver, Bond Villain

“The key to a great story is not who, or what, or when, but why.”

commit message

We run acceptance-level automation

We currently run entire cake + salvos before merge:

- this is dead time for a developer

- doesn’t expose poorly designed code to other members of the team

Developers should only need to run:

- @smoketest

- relevant scenarios

requirements

code

test cases

Product Owner

User

What goes into our other work products?

We define things

We define terminology to help us implement a feature

That same terminology will be used by the next person who works on that feature

Treat terminology as a deliverable

Instantly resolve ambiguity you find:

>1 term to describe the same thing

>1 thing can be described with the same term

We deal with surprises

Surprises normally slow us down

It’s better to move from up-next > blocked, rather than ready-for-test > blocked

Developer/Tester chat before up-next -> in-progress

is there any unclear terminology here?

is this a candidate for a smoke test?

does this rely on any 3rd party code?

is there any device-specific behaviour?

is there anything here that could be difficult to automate?

Can this improve the performance of our team?

Your actions provide gains to other members of the team :)

You’ll experience gains because of someone else’s actions :)

However, to really understand performance we need measurements

–Sir Dave Brailsford

“We're in the right mindset, we're looking for little things, collectively, all the time that's going to make us improve.”

collectively

?