8 techniques to reduce release times while maintaining quality

Building together.
Living together.
Improving together.

The human side of software development.

Applying development practices against every-day life, and applying life lessons to development

This is developer++

More often than not, software release cycles tend to stretch out longer than originally intended.

This happens for many reasons, but the 3 big ones are:

  1. Scope creep
  2. Insufficient development / testing resources
  3. Shift in priorities

One of my pet peeves is tested code that is not released.  It’s value is steadily decreasing because no one is using it.

It’s like leaving a block of jalepeno havarti on the counter.  Oh sure, it’s good for a while, but soon it starts getting rubbery and warm.  It still looks good, and tastes ok, but soon enough no one wants to touch it.  And it smells bad.

So how can we avoid long release cycles?

1. Limit the amount of work in progress

This sounds easier than it is, and many developers wildly over-estimate how much work they can get done in any given time period.  Using a system like Kanban can help manage the workload at each stage in the process to accomplish this.

As work piles up at any point in the development process, it forms a bottleneck that affects the delivery times for all items in the pipeline, both before and after the bottleneck.

When one part of the development process is consistently behind the others, there are 2 likely outcomes:

  1. quality begins to suffer in an attempt to keep up
  2. release cycles start growing while you wait for the work to be completed

2. Keep your features small

Scope creep seems to be a percentage of the total size of a task.

Therefore, an increase in scope of 10% always feels like 10% when you compare it to the total work of a feature, but in reality, it’s a whole extra day for a 2 week feature, and only 1.5 hours (assuming your work 7.5 hour days) of a 2 day project.

Our minds tend to play tricks on us with these percentages, and often the impact of scope creep is not even factored into the planning, so you end up delivering late.

3. Reject scope creep

Sounds pretty unrealistic I know, but stay with me.

If you are keeping your features small as discussed in the previous item, your scope creep will also be relatively small.  But don’t give in!

Consider pushing the items causing the scope creep into the next release.  Push the business users on this if they insist that they can’t wait, because often there are minor work-arounds that can be put in place until the next release is completed.

If they absolutely can’t wait, you still have options:

  1. Push the increased scope into the next release anyway.  (Be sure to structure your code so it can be put into production without being turned on.)   Tell the business that the new delivery date will be your next release date. This does a couple of things.  It will sober them up first of all and force them to consider work-arounds in the mean time.  And as a result of that, they may reconsider the value of the increased scope in the first place.
  2. Postpone the release.  This is least desirable because it can cause disruption in the cadence of your team.  It’s a great feeling to ship software to people that need it, and if you being to negotiate on your ability to do that, you find yourselves on a slippery slope of allowing outside factors to impact your value stream as developers.

4. Restrain yourselves

Many developers want to fix / rewrite / refactor / gold plate unaffected code while fixing a bug or building a feature.  It’s in our blood.  I know that this piece of code can be better, so that’s what I want to do.

Don’t fall into the trap of fixing code because it’s academically wrong.  If it doesn’t affect the feature / bug you’re working on, maybe just leave it alone.  Software is so complex and inter-connected, many times trying to do too much leads you down a rabbit hole of endless changes until you wonder why you’re implementing a new custom logging class as part of a ticket to change the colour of a button.

This is a rule of thumb, a guideline, because we also talked about Making the World Better, One Line at a Time.

5. Balance your resources

If you have dedicated resources for architecting, testing, development, QA, etc, make sure the resources are well-balanced to avoid human resource bottlenecks.  This is similar in effect to limiting the amount of work in progress, but when your resources are also unbalanced, you end up with people sitting around waiting for others.

An alternative is to have team members that are flexible enough to switch into other roles as the workload dictates.  This may happen many times over the course of a release cycle.

6. Stay the course

There are times when management can’t seem to make up their mind about what project is important today, and which one will be important tomorrow.

Switching focus mid-stream can have devastating effects on the effectiveness of a team.  It essentially takes the entire team out of the zone.  All the focus on a particular set of problems is put on hold, which really pushes progress backwards.

I like this explanation I found on Stack Exchange about being in the zone:

“How long does it take for you to fall asleep?”

“X minutes”

“Now imagine that when you are close to falling asleep, someone walks in and interrupts you, how long will it take you to fall asleep now? Those few seconds you had left, or will you have to start again to ‘sink back’ to where you were?”

“I’ll have to start again”

“Great. Same thing. Just like falling asleep, it takes me a while to ‘sink’ into focus mode, and it takes me a while to get back to it once I’m interrupted, except that I also forget half of what I was doing.”

By applying all the items above you gain 2 advantages when being pushed to switch priorities:

  1. Less work in progress means less ground to lose when you switch
  2. Less work in progress means you’re closer to finishing it up for a release, therefore, increasing your chances of management waiting until the release is done before changing priorities.

7. Automated testing

Automated tests provide assurances that you aren’t introducing regression bugs while developing new features.  As your codebase grows, so does the amount of things that can go wrong, and you cannot rely on manual testing to keep pace over the long term.

So write your tests.

8. Continuously evaluate your own performance

How short should my release cycle be?

This will be different for each team, but hours are better than days, days better than weeks, weeks better than months, and so on.

Aim for something consistent, and keep applying these principles to continuously tighten it up.

Continuous deployment doesn’t have to be the goal, and it’s often not practical, but keeping yourselves in a position very near to that is very beneficial.

Bonus – Automate your release

Take all the friction out of releasing as possible.  You don’t want the act of releasing code itself to be a deterrent, so make it easy.

In summary

You want the act of releasing software to be a seamless task that developers want to do, not a laborious task that is avoided.  Follow these guidelines to get closer to that goal.

  1. Limit the amount of work in progress
  2. Keep features small
  3. Reject scope creep
  4. Restrain yourselves
  5. Balance your resources
  6. Stay the course
  7. Automated testing
  8. Continuously evaluate your own performance

Bonus: Automate your release


Thanks for visiting!

If you enjoyed this article, please subscribe to my newsletter below and I'll make sure you are notified of any future articles

As a thank you for signing up, you will receive my free ebook - Iterative Development for the Human Condition. This book takes a look at how the same principles used in software development can be used to effect positive changes at a personal level.

[nm-mc-form fid="1"]

  1 comment for “8 techniques to reduce release times while maintaining quality

Leave a Reply

Your email address will not be published. Required fields are marked *