Nexus is structured more carefully here: there should be a maximum of 9 teams with 90 people - ideally even fewer. It is not specified where the teams come from and scaling Nexus to Nexus+ with several hundred people should be very, very well considered and is also rarely used.
The core element of Nexus is the Nexus Integration Team (NIT). The NIT solves problems on a scaled level in a separate daily, which takes place before the actual team dailies. The rule of thumb is that the overall system should be optimised first before moving on to the subsystems of the teams. The NIT is also concerned with identifying dependencies and eliminating them where possible. This is visualised above all by the Nexus Sprint Planning Board. This is not Kanban, but serves exclusively to track dependencies. Other tasks are the coaching aspect, which favours knowledge transfer, and overall end-to-end testing. This is to be done by the teams themselves and only care is taken that this happens. The most competent people for the current situation are in the NIT. Conversely, this means that other people could be on site every day besides the PO.
In SAFe, these competences are addressed by the ART Sync once a week or there is a separate System Team for Overall End-to-End Testing. The establishment of these institutions is the responsibility of the Chief Scrum Master, who is called the Release Train Engineer. The teams themselves can of course coordinate their dependencies with each other at any time. These are visualised by the ART Planning Board. The core elements of SAFe are, in a broader sense, the four Core Values (Alignment, Transparency, Respect for People, Relentless Improvement) from which actions can be derived.
Communities of Practice (CoPs) are not directly mentioned in Nexus. However, they are taken into account and implicitly given space. In SAFe they are advocated from the beginning and used in more detail, especially in the Advanced Scrum Master course.
At the end comes the most interesting aspect of Nexus – Descaling! That's right, Nexus does not advocate further scaling above a certain size, but the opposite: a team should be taken out of the Nexus again. This is derived from the "law of diminishing returns", because Value does not grow proportionally with each team, but becomes more and more expensive. Therefore, one can certainly dare to experiment and add an additional team. However, you should then also have the courage to withdraw it again if necessary. Scaling must make sense, and that is the beauty of the Nexus.
Understanding Nexus
from a SAFe perspective
Understanding Nexus from a SAFe perspective
In this short article, I would like to introduce you to the Nexus Framework. The blog article is aimed primarily at those who work primarily with SAFe - it should be said at the outset that both frameworks have their raison d'être. As always, it depends!
First of all, SAFe aims to optimise the entire organisation. Top management is convinced and involved and there is a focus on leadership at all levels! Furthermore, several products can be coordinated and scaled via a portfolio level. The picture is rounded off by SAFe's own principles, which are based on the principles of the Agile Manifesto, among others.
In contrast, Nexus first scales a product and tries to optimise it further and further, and with it the teams within it in the next step. Interesting for daily business is the Nexus Guide, which gives a purpose for each event (planning, retro etc.). Everything can be derived from the purpose in a very "lean" way. Leadership is not the focus and does not form an ideological foundation. Here we refer to a separate Scrum.org course.
With regard to the different philosophies, it can be stated that SAFe represents the maximum of a scaled toolbox. Initially, elements have to be eliminated that can gradually be lived in the framework. The initial setup is very extensive and includes, for example, an overall end-to-end integration by a system team, DevOps including CI/CD pipeline, OKRs, Large Solutions, Design Thinking, Value Stream Identification etc.
In contrast, Nexus outlines the minimum of a toolbox to be able to scale a product. So it includes things that are necessary for survival, e.g. cross-team refinement at product level, Nexus Sprint Planning and a Product Owner. What else is to be added is up to the users themselves.
And this brings us to the key role in every scaled framework - the product owner! It is important to understand that there is always only one product owner, regardless of whether he or she is called Product Manager, Chief Product Owner or Master of the Universe. The product owner is the one who has the overall responsibility, holds his head down and has budget. In the SAFe context, this is the product manager with the most competence. However, it is questionable whether he can dispose of budget or whether it is allocated to him at portfolio level by the business owner. The SAFe POs at the tactical team level support the product manager(s). They should be seen as support so that the role scales.
Nexus decides very clearly: there is a PO and end. However, support must also be created informally. So people from the teams have to support the PO. However, the Scrum or Nexus Guide does not care what their role is called.
How many teams are there now? SAFe recommends a maximum of 125 people. It doesn't matter how many people are outside the teams at the product level. The teams come from different silos within a larger organisation and the Value Stream is meant to break through these silos.
Autor
Kontaktiere uns
Contact
Martin Brösamle
Head of Sales and Marketing
Balanstr. 73, House 19 81541 Munich
E-Mail: info@eggs.de Headquarter: +49 (89) 743456-0