Het Nexus Framework uitgelegd

Door gebruik te maken van het Nexus Framework wordt een Scrum project vergroot door meerdere teams van Developers in te zetten; dit gaat vanaf 3 tot maximaal 9 teams binnen één project. Binnen ieder team van Developers wordt op de traditionele manier met Scrum gewerkt. Het Nexus Framework vult het werkproces daarbij aan. Belangrijk in deze werkwijze is dat leden van de Scrum teams initiatief tonen. In dit artikel wordt nader ingegaan op hoe dit proces in zijn werk gaat.

Niet één, maar meerdere teams van Developers

Vaak starten bedrijven met een kleine opzet wanneer zij met Scrum gaan werken. Een Scrum team bevat een Product Owner, Scrum Master en de Developers. Echter als het project vele werkzaamheden bevat en de Product Backlog overloopt met taken, zullen meerdere teams van Developers ingezet moeten worden. De oplossing kan dan gevonden worden in het Nexus Framework.

Uit de Scrum Guide komt naar voren dat slechts één Product Backlog zou moeten bestaan per project, waarbij het bijhouden en indelen van de Product Backlog onder de verantwoordelijkheid van een Product Owner valt. Indien de wens bestaat meerdere teams van Developers te laten werken aan hetzelfde project, kunnen deze teams worden gekoppeld aan dezelfde Product Backlog met één duidelijke Product Goal. Het is dan zaak de samenwerking van de verschillende teams goed te coördineren. De werkzaamheden van ieder afzonderlijke team moeten bijdragen aan het uiteindelijke sprint doel. Houd daarnaast eventuele problemen nauw in de gaten.

Onderdelen

Naast alle onderdelen van Scrum zoals beschreven in de Scrum Guide, hanteert het Nexus Framework nog extra onderdelen. Lees daar hieronder meer over.

Artefacten

Bij Scrum is er slechts één Product Backlog. Op de backlog worden de werkzaamheden genoteerd die nodig zijn om de Product Goal te behalen. De taken worden zo gedetailleerd mogelijk beschreven, zodat voor iedereen duidelijk is welk team van Developers aan het item zal gaan werken.

Vervolgens selecteert ieder Scrum team een aantal items waar zij de komende sprint aan zullen gaan werken. Alle items van alle teams worden verzameld op de Nexus Sprint Backlog. Op deze manier kan de gezamenlijke voortgang worden gevolgd en bijgewerkt, waardoor volledig overzicht wordt behouden.

Uiteindelijk worden alle uitgevoerde werkzaamheden samengebracht, zodat het één werkend deelproduct vormt. Dit wordt het geïntegreerd Increment genoemd. Alle onderdelen moeten voldoen aan de vooraf opgestelde Definition of Done. Dit zijn de kwaliteitseisen waaraan een deelproduct moet voldoen alvorens deze mag worden opgenomen in het geïntegreerd Increment. Ieder afzonderlijk Scrum team mag zijn eigen Definition of Done bepalen. De voorwaarde is dat deze minimaal de Nexus Definition of Done bevat.

Meetings

In het Nexus Framework worden alle meetings, zowel het aantal als de volgorde, overgenomen vanuit het Scrum Framework.

Allereerst komt het team bij elkaar voor de Nexus Sprint Planning. Tijdens deze meeting komen de vertegenwoordigers van alle teams van Developers en het Nexus Integration Team bij elkaar. In de meeting informeert de Product Owner de teams welke taken als eerste opgepakt dienen te worden in de eerstvolgende sprint. Hierop volgend wordt een Nexus Sprint doel gemaakt, zodat alle teams het doel duidelijk voor ogen hebben. Ieder Scrum team creëert hierna zijn eigen Sprint planning en Sprint Backlog.

Na aanvang van de sprint vindt iedere dag op een vast tijdstip de Nexus Daily Scrum plaats. Alle vertegenwoordigers komen bij elkaar om het verloop van de werkzaamheden te bespreken, met het oog op het Sprint doel.

In deze meeting komen altijd deze drie vragen aan bod:

  • Welke informatie moet worden gedeeld met de Nexus teams?
  • Is het werk van de afgelopen 24 uur succesvol verwerkt?
  • Welke nieuwe afhankelijkheden zijn duidelijk geworden?

In deze meeting wordt ook de Nexus Sprint Backlog bijgewerkt. Vervolgens spelen de vertegenwoordigers deze informatie door naar de eigen Developers: ieder team organiseert tevens zijn eigen Daily Scrum.

Bij de Nexus Sprint Review meeting bestaat een groot verschil met de Sprint Review zoals we die kennen uit het Scrum Framework. In het Nexus Framework worden geen individuele resultaten besproken, slechts het geïntegreerde Increment wordt aan de stakeholders getoond ter feedback. In de aparte teams van Developers wordt dus geen eigen Sprint Review georganiseerd.

Afsluitend wordt de Nexus Sprint Retrospective behandeld in drie onderdelen. In de eerste fase komen alle vertegenwoordigers bij elkaar ter bespreking van welke zaken wel, of juist niet, goed gingen tijdens de afgelopen sprint.

Meer weten over de Sprint Retrospective in het Scrum Framework? Bekijk dan onze animatie video.

In fase twee plannen alle individuele Scrum teams een eigen Sprint Retrospective in, waarbij het presteren van de eigen teamleden wordt geëvalueerd. Hierna komen in fase drie alle vertegenwoordigers nogmaals bij elkaar om de uitkomsten en actiepunten van de afzonderlijke meetings door te nemen.

Verantwoordelijkheden

In dit framework wordt er één Nexus Product Owner aangewezen. Deze heeft dezelfde verantwoordelijkheden als een traditionele Product Owner uit het Scrum Framework. Denk hierbij aan het maximaliseren van de waarde van de Nexus Product Backlog.

Het Nexus Integration Team draagt verantwoordelijkheid voor het integreren en verwerken van de afhankelijkheden. Onder dit team vallen de Scrum Master, Product Owner en verschillende teamleden. De teamleden mogen tevens lid zijn van een team van Developers; onder de voorwaarde dat de taken in het Nexus Integration Team altijd voorrang krijgen. Daarnaast mag ook de Scrum Master werkzaam zijn bij een ander Scrum team. Net als bij Scrum is deze persoon ook in het Nexus Framework verantwoordelijk voor het proces.

Heb je hulp nodig om het Nexus Framework toe te passen in jouw bedrijf? Neem dan contact met ons. Wij helpen je met een Nexus Framework brainstormsessie.

Ook interessant:

Of deel deze blog in je netwerk.
[addtoany]