Nexus is een eenvoudige scaling methode van Scrum voor ca. 3 tot en met 9 teams. Het doel van Scrum Nexus is om de productiviteit te verhogen door onderlinge afhankelijkheden te verkleinen. Een Nexus focussed zich op goed samenwerken en bestaat uit een Nexus Integration Team en ca. 3 tot en met 9 teams.
Nexus is dus een eenvoudig scaling framework dat bestaat uit rollen, gebeurtenissen, artefacten en technieken die het gezamenlijk werk verbinden en verweven. Meerdere Teams werken aan één Product Backlog om een gezamenlijk Increment elke Sprint te kunnen opleveren om een gezamenlijk doel te bereiken.
Het Nexus framework kan je het beste beschouwen als een toevoeging, een soort overlay, op het bestaande Scrum framework. Veel zaken blijven dan ook ongewijzigd, zoals dat de teams gewoon via de reguliere scrum principes blijven werken. Op een aantal belangrijke aspecten wijkt het echter af. Het belangrijkste verschil is dat er veel meer aandacht word besteed aan afhankelijkheden en samenwerking tussen Scrum Teams.
Wat je vast ook al direct wilt weten is dat het Nexus scaling framework niet vraagt om een wijziging in de organisatiestructuur. Dit kan wel, maar is geen vereiste. Dit in tegenstelling tot andere scaling methodes, zoals bijvoorbeeld het SAFe framework.
Een volledig en uitgebreide beschrijving vindt je in de Nexus Guide. Dit artikel is een beschrijving van het Nexus Framework en een samenvatting van de belangrijkste veranderingen t.o.v. het Scrum Framework.
Ben je nog niet op de hoogte hoe het volledige Scrum framework in elkaar zit? Dan verwijs ik je naar het artikel Scrum framework.
Waarom Scrum Nexus?
Een van de bedenkers van Scrum (Ken Schwaber) heeft samen met scrum.org een methode bedacht om meerdere Scrum teams met elkaar beter te laten samen werken. De methode Scrum of Scrums werkt vanzelfsprekend ook, maar met Scrum Nexus is verdere opschaling mogelijk.
Opleveren van een geïntegreerd stuk werk is het bewezen succes van Nexus. Het is de verantwoordelijkheid van de Nexus integratieteam om alle Nexus teams de juiste tools, richtlijnen, support en/of al het andere wat de team nodig hebben om hun (software) integratie succesvol te laten zijn.
Dagelijks wordt de voortgang van meerdere teams besproken. De verkregen informatie is input voor de Scrum teams die ook dagelijks plannen.
Rollen in de Nexus
Nexus Integration Team
Laat ik beginnen met de kern van het Nexus framework. Het Nexus Integration Team bestaat uit:
- De Product Owner
- Scrum Master en
- één of meer Nexus Integration Teamleden
Het doel van het Integration Team is om al het werk te coördineren van alle Scrum teams. Het werk kan dan worden samengevoegd zonder conflicten. De noodzaak van een Integration Team wordt steeds groter naarmate er meer teams aan dezelfde Product Backlog werken
Product Owner in het Nexus Integration Team
De Product Owner is lid van het Nexus Integration Team en is verantwoordelijk voor het maximaliseren van de waarde van het geïntegreerde op te leveren werk (integrated increment) door het beheren van de Product Backlog.
Scrum Master in het Nexus Integration Team
Het Nexus framework (laten) begrijpen en juist (laten) uitvoeren. Overigens kan deze Scrum Master ook een rol hebben in één of meerdere teams in de Nexus.
Nexus Integration Teamleden
De Nexus Integration Teamleden dragen zorg voor de Definition of Done, begeleiden en coachen de Scrum teams in een Nexus. Zowel op praktijken en tools, maar ook met standaardontwikkeling, infrastructuur en architectuur. Als aan voorstaande voorwaarden is voldaan, mogen ze ook werken als teamleden in één of meer Nexus Scum Teams.
Artifacten voor het Nexus Framework
T.o.v. het standaard Scrum Framework zijn de volgende artifacten anders:
- één Nexus Product Backlog voor alle teams, met een Nexus Product Owner voor de prioritering.
- een ‘eigen’ Sprint Backlog voor elk Scrum team. Die een afgeleide is van de gekozen Stories van de Nexus Product Backlog.
- de Nexus Sprint Backlog is de samengevoegde individuele Sprint Backlog. Het is het totale plan voor de Sprint, die helpt om alle afhankelijkheden tussen Scrum teams inzichtelijk te maken.
- Daarnaast is een geïntegreerde Definition of Done: de Nexus Sprint Goal. Scrum Teams in de Nexus mogen een strengere definitie van DoD hanteren, maar zeker geen lichtere versie.
Refinement
Refinement is een bekende activiteit binnen het Scrum Framework. Voor de Nexus geldt dat naast dat er bepaald gaat worden welke items geleverd zullen worden, ook de afhankelijkheden moeten worden geïdentificeerd.
Nexus Sprint Planning
Het coördineren van alle activiteiten van alle Scrum teams in een Nexus voor de komende Sprint.
Het Nexus Sprint Goal
Het Nexus Sprint Goal komt voort uit de Sprint Planning.
Als het totale werk van de Nexus wordt begrepen, gaat de Nexus Sprint Planning verder. Men gaat verder met het uitvoeren van de eigen Sprint Planning door ieder Scrum Team.
Overige activiteiten
De overige activiteiten tijden de Nexus Sprint Planning lijken sprekend op een ‘gewone’ Sprint Planning. Hier is het vooral waakzaam blijven op nieuwe afhankelijkheden die zichtbaar worden en nog tijdens de Nexus Sprint Planning geminimaliseerd moeten worden.
Nexus Daily Scrum
In tegenstelling tot een ‘gewone’ Daily Scrum wordt er door vertegenwoordigers van de teams de status van het increment beoordeeld. De focus ligt op het bespreken en oplossen van integratie issues en team overstijgende afhankelijkheden.
Wat wel echt anders is t.o.v. Scrum dat er 3 nieuwe vragen zijn:
- Was het werk van de vorige dag succesvol geïntegreerd. Zo nee, waarom niet?
- Welke nieuwe afhankelijkheden zijn geïdentificeerd?
- Welke informatie moet gedeeld worden met de team in de Nexus?
Issues en werk worden daarop meegenomen naar de individuele teams.
Nexus Sprint Review
De Nexus Sprint Review vervangt de Sprint Reviews van individuele Scrum Teams. Stakeholders geven feedback op het volledige integrated increment. Niet al het werk wordt in detail getoond. Het resultaat van de Nexus Sprint Review is een gereviseerde Product Backlog.
Nexus Sprint Retrospective
De Nexus Sprint Retrospective vindt plaats na de Nexus Sprint Review en voor de volgende Nexus Sprint Planning.
De Nexus Sprint Retrospective is net als een ‘normale’ Retrospective bedoelt om als team het eigen handelen te bespreken, verbeter mogelijkheden te bespreken en deze mee te nemen naar de volgende Sprint. Het grote verschil bij Nexus is echter de omvang en er zijn andere vragen te stellen.
Nexus Sprint Retrospective bestaat uit 3 onderdelen:
- Vertegenwoordigers uit heel de Nexus ontmoeten elkaar en identificeren issues die impact hadden op meer dan één team. Het doel is om gedeelde issues transparant te maken voor alle Scrum Teams.
- Het houden van eigen Sprint Retrospectives door ieder Scrum Team. Issues uit het eerste deel van de Nexus Sprint Retrospective kunnen worden gebruikt als input voor discussies binnen hun teams. De individuele Scrum Teams zouden acties moeten formuleren om de issues te adresseren tijdens hun eigen Sprint Retrospectives.
- Vertegenwoordigers van de Scrum Teams ontmoeten elkaar opnieuw en komen met elkaar overeen hoe geïdentificeerde acties zichtbaar gemaakt en gevolgd kunnen worden. Hierdoor is de Nexus als geheel in staat om zich aan te passen.
Zoals je zult begrijpen hebben veel problemen met scaling te maken, maar hier gaat het ook om de inhoud. Idealiter worden de volgende onderwerpen tijdens elke Retrospective behandeld:
- Is er werk niet gedaan? Heeft de Nexus technical debt gegenereerd?
- technical debt: extra werk ontstaan door het implementeren van een kortetermijnoplossing in plaats van de beste oplossing.
- Zijn alle artefacten, en in het bijzonder code dagelijks succesvol geïntegreerd?
- Is de software succesvol gebouwd, getest en vaak genoeg uitgerold om onopgeloste afhankelijkheden te voorkomen?
Bespreek indien nodig voor elk van bovenstaande vragen:
- Waarom is dit gebeurd?
- Hoe maak je de technical debt ongedaan?
- Hoe voorkom je herhaling?
Uit bovenstaande blijkt duidelijk dat de scrum value transparantie een belangrijk aandeel heeft in het Nexus Framework.
Samenvatting
Nexus is een effectieve manier om Scrum op te schalen. Het is ontwikkeld door de founders van Scrum. Het introduceert een aantal nieuwe concepten waarmee teams geholpen worden om effectief te kunnen opschalen. Groeien met meerdere teams is mogelijk, maar toch zijn de voorschriften zo beperkt mogelijk gebleven. Net als Scrum.
‘Scrum is simple, but hard’
Bovenstaande is een vaak gehoorde uitdrukking. Het Scrum framework is relatief simpel, maar het echt goed toepassen is een uitdagende klus.
Net als Nexus. Het framework is verrassend simpel, maar het is een uitdaging om met meerdere teams een gezamenlijk increment op te leveren. Met een focus op continuous improvement, excellente vaardigheden en hard werken is het mogelijk.
Tot slot
Alleen als het Nexus raamwerk, met alle Nexus rollen, artefacten, gebeurtenissen en regels wordt gehanteerd is het volgens de bedenkers een Nexus.
Scrum.org heeft een Nexus examen beschikbaar. Bij het behalen van het examen ontvang je het certificaat: Scaled Professional Scrum (SPS). Ik heb dit certificaat behaald. Goed inzicht in de verschillen en overeenkomsten met het reguliere Scrum framework is verstandig! Naast feitelijke kennis over het Nexus framework.
Een ander scaling framework gebaseerd op Scrum is LeSS.