How to handle elaborate product releases?
Hello!
We have problems with our release management in relation to scrum. We have good internal testing and release tools setup, but our customers have complex processes required to sign-off on each new version.
This results in considerable overhead which we cannot get rid of, and which takes a large amount of developer time on each public release.
Would you put the public release onto the Product Backlog? In general: how would you organize release and shipping of the finished product as part of the scrum process?
Cheers, Raphael
In Scrum, each increment must be of potentially releasable quality. In other words there should be no further work needed for a release to occur. "Processes required to sign-off on each new version" would count as work that is involved in building the increment. Development work isn't necessarily just coding and testing.
The qualities required for a release to be effected do not belong in the Product Backlog, but rather in the Definition of Done. It might therefore be reasonable to stipulate those "complex processes required to sign-off on each new version" within the DoD. However this stipulation should also be challenged, on the grounds that release should be a decision that the Product Owner makes. Complex sign-off processes which get in the way of that timely and value-based PO decision are, in effect, waste. It might be possible to expose this on a Scrum Board by planning tasks for sign-off in the Sprint Backlog and revealing the delays or impediments that subsequently occur.
To ian's point - a value stream mapping will help quantifying the waste here. other than visually showing the anchoring of some items under swimlines (qualitative and implied) i fail to see how scrum board will help show waste.
> ...i fail to see how scrum board will help show waste.
Delays and impediments - such as those that may result from complex sign-off processes - are a form of waste. A Scrum board should make wastage transparent. For example, tasks may build up in a particular state or station, or otherwise fail to progress; or blockages may be highlighted where an impediment or dependency can be qualified. VSM's are indeed another technique. Scrum does not prescribe which if any to use, but a board of some kind is common...and to be of value it must tell the truth.
Hi Ian,
thank you for your reply. I have a question regarding your answer. You write
> In Scrum, each increment must be of potentially releasable quality. In other words there should be no further work needed for a release to occur.
Now we have two types of release: internal release which is painless and release to the clients which has a lot of overhead regarding documentation, etc. Would you consider "potentially releaseable quality" to include preparing all the neccessary release documentation for the clients during each sprint?
Yes. The operative word in your question is "necessary". If something must be provided for the increment to be releasable, then its production must be considered part of the development effort. This includes all "necessary" documentation. An increment may require more than just a code deployment in order to be usable and releasable.