Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Appli rewrite & Big Bang Release

Last post 03:45 pm May 17, 2014 by Ian Mitchell
5 replies
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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.