DevOpsNexus Framework – Scaled Professional Scrum

Nexus Framework - Scaled Professional Scrum

Bij Delta-N maken we al jaren gebruik van Scrum als agile methodiek. Een waardevolle aanpak die ruimte biedt aan innovatie en creativiteit, maar voldoende regels kent om te voorkomen dat het een chaos wordt. Scrum is echter gericht op de samenwerking binnen een team, terwijl software producten vaak door meerdere teams ontwikkeld worden. Er zijn een aantal frameworks die handvatten bieden voor samenwerking tussen teams. In dit blog behandelen we het Nexus Framework van Scrum.org.

Meerdere Scrum teams

Zodra er meerdere Scrum teams aan een software product werken, is er afstemming nodig tussen de teams. Een Product Owner verwacht één geïntegreerd eindproduct en niet een aantal deels op elkaar afgestemde deelproducten. Laat je deze afstemming volledig aan de teams zelf over, dan bestaat de mogelijkheid dat er niet voldoende of zelfs geen afstemming plaatsvindt.

Self organizing

Waarom zijn er regels nodig om de afstemming tussen Scrum teams te regelen? De teams zijn toch self-organizing, waarom teams onderling dan niet?

Het binnen Scrum gebruikte Tuckmans model voor groepsvorming benoemt een aantal stadia (forming-storming-norming-performing). Hoewel het Scrum Framework het snel doorlopen van deze fasen stimuleert, is een groep pas in de vierde fase een performing team. Regels zoals een dagelijkse afstemming tussen de teamleden (daily stand up) zorgen voor duidelijkheid. Deze openheid zorgt voor duidelijkheid en zal het team eerder uit conflict stadium halen. Ook bij de samenwerking tussen teams is er behoefte aan handvatten die zorgen voor duidelijkheid, waardoor mogelijke miscommunicatie zo veel mogelijk wordt voorkomen en beslissingen eerder genomen kunnen worden. Deze regels moeten richting geven, maar wel zo flexibel zijn dat de rest van de aanpak door teams samen verder in te vullen is. Het team is immers self-organizing. Een voorbeeld van een afspraak die noodzakelijk is bij ontwikkelen met meerdere teams, is dat de status van afhankelijke PBI’s continue transparant is en de afhankelijkheden zo minimaal mogelijk worden gemaakt.

Het Nexus Framework

Het Nexus Framework is ontwikkeld door Scrum.org om handvatten te geven in de situaties waarbij 3 tot 9 Scrum teams samen werken aan één product.

Nexus heeft, in onze ogen, als doel om alle voordelen die het Scrum framework individuele teams biedt, te behouden. Maar tegelijkertijd richting te geven aan de samenwerking tussen teams die samen één product ontwikkelen. Waar het Scrum framework ‘guidance’ biedt binnen het team, is het Nexus framework gericht op guidance over de teams heen.
Het Nexus framework ligt zodoende over het Scrum framework heen, een aanvulling dus. Het voegt een extra rol, een extra artifact en extra events toe aan het Scrum Framework.

 

Nexus Integratie Team

De extra rol is het Nexus Integratie Team (NIT). Het NIT is geen apart team, maar wordt gevormd door leden van de individuele Scrum teams. Alle Scrum teams  (+ de proces bewaker (SM) en voice van het product (PO) worden door minimaal één persoon vertegenwoordigd.

Doordat het NIT gevormd wordt door leden uit de teams, is er een natuurlijke vorm van acceptatie van het werk van en de beslissingen van deze groep. De praktijk zal uitwijzen wat op welk moment een handige samenstelling is (common practice), maar hoe groter een NIT hoe meer communicatielijnen en kans op miscommunicatie.
Het NIT is verantwoordelijk voor de oplevering van één geïntegreerd increment aan het einde van de Sprint en faciliteert de individuele teams daarin. Daarnaast lijkt ook het facilteren van zaken waar alle Scrum teams voordeel van hebben een taak voor het NIT. Zoals bijvoorbeeld het faciliteren van uniforme style en user-interaction en de gebruikte ALM tooling.

Nexus Sprint Backlog

De Nexus Sprint Backlog is niets anders dan de gecombineerde Sprint backlogs van de individuele teams, gefocust op de afhankelijkheden. De Nexus Sprint Backlog bevat ook werk voor het NIT. De items in de Nexus Backlog hebben een hogere prioriteit dan het werk van de individuele Scrum teams.
Tijdens de Nexus Sprint Planning wordt ook een Nexus Sprint Goal vastgesteld. Zodoende weten alle teams wat het te realiseren grotere plaatje is voor de Sprint. Het uitspreken van een gemeenschappelijk doel leidt tot team building en zorgt voor een natuurlijke borging van verantwoordelijkheid.

Het NIT stelt ook een Definition of Done (DoD) op. Ieder Scrum team mag hun eigen DoD opstellen maar deze moet minimaal de gemeenschappelijke DoD bevatten. De gemeenschappelijke definitie zal natuurlijk integratie afspraken bevatten, zoals ‘alle code wordt elke dag voor de nightly build ingechecked’. DoD moet uiteindelijk zorgen voor een bruikbaar en geïntegreerd increment voor de Product Owner.

Nexus events

De Scrum events zijn ook aangevuld met vier extra Nexus events; Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review en Nexus Sprint Retrospective. De Nexus events hebben tot doel de individuele Scrum events te faciliteren.
• De Nexus Sprint Planning is een container met de Scrum planning van de individuele teams. De Nexus Sprint Planning is aanvullend op de Sprint planningen en heeft tot doel de de onderlinge afhankelijkheden tussen de teams inzichtelijk te maken. De Nexus Sprint Backlog is de manier om dit zichtbaar te maken. In Scrum scaling oefeningen hebben wij ervaren dat met pijltjes op Backlog Items je de afhankelijkheden heel goed visueel inzichtelijk kunt maken.
De Nexus planning kan pas gedaan worden als alle individuele Sprint planningen afgerond zijn, zodoende wordt de Nexus planning dus als een container gezien. Een voorbeeld: De ontwikkeling van een routeplanningsproces is afhankelijk van de te ontwikkelen functie ‘vastleggen bezoekadressen’. Beide functies zouden door verschillende Scrum teams in dezelfde sprint opgepakt kunnen worden, mits in de Nexus planning dit duidelijk wordt en onderling wordt afgestemd.
• De Nexus Daily Scrum is een dagelijks inspectie moment, waarin 3 vragen beantwoord worden. Is het werk van voorgaande dag succesvol geïntegreerd? Zijn er nieuwe afhankelijkheden? En, welke informatie moet tussen de teams worden gedeeld? Omdat elk team via een individu in het NIT zit, is elk team vertegenwoordigd voor de nodig afstemming.
• De Nexus Sprint Review vervangt de Scrum Review van de individuele teams. Alle Scrum teams zijn bij deze ene grote Nexus Review. Het is logisch dat er één review is. Het gaat de Product owner en de stakeholders uiteindelijk om het geïntegreerde increment en niet de losse increments van individuele Scrum teams.
• De Nexus Sprint Retrospective is gericht op procesverbetering en net als de Nexus Sprint Planning, een container. Een voorbeeld; misschien ‘werkt’ de afstemming tussen de teams door de NIT niet vlekkeloos (transparantie) en kan dit door te bespreken (inspectie) leiden tot acties (adoptie).

Bij de Nexus event gaat het, net als in de individuele Scrum events, om transparantie, inspectie en adoptie. Bij Nexus events gaat het echter om integratie / Scrum team gemeenschappelijke zaken.

Het heeft even geduurd om het Nexus te leren begrijpen en een plaats te geven naast alle andere Scaling frameworks als LeSS en SAFe. Nexus is, net als het Professional Scrum framework, gericht op personen, proces en product en borduurt verder op de pijlers Transparantie, Inspectie en Adoptie. Het Nexus framework is daarom voor mij logisch en nodig. In de praktijk kunnen wij ons voorstellen dat er aanvullende scaling practices, technieken en tools gebruikt worden. Op het gebied van ALM zien wij vele mogelijkheden. Mooi om als Delta-N daar bijdrage aan te mogen geven!

Meer weten

Er is meer geschreven over Nexus Framework. De Nexus Guide van Scrum.org is gratis te downloaden, er zijn verschillende blogs, video’s en natuurlijk de Scrum.org SPS workshop. Wij raden een ieder die te maken heeft met meerdere scrum teams die aan één product werken, aan om zich verder in Nexus te verdiepen en de workshop te volgen.

Roderick Schoon, Development Manager en Professional Scrum Trainer
Marcel Groennou, Scrum Master