Scaled scrum Questions
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
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
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
> 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?
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.
Hello Ian,
I am not able follow you. Can you please add some more details?
Regards,
Soumya
> 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.
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
> 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?
Thanks, Ian for pointing it out.