het Nexus Framework for Scrum Scrum in Software Development

Scrum, de meest voorkomende agile manier waarop software development teams werken, leidt tot de vraag: “hoe schalen we Scrum verder dan één team?’Als je problemen hebt met cross-team afhankelijkheden, risico’ s die van invloed zijn op meerdere teams, planning van leveringen, heb je misschien een scaling framework nodig.

u kunt meerdere scrumteams op veel verschillende manieren organiseren. In dit artikel gaan we dieper in op het Nexus framework voor het schalen van Agile en Scrum, gebaseerd op DevCom ‘ s ervaring. Er zijn andere kaders voor het schalen Agile zoals minder, veilig, DAD (gedisciplineerde Agile Delivery) en, maar ze zijn niet behandeld in dit artikel.

Wat is Nexus Framework?Nexus framework werd opgericht door Scrum co-creator Ken Schwaber en de Scrum.org team in 2015 als gids voor Scrum schalen in brede agile projecten.Aangezien Scrum een integraal onderdeel is geworden van veel organisaties, moeten hun projecten verder gaan dan de typische dagelijkse, plannings -, evaluatie-en Retro-vergadersessies die in de Scrum worden gebruikt om effectief te zijn. Scrum alleen is niet genoeg als meerdere teams aan een product werken. De productiviteit erodeert als gevolg van de afhankelijkheden tussen de teams.
Nexus framework gebruikt Scrum als bouwsteen en breidt het uit voor een beter beheer van meerdere scrumteams die aan één product werken. Nexus wordt toegepast op 3-9 scrum groepen en hen begeleiden over hoe ze moeten samenwerken, en delen werk om software te leveren in elke Sprint met minimale afhankelijkheden.

Hoe Schaalt Nexus Framework Scrum?

Scrum is een raamwerk van waaruit het proces evolueert. Het is gericht op hoe een enkel Scrum Team werkt aan een enkel product en software levert in kleine stappen. Het belangrijkste verschil tussen het Nexus framework en Scrum is de toevoeging van een integratieteam dat gericht is op het faciliteren van de afhankelijkheden tussen de teams.

Scrum Framework

(bron)

Nexus voor het schalen van agile

(bron)

Nexus-processtroom:

  1. verfijn de product achterstand.
  2. Nexus Sprint Planning.
  3. ontwikkelingswerkzaamheden.
  4. Nexus Daily Scrum.
  5. Nexus Sprint Review.
  6. Nexus Sprint Retrospective.

op het moment dat u de Nexus implementeert, zijn er geen significante veranderingen in Scrum fundamentals zelf. Nexus is vrijwel hetzelfde als het toevoegen van nieuwe praktijken aan Scrum, extra rollen, gebeurtenissen, en artefacten alleen waar dat nodig is om succesvolle initiatieven voor softwareontwikkeling mogelijk te maken. Nexus vergroot Scrum om Scrum effectief te laten schalen. Dit wordt bereikt door het stimuleren van rechtlijnigheid en transparantie door te werken vanuit een enkele product achterstand. Het belangrijkste is dat er meer aandacht wordt besteed aan afhankelijkheden tussen Scrum Teams, die verantwoordelijk zijn voor het leveren van “Done” stappen bij elke Sprint.

een definitie van “gedaan” is rigoureuze criteria die kunnen worden toegepast op de geïntegreerde Increment ontwikkeld elke Sprint, en die wordt gevolgd door alle Scrum Teams van een Nexus.

DevCom hoe Nexus Scrum uitbreidt

implementatie van Nexusraamwerk

het Nexusraamwerk veronderstelt Scrum-ervaring. Organisaties die al met Scrum werken, kunnen Nexus eenvoudig implementeren. Om een Nexus te starten, moeten organisaties eerst de teams in hun Nexus identificeren, een eerste Nexus integratie Team, een enkele product achterstand, een definitie van “gedaan”, een Sprint cadans.

Nexus implementatiestrategie

Definieer de Scrum teams (houd de focus op functies, in plaats van componenten). 1.1. Organiseer een vergadering en bepaal hoe teams worden gevormd;
1.2. Teamleden toewijzen (idealiter zelfgemaakte teams);
1.3. Definieer de belangrijkste speler(s)/vertegenwoordiger (s) van elk team.
Definieer de omgevingen en repo ‘ s voor ontwikkeling (gebaseerd op # van klanten(huurders) en toegangsniveau). 2.1. Maak een lijst met huidige repo’s;
2.2. Repo ‘ s reorganiseren en omgevingen herzien om de doorlooptijd van taken te verkorten;
2.3. Maak een gemeenschappelijke codebase (indien mogelijk);
Definieer het Nexus integratie Team (leden van Scrum teams. Kan variëren, afhankelijk van informatie die moet worden verspreid en opgelost als gevolg van Nexus Daily Scrum). 3.1. Definieer mensen die verantwoordelijk zijn voor integraties voornamelijk en afhankelijkheden resolutie;
3.2. Wijs de rol van een Scrum master toe binnen elk team.
leer en verklaar Scrum & Nexus framework. 4.1. Organiseer een vergadering voor alle Scrum teams en bekijk de basis;
4.2. Faciliteer vergaderingen waar nodig.
definieer tools om mee en binnen te werken. 5.1. Definieer productiviteit en project management tools om mee te werken en binnen en te integreren (set-up).
Definieer de “definitie van gedaan”. 6.1. Komen met de NIT overeen over de term;
6.2. Maak een formeel document aan.
definieer product achterstand / verfijn product achterstand met Product eigenaar (PO) of/en vertegenwoordigers. 7.1. Registreer functionele eisen met behulp van een van de bovenstaande gereedschappen;
7.2. Maak een sjabloon met verplichte velden die moeten worden ingevuld (bijvoorbeeld naam, beschrijving, acceptatiecriteria, beperkingen).
Geef de goedkeuring van de producteigenaar & laat haar de achterstand prioriteren. 8.1. Betrek PO om de achterstand weg te werken en te verfijnen;
8.2. Continue samenwerking met PO om te werken aan de product achterstand (schrijf verhalen, taken met behulp van een sjabloon 7.2).
organiseer NIT om de achterstand in te schatten met behulp van relatieve punten. 9.1. Houd het eerste deel van de vergadering om een schatting techniek te verwerven.
9.2. Houd een tweede deel van de vergadering om ruwe schattingen te maken voor Product backlog items (PBI ‘ s).
Implementeer Nexus Sprint Planning. 10.1. Definieer Sprint cadans;
10.2. Definieer afhankelijkheden, integratie problemen die kunnen verschijnen;
10.3. Te definiëren toepassingsgebied: ongeveer ten minste 2 Sprints vooruit en stroom;
10.4. Houd een vergadering om nit-leden te helpen met sprintplanning in teams.
implementeer sprintplanning binnen elk Scrum team. 11.1. Gebruik absolute schattingen voor taken en subtaken tijdens sprintplanning;
11.2. Vergemakkelijken Sprint planning voor elk team;
11.3. Maak een documentsjabloon.
implementeer Nexus Daily Scrum en Daily Scrum voor elk team. 12.1. Definieer de tijd, faciliteer Nexus Daily Scrum meetings (probeer ze in een Timebox te houden);
12.2. Definieer de tijd, faciliteer dagelijkse scrum vergaderingen (houd ze timeboxed).
implementeer Nexus Sprint beoordeling (max 4h). 13.1. Houd een Nexus Sprint Review (inclusief demo-opname indien nodig) met Scrum teamleden, PO, andere belanghebbenden.
implementeer Nexus Sprint Retrospective en Retrospective meeting voor elk Scrum team (Maak een document van sjablonen) (max 1h en 3h). 14.1. Een vergadering met terugwerkende kracht houden voor NIT;
14.2. Maak een sjabloondocument aan;
14.3. Faciliteer retrospectieve bijeenkomsten in Scrum teams.
14.4. Een sjabloondocument maken.
implementeer Nexus raffinement event op regelmatige basis van de product achterstand. 15.1. Definieer de frequentie (zo vaak als nodig; bijvoorbeeld 2t / week).
implementeer schatting in story points (afhankelijk van het PO-initiatief en de bereidheid om te voorspellen). 16.1. Volg scrum teams snelheid (na 3 Sprints);
16.2. Volg de voortgang met behulp van de sprint burndown grafiek.
implementeer visuele afhankelijkheden en hun voorspelling tussen taken. 17.1. Visualiseer afhankelijkheden tussen gebruikersverhalen, taken (bijvoorbeeld vlag en link);
17.2. Definieer afhankelijkheden voor de huidige Sprint en twee Sprints vooruit.
Start project management activiteiten om het project te ondersteunen. 18.1. Maak documenten die handig kunnen zijn (bijvoorbeeld Project Charter, Risk management Matrix, Stakeholder management, Team management (incl. Informatie over teamleden, schijftest, motivatietest, gezondheidscontrole van het team));
18.2. Definieer project KPI ‘ s en maak een sjabloon om ze te volgen. Meestal omvatten ze snelheid, Sprint burndown, CSAT. Andere kunnen begrotingsberekeningen omvatten;
18.3. Definieer rapporten voor projectgezondheidscontroles met PO en de belangrijkste belanghebbenden;
18.4. Bekijk de teststrategie binnen taken en flow (handmatig, unit tests, automatisering) als ze geen deel uitmaken van de standaard flow.
strategie om meer waarde te leveren en de resultaten te maximaliseren na het implementeren van de bovenstaande stappen (TBD). 19.1. Een vergadering houden met de belangrijkste belanghebbenden (PO, CEO anderen);
19.2. Verzamel en bespreek vereisten die aansluiten bij de bedrijfsstrategie.

Nexus-Teams

een Nexus-team bestaat uit ongeveer 3 tot 9 Scrum-Teams en een Nexus-integratieteam bestaande uit 1-2 leden van elk scrum-team die verantwoordelijk zijn voor het plannen van de visie op het totale product en het coördineren van de Teams.

het wordt aanbevolen teams te vormen op basis van de haalbaarheid. Feature teams maken het meest zinvol als ze kunnen werken op een product achterstand item.

echter, de huidige workflow leunt naar componentteams, wat kan leiden tot grotere afhankelijkheden onder hen. Om het risico te verminderen is het een geldig punt om teams die taken te delegeren die behoren tot andere dan hun component. Het proces van kennisuitwisseling zal in dit geval van essentieel belang zijn en het gebrek aan informatie bij integratie verminderen.

Nexus Integration Team (NIT) bestaat uit leden van:

  • ⇒ Product Owner-verantwoordelijk voor het maximaliseren van de waarde van het Product en om ervoor te zorgen dat het gecombineerde werk voltooid door een Nexus wordt geproduceerd ten minste eenmaal per Sprint.
  • ⇒ Scrum Master-verantwoordelijk voor Scrum teams die Scrum en Nexus correct uitvoeren en de door het ontwikkelingsteam geleverde waarde maximaliseren. Verantwoordelijk voor het leveren van “Done” stappen van potentieel releasable producten.
  • Development ontwikkelingsteam-verantwoordelijk voor het maken van geïntegreerde stappen die ‘gedaan’zijn. NIT zorgen dat de Scrum Teams binnen de Nexus begrijpen en implementeren van de praktijken die nodig zijn om afhankelijkheden te detecteren, en vaak integreren alle artefacten om de definitie van “gedaan.”

Nexus integratie Team rol:

  • ⇒ het Nexus Integration Team is verantwoordelijk voor het waarborgen van de definitie van “gedaan”.
  • Integrated geïntegreerde verhoging (het gecombineerde werk voltooid door een Nexus) wordt ten minste eenmaal per Sprint geproduceerd.
  • ⇒ de Scrum Teams zijn verantwoordelijk voor het leveren van “Done”.
  • ⇒ het NIT vormt een centraal punt van integratie voor de Nexus. Integratie omvat het oplossen van technische en niet-technische teamoverschrijdende beperkingen die het vermogen van een Nexus om een voortdurend geïntegreerde toename te leveren, kunnen belemmeren.
  • ⇒ het lidmaatschap kan in de loop van de tijd variëren, afhankelijk van de belemmeringen die de Nexus-ervaringen bieden.

teamleden moeten het maximale resultaat voor elke Sprint produceren. Een regelmatige gezondheidscontrole voor de Teams wordt aanbevolen, evenals voor software. Een keer per maand kan men een quick questionnaire houden om de productiviteit van de teams binnen elk Scrum team te monitoren.

vragen voor de teamleden:

  • ⇒ leveren ze waarde?
  • ⇒ is het product gemakkelijk vrij te geven?
  • ⇒ hebben teamleden plezier?
  • ⇒ Is het Product gezond?
  • ⇒ is het duurzaam en draagbaar?
  • ⇒ leren teamleden?
  • ⇒ begrijpen zij de productdoelstellingen?
  • ⇒ voelen ze zich pionnen of spelers?
  • ⇒ voelen zij zich eigenaar?
  • ⇒ is hun snelheid voldoende?
  • ⇒ zijn zij van mening dat zij een geschikt proces hebben?
  • ⇒ voelen zij zich ondersteund?
  • ⇒ werken ze goed als team?
  • ⇒ draagt het bedrijf bij aan de ontwikkeling van de werknemers?

DevCom Nexus Team Health Check

Nexus-Voorvallen

1.Verfijning

verfijning resulteert in een product achterstand die korrelig genoeg is voor Scrum teams om werk te trekken zonder onbeheersbare afhankelijkheden te creëren. Tijdens de verfijning moeten de Scrum teams zich richten op deze vragen:

  • ⇒ welk werk zal elk team doen?
  • ⇒ in welke volgorde moet dat werk worden gedaan om de grootste bedrijfswaarde op het vroegst te leveren, terwijl risico ‘ s en complexiteit worden geminimaliseerd?

Nexus Sprint Planning

Nexus Sprint Planning bestaat uit:

  • ⇒ valideren van product achterstand. De Scrum teams beoordelen de PBI ‘ s en maken de nodige aanpassingen die nodig zijn voor het werk van het raffinement event. Alle Scrum teams moeten deelnemen en bijdragen aan het minimaliseren van communicatieproblemen; echter, alleen de juiste vertegenwoordigers (degenen die denken dat ze een bijdrage kunnen leveren aan het verfijnen van de PBI ‘ s) van elk van de Scrum teams hoeven aanwezig te zijn.
  • Formulating het doel van de Nexus formuleren. Het Nexus-doel is een Sprint-doelstelling die wordt bereikt door de implementatie van PBI ‘ s door meerdere teams.
  • ⇒ Scrum Team Sprint Planning. Zodra de Nexus Goal voor de Sprint is begrepen, zal elk Scrum team zijn individuele Sprint Planning events organiseren waarin de leden hun eigen Sprint Backlogs creëren. Als ze afhankelijkheden identificeren met andere teams, werken ze met die teams om de afhankelijkheden te minimaliseren of te elimineren. De meeste sprintplanning duurt 8 uur.

in sommige gevallen betekent dit dat de volgorde van de werkzaamheden van de teams moet worden aangepast om het ene team zijn werk te laten afmaken voordat een ander team begint.

Nexus Daily Scrum

Nexus Daily Scrum meeting omvat de belangrijkste vragen:

  • ⇒ Was het werk van de vorige dag met succes geïntegreerd, en zo niet, waarom?
  • ⇒ zijn er nieuwe afhankelijkheden geïdentificeerd?
  • ⇒ welke informatie moet worden gedeeld tussen teams in de Nexus?

gewoonlijk wordt het op hetzelfde tijdstip en op dezelfde plaats gehouden.

Nexus Sprint Review

de Sprint Review bevat de volgende elementen:

  • ⇒ deelnemers zijn de Scrum-teams en de belangrijkste belanghebbenden die door de producteigenaar zijn uitgenodigd;
  • ⇒ de producteigenaar legt uit welke items met Productachterstanden zijn “gedaan” en wat niet “gedaan”;
  • ⇒ de ontwikkelingsteams bespreken wat goed ging tijdens de Sprint, welke problemen het opliep en hoe die problemen werden opgelost;
  • ⇒ de ontwikkelteams tonen het werk dat het heeft “gedaan” en beantwoorden vragen over de toename;
  • ⇒ de producteigenaar bespreekt de product achterstand zoals die er nu is. Hij of zij projecteert waarschijnlijke streefcijfers en leveringstermijnen op basis van de voortgang tot op heden (indien nodig);
  • ⇒ de hele groep werkt samen aan de volgende stappen, zodat de Sprint-evaluatie waardevolle input levert voor de daaropvolgende sprintplanning;
  • Review overzicht van hoe de Marktplaats of het potentiële gebruik van het product kan hebben veranderd wat het meest waardevolle is om vervolgens te doen;
  • Review overzicht van de tijdlijn, het budget, de potentiële mogelijkheden en de marktplaats voor de volgende verwachte releases van functionaliteit of mogelijkheden van het product.

het resultaat van de Sprint Review is een herziene product achterstand die de waarschijnlijke product achterstand items voor de volgende Sprint definieert. De product achterstand kan ook worden aangepast aan de nieuwe mogelijkheden.

deze activiteit mag niet langer dan 3 uur duren.

Nexus Retrospective Meeting

5.1. Nit retrospectieve

omdat er vaak schalen disfuncties, elke retrospectieve moet de volgende vragen te beantwoorden.

  • ⇒ hebben ze het doel van de Nexus gehaald? Zo niet, waarom niet?
  • ⇒ is er nog werk ongedaan gemaakt? Heeft de Nexus technische schulden gegenereerd?
  • ⇒ waren alle artefacten, met name code, vaak (idealiter continu) en met succes geïntegreerd?
  • ⇒ Was de software succesvol gebouwd, getest en vaak genoeg ingezet om de overweldigende accumulatie van onopgeloste afhankelijkheden te voorkomen?

wanneer problemen worden ontdekt, moeten de vertegenwoordigers:

  • ⇒ Waarom is dit gebeurd?
  • ⇒ Hoe kan het probleem worden opgelost?
  • ⇒ Hoe kan herhaling worden voorkomen?

na de retrospectieve Nexus-bijeenkomst is het belangrijk om de actiepunten te definiëren waaraan binnen alle Scrum-teams moet worden gewerkt. De NIT moet dergelijke items bijhouden en mag een onderstaande tabel gebruiken.

DevCom Nexus-Actiepunten

5.2. Scrum Teams Retrospective

elk Scrum team kan een board gebruiken om items te visualiseren waaraan gewerkt moet worden. Daarnaast is het raadzaam om formeel bij te houden van dergelijke records op een gestructureerde manier. Het duurt hooguit 4 uur om met de ploeg te bespreken hoe een Sprint verliep.

Scrum teams Retrospective

Product Owner

de Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product.

de eigenaar van het Product is de enige persoon die verantwoordelijk is voor het beheer van de product achterstand. Product Backlog management omvat:

  • ⇒ duidelijk Product Backlog items uitdrukken;
  • ⇒ de items in de Product Backlog bestellen om doelen en missies het beste te bereiken;
  • ⇒ de waarde optimaliseren van het werk dat het Nexus Team uitvoert;
  • ⇒ ervoor zorgen dat de Product Backlog zichtbaar, transparant en duidelijk is voor iedereen, en laat zien waar de Scrum teams aan zullen werken;
  • ⇒ zorg ervoor dat de Scrum teams de items in de product achterstand begrijpen tot het vereiste niveau;
  • Define Definieer het Nexusdoel voor elke Sprint (vergelijkbaar met mijlpaal).

de eigenaar van het Product kan het bovenstaande werk doen, of het Nexus-team het laten doen. De producteigenaar blijft echter verantwoordelijk.

Key Takeaways

  1. geschaald Agile werken, en het gebruik van een schalen framework helpen u om een snelle start.
  2. Scrum schalen is gewoon Scrum. Je verandert niet hoe je werkt als Scrum team noch verander je het werk dat wordt geleverd.
  3. door het Nexus framework bovenop Scrum toe te voegen, biedt het teams een manier om met teamoverschrijdende afhankelijkheden om te gaan en ervoor te zorgen dat ze allemaal samenwerken aan een gemeenschappelijk doel en productverhoging.
  4. Als u Scrum goed kent, is het Nexus framework het” no-brainer ” framework voor het schalen van softwareontwikkelingsteams, en u hebt misschien nooit iets anders nodig.
  5. Nexus is een nuttig discussiekader voor degenen die al verschillende scrumteams hebben die samenwerken.
  6. Als u uw proces wilt beschrijven, is het Nexus-framework een goed uitgangspunt, zodat u geen perspectieven mist.
  7. als het gaat om het schalen van agile, onthoud dan deze drie belangrijke dingen:
  • ⇒ Pas de methode aan op uw organisatie.
  • ⇒ voortdurend nadenken over de situatie.
  • ⇒ Verbeter de manier waarop u samenwerkt.

heeft u meer suggesties voor “beyond the team” – technieken? Wil je hulp bij het implementeren van deze ideeën? Sinds 2000 heeft DevCom Agile-methodologieën van de industriestandaard aangepast om tijdige, effectieve en efficiënte oplossingen te creëren om de doelen van onze klant te bereiken. Deze methodologieën vormen een iteratief ontwikkelingsmodel waarin de totale inspanning wordt opgesplitst in meerdere releases om de doelstellingen voor een bepaalde fase te bereiken. We leggen veel nadruk op drie elementen van de ontwikkelingscyclus: initiële projectbeoordeling en Planning, kwaliteit Projectmanagement, kwaliteitsborging.

onze ontwikkelingsaanpak vermindert projectrisico ‘ s en werkt aan het beheersen van time-to-market en budget. Die ervaring en kennis delen we met onze nieuwe klanten, zodat iedereen succesvol kan schalen.

haal betere resultaten door teamwork: neem vandaag nog contact met ons op bij DevCom!

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.