2

Our product involves many (dozens) front and back-end modules which work in together with each other. We have decided to completely replace one of the largest which means we plan to port it to the new programming language/technologies. Most likely we do an initial direct port, verify the functionality then look at tidying/fixing all the weird legacy stuff that accumulates in multi-decade-old code.

I can't give precise details but it's pretty comparable with wanting to switch our database provider - say from Oracle to SQLServer - all those stored procedures to rewrite, etc.

I'm struggling to get my head around how we might best model this in an agile way given that as far as the user is concerned, nothing changes. As an Epic "replace Oracle database with SQLServer" seems to make sense but then what about features/stories?

Improve this question

2 Answers 2

Reset to default
4

During such a long-lasting architectural change, it will be next to impossible to deliver small increments to the end user, since it would break too much of the existing functionality.

In such a situation, you still can work in sprints, but deploy the results in increments only to a testing environment, where the new backend runs in isolation, with either no frontend, or a frontend where you expect certain things not to work. Someone has to test the intermediate versions there, so you can use the feedback from the testing as input for the next sprint. The final step of replacing the existing backend by the new one in production will be delayed until the new backend provides enough functionality.

As an alternative, suggested by @bdsl, it may be possible to deploy certain parts of the new backend to the production environment gradually, but without really replacing the old backend (or at least not in full). That gives your testers the opportunity to see the new backend in the live environment, maybe only accessible for them, with the technical differences only visible for them, but not for the end user.

Now, with such an environment in mind, you can choose features for "user stories" just in the order it makes most sense for testing and replacing the old tech. You describe them from the point of view of a tester or a "test engineer", not from the perspective of an end user. That should work even if your tests involve more technical tasks and no UI.

Improve this answer
6
  • It's almost always possible to design the change path in a way that will allow continuously deploying to production, even if there's no immediate benefit. For instance for migrating a database you can make the app connect to two databases at once, gradually add double-write code to put the info in both dbs, and then replace the read queries one at a time.
    – bdsl
    May 18 at 14:43
  • See e.g. branch-by-abstraction pattern for other ways of doing large scale architectural change with continuous integration and continuous delivery.
    – bdsl
    May 18 at 14:44
  • @bdsl you might be able to deploy it without it breaking anything but this seems to raise issues; in your example now there are two sources of failure and may be performance implications. But it's a good point to try and find a way to make it work rather than just assume it doesn't.
    – Mr. Boy
    May 19 at 15:16
  • 1
    @Mr.Boy There could be, how much extra possibility of failure and performance cost depends on exactly how you do it. But I would argue it's almost always worthwhile to find a way to deploy incrementally. The alternative feels safe and easy because there's no risk of breaking anything for the user as you prepare the changes, but you're pushing all the risk to the end.
    – bdsl
    May 19 at 16:22
  • 1
    @bdsl: I agree, that is a viable alternative, and the OP should seriously validate if that approach makes sense for their system. For this specific question, however, the issue of having increments which don't deliver any visible benefit to the end user stays the same. So I think my recommendation to write "user stories" from the point of view of a tester fits to your suggestion as well.
    – Doc Brown
    May 19 at 19:05
2

This is a somewhat common problem that teams face when things are no longer a monolith. It's not really a problem, it's just a lack of understanding what a user story really is. Writing a story from the perspective of the user of the module or microservice or API or any other, which can be other code or developers and not just end users. The key focus id delivery of value, stories that focus on end users are easy to demonstrate value, so they tend to be the primary examples, but really there are a lot of non user focused or indirectly user focused things that can deliver value, but don't really make sense to word from a user perspective.

As a dev I want a getFoo() endpoint in #newApp so that #newApp can be used by #MainApp. That is an acceptable story, even though it may not have any direct end user impact. This is also a pattern that can be followed by teams that are more traditionally support or admin roles.

The point of being agile is focusing on that delivery of value and having feedback loops to adjust anything that is getting in the way of delivering value. Many times organizations create rules and process that are overly focus on UI and deployment of code as what stories are for, but this is really more of the 80% case. Process can provide value when it's ensuring compliance or allowing status to be reported or known to others at a glance, but rules about requiring a deploy or a UI change often become problematic as an organization matures.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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