Skip to main content

end to end delivery with multiple teams

Last post 08:29 pm December 19, 2022 by Mark Derrida
5 replies
01:57 pm December 17, 2022

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

 

 

 

 

 


02:46 pm December 17, 2022

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.


09:45 pm December 17, 2022

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"?

 


11:16 pm December 17, 2022

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.


12:46 am December 18, 2022

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.

 


08:29 pm December 19, 2022

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!


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.