Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

Multiple Scrum teams
Last Post 10 Sep 2014 05:29 AM by Alper Gurbuz. 11 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Eugenia Gebert
New Member
New Member
Posts:12
Eugenia Gebert

--
06 Feb 2014 01:04 AM
    Hi,
    I have a question related to multiple Scrum teams. How to syncronize them?
    They work usually on the same PB and share the common definition of "Done". But what's about the Spint length and the Sprint start? Must multiple teams start and end the Sprints at the same time (syncronically)?

    Thanks!
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1534
    Ian Mitchell

    --
    06 Feb 2014 01:28 AM
    Scrum does not mandate that Sprints must be synchronized. As you have noted, when multiple teams are working on the same product, and are therefore drawing from the same Product Backlog, the emphasis is placed on having a shared Definition of Done.

    Yet as a general rule one can reasonably expect Sprints to be synchronized. This is because if they aren't, at least one team's increment will be put in delay, and will therefore depreciate in value before a release can be made. However in the wider scheme of things the waste thus incurred is typically minimal, and there can be valid reasons (e.g. logistical ones) for sprints to be staggered.

    If sprints are to be synchronized, it's important to make sure that the reasons for doing so are sound ones. Higher management can be very keen to synchronize sprints...not because they value the elimination of such waste, but rather because they want to encourage "release on cadence". Although this sounds good it is often a smoke-screen for wanting to constrain releases to stage gated boundaries, as opposed to the more agile practice of releasing each sprint or on demand.

    Eugenia Gebert
    New Member
    New Member
    Posts:12
    Eugenia Gebert

    --
    06 Feb 2014 03:15 AM
    Thank you for the detailed answer!
    Mehdi Hafezi
    New Member
    New Member
    Posts:46
    Mehdi Hafezi

    --
    06 Feb 2014 04:23 AM
    @Jeny: good Question.

    @Ian: How could they be synchron- let's take following constallation?

    There are 5 Scrum Dev. that work on the same product.
    They share DoD , PB List sprint length (i.e. 4 weeks), and Product Owner
    The sprint planning meeting is for monthly sprints timeboxed (8 hours / 1 day).

    From my point of view there will be bottle neck regarding presence of PO in their planning and review meetings,
    I think they must start and end with for example with 1 day delay toeach other:

    - Team-1 Sprint Planning on monday
    - Team-2 Sprint Planning on Tuesday
    - Team-3 Sprint Planning on Wedensday,....

    Or a big meeting will be organized which all teams participate for S. Planning and S. Review meetings?





    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1534
    Ian Mitchell

    --
    06 Feb 2014 04:35 AM
    > there will be bottle neck regarding presence of PO in their planning and review meetings

    Yes, it's a problem. That's what I mean by "logistical reasons" for staggering sprints. PO availability is one such constraint. Another might be the availability of meeting rooms.

    > Or a big meeting will be organized which all teams participate for S. Planning and S. Review meetings?

    This is another option. Larman and Vodde have considered it in their work on Large Scale Scrum. See the following PDF:

    http://www.crosstalkonline.org/stor...Larman.pdf
    Sanjay Saini
    Basic Member
    Basic Member
    Posts:151
    Sanjay Saini

    --
    06 Feb 2014 05:34 AM

    I won't recommend a PO feeding multiple teams, idle case is ONE, at max Two otherwise he won't be able to do justification his role. Don't treat PO as a Project/Program who can be assigned to multiple teams on partial allocation. Having a same start and end date is good for everyone. Your stakeholders and customer will be happy to get a demo of integrated software demo from all teams.

    For multiple teams, one of the items in DoD should be related to Integration of their releasable slice.

    Cheers
    Sanjay
    Eugenia Gebert
    New Member
    New Member
    Posts:12
    Eugenia Gebert

    --
    06 Feb 2014 08:49 AM
    And what's about the integration of increments every Sprint (multiple team, the same product)?
    Is it mandatory to do it in purpose of inspection by PO? I suppose it is so, but I'm not sure...
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig  Harsch

    --
    07 Feb 2014 01:19 AM
    Hi Jeny,
    the whole concept of scaling Scrum is not part of the Scrum Guide, so there is no "mandatory".
    However there are good practices, for a deeper understanding I would also recommend the book "´Practices for scaling lean & agile development" by Larman and Vodde.
    To answer your last question: If you have multiple dev teams working on the same Product, it is a good practice to have a common Product Backlog and Definition of Done. This implies they have an integrated increment at the end of each sprint, which means they have to integrate at least every sprint (which will not be enough in practice).
    Successful teams manage to integrate continuously. Some have a dedicated integration team as one of the dev teams which passes any defects found to the respective dev team, which has to fix them with highest priority.
    Best, Ludwig
    Sanjay Saini
    Basic Member
    Basic Member
    Posts:151
    Sanjay Saini

    --
    07 Feb 2014 01:24 AM
    Re: the integration of increments - it must be part of team's DoD. For multi team scrum implementation each sprint across teams should be releasable.

    Cheers
    Sanjay
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1534
    Ian Mitchell

    --
    07 Feb 2014 03:32 AM
    > the whole concept of scaling Scrum is not part of the Scrum Guide, so there is no "mandatory".

    That's right. However, each team's increment must be potentially releasable. If that means integrating it with other team's work, then that is what has to be done. It's a borderline matter and it does touch on scaling, but on balance I'd say that cross-team integration is in fact mandatory in the Scrum Framework.

    > Re: the integration of increments - it must be part of team's DoD. For multi team scrum
    > implementation each sprint across teams should be releasable.

    Correct.
    Bhuvan Misra
    New Member
    New Member
    Posts:21
    Bhuvan Misra

    --
    11 Feb 2014 03:19 AM
    For multiple Scrum team's that are working towards a Single Product, it becomes important to minimize the "Intersection Set" of the Items that they pick up. Also, important is how the Stories have been split. A horizontal split of User Stories (UI only, Middle Tier only, DB only etc) will may run into problems. A vertical split of Stories will help each team work on a complete stack from UI to DB and help create apotentially shippable product.

    Adoption of Development process that includes focus on Automation of Unit Test and Integration Test will also aide such teams.

    Further, if the teams are in different geographies optimum use of electronic tools and communication will have to be planned for smooth execution of Sprint.

    --Bhuvan.
    Alper Gurbuz
    New Member
    New Member
    Posts:9
    Alper Gurbuz

    --
    10 Sep 2014 05:29 AM
    As per the open assessment questions, teams dont have to have a shared DoD. Each DoD needs to satisfy the potentially shipable criteria for the integrated work.
    You are not authorized to post a reply.


    Feedback