How would you approach delivering a Scrum-based front-end product that integrates with a backend system developed using a Waterfall or hybrid model?
What tools and techniques would you recommend to align rapid front-end iterations with the slower pace of backend changes?
Off the top of my head, you’d need extensive planning where both teams collaborate.
Contracts set up to make sure everyone is on the same page and is working towards the same goal. This will be followed by a separate task of dotting the i’s and crossing the t’s when the front end and back end are ready to be merged.
A generic example could be:
There will surely be instances when you’ll want both teams working together to finalize things either be it the planning or merging.
@hananurrehman , these are all great suggestions.
Having a thorough understanding of release cycles of each integrated solution (circa 7) both backend and 3rd party, allows for smart release planning.
Avoiding too much change for users, particularly of backend systems and timing is essential.
Also consideration for bundling releases should be made. That allows for specific integrations to be deployed in tandem.
I’m not sure you should be trying to align a well performing team with a slower one as a specific goal.
Perhaps its how would you maintain your optimal approach “despite” slower availability of dependent parts. Note this also happens quite a bit with 3rd party integrations and you dont want the team sitting around waiting at each step.
Make sure everyone is aware of the impact of the different ways of work, maybe someone can help align teams on this and maybe the other team can reprioritise but maybe not.
A lot of teams will sandbox the backend or parts of it when this is the case. This seems fairly common with some sort mocks or stubs available.
Early projects I’ll often be testing with a sandboxed backend or 3rd party integration, I’ll retest later when everything catches up but it allows progress but with some risk of rework later.
Absolutely, I wouldn’t ever encourage aligning in a way that slows down the agile team.
Also, it isn’t about performance, although it’s interesting that you took that from my initial questions. None of the teams are performing badly, they are just different delivery models, and somewhere in the middle need to integrate successfully to allow the front end to deliver at speed without causing significant issues to the backend systems and teams.
The backend is a monolith so naturally slow to move, and as you rightly observed a 3rd party COTS product (with significant customisation).
My question was more, how would you enable the agile scrum team’s delivery to deploy to a slower backend. Not necessarily align their deliveries specifically.
My response about bundling releases again, was more about impact of regular change on backend teams that are currently working in a more waterfall way.
Understanding the deliveries on both sides to align them effectively ensures that end to end workflows are not impacted by a rapidly changing front end.
I know how I would approach it, but my question was to gain an understanding of how other people might.
There’s an environment that connects the QA’d deliveries from the scrum teams once they are ready to ship, into an end to end environment, so while environments are challenging in this instance, they are in place.
How would you speed up the regression of circa 200 processes? Again, I know what my thoughts are but I’m interested to hear yours.