Sprinting for a Year

06 Aug 2017

History’s greatest sprinter Usain Bolt is retiring after 10 years. My Engineering team has been sprinting for a year – here’s what we’ve learned.

After 24 iterations we’ve gone from one big flatline in 2016 to multiple independent burndowns in 2017:

Aug 2016 Aug 2017
Start Today

It’s been quite a journey. Here’s the full year:

By the numbers

  Aug 2016 Aug 2017
Commitment 200 points 130 points
Velocity 10 points 130 points
Rollover 190 points 0 points
Engineers 5 13
Backlogs 1 big one across many teams 1 per team
Standups none 1 per team @ 10AM
Grooming ad hoc 1 per week + as needed
Review ad hoc timeboxed demos of working software
Retro 1 big one, mostly PMs talking 1 per team, mostly engineers talking

Successes

  1. True iterative development of both product and the sprint process itself really does work – but it is scary to “let it ride” and requires attention, and no matter how well it works some people will not get it. Work hard and deliver and let the results speak for themself.
  2. There was initial trepidation around teams scaling back their commitments to match their established velocity – there was momentum around drastic overcommitment even though it was widely acknowledged that it did not work.
  3. Engineering and PMs have mostly run with it, but it took activation energy from an internal champion plus directors, PMs, VPs and the CTO (and a little bit of timing and good luck) to kickstart it.
  4. Identifying and reducing/eliminating impediments each sprint has worked, but it’s taken time and patience.
  5. Redirecting ad hoc work requests from chat, email and verbally to written stories in JIRA has mostly worked, clarifying Engineering workloads and prioritization – but well-intentioned people will still do their best to cheat it by all available means.
  6. Splitting up boards per team works, but each needs 1 person to run it that is onboard with Scrum to make the most of it.
  7. Fast, automated unit testing on key projects is worth the investment non-trivial, dedicated resources.
  8. Engineers use JIRA somewhat grudgingly, but with some help and reminders it mostly works.
  9. Entirely remote Scrum can work.

Challenges

  1. Despite our progress, Scrum/Sprint hasn’t really taken root culturally. The clearest evidence of this is that when Engineering directors go on PTO the burndown flatlines. Most folks are at best ambivalent about the process and haven’t internalized it. I’m not sure whether it’s common for sprint to hinge on an internal champion or 2 but despite all this work what we have seems frustratingly fragile.
  2. Scrum/JIRA will not solve prioritization and planning problems. Iterative development and delivery by Engineering will not necessarily translate to product planning for MVP + iteration.
  3. Scrum will send very clear signals about what works and what doesn’t and where to focus your energy next if you are receptive to them, but not everyone will be. I’ve had very smart, open-minded Engineering personnel vehemently defend bad behavior out of habit or self interest.
  4. Some people are unwilling to take 30 seconds to write stories down. The best solution is to choose not to do work not represented in a story, but C-suite and VP-level will cheat and get away with it.
  5. JIRA’s output is a limiting factor – I would kill for better views, reports and visualizations.

References

  1. Scrum
  2. Lean Software Development
  3. Theory of Constraints
  4. Minimum Viable Product