Hot answers tagged

6

TL;DR Nexus is about integration. It's very hard to do integration well without an adequate toolchain, but following the Nexus framework should enable you to iteratively improve your organization's ability to integrate. Your main challenge seems to be either: A misunderstanding of the way that the Nexus Product Backlog items are refined, visualized, and ...


5

Each Scrum Team Tests Its Own Work A lot depends on your scaled framework, but in general the answer will be that each individual Scrum team is responsible for testing its own work. For example, when using Nexus: The Scrum Teams are responsible for developing Increments of potentially releasable software, as prescribed in Scrum. [NB: A completed ...


5

The Scrum Guide states that a Scrum team should have all the skill necessary to deliver a product increment. The idea is that a team will take one or more features and fully implement them by the end of a sprint. Scrum teams own the features they are working on and this will include system testing and deployment. When you have multiple Scrum teams working ...


2

To understand the how bit you will need to study each individually. The good news is that all will talk about basically the same thing but with different terminologies. If you are familiar with Scrum, then understanding the how of any of the 3 should be fairly straightforward. In case of Nexus, which is my favourite, you basically add additional events ...


1

The cross-team dependency is a known problem on large scale projects. We're running a project with four teams sharing the same platform, and the solution boils down to communicate... a lot. Specific actions to take into account on how to manage these dependencies: Avoid cross-dependency as much as possible; it's a no brainer, but sometimes you need someone ...


Only top voted, non community-wiki answers of a minimum length are eligible