Het Nexus Framework uitgelegd

Door gebruik te maken van het Nexus Framework wordt een Scrum project vergroot door meerdere Development Teams in te zetten; dit gaat vanaf 3 tot maximaal 9 teams binnen één project. Binnen ieder Development Team 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 Development Teams

Vaak starten bedrijven met een kleine opzet wanneer zij met Scrum gaan werken. Een Scrum team bevat dat de Product Owner, Scrum Master en de leden van het Development Team. Echter als het project vele werkzaamheden bevat en de Product Backlog overloopt met taken, zullen meerdere Development Teams 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 Development Teams te laten werken aan hetzelfde project, kunnen deze teams worden gekoppeld aan dezelfde Product Backlog. 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 het sprint doel te behalen. De taken worden zo gedetailleerd mogelijk beschreven, zodat voor iedereen duidelijk is welk Development Team 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 Development Teams 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 het eigen Development Team: 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 Development Teams 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.

Rollen

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 Development Team; 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.