Paul Hammant's Blog: Developers Activities Shouldn't Change With Proximity To Release Dates

So my gut tells me that developer’s activities shouldn’t change with proximity to a release date.

I was not sure if it was an Agile thing, or Continuous Delivery, or DevOps. That’s because I’ve done all three for a decade or more now. I thought I’d ask Twitter:

It seems the consensus is developers changing daily activities with proximity to a release is the antithesis of CD.

OK, so taking a previous blog entry, Trunk Supporting Practices a little further, there is now one more thing that changes with release cadence:

(and I thought I’d add in ‘methodology’ too, seeing as I had not before)

What Activities? What ‘change’ with proximity to release?

Say the developers are used to chomping through story-cards a few days after the last release has gone out, and say it is four weeks between planned releases. How long does the enthusiasm for new features last? Is it a week or two before the tension mounts as people start to worry about the next release? Does the number of hours worked a day increase steadily towards the release date? Do more and more developers leave regular feature development and focus frantically on break/fix stabilization of the pending release?

Teams that are doing the ‘branch for release’ variant of Trunk-Based Development sometimes witness a last minute rush of cherry-pick merges into the release branch after it is cut. This is most often because the business can’t wait until the next release, which is a clue that release cadence is not high enough.

Teams doing legacy branching models have an additional activity that lowers the feature delivery rate for periods of time: merging. In the worst branching models, it is going to be a huge merge after the release, with plenty of room for mistakes that includes a chance of regression defects.