How do you avoid disrupting the flow of work when the Product Owner asks for a release?

Question

My team has been using Scrum for years with a goal to deliver a potentially releasable build each sprint. We recently started using a Kanban board moving away from time-boxed delivery to feature-boxed delivery. So far, this seems to better fit the teams natural way of working. With feature-boxed delivery, stories are pulled from the backlog when an individual feels they are comfortably ready to begin working on it.

The teams average story lead time is three weeks. So, theoretically, at the moment the product owner asks for a release, the team should be able to deliver it three weeks later.

When the PO sets the "stop development" trigger, individuals who have time are supposed to start helping with stories already underway to begin clearing out the board. The people freed up first are typically the "front-end" folks... Those more skilled at analysis and development. They are typically asked to help with back-end work, like system testing.

The teams work flow, or cadence changes each time the stop trigger is set. What do you do to minimize this change and keep the team working as efficiently as possible? How do you avoid the disruption caused by the Product Owner asking for a release?

Answer 1

The way you describe it preparing for a release is a significant interruption of your workflow which appears to work otherwise.

As we had a similar demand placed on our team we introduced the following solution. It has mainly to do with branch management in your version control system. The concept is known to me as "No Junk In The Trunk". It basically means that you have a branch that is 'clean' in that it contains only work that has successfully passed Quality Assurance (QA). Using Subversion this branch may be called 'trunk' hence the name. Of course this works with other version control systems as well, e.g. GIT.

When we start work on a new feature then we create a feature branch. This feature branch is updated with a merge from trunk at least once a day to keep the difference to a minimum. All testing, quality assurance, sign-off by various parties is entirely done on the feature branch. Once the feature is complete it is then merged back into 'trunk' followed by a quick integration testing focusing on where the new feature integrates with what is already there.

When we release we create release branches out of 'trunk'. Since 'trunk' is 'clean' we can pretty much release at any time. Since releases do not depend on wiping out all stories from the Kanban board we can prepare a release at any time without interrupting the regular development workflow.

This process works very well for us. Creating the release branch takes about 10 seconds as it is fully automated. The most significant item on the release branch is reviewing the release notes by a native English speaker. This is unfortunately a manual process and it takes about one or two hours depending on the amount of new features and bug fixes in the new release.

As always you may have factors in your environment that may make other solutions to the challenge a better option.