Skip to main content

Scaled scrum Questions

Last post 02:26 am October 12, 2015 by Soumya Das
9 replies
07:26 am September 29, 2015

Hello, I have below questions on Nexus guide.

1. If we need 100+ developer to work on a Product. Can it be done through scrum?

As per nexus guide: Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.

2. Is it recommended that all scrum teams working on the same product to have common “Sprint Length". Otherwise it may create problem for sync up.

3. Can I have some example on the “priority must be given to the work for the Nexus Integration Team Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership."

As per nexus guide: Members of the Nexus Integration Team may also work on the Scrum Teams in that Nexus, as appropriate and necessary. If this is the case, priority must be given to the work for the Nexus Integration Team. Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership. This preference helps ensure that the work to resolve issues that affect many teams has priority

Thanks,
Soumya


08:04 am September 30, 2015

Hi Soumya,

Thanks for the very interesting questions.

1. Is effective work of 100+ people on the same product even possible? Let's look how the author of the Nexus Guide answers it here: https://kenschwaber.wordpress.com/2015/01/30/more-on-scaling-scrum/#com…

So you can have hundreds and hundreds of Scrum teams working on the same product area. However, when you have functionality that requires more than nine or so teams you have two choices:
1. Build architectural and platform structures (IOS, API, etc.) that defines how the functionality from each set of Scrum teams must deliver and interoperate.
2. and/or take longer and only do as much as the nine or so teams can do at once. Then do more. Then do more.
--------------------------

2. What about common Sprint Length and alignment of Sprints of all teams... The Scrum framework does not require any of it. However, if all the teams work together using the Nexus Framework, they work in the same Nexus Sprint, have common Nexus Sprint Planning and other events. I think, the teams should use the same Sprint length and all Sprints should start and finish together.

3. It is easy. If there is some integration work to do in the Sprint, it should be done first. For example, any dependencies between teams should be removed or minimized to facilitate work of all teams.

To look for answers on other scaled Scrum questions you can look at my quiz: http://mlapshin.com/index.php/psm-quiz/nexus-quiz/
It has about 40 questions with explanations.

Thanks,
--Mikhail


01:45 am October 1, 2015

Thank you, Mikhail for your response. I will not agree on point 1. There are teams of 100+ developers work on the same product but each team deals with different area like UI, DB etc. Even I came across questions from scrum org that says teams of 500 or 200 developers. However A large product can be divided into sub products. I read some concepts on Product, Program and portfolio. Not sure whether we can fit this here.

on point 2 although the nexus guide does not mention on Sprint length of scrum teams working on a product. The way nexus activities organized it'll be helpful if the scrum teams have uniform sprint length. Agree with you here. But want more opinions.

Agree with you on third point too. Again thanks for sharing your quiz link.

Regards,
Soumya


03:36 pm October 1, 2015

> There are teams of 100+ developers work on
> the same product but each team deals with
> different area like UI, DB etc. 

What risks might arise with such a team structure?

Suppose that teams are aligned by feature instead, and not by layer or component. If each team delivers a piece of work that is feature complete, might that help to mitigate some of the risks?


12:04 pm October 3, 2015

My answers:

1. Nexus+

2. There is absolutely no need of cadence among Nexus Teams. There is flexibility around synchronisation.

3. Obviously more value could be created when you solve a problem for multiple teams.


01:03 am October 7, 2015

Hello Ian,

I am not able follow you. Can you please add some more details?

Regards,
Soumya


06:47 am October 7, 2015

> I am not able follow you. Can you please add some more details?

Scrum Development Teams should deliver increments that are feature complete. Feature-complete increments are deliverables of business value, and their delivery is concrete evidence that business risk is being mitigated.

If teams are not aligned by feature, but instead "each team deals with different area like UI, DB etc" as you suggest, then each team's ability to delivery by feature will be compromised. No feature can be evidenced unless and until integration occurs across multiple teams and their deliverables.


02:24 am October 8, 2015

Thanks Ian, I just wanted point it that there are 100 + developer teams. And some of the large projects I had come across works in above way. But again we were not following scrum on those projects.

Basically What I want to ask is should we limit team size to somewhere around 90 for nexus. I agree on that products can be decomopsed. But then why nexus if we can not have 100+ developer team (for a product)? Just want to get feedback on this point.

Regards,
Soumya


11:13 am October 8, 2015

> Basically What I want to ask is should we limit team size to somewhere around 90 for nexus.
> I agree on that products can be decomopsed. But then why nexus if we can not have 100+
> developer team (for a product)?

What does the Scrum Guide have to say about Development Team size? Is it possible that some of those constraints might also be echoed at scale?


02:26 am October 12, 2015

Thanks, Ian for pointing it out.


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.