Skip to main content
Back
X
Back

Scrum Forum

Appli rewrite & Big Bang Release

Last post 03:45 pm May 17, 2014
by Ian Mitchell
5 replies
Author
Messages
03:16 am May 16, 2014

Hi,

In my company (large bank), we have some new projects which are good candidates for incremental release, but we also have some rewrite of old legacy junk.

In case of rewrite, what kind of pattern do you use to avoid Big Bang release after several quarters of work.

Yours
Olivier

05:18 am May 16, 2014

Is the rewrite to be done from scratch, or is it a technical uplift of the existing legacy system? Also is there a legacy DB, the content or schema of which must be preserved?

07:49 am May 16, 2014

Well, all the options are there, but I think mainly about rewrite from scratch and with a new DB (we will use some ETL to convert the datas)

08:25 am May 16, 2014

Is it possible to rewrite components from scratch, and release them on a sprint by sprint basis? You'd need to discuss this with the PO to find out the business value of doing so, as well as finding out if it is architecturally possible. Standard GOF patterns such as bridge and adapter may be of use.

06:23 am May 17, 2014

Is it possible to rewrite components from scratch, and release them on a sprint by sprint basis?

Well, it is actually my question ;-)
Sorry for not being clear enough. When I asked for patterns, I didn't have design-pattern in mind but instead organization -pattern or project-pattern.

The business value will be hard to define, but in term of risk-reduction and knowledge acquisition, the sprint by sprint releases are very useful.
I wonder how when can avoid big-bang production release. For instance, we can release in pre-production sprint by sprint, but is there a better solution ?

03:45 pm May 17, 2014

The distinction between production and pre-production environments doesn't have to be black-and-white. It may be possible to target early adopters for certain increments, or a similarly narrowed audience.

This is a Lean Startup technique which allows delivery risk to be sandboxed, while still permitting a degree of feedback and some measure of control over the accumulation of technical debt.