Could this idea, proven to be very successful for sport teams, be applicable to our software engineering team?

1. Improving performance
through the
aggregation of marginal gains
13th August 2015

2. Agenda
• What does `the aggregation of marginal gains` mean?
• Could this improve the performance of our software engineering
team?

3. Sir Dave Brailsford
Ex-Performance Director, British Cycling
General Manager, Team Sky
By utilising marginal gains, these teams
saw considerable success..

4. British Cycling
Olympic Medal Haul 2000 - 2012

5. Team Sky
Tour de France British Winners
2012 2013 2015

6. –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”

7. Sleep posture is important for an athlete
The team replaced the
mattresses + pillows in
every hotel room the
riders stayed in

9. We are not a professional cycling team.

10. We are a team. We have goals.

11. requirements
code
test cases
Product Owner
User

12. 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)

13. What could our marginal gains look like?

14. requirements
code
test cases
Product Owner
User

15. What goes into the ‘code’ work
product?

16. We review code

17. Not all diffs are created equal

18. Work to a maximum number of characters per line:
Ideally <80
Definitely <132
It’s much easier to interpret diffs during a code review

19. We debug code

20. Commit messages vary in their usefulness

21. Elliot Carver, Bond Villain
“The key to a great story is not who, or what, or when, but why.”
commit message

22. We run acceptance-level
automation

23. 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

24. Developers should only need to run:
- @smoketest
- relevant scenarios

25. requirements
code
test cases
Product Owner
User

26. What goes into our other work
products?

27. We define things

28. We define terminology to help us implement a feature
That same terminology will be used by the next person who works on
that feature

29. 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

30. We deal with surprises

31. Surprises normally slow us down
It’s better to move from up-next > blocked, rather than ready-for-test
> blocked

32. 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?

33. Can this improve the
performance of our team?

34. 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

35. –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

36. ?