end to end delivery with multiple teams
I'm working as Product Owner on a financial application that needs to use different components developed by different teams.
Each team use scrum:
- Frontend/Backend application that collect user data, store them, and show results after running other services.
- Financial service application that receives data from FE/BE application, retrieve parameters from a master data service and trigger an Engine
- an Engine, running inside the Financial service, that executes the calculations and return back results
The current situation is:
- FE/BE application is testing mainly UI functionalities. They don't want to have anything to do with correctness of results
- Financial Service: is concerned with retrieving data and exposing API. They also don't care about correctness of data
- Engine: has unit tests, performed on a sample data set with no connection with any service, and checked with domain experts.
Guess what?
Every team is a SCRUM team with a scrum master and all the processes in place, but is accountable to its own business unit only, and is worried about accomplishing its own sprint goal.
Each part works perfectly, but the final end to end results are completely wrong.
Of course all the sprints run on different timelines and deployments on different environments are not in sync.
As P.O., I tried to organize several periodical overarching "touch points" or escalate the issues to the respective scrum masters/product managers/business owners etc...but I really feel that nobody is really committed to the overarching goal, and that we are going to miss it if I don't act.
I involved myself heavily in end to end testing, which is difficult because the data set is not trivial, it's written in the "financial" language and not immediately usable on the frontend application.
I was thinking about a kind of "cross-functional" team, maybe one person from each of the services involved, but I can't find the right frequency. Basically features are available for e2e testing on a random basis and people just meet to find out that they cannot do anything: because, oh that's still in dev! no we deployed on test, but not the last version, or wait, we changed something in a feature branch, oh the parameters are still wrong on that environment (there are more than 100 parameters) and so on.
I'm slowly failing, and if I try to explain the situation to my boss, it's just like: "it's your responsibility to make this work"
Any suggestion welcom
Why not coach them to self-organize as actual feature teams, each one of which commits to delivering a Done increment under its own steam? They would each have a clear accountability to do so, and to minimize and self-manage their integration dependencies. Scrum thrives on self-organization but it is also a skill which has to be learned.
There is no "them"...So far I pointed out the issue several times, but there was no spontaneous self organization happening.
So I decided to ask explicitly to a reduced set of people from each team to join a bi-weekly 15 min call to address specific tasks I assign them.
I designed the tasks in a way I believe will accomplish the final goal and I executed a few myself as example.
Is this what you call "coaching" and "self organizing"?
Throw everyone in 1 team. Then break that into at least 2 teams (they may self organize to form the old teams again if you simply put everyone together). Then the teams have people that can do FE/BE, Fin. Service and Engine, and they can create and release a feature all on their own. As long as you don't do that, you'll have "that's not our problem" situations.
The teams can't do this themselves: management needs to form these new teams. If you have multiple teams, they can have a say in who is in which team, as long as the teams are cross functional and able to create a releasable increment.
Also, from experience, I'm going to guess the bi-weekly 15-min call is not their problem, it's your problem: they don't actually care and they do the minimum effort to satisfy the assigned tasks.
There is no "them"...So far I pointed out the issue several times, but there was no spontaneous self organization happening.
That's right. Self-organization does not happen spontaneously. It is a skill which has to be learned, and there will be an organizational gravity to be overcome.
So I decided to ask explicitly to a reduced set of people from each team to join a bi-weekly 15 min call to address specific tasks I assign them.
I designed the tasks in a way I believe will accomplish the final goal and I executed a few myself as example.
Is this what you call "coaching" and "self organizing"?
No, because you were reducing people to a subset and then assigning them tasks. Instead it might be better to create a bounded environment for others to take action in. For example, this could be a time-boxed workshop (e.g. 30 minutes) within which attendees are given a clear goal (e.g. self-organize into feature teams, each with the skills to build a usable increment) and rules (e.g. no more than about 10 people in each team).
The job of a servant leader would be to facilitate this, pointing out issues and discrepancies (e.g. skills shortages and imbalances). The skill lies in being able to reveal rather than resolve. Scrum Masters should be in a position to help here. The job of senior leadership meanwhile is to sponsor systemic change, and to create, communicate and reinforce a sense of urgency for it.
The job of senior leadership meanwhile is to sponsor systemic change, and to create, communicate and reinforce a sense of urgency for it.
...I did manage to create a sense of urgency indeed :-D
I think I organized in a much more "command" way, but open to suggestion anyway.
I like both the way you both explain the dynamic. It's inspiring. Thank you!