Questions

i will chose

2.Teach them that it is their responsibility to work with the other teams to create an integrated Increment.

I have not seen this question before, I guess it is new.

These are my thoughts.

Four teams are working on one product. That product will be released in one or more steps. The alignment of the increments can only be done when these increment are done, not in the middle of a sprint. The product backlog should be prioritized and the selection of PBI’s at the sprint planning should work towards a meaningful integrated release(s).

So
1) I think this is wrong. This would basically merge the four teams in one big team.
2) I would not choose this one, teams should be focused on delivering their increment, not on inter team communications. This would also imply that the teams would change the Sprint content and the Sprint Goals during the Sprint.
3) This would be micromanagement to no valuable result. And why make the sprints depended on each other?
4) The sequencing of the Product Backlog and the selection of items during the sprint planning should ensure the alignment of increments that are possible releasable in combination. This is primary the responsibility of the Product Owner, possible assisted by the Scrum Master and Development Team to advice on technical dependencies.Two other mechanisms for alignment are the Sprint Goals from the functional point of view and Definition of Done to ensure technical interoperability.

> Four new Scrum Teams have been created to
> build one product. A few of the developers on
> one of the Development Teams ask the
> Scrum Master how their Sprint work is going
> to remain aligned. What should the Scrum Master do? 
>
> 1.Collect the Sprint tasks from the teams at
> the end of their Sprint Planning and merge
> that into a consolidated plan for the entire Sprint.

It is not the responsibility of a Scrum Master to create a Sprint plan on a Development Team's behalf. The team is responsible for its own plan, and where multiple teams are involved in creating a Product Increment the responsibility for doing so must be shared jointly between them. This answer can therefore be rejected.

> 2.Teach them that it is their responsibility to
> work with the other teams to create an
> integrated Increment.

Where multiple teams are involved in creating an Increment the responsibility for integrating work products is commonly shared. The teams are expected to self-organize, and to ensure that an integrated and potentially releasable Increment is planned and delivered. The Scrum Master should coach them to do this as effectively as possible. This is therefore a very good answer.

> 3. Visit every team each day to inspect that
> their Sprint Backlogs are aligned. 

It is not the responsibility of a Scrum Master to align the Sprint Backlogs of teams that are working on the same Product. The teams must be self-organizing. This answer can therefore be rejected.

> 4. Teach the Product Owner to work with the
> lead developers on ordering Product Backlog
> in a way to avoid too much technical and
> development overlap during a Sprint. 

Although a Product Owner should order the Product Backlog to reduce team overlap as far as possible, and although the Scrum Master has an associated coaching responsibility, there is no "lead developer" role in Scrum for a PO to work with. This answer can therefore be rejected.

2) I would not choose this one, teams should be focused on delivering their increment, not on inter team communications. This would also imply that the teams would change the Sprint content and the Sprint Goals during the Sprint.

And in which sprint will you integrate their combined work and do a sprint review on a "working software" ?

Hi Ian & Muthaiya,

Thank you for your responses. I have been thinking about this issue for the last days.

I’m now wondering what the origin of the question was. Since the question is about 4 teams, it is more in the area of Scaled Scrum than the open assessment for Scrum Master. But I have no other reference than the Scrum Guide.

In using so, I can apply the logic to discard answer 4) for there is no “lead developer” defined in Scrum also to answer 2): Scrum does not define the “other Scrum team(s)”. So answer 2) is also not ratified by the Scrum Guide.

I guess I approach the question rather from the position of a Product Owner than from a Scrum Master / Developer role. In this capacity I view the Product Backlog as chunks of functionality that can be ‘freely’ ordered as needed to optimize customer value. So, technical dependencies should be minimal.

Furthermore, I’d expect every team to deliver a potentially releasable increment, independently from other teams. So if one team fails completely, I’d expect the other teams still to deliver the PBI’s.

And in this example it is only 4 teams. How would we organize the communication & integration of the software if we had 8 teams? Or 16?

So, from a Product Owner / business point of view (in terms of freedom to prioritize the Product Backlog and to minimize inter team communication), I would like to minimize technical dependencies across features. I have been thinking of a scenario where dependencies would be inevitable. The only example I could think of is shared asset like a database table that has to be changed by multiple teams. In that exceptional case answer 2) would be to right choose.

As for the integration for larger software buildings with multiple teams, it is advisable to compartmentalize the software building. This can be done by techniques like component based development or with SOA (Service Oriented Architecture). The software building is split in functional chunks that communicated through ‘fixed’ interfaces, and the teams only have to integrate against their own code in their component / service.

I’ve read about a company that has a stockpile of independent services using above scenario and they integrate & release new software like 8000 times a day!

Hi Christian,

Take a look at page number 16 in the scrum guide. It says.

" If there are multiple Scrum Teams working on
the system or product release, the development teams on all of the Scrum Teams must mutually
define the definition of “Done.” "

That is why Option 2 is the only right answer for this question.

Even when a team depends on a "fixed" SOA interface, both teams should agree on their "done" as part of what each should expect in the interface. Which is exactly what the scrum guide says that the team should do.

You mention that its PO responsible for "during the sprint planning should ensure the alignment of increments"
PO is responsible for business value. Optimizing the value of the work done by the teams.He gives his wishlist in the sprint planning based on what is valued the most. Not based on what will fit well with the last increment.

> Furthermore, I’d expect every team to deliver a potentially releasable
> increment, independently from other teams. So if one team fails completely,
> I’d expect the other teams still to deliver the PBI’s.

If that was your expectation then each increment would be potentially releasable in its own right, and you would therefore be the PO for four separate products. However, the question makes it clear that there is only one product.

Where there is only one product, that product can only take the form of one fully integrated and potentially releasable increment. No other work, including integration work, remains to be done.

I can imagine for 1 product that DevTeam A is creating functionality for User A’ and DevTeam B for User B’. Both teams can create integrated and releasable increments independently. That is more the scenario I had in mind. It all of course depends on the breakdown of the PBI’s, the priorities and the selection for the sprints. That's why answer 4 still appeals to me.

Hi Muthaiya,

A shared and mature DoD would reduce the need for inter team alignment on the technical level. As do the techniques I mentioned. A well designed SOA can completely eliminate integration dependencies.

I’m not saying option 2 is wrong, I’m saying technical dependencies and the need for team alignment should be minimized. That would make the whole operation more Agile. I think we can agree on the desirability of this.

With “the alignment of increments" I meant the coherent/aligned selection of PBI’s towards a release. The fitness to the existing increments should not be a concern.

The original question was about alignment of the work the Development teams. Technical dependencies should be minimal in my view, so I interpreted the question for functional alignment towards releases. Then again the Development Team members might actually have been wondering about increment alignment in time.

So the correct answer is answer 5:
5) The Scrum Master should ask the team members if the question concerns technical alignment, time alignment or functional alignment towards a release and then answer accordingly.
;-)

I think the need of teams mutual alignment should be high.

Have you heard about "swarming" ?

When I look at the original "new new product development game" paper which talks at great length about how good teams have their responsibility over lapping between the specialists.

Wherever I have heard Jeff and others speak, they always insist on having multiple skills in the team.

Your concept of making the teams more isolated is new to me. Would be glad to read a paper or some text, where they describe the "advantage" of independent scrum teams which work by "mutual" contracts?

Can someone official here, clarify us please.

I simply don't want to the "official" concepts wrong.

Swarming – in my understanding – is about all team members working collectively on one Sprintbacklog Item. Not about interaction between multiple teams over one increment.

My idea for the ideal Development team is that they work in sort of ‘isolation’ from the rest from the organization to the Sprint Goal, except from de PO for the What and the SM for the How.

The mutual contracts I was referring to are between the components, not between the teams. When the software is build in components with well defined boundaries, alignment between teams is only necessary when increments are spanning multiple components. This is known in advance and can be taken into account.

During our discussion, I realized that the interactions, the communication and the organization of multiple Scrum Teams greatly depend on the used architecture and technology. This might imply that the implementation of Scaled Scrum has a strong dependency on S/W architecture.

> I can imagine for 1 product that DevTeam A is creating functionality for
> User A’ and DevTeam B for User B’. Both teams can create integrated
> and releasable increments independently.

Can you elaborate on how the teams would integrate their work into those releasable increments, if they did so independently of each other, and without collaboration? How would the challenges and risks of integrating the deliverables of each team into the one product be managed?

My frame of thinking stems from splitting a software product in smaller pieces along functional borders into components (sub-system / services etc). Every component has well defined and bounded functionality and a stable interface. The collaboration is done via messages exchange (rpc, msg bus, XML, DCOM, Corba, WEB services whatever).

So every component can be build and tested independently and code integration is only necessary within 1 component (in 1 team), not across components.

The examples with 8000+ integrations & releases a day I mentioned was from a company like eBay or Amazon, I’m not sure. It goes without saying that these guys did not do cross team communication while creating value.

> The collaboration is done via messages
> exchange (rpc, msg bus, XML, DCOM, Corba,
> WEB services whatever). 

CORBA and messaging services are examples of integration technologies. However, they do not eliminate the need to integrate separate deliverables where those deliverables constitute a single product.

> So every component can be build and tested
> independently and code integration is only
> necessary within 1 component (in 1 team),
> not across components.

Individual component teams are in an especially poor position to deliver feature-complete items. Multiple components are typically needed to evidence business value, and the work of the respective teams would have to be integrated before that value (e.g. features, user stories, or scenarios) can be demonstrated. The acceptance criteria and the Definition of Done may thus be shown to be satisfied.

At the very least, this can be expected to involve the integration testing of multiple components in order to assert that these concerns have been met. That's an integration matter which would demand inter-team collaboration. Wise technology choices can certainly reduce the workload involved, but they cannot eliminate the shared responsibility of evidencing the value that an integrated and "Done" product is expected to provide.

Yes, I agree, integration is not completely eliminated. Eliminated is code integration across multiple components/teams. Also is eliminated cross component/team functionality when the functionality is located in 1 component. What remains is integration of functionality spanning multiple components as you point out. But this job is much easier when the first two burdens are alleviated.

This approach may not be possible for all products / organizations for technical, legacy or cultural reasons. And it requires knowledge and planning.

I suggest we close this thread, for it is more about software architecture than about Scrum.

I find it very interesting to think about the impact of software architecture on scaling up Scrum.

@Karin and others, the votes are
2 for answer 2)
1 for answer 4)
If you get this question at the assessment, I think answer 2 would be your best bet!

HI ,

Please suggest answer to below question .

1. You are part of a group of 500 developers that is responsible for building a large enterprise product. How should the architecture for the product be defined in order to effectively support this many developers working on the same product at the same time?
a) A team should design and build architectural and platform structures that define how the functionality from each set of Scrum Teams must deliver and work with each other.

b) Perform Subsystem Design. Teams should volunteer to develop specific areas of sub-system responsibility.

c) The architecture will emerge during development through early Product Backlog items

d) An architectural backlog should be created to ensure that architectural concerns are addressed in the product development process.

My answer : A)

Please give feedback.

Thanks

If you chose option A, when would sprinting begin, and how would value be evidenced to the Product Owner?

Hi!
I have problem with question:
"Could have one member of one Development Team two different Scrum Masters and two different Product Owners and the rest of the Team only one Scrum Master and one Product Owner"
A. TRUE
B. FALSE

In my opinion it should be answer B becasue DT should have only one PO but answer A is correct :/ Why?

It's possible, though not recommended, for a developer to work for more than one team. If that is the case then a developer could have more than one Scrum Master or Product Owner.

No *single* Scrum Team can have more than one Scrum Master or more than one Product Owner at any given time. So if a developer only works for one team, he or she may only have one Scrum Master and one Product Owner.

The question is poor, because the text is ambiguous as to whether or not the developer works uniquely for one team.

Thanks Ian for your answer :)!

I am not sure, but I think the right answer of the question from DEEPA MIGLANI is "c"
"The architecture will emerge during development through early Product Backlog items."

Folks, I also think the answer is "The architecture will emerge during development through early Product Backlog items.". Could anyone else here confirm?

Folks, I just completed an assessment where I scored 100% and this question about how architecture is handled in a large enterprise product was in. The correct answer is:

"A team should design and build architectural and platform structures that define how the functionallity from each set of Scrum Teams must deliver and work with each other."

Thanks!

I agree with Gabriel.
this is the best and correct answer.
definitely a group of 500 devs needs "architectural and platform structures"

b) Perform Subsystem Design. Teams should volunteer to develop specific areas of sub-system responsibility.
Perform Subsystem Design sounds not bad, but volunteer might not be enough for 500 devs

c) The architecture will emerge during development through early Product Backlog items
Sounds very optimistic for a system realized by 500 devs

d) An architectural backlog should be created to ensure that architectural concerns are addressed in the product development process.
there should be only one product backlog. 500 devs might build more than one product however there is no need for a architectural backlog.

Hi Alex,
My reply may sound very late but I just saw this post now as I came across this question in one of test assessments just completed.
If I understand your explanation, c) would be right choice for a project/product of a smaller nature unlike the one in question which has 500 developers. So basically saying, architecture and design work has to be done in a dedicated manner in early sprints for large product as one cannot wait for it evolving during development.

Also, I find language of a) little incomplete as it does not say clearly that the architecture/design work is being done as part of early sprints and not outside.

Here are some questions to ask yourself as a Scrum Master:

• Putting your Servant Leader hat on, who is closest to the problem to come to the best solution? What is the benefit of a Dev Team being able to solve their own challenges?
• What does Scrum require at the end of every Sprint? And what are two important characteristics of a Development Team to meet this requirement?
• Is stable velocity and keeping busy a goal of Scrum and a concern of a Scrum Master?

Thank you so much "Ian Mitchell" for the to the point and the most accurate answer I ever expected for this question.

> Four new Scrum Teams have been created to

> build one product. A few of the developers on

> one of the Development Teams ask the

> Scrum Master how their Sprint work is going

> to remain aligned. What should the Scrum Master do? 

>

> 1.Collect the Sprint tasks from the teams at

> the end of their Sprint Planning and merge

> that into a consolidated plan for the entire Sprint.

It is not the responsibility of a Scrum Master to create a Sprint plan on a Development Team's behalf. The team is responsible for its own plan, and where multiple teams are involved in creating a Product Increment the responsibility for doing so must be shared jointly between them. This answer can therefore be rejected.

> 2.Teach them that it is their responsibility to

> work with the other teams to create an

> integrated Increment.

Where multiple teams are involved in creating an Increment the responsibility for integrating work products is commonly shared. The teams are expected to self-organize, and to ensure that an integrated and potentially releasable Increment is planned and delivered. The Scrum Master should coach them to do this as effectively as possible. This is therefore a very good answer.

> 3. Visit every team each day to inspect that

> their Sprint Backlogs are aligned. 

It is not the responsibility of a Scrum Master to align the Sprint Backlogs of teams that are working on the same Product. The teams must be self-organizing. This answer can therefore be rejected.

> 4. Teach the Product Owner to work with the

> lead developers on ordering Product Backlog

> in a way to avoid too much technical and

> development overlap during a Sprint. 

Although a Product Owner should order the Product Backlog to reduce team overlap as far as possible, and although the Scrum Master has an associated coaching responsibility, there is no "lead developer" role in Scrum for a PO to work with. This answer can therefore be rejected.

hi every body, 

until now we don't have a factual answer, most of the test online give the answer that i respect but we must to take a decision!!!

>Collect the sprint task from the teams at the end of their sprint planning and merge that into a >consolidated plan for the entire sprint 

or 

this kind of question can be confuse the trainer. we need more detail. anyway, for me the best answer is (from  Ian Mitchell):

>Teach them that it is their responsibility to work with the other teams to create an integrated >increment

Where multiple teams are involved in creating an Increment the responsibility for integrating work products is commonly shared. The teams are expected to self-organize, and to ensure that an integrated and potentially releasable Increment is planned and delivered. The Scrum Master should coach them to do this as effectively as possible. This is therefore a very good answer.

thank you to confirm.

best regards

In the guide says this:

If Scrum Teams become too large, they should consider reorganizing into

multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the

same Product Goal, Product Backlog, and Product Owner.

So, in my opinion, this comment: "I would not choose this one (2), teams should be focused on delivering their increment, not on inter team communications. This would also imply that the teams would change the Sprint content and the Sprint Goals during the Sprint." is not true.

For me the correct answer is: 2 - Teach them that it is their responsibility to work with the other teams to create an  integrated Increment.

Yes, the answer is 2.  If you are preparing to take a scrum certification, then don't just rely on the scrum guide as that will not be enough to allow you to pass the open assessments let alone the actual certification assessments. 

Utilise the resources accumulated for each exam on this site before taking any of the open assessments, so that you will then be able to not only answer those questions but understand why you are choosing the correct answer.