Skip to main content

Organising squads in scrum

Last post 10:58 am November 21, 2019 by Xander Ladage
3 replies
02:20 pm November 18, 2019

Hi - Looking for some advice please. I look a squad that looks after (Adobe Experience manager) development. The squad focus on new components needed, tech debt and building out the optimisations to existing journeys from Adobe target (a/b) test results. I have another squad purely focussed on hypotheses and target execution of the tests and then deciding which things should flow into the AEM backlog. The problem is that both squads effectively work on the same end to end sales journey so KPIs and outcomes are heard to define and split between then. Plus the optimisation squad have a dependancy on the AEM squad to ship things to customers. We have a bottleneck where the PO in the AEM squad isn't prioritising the target tests being built as they have loads of other things like new components for product launches being required. Do others face similar challenges and of these options I(Assuming no constraints to resource or funding) what should we do?

1. Collapse both squads into one with target and AEM developers in it

2. Leave the squads separate but put 1-2 AEM devs in the optimisation squad to sort the bottleneck

3. Set up a third squad of AEM devs who purely focus on the optimisation test outputs build

4. Do nothing

Any feedback welcome or other ideas to the 3 listed

Thanks, Ad


02:57 pm November 18, 2019

What are your thoughts about having Scrum Development Teams, as described in the Scrum Guide and Nexus Guide?


03:15 pm November 18, 2019

We do have scrum development teams and we keep those development teams synced up through cermonies etc but there is still a problem in prioritisation and outcomes / KPIs.


10:58 am November 21, 2019

The problem is that both squads effectively work on the same end to end sales journey so KPIs and outcomes are heard to define and split between then.

There should be only one KPI for you: delivering working Done software increments (or translated: meeting the sprint goals). Any other KPI should not be your concern.

Other thing; it two squads work on the same end-to-end deliverable; does having two squads cutting these deliverables in half help your delivery process? Or could it be benificial for both of them to produce a deliverable end-to-end? If you want hamburgers; would you rather have one squad delivering the meet burger, and than another delivering the bun and sauce after this; serving a cold hamburger in the end? Or would you rather have each squad delivering a smaller warm hamburger to the client?

We have a bottleneck where the PO in the AEM squad isn't prioritising the target tests being built as they have loads of other things like new components for product launches being required.

The PO not prioritizing based on your squad delivery is exactly the way it should work. The PO decides based on (enduser / stakeholder) value, not in based on when you have your stuff ready. you should accomodate the PO's prio, not try to determine it.

It is fine you have a meet burger, bun and sauce ready; but not if the person eating wants to order french fries and a milkshake.


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.