5

Is it worth working in 2-week sprints, and in a Scrum fashion for that matter, for a client migration project from a legacy system, to a system which is already live and with other clients (a white label software)?

It seems to me to be somewhat futile to try to fit tasks into 2-week sprints, since whether they’re delivered or not, no one is going to complain (since the client is already live on a legacy software). The only effect will be to move the migration date (that has been set by a project manager) to an earlier or later date, which is reviewed every 2 weeks.

I think a Kanban style is more appropriate, as the workload is known (no surprises or areas to explore) and it’s going to take however long it’s going to take to deliver the software. There’s no added functionality as it would be with incremental releases in Scrum, because the client is still on the legacy system. Can anyone provide any reasons for or against using Scrum for clients' migration from legacy products to new live products?

Improve this question
2
  • Upvoted. Very interesting question.
    – Piotr Uryga
    Mar 28, 2017 at 20:14
  • In a world of constant systems migration, I am surprised this topic has not been discussed enough!
    – dqm
    Apr 4, 2017 at 13:33

2 Answers 2

Reset to default
4

Being an Agile evangelist, I can't believe I'm about to type this, but I'm wondering if Agile itself is really needed for you. In my view, the main purpose of Agile is to deal with changing requirements. If you know ahead of time that all your requirements are static, then there's... not much point.

For Scrum, certainly, this might be overkill. How would the Product Owner create/prioritize stories? How would you plan stories? How are you going to get a shippable product at the end of each Sprint? How would you demo stories, every Sprint? To whom would you demo them? Unless you can answer all of those questions, consider the possibility that Scrum is unnecessary overhead.

Of course, you might still want to go with Kanban, rather than forsaking Agile entirely. Its Work In Progress limits would still provide benefit, even in lieu of changing requirements. Likewise, if your team is used to Agile, may as well just stick with it; Kanban is pretty light, with very little overhead.

Improve this answer
3
  • Thanks for your comments, they are very valid. So to answer to your questions: the PO gets a hand-over from the BAs who have signed off the business requirements with the client to be migrated i.e. which elements of the software he wants. Then they hand over to the PO who creates epics and stories and sets the backlog. We don't have shippable product at the end of the sprint, we merely have an addition, but the whole thing is not live. We still demo stories to the steakholders, i.e. BA and our internal department who ultimately uses the product.
    – dqm
    Mar 27, 2017 at 15:08
  • Also, prioritization is on the basis of "what functionality do we need to enable in order for the next functionality to work?". For example, you have to enable the API connectivity to then invoke the service. Both exist, they just need to be configured for each client.
    – dqm
    Mar 27, 2017 at 15:10
  • The purpose of Agile is to deal with changing circumstances - not just changing requirements. What if developers are unwell? What if a particular story or task ends up more complicated than origin thought? And even with a migration like this, some assumptions and even requirements will inevitably change at some point.
    – HorusKol
    Mar 31, 2017 at 13:33
1

There is certainly value in using the Scrum approach.

The Product Owner would prioritise the backlog based on which features of the system are most valuable.

Delivery would be frequent and of a working system (although not with all the features completed until the end).

The value that you get from this is:

  • Transparency of progress. As the team delivers working features the client gains confidence.
  • The ability to give the client a schedule that is updated to match real world achieved progress.
  • The ability to do continuous testing in a production environment (including user acceptance testing to ensure the new system matches the legacy system). Helping to de-risk the delivery by avoiding leaving testing to the end of the project.
  • All the other benefits of Scrum: the self-organising team, retrospectives, cadance, etc.
  • Feature prioritisation moves the least valuable features to the end of the project, making it less critical.
Improve this answer
2
  • Maybe I wasn't clear enough: The core software is live (with other clients). The existing client to be migrated doesn't live on this software, lives on legacy. When the migration project is completed, then the client will go live to the new product. So until now we're building iterations and we keep them on a QA environment. The client is our internal teams that will ultimately use it. We don't even demo to those because the things are very technical and they can't understand them. Also there are no things of the system more/less valuable to prioritize, there is a known MVP.
    – dqm
    Mar 28, 2017 at 12:38
  • Then you need to get them onto tge new software and empirically adapt that software to suit their needs..
    – MrHinsh - Martin Hinshelwood
    Apr 2, 2017 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.