Story: extract a service from big-ball-of-mud
Before:
There are 3 services, part of a product.
The users of the system, need to interact with all 3 services.
There is no unified way / place for interacting with all 3.
Each system is owned by a separate team.
Both the users and the services are internal to the company.
Assignment:
Create a single point for the user to interact with the system (instead of 3)
Rethink the way users interact with the product, so it closer matches the product vision.
More fine grained configuration, possible to change on a per case basis.
Process: water-scrum-fall
While probably not intentional, in hindsight the process ended up becoming water-scrum-fall.
- Relatively long preparation (analysis) phase.
- Followed by scrum iterative development, but only internally, not actually used by anyone.
- Near the end, when it is 'done enough', it can start being used.
- Active development stops.
We created a new service, which all 3 services use, and behind which they are hidden away for the user.
Only in step (3) when it was 'done enough', the 3 services started using our new service.
And only after that, the user could use our service.
One of those 3 services, created a fallback mechanism to the old way, in case our new service would not be able to handle the load. And did a gradual transfer to our service.
The other 2 services, switched over at once.
Challenges in the cross-team collaboration aspect.
We had to work closely together with the different teams that have expertise about their service, which we lack.
Challenges because of backwards incompatible changes.
Changing our endpoints in a non-backward compatible way,
required patience and time for the 3 services' teams to migrate to the new endpoints.
Challenges because of code ownership boundaries.
We could not simply change the code in the 3 using services, because that was not ours to do.
Challenges in responsibility boundaries.
The 3 services' teams, were each responsible for their service.
But now they would become dependent on our service.
This caused hesitance for them to start using our service.
Combined with our service being relatively new and unproven,
it took some time before they started actually using it.
Conclusion
We had everything deployed in production since the beginning.
So in that way we were working in an agile manner.
But actual usage of our system only happened near the end.
So in that way we were working in a waterfall manner.
Hence the water-scrum-fall.
What could we have done better?