Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Improving performance
through the
aggregation of marginal gains
13th August 2015
Agenda
• What does `the aggregation of marginal gains` mean?
• Could this improve the performance of our software engineer...
Sir Dave Brailsford
Ex-Performance Director, British Cycling
General Manager, Team Sky
By utilising marginal gains, these ...
British Cycling
Olympic Medal Haul 2000 - 2012
Team Sky
Tour 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 goe...
Sleep posture is important for an athlete
The team replaced the
mattresses + pillows in
every hotel room the
riders stayed...
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 sho...
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 ...
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 c...
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
th...
Treat terminology as a deliverable
Instantly resolve ambiguity you find:
>1 term to describe the same thing
>1 thing can b...
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...
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 :)
Ho...
–Sir Dave Brailsford
“We're in the right mindset, we're looking for little things,
collectively, all the time that's going...
?
The Aggregation of Marginal Gains in Software Engineering
Upcoming SlideShare
Loading in …5
×

of

The Aggregation of Marginal Gains in Software Engineering Slide 1 The Aggregation of Marginal Gains in Software Engineering Slide 2 The Aggregation of Marginal Gains in Software Engineering Slide 3 The Aggregation of Marginal Gains in Software Engineering Slide 4 The Aggregation of Marginal Gains in Software Engineering Slide 5 The Aggregation of Marginal Gains in Software Engineering Slide 6 The Aggregation of Marginal Gains in Software Engineering Slide 7 The Aggregation of Marginal Gains in Software Engineering Slide 8 The Aggregation of Marginal Gains in Software Engineering Slide 9 The Aggregation of Marginal Gains in Software Engineering Slide 10 The Aggregation of Marginal Gains in Software Engineering Slide 11 The Aggregation of Marginal Gains in Software Engineering Slide 12 The Aggregation of Marginal Gains in Software Engineering Slide 13 The Aggregation of Marginal Gains in Software Engineering Slide 14 The Aggregation of Marginal Gains in Software Engineering Slide 15 The Aggregation of Marginal Gains in Software Engineering Slide 16 The Aggregation of Marginal Gains in Software Engineering Slide 17 The Aggregation of Marginal Gains in Software Engineering Slide 18 The Aggregation of Marginal Gains in Software Engineering Slide 19 The Aggregation of Marginal Gains in Software Engineering Slide 20 The Aggregation of Marginal Gains in Software Engineering Slide 21 The Aggregation of Marginal Gains in Software Engineering Slide 22 The Aggregation of Marginal Gains in Software Engineering Slide 23 The Aggregation of Marginal Gains in Software Engineering Slide 24 The Aggregation of Marginal Gains in Software Engineering Slide 25 The Aggregation of Marginal Gains in Software Engineering Slide 26 The Aggregation of Marginal Gains in Software Engineering Slide 27 The Aggregation of Marginal Gains in Software Engineering Slide 28 The Aggregation of Marginal Gains in Software Engineering Slide 29 The Aggregation of Marginal Gains in Software Engineering Slide 30 The Aggregation of Marginal Gains in Software Engineering Slide 31 The Aggregation of Marginal Gains in Software Engineering Slide 32 The Aggregation of Marginal Gains in Software Engineering Slide 33 The Aggregation of Marginal Gains in Software Engineering Slide 34 The Aggregation of Marginal Gains in Software Engineering Slide 35 The Aggregation of Marginal Gains in Software Engineering Slide 36
Upcoming SlideShare
Dave Brailsford Model of Marginal Gains
Next
Download to read offline and view in fullscreen.

2 Likes

Share

Download to read offline

The Aggregation of Marginal Gains in Software Engineering

Download to read offline

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

The Aggregation of Marginal Gains in Software Engineering

  1. 1. Improving performance through the aggregation of marginal gains 13th August 2015
  2. 2. Agenda • What does `the aggregation of marginal gains` mean? • Could this improve the performance of our software engineering team?
  3. 3. Sir Dave Brailsford Ex-Performance Director, British Cycling General Manager, Team Sky By utilising marginal gains, these teams saw considerable success..
  4. 4. British Cycling Olympic Medal Haul 2000 - 2012
  5. 5. Team Sky Tour de France British Winners 2012 2013 2015
  6. 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. 7. Sleep posture is important for an athlete The team replaced the mattresses + pillows in every hotel room the riders stayed in
  8. 8. We are not a professional cycling team.
  9. 9. We are a team. We have goals.
  10. 10. requirements code test cases Product Owner User
  11. 11. 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)
  12. 12. What could our marginal gains look like?
  13. 13. requirements code test cases Product Owner User
  14. 14. What goes into the ‘code’ work product?
  15. 15. We review code
  16. 16. Not all diffs are created equal
  17. 17. Work to a maximum number of characters per line: Ideally <80 Definitely <132 It’s much easier to interpret diffs during a code review
  18. 18. We debug code
  19. 19. Commit messages vary in their usefulness
  20. 20. Elliot Carver, Bond Villain “The key to a great story is not who, or what, or when, but why.” commit message
  21. 21. We run acceptance-level automation
  22. 22. 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
  23. 23. Developers should only need to run: - @smoketest - relevant scenarios
  24. 24. requirements code test cases Product Owner User
  25. 25. What goes into our other work products?
  26. 26. We define things
  27. 27. We define terminology to help us implement a feature That same terminology will be used by the next person who works on that feature
  28. 28. 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
  29. 29. We deal with surprises
  30. 30. Surprises normally slow us down It’s better to move from up-next > blocked, rather than ready-for-test > blocked
  31. 31. 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?
  32. 32. Can this improve the performance of our team?
  33. 33. 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
  34. 34. –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
  35. 35. ?
  • MaartenVanOudenhove

    Oct. 18, 2015
  • markmccann32

    Oct. 11, 2015

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

Views

Total views

2,248

On Slideshare

0

From embeds

0

Number of embeds

20

Actions

Downloads

55

Shares

0

Comments

0

Likes

2

×