5

OK; this is a real-world question rather than a theoretical construct.

Context: Multinational company flirting with scaled Agile and/or Nexus. Currently have 3 large agile programmes of 200+ developers in each. The most mature programme has 20 feature teams and 6 of those feature teams have been selected to pilot Nexus.

Problem: The teams were originally structured around product feature sets (teleconference integration, digital transformation, sales/customer contact history) which had little to no dependency between each team.

The move to Nexus means all teams should prioritise all of the highest priority stories even though it means all teams start working within the same codebase (, that is, all work on teleconference integration).

Curveball: The technology we are working on is not very mature and it has no version control at present. It's coming in the next 12 months. Essentially, one developer locks out a coding object until it is deployed to the next environment which causes delays for other developers and teams.

Question What is the best way to scale delivery? Is it for all teams to work on the highest priority items (a la Nexus guidance) even though dependencies will slow down delivery; or is it better to split the feature sets across teams so they can work independently and integrate the increments in a longer cycle?

I am looking for thoughts from the agile community; I have my own opinion, but I want to see how others have interpreted Nexus and the solution to this problem.

  • 2
    How to scale delivery when the technology has no version control. Work on separate features or all teams work on the highest priority items even if it means codebase becomes locked/dependent. – Venture2099 May 13 '16 at 11:11
  • Nexus is an artifact repository, not an SCM. They are not orthogonal; they solve different problems. You really need both. – Todd A. Jacobs May 13 '16 at 13:11
  • 3
    @CodeGnome I believe "Nexus" in the question refers to the scaled Scrum framework called Nexus and not the software repository called Nexus. – Thomas Owens May 13 '16 at 15:01
  • Comments are not for extended discussion; this conversation has been moved to chat. – jmort253 May 20 '16 at 10:50
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 selected across teams.
  • Missing Product Backlog items related to developing the capabilities required to actually integrate the Integrated Increment.

In either case, the process side of the problem can be addressed during the Nexus Refinement and Nexus Sprint Planning events.

Using the Product Backlog Effectively in Nexus

The following is a restatement of your interpretation of Nexus as it applies to your situation:

A move to Nexus means teams should select the highest priority stories even if it means all teams start working on the same code, i.e. all teams would work simultaneously work on teleconference integration.

This is an understandable misinterpretation based on common Scrum practice. However, it is incorrect for three reasons. The reasons are:

  1. Scrum Teams within Nexus are expected to be structured around subsystems.

    While not clearly stated within the guide, the framework nevertheless contains this guidance:

    To the extent that requirements, team members’ knowledge, and code/test artifacts are mapped to the same Scrum Teams, dependency between teams can be reduced.

    When software development using Scrum is scaled, these dependencies of requirements, domain knowledge, and software/test artifacts should drive team organization.

    Remember, Nexus is all about integration, not adding more resources to the same set of tasks. Structuring your Scrum Teams around feature sets or subsystems that need to be integrated, with an eye towards minimizing cross-team dependencies, is the ideal.

  2. The Nexus framework requires the Nexus Integration Team to refine the Product Backlog to eliminate or minimize dependencies between teams.

    The Product Backlog needs to be decomposed so that dependencies are identified and removed or minimized. Product Backlog items are refined into thinly sliced pieces of functionality and the team likely to do the work should be identified as early as possible...Only when the Product Backlog items are adequately independent can they be selected and worked on without excessive conflict between Scrum Teams in a Nexus.

    This isn't really about assigning work to teams. Rather, it is supporting the notion that the teams should work on loosely-coupled areas that are integrated daily within the Nexus. This is much easier to do when teams are formed around feature sets or subsystems.

  3. The Product Backlog in Nexus is not intended to be addressed in strictly linear order.

    Instead of a strictly linear or sequential order, a Nexus Product Backlog is intended to carry additional information to guide selection of items during Nexus Sprint Planning. Consider the following statements:

    • As the Product Backlog items are refined and made ready, indicators of which team will do the work inside a Sprint are made visual.

    • Product Backlog items are refined into thinly sliced pieces of functionality and the team likely to do the work should be identified as early as possible.

    • The first part of cross-team Refinement should be spent decomposing Product Backlog items into enough detail in order to understand which teams might deliver them, and in what sequence over upcoming Sprints.

    During Nexus Sprint Planning, each team selects work for the Nexus in a Scrum-like way, but teams should be selecting the topmost backlog items that support their specific Sprint Goal within the overarching Nexus Sprint Goal. Any additional refinement or reordering can be done by the Product Owner on the fly, if needed.

By ensuring that your Scrum Teams are cross-functional but as loosely-coupled as possible with other teams, you are more likely to achieve scale. Your use of the Product Backlog must support this organizational structure, and be optimized for cross-team refinement and integration.

Add Missing Integration Stories to the Product Backlog

The goal of Nexus is to scale Scrum for integration between subsystems. If your process or toolchain doesn't support integration, then you need to iterate until it does.

The role of the Nexus Integration Team is to identify what needs to be done to facilitate integration. If integration is difficult because you lack the tools or infrastructure to integrate properly, then the Nexus Integration Team should work with the Scrum Teams and the Product Owner to create and prioritize integration items on the Product Backlog.

This isn't just an ideal; it's actually a requirement of the Nexus framework. The guide specifically says:

The Nexus Integration Team takes ownership of any integration issues. It is accountable for successful integration of all work by all Scrum Teams in a Nexus. Integration includes resolving any technical and non-technical cross-team constraints that may impede a Nexus’ ability to deliver a constantly Integrated Increment.

If the Product Owner or the stakeholders won't allow integration to be prioritized, the Nexus implementation will probably fail. Treating Nexus as a way to scale resources without addressing integration misses the entire point of the framework.

  • 1
    Thankyou @CodeGnome; what you have written very closely maps to my own interpretation of how to move forward. Now I need stakeholder buy-in. Thanks for an excellent answer. – Venture2099 May 14 '16 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.