In one of my previous post “A feather for scaling Lean/Agile Product Development“, I presented the main characteristics of Nexus, the scaling framework created by Ken Schwaber and Scrum.org.
In this post I would like to share what are the strengths of this framework and what could be the attention points, according to my personal experience. Actually, the more I use it, the more I appreciate its concreteness, simplicity and “stubbornness” with agile and lean.
A very interesting given advantage, is that its learning curve is not that steep for someone who knows already Scrum, Agile principles and Lean.
My previous post gives you some of the basics of that framework if you are not familiar with, which I suggest before proceeding further with this one.
First of all, it is worth citing here the definition of Nexus, found in the official guide:
Nexus is a framework consisting of roles, events, artifacts, and rules that bind and weave together the work of approximately 3 to 9 Scrum Teams, working on a single Product Backlog to build an Integrated Increment that meets a goal
Well, Scrum scaled up to 9 teams, with one Product Owner and one Backlog. Cool! Wanting to make a very short-list, these are the strengths I appreciate the most:
- Simple and Lean
- Backlog Refinement and Interdependence Management
- Obsessive focus on Integration
- Tangible set of Tools and Techniques
Simple and Lean
When you read the Nexus Guide and the book “The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams“, you will read statements like these ones: “Nexus is consistent with Scrum“, “Nexus uses Scrum as its building block“, “Nexus is 100% derived from Scrum“.
The first form of simplicity is that Scrum pervades everything . Indeed, it is used as it is by the agile teams forming the Nexus, with some minor adjustments to accommodate its process flow at a higher level. Additionally, the “new things” Nexus brings, are fully built on top of Scrum, too (roles, events, artifacts, etc.).
It’s Lean because it fully adheres to the 7 guiding principles of lean development:
- Eliminate Waste
- Build Quality In
- Create Knowledge
- Defer Commitment
- Deliver Fast
- Respect People
- Optimize the Whole
To make one example, the way the “new” Nexus events have been introduced, witnesses how the creators wanted to minimize overhead and any additional waste by 1) not adding too many new entities (role, rules, events, artifacts, etc.), 2) normalizing responsibilities about product backlog management (only one Product Owner), 3) finding synergies and lean methods to incorporate events at team and Nexus levels (diverging-converging approach, team representatives, etc.), 4) avoiding waste and reduce as much as possible quality problems by tightening the way the teams coordinate to integrate and create a product increment, through the formation of a semi-virtual agile team (Nexus Integration Team).
Backlog Refinement and Interdependence Management
Many teams fail because do not correctly take into account the strategic importance of backlog refinement.
Starting from the basics, the following text is what the official Scrum guide reports about the Backlog Refinement practice:
“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.“
As you can read, generic guidelines are given about its execution, leaving teams to decide when and how to do it. Of course the authors did not want to be too much prescriptive because of the complexity and differences among the multitude of organizations which would have had adopted Scrum.
But, a bit of realism is needed. When launching new teams, they will struggle a lot to fully understand, interpret and finally adopt it, as a routine activity.
This gets more and more arduous when, the work of several teams needs to be orchestrated to produce every two weeks something valuable and potentially shippable to clients. Well, Nexus placed Backlog Refinement in the front row when describing its process flow.
As you can appreciate at the top left corner of the above image, backlog refinement has finally its own official place! Nexus identifies two primary objectives teams need to achieve through this practice. Here below an excerpt:
Refinement of the Product Backlog at scale serves a dual purpose. It helps the Scrum Teams forecast which team will deliver which Product Backlog items, and it identifies dependencies across those teams. This transparency allows the teams to monitor and minimize dependencies.
From one side it guides the teams to decompose appropriately the backlog to make the whole Nexus being able to work and finish items within sprints. Additionally, it helps to make a forecast on what will be delivered in the next sprints.
(By the way, a small digression: in 2011, the Scrum Guide replaced the word “commitment” when selecting the backlog items during the sprint planning, with “forecast“. Here you can find an interesting, explanatory article which definitely sheds a light on this)
Back to Refinement.
Then, the inter-dependencies are addressed. Due to the important of this topic, it has been also developed accurately through another whitepaper developed by Scrum.org which you can find here:
The resulting cross-team refinement board is then reviewed and discussed every day, during the Nexus Daily Scrum.
Obsessive focus on Integration
The creators thought that, for integration stuff, coordination among teams would not be totally left to self-organization. Indeed, they identified the Nexus Integration Team (NIT) to be responsible for helping teams to integrate frequently, at least every sprint, into a common environment, where integration testing and acceptance can be performed.
That team is formed by people coming from other teams and any additional expert whose primary objective is to coach, support and help teams in integration (preferably not doing the work itself).
The new Nexus Daily Scrum anticipates the teams’ one on purpose: the most important thing, during that event, is to inspect the state of the integrated work, assess any issues and then have teams working actively on these, by addressing them in their Daily Scrum events.
The NIT team is also responsible to raise any technical and non-technical issue.
This means that NIT has also managerial responsibilities: if the whole Nexus, for instance, has problems with missing knowledge or expertise, NIT has the responsibility to understand how this knowledge can be shared between teams, arranging dedicated sessions or bringing on board new people to ease bottlenecks and problems.
A final, special, mention must be made to the Definition of Done (DOD). Having a clear and rigorous DOD is a fundamental pillar for integrating smoothly.
In Nexus, the DOD is defined by the NIT and inherited by the agile teams. Of course this is a collaborative effort but it ends with teams that cannot modify it, unless they want to make it even more rigorous.
Haven’t I told you about their obsession and stubbornness?! :o)
Tangible set of Tools and Techniques
Another interesting thing is that the authors, when explaining the framework and its elements, do suggest optional practices and techniques to better support the work of the Nexus.
Some of them are new, others are not. Among the others, you can find techniques for: Team Scaling, De-scaling, Backlog Refinement, Visual Management, Events Facilitation.
Here the comprehensive list of suggested Nexus Practices.
Conclusion
Addressing agile at scale with Nexus could be generally less mentally strenuous. This, per se, is a great advantage. But, actually, putting in place a framework, whatever it is, does not mean that we are scaling Agile, being Agile.
Relying on values and principles should always guide our behaviors and actions….but, yes, relying on a good framework is good starting point. :o)
Some thoughts on what could be some difficulties in applying it on the ground.
- Having just one Product Owner increases transparency, reduce misunderstandings. Even though the work a PO needs to do when teams are more than 3 or 4 is huge. In these cases you need to think on how to scaled Product Ownership while maintaining the PO accountable
- When under pressure, the NIT team could tend to do the work by themselves, instead of coaching and facilitating the teams.
- By mentioning the Definition of Done, Nexus helps in fully understanding its relevance and importance. Due to the fact that Nexus stresses a lot the Backlog Refinement practices, my expectation was that also the Definition of Ready would have been cited and addressed. Unfortunately it was not. A pity.
- Adhering and always stick 100% to integration practices is hard. It is not only about the discipline of the people involved in applying Nexus, several times it has to do with issues like environments stability, teams’ knowledge of specific sw-eng practices (e.g. Test-Driven Development, Code Refactoring, Continuous Integration, Coding Reviews, etc.), external dependencies, delivery pressure; this can hinder, at least during the very first sprints, the effectiveness of frequently creating an integrated potentially shippable increment. But, persisting is a good advice: “if it hurts do it more often“
Pubblicato da
