Beyond the two week iteration

On the nature of software delivery management

Continuous improvement over agile methodologies

The two-week iteration cycle is not good enough

25 releases

Few releases mean

  • Frustration
  • Stress
  • Gaming requirements
  • Release trifle
    • Many features, one release
    • QA headaches
  • Big consequences if a release slips
    • If one thing slips, everything slips
    • Value realisation depends on your weakest link

What is the magical quality of the fortnight?

Dual-value stream fallacy

Would you take two-weeks to fix a bug in production?

Can you help us?


Let's do it now

Continuous Delivery?


continuous delivery
simon hildrew

Release when you want to

Release when you have to

My experience at the Guardian

Project one: Java monolith

  • Core to the business
  • Manually deployed once a fortnight
  • Unloved and scary

We can't do it

  • We can't develop fast enough
  • We can't coordinate changes without time
  • Many releases are riskier than fewer
  • We can't deploy without disruption
  • Users don't like inconsistency
  • Partial features have no value
  • What if something goes wrong?

We can do it

  • We can build tools to control our deployments
  • We can change the way we work
  • We can separate releases and deployments
  • We can deliver value faster
  • Everyone can chill out

The Plan

  • Fortnightly
  • Weekly
  • Daily
  • AM/PM
  • As we need

The most important thing we've done this year

Project two: dating site

  • Three big milestones due
  • Early delivery == additional revenue
  • A background of an 18 month delivery

We can't do

  • Users need consistency
  • Analytics needs consistency
  • No-one knows how to do it
  • The business doesn't get it

We can do it

  • Feature switches
  • Audience segmentation
  • Component-based transition
  • Page-based transition

We did it

But it was inefficient

I didn't believe we could do it

But this team is great

My inexorable rise to greatness

We can't do it

  • We can't release on Friday
  • [Do not merge] pull requests
  • We can't support our changes

Top change tips

Organisations don't change unless they are in crisis

People fear loss (or blame) more than they value reward

Getting people to change

  • Articulate a vision
  • Rewards need to be shared
  • Benefits need to be realised
  • Momentum must be preserved

Attitudes may change...

but automation is forever

Reconsider the release

  • Deployment
  • Release
  • Value
  • Feature
  • Pull request
  • Change

In conclusion

Two-week iterations are not good enough

Release when you want to

Release when you have to

Going beyond the two-week iteration means understanding your business

Only you can do this

You can do it

Please don't be afraid

Thank you

  • Twitter/Github: rrees
  • Blog: