We are facing a new challenge and I was wondering if someone else experienced a similar situation and how they managed it.
Briefly:
-Current situation (aka Configuration 1): for a big mass retailer we manage 5 Software Platforms which are constantly under continual improvement. For each quarter, we pick the change requests from a backlog and put in a Gantt. A sort of hybrid approach where the quarter is like a sprint and CRs are story items. The development is managed in the waterfall.
-Future situation (aka Configuration 2): from 2022, our Client will change the ERP and took the opportunity to re-engineer all the Software Platforms from scratch using the last release of the software. It will take 1 year for the Pilot and 2-3 years for the remaining systems. While doing this, Configuration 1 will continue to accept and develop small (1-3 MDs), medium (10-20 MDs), and large (20 MDs) changes.
-The goal: At cut-over (Q4 2022?) Configuration 1 will be dismissed and Configuration 2 will go live. At Go-live, Configuration 2 shall have all the CRs developed in Configuration 1 until its last day of life.
-The challenge: During the Configuration 2 development, keep it aligned with CRs incoming in Configuration 1 without loss of efficiency and without causing lag times.
From a “software development” point of view, we are speaking of developing a major release of software from scratch while the previous release continues to publish new functionalities, keeping both versions aligned.
Did you experience something similar? Do you know a “standard” approach or want to kindly share your ideas?
Thank you so much for your time.
Best Regards Saving Changes...
Given that the Configuration 2 code will be completely different than that for Configuration 1, traditional code merge techniques won't work.
As such, the only option will be to ensure that someone from the Configuration 2 team is plugged into the Configuration 1 change control process so that they are notified of new CRs in a timely manner so that they can review them, analyze their applicability and impact to Configuration 2 and then pass those to the Configuration 2 team to apply.
Kiron
...
1 reply by Endless Martinenghi
Oct 18, 2021 8:26 AM
Endless Martinenghi
...
Thank you Kiron for your reply. I was thinking about something similar, scheduling some periodic retrospective meeting to align Configuration 2 Team (C2T) with the changes made by Configuration 1 Team (C1T). Development approaches on both sides may be waterfall, while the sync between them may be like agile/hybrid. I really like your idea to plug a C2T member in C1T group to act as a bridge!
Given that the Configuration 2 code will be completely different than that for Configuration 1, traditional code merge techniques won't work.
As such, the only option will be to ensure that someone from the Configuration 2 team is plugged into the Configuration 1 change control process so that they are notified of new CRs in a timely manner so that they can review them, analyze their applicability and impact to Configuration 2 and then pass those to the Configuration 2 team to apply.
Kiron
Thank you Kiron for your reply. I was thinking about something similar, scheduling some periodic retrospective meeting to align Configuration 2 Team (C2T) with the changes made by Configuration 1 Team (C1T). Development approaches on both sides may be waterfall, while the sync between them may be like agile/hybrid. I really like your idea to plug a C2T member in C1T group to act as a bridge! Saving Changes...
Thanks Endless. There's even a term for such a role - a "boundary spanner"! The key is to pick the "right" person who has enough knowledge of the overall Configuration 2 scope & solution approach to know whether a given Configuration 1 CR is actually applicable to Configuration 2 or not.
I deal with this configuration management issue regularly and the synchronization should occur when the change request is processed.
Changes to config 1 may not actually even impact configuration 2, such as when the architecture of the new system completely eliminates the reason for the requested change on the old system. As part of the change management process, the approval process needs to ask whether the config 1 change is necessary for config 2 also, in which case you either have a separate CR, or the CR covers both configs. That will depend on your business systems and processes.
Regardless of what development model you use, the incorporation should be planned up front. Otherwise you are likely to encounter many unwelcome surprises along the way. It may have a significant influence on how you pick CRs from your backlog. Some may be wasteful to incorporate on the old SW rather than just waiting for the new SW.
...
1 reply by Endless Martinenghi
Oct 19, 2021 3:27 AM
Endless Martinenghi
...
Thank you Keith for your help! I agree with you, CRs selection must consider the impact on both scenarios and this evaluation must be done upfront.
Moreover, we were thinking about how and when apply selected CRs: if some changes requested for Conf 1 are related to a module that will be developed in the future on Conf 2, is not a big deal: the FDS of the module will be updated (with estimates and timing) and the new functionalities will bee included within the main development.
On the other side, if those CRs impact a module already developed, which is the best way to proceed? A new change management flow must be applied only for Conf 2, or maybe will be more efficient to collect all those CRs in a new product backlog to be addressed after go-live?
Anyway, thank you so much for sharing your experience!
I deal with this configuration management issue regularly and the synchronization should occur when the change request is processed.
Changes to config 1 may not actually even impact configuration 2, such as when the architecture of the new system completely eliminates the reason for the requested change on the old system. As part of the change management process, the approval process needs to ask whether the config 1 change is necessary for config 2 also, in which case you either have a separate CR, or the CR covers both configs. That will depend on your business systems and processes.
Regardless of what development model you use, the incorporation should be planned up front. Otherwise you are likely to encounter many unwelcome surprises along the way. It may have a significant influence on how you pick CRs from your backlog. Some may be wasteful to incorporate on the old SW rather than just waiting for the new SW.
Thank you Keith for your help! I agree with you, CRs selection must consider the impact on both scenarios and this evaluation must be done upfront.
Moreover, we were thinking about how and when apply selected CRs: if some changes requested for Conf 1 are related to a module that will be developed in the future on Conf 2, is not a big deal: the FDS of the module will be updated (with estimates and timing) and the new functionalities will bee included within the main development.
On the other side, if those CRs impact a module already developed, which is the best way to proceed? A new change management flow must be applied only for Conf 2, or maybe will be more efficient to collect all those CRs in a new product backlog to be addressed after go-live?
Anyway, thank you so much for sharing your experience! Saving Changes...
As there isn't the challenge of applying changes from C2 back to C1 which would be the case if this was a classic parallel development project for the same product, it is a one-way flow.
I'd suggest that whoever is the gatekeeper for C2 changes would review each and then classify them based on how soon they'd need to be applied - some might need to be adapted and applied ASAP whereas others could be batched into the next planned change release for C2.
