Nexus Framework for Scaling Scrum in Software Development

Scrum, som är det vanligaste agila sättet, som mjukvaruutvecklingsteam arbetar, leder till frågan om ‘ hur skalar vi Scrum bortom ett enda team?’Om du har problem med lagöverskridande beroenden, risker som påverkar flera lag, schemaläggning av leveranser, kan du behöva en skalningsramverk.

du kan organisera flera Scrum-team på många olika sätt. I den här artikeln kommer vi att fördjupa Nexus-ramverket för skalning av Agile och Scrum, baserat på Devcoms erfarenhet. Det finns andra ramar för skalning Agile som mindre, säker, pappa (disciplinerad Agile leverans) och, men de är inte omfattas av den här artikeln.

Vad är Nexus Framework?

Nexus framework grundades av Scrum medskapare Ken Schwaber och Scrum.org team i 2015 som en guide för skalning Scrum i omfattande agila projekt.
eftersom Scrum har blivit en integrerad del av många organisationer måste deras projekt gå utöver de typiska dagliga, planerings -, gransknings-och Retro-mötessessionerna som används i Scrum för att vara effektiva. Scrum ensam räcker inte när flera team arbetar med en produkt. Produktiviteten eroderar på grund av beroendet mellan lagen.
Nexus framework använder Scrum som byggsten och utökar det för bättre hantering av flera Scrum-team som arbetar med en enda produkt. Nexus tillämpas på 3-9 scrum grupper och vägleda dem om hur de måste samarbeta, och dela arbete för att leverera programvara i varje Sprint med minimala beroenden.

Hur Nexus Framework Skalar Scrum?

Scrum är ett ramverk som utvecklar processen. Det är inriktat på hur ett enda Scrum-Team arbetar på en enda produkt och levererar programvara i små steg. Huvudskillnaden mellan Nexus framework och Scrum är tillägget av ett integrationsteam som fokuserar på att underlätta beroendet mellan lagen.

Scrum Framework

(källa)

Nexus för scaling agile

(källa)

Nexus processflöde:

  1. förfina produktbackloggen.
  2. Nexus Sprint Planering.
  3. utvecklingsarbete.
  4. Nexus Dagliga Scrum.
  5. Nexus Sprint Recension.
  6. Nexus Sprint Retrospektiv.

när du implementerar Nexus finns det inga signifikanta förändringar i Scrum fundamentals själv. Nexus är ungefär detsamma som att lägga till nya metoder för Scrum, ytterligare roller, händelser och artefakter endast där det behövs för att möjliggöra framgångsrika programutvecklingsinitiativ. Nexus förstärker Scrum för att tillåta Scrum att skala effektivt. Detta uppnås genom att öka enkelhet och öppenhet genom att arbeta från en enda produktbacklog. Det som är viktigt är att mer uppmärksamhet ägnas åt beroenden mellan Scrum-Team, som ansvarar för att leverera “färdiga” steg vid varje Sprint.

en definition av” Done ” är rigorösa kriterier som kan tillämpas på den integrerade inkrementet som utvecklas varje Sprint, och som följs av alla Scrum-Team i en Nexus.

DevCom hur Nexus utökar Scrum

Nexus Framework Implementation

Nexus framework förutsätter Scrum erfarenhet. Organisationer som redan arbetar med Scrum kommer att kunna implementera Nexus enkelt. För att starta en Nexus bör organisationer först identifiera lagen i deras Nexus, ett första Nexus-Integrationsteam, en enda produktbacklog, en definition av “klar”, En Sprintkadens.

Nexus implementeringsstrategi

definiera Scrum-teamen (håll fokus på funktioner snarare än komponenter). 1.1. Håll ett möte och definiera hur man bildar lag;
1.2. Tilldela teammedlemmar (helst självgjorda lag);
1.3. Definiera nyckelaktör(er) / representant (er) från varje lag.
definiera miljöer och repor för utveckling (baserat på antal kunder(hyresgäster) och åtkomstnivå). 2.1. Gör en lista över aktuella repor;
2.2. Omorganisera repor och granska miljöer för att förkorta ledtiden för uppgifter;
2.3. Gör en gemensam kodbas (om möjligt);
definiera Nexus Integration Team (medlemmar i Scrum teams. Kan variera beroende på information som ska spridas och lösas som ett resultat av Nexus Daily Scrum). 3.1. Definiera personer som är ansvariga för integrationer huvudsakligen och beroenden upplösning;
3.2. Tilldela rollen som en Scrum master inom varje lag.
Lär och förklara Scrum & Nexus framework. 4.1. Håll ett möte för alla Scrum-Team och granska grunderna;
4.2. Underlätta möten vid behov.
definiera verktyg att arbeta med och inom. 5.1. Definiera produktivitets-och projekthanteringsverktyg för att arbeta med och inom och integrera (konfigurera).
definiera “Definition av gjort”. 6.1. Håller med NIT på termen;
6.2. Skapa ett formellt dokument.
definiera produktbacklog / förfina produktbacklog med produktägare (po) eller/och reps. 7.1. Registrera funktionskrav med hjälp av något av verktygen ovan;
7.2. Skapa en mall med Obligatoriska fält som ska fyllas i (t.ex. namn, beskrivning, acceptanskriterier, begränsningar).
få produktägarens godkännande & låt henne prioritera eftersläpningen. 8.1. Involvera PO att bruka och förfina eftersläpningen;
8.2. Kontinuerligt samarbete med PO att arbeta på produktbacklog (skriva berättelser, uppgifter med hjälp av en mall 7.2).
organisera NIT för att uppskatta eftersläpning med hjälp av relativa punkter. 9.1. Håll den första delen av mötet för att förvärva en uppskattningsteknik.
9.2. Håll en andra del av mötet för att göra grova uppskattningar för Produktbackloggposter (PBIs).
Implementera Nexus Sprint Planering. 10.1. Definiera Sprintkadens;
10.2. Definiera beroenden, integrationsproblem som kan visas;
10.3. Omfattning som ska definieras: ungefär minst 2 sprintar framåt och nuvarande;
10.4. Håll ett möte för att hjälpa NIT-medlemmar med sprintplanering i team.
implementera sprintplanering inom varje Scrum-team. 11.1. Använd absoluta uppskattningar för uppgifter och underaktiviteter under sprintplanering;
11.2. Underlätta sprintplanering för varje lag;
11.3. Skapa en dokumentmall.
implementera Nexus Daily Scrum och Daily Scrum för varje lag. 12.1. Definiera tiden, underlätta Nexus dagliga Scrum möten (försök att hålla dem timeboxed);
12.2. Definiera tiden, underlätta dagliga Scrum möten (hålla dem timeboxed).
implementera Nexus Sprint Review (max 4h). 13.1. Håll en Nexus Sprint recension (inklusive demoinspelning om det behövs) med Scrum teammedlemmar, PO, andra intressenter.
implementera Nexus Sprint retrospektiv och retrospektiv möte för varje Scrum team (skapa ett dokument med mallar) (max 1h och 3h). 14.1. Håll ett retrospektivt möte för NIT;
14.2. Skapa ett malldokument;
14.3. Underlätta retrospektiva möten i Scrum-Team.
14.4. Skapa ett malldokument.
implementera Nexus förfining händelse på regelbunden basis av produktbackloggen. 15.1. Definiera frekvensen (så ofta som behövs; t.ex. 2t/vecka).
implementera uppskattning i berättelsepunkter (beroende på PO-initiativet och beredvillighet att förutse). 16.1. Börja spåra Scrum teams hastighet (efter 3 Sprints);
16.2. Spåra framsteg med Sprint burndown-diagrammet.
implementera visuella beroenden och deras prognos bland uppgifter. 17.1. Visualisera beroenden mellan användarhistorier, uppgifter (t.ex. flagga och länk);
17.2. Definiera beroenden för nuvarande Sprint och två sprintar framåt.
starta projektledningsaktiviteter för att stödja projektet. 18.1. Skapa dokument som kan vara praktiskt (t. ex.projekt Charter, Risk management Matrix, Stakeholder management, Team management (inkl. Teammedlemsinformation, SKIVTEST, motivationstest, laghälsokontroll));
18.2. Definiera projekt KPI: er och skapa en mall för att spåra dem. Vanligtvis inkluderar de hastighet, Sprint burndown, CSAT. Andra kan inkludera budgetberäkningar;
18.3. Definiera rapporter för projekthälsokontroller med post och viktiga intressenter;
18.4. Granska teststrategin inom uppgifter och flöde (Manuell, enhetstester, automatisering) om de inte ingår i standardflödet.
strategi för att leverera mer värde och maximera resultaten efter genomförandet av stegen ovan (TBD). 19.1. Håll ett möte med viktiga intressenter (PO, VD andra);
19.2. Samla in och diskutera krav som stämmer överens med affärsstrategin.

Nexus Teams

en Nexus består av cirka 3 till 9 Scrum-Team och ett Nexus-Integrationsteam bestående av 1-2 medlemmar från varje scrum-team som ansvarar för att planera visionen för den övergripande produkten och samordna lagen.

det rekommenderas att bilda lag baserat på genomförbarhet. Funktionsteam är mest förnuftiga eftersom de kan fungera på alla produktbackloggar.

det aktuella arbetsflödet lutar dock mot komponentgrupper, vilket kan leda till större beroenden bland dem. För att minska risken är det en giltig punkt att delegera lag de uppgifter som tillhör andra än deras komponent. Kunskapsdelningsprocess kommer att vara avgörande i detta fall och minska bristen på information vid integrering.

Nexus Integration Team (NIT) består av medlemmar från:

  • ⇒ produktägare-ansvarig för att maximera produktens värde och för att säkerställa att det kombinerade arbetet som utförs av en Nexus produceras minst en gång varje Sprint.
  • Scorpion Scrum Master-ansvarig för Scrum-team som gör Scrum och Nexus korrekt och maximerar värdet som levereras av utvecklingsteamet. Ansvarig för att leverera” färdiga ” steg av potentiellt släppbara produkter.
  • utvecklingsteam för utvecklingsländer i utvecklingsländerna i utvecklingsländerna i utvecklingsländerna i utvecklingsländerna i utvecklingsländerna i utvecklingsländerna – ansvariga för att skapa integrerade steg som görs. NIT säkerställa Scrum Team inom Nexus förstå och genomföra de metoder som behövs för att upptäcka beroenden, och ofta integrera alla artefakter till definitionen av “klar.”

Nexus Integration Team Roll:

  • ⇒ Nexus Integrationsteam är ansvarig för att säkerställa definitionen av “klar”.
  • integrated Increment (det kombinerade arbetet som utförs av en Nexus) produceras minst en gång per Sprint.
  • Brasilien Scrumteamen ansvarar för att leverera “Done”.
  • Brasilien NIT ger en kontaktpunkt för integration för Nexus. Integration innefattar att lösa eventuella tekniska och icke-tekniska begränsningar över team som kan hindra en Nexus förmåga att leverera en ständigt integrerad ökning.
  • medlemskap i Brasilien kan variera över tid beroende på de hinder som Nexus upplever.

teammedlemmar måste producera maxresultatet för varje Sprint. En regelbunden hälsokontroll för lagen rekommenderas såväl som för programvara. En gång i månaden kan man hålla ett snabbt frågeformulär för att övervaka lagens produktivitet inom varje Scrum-team.

frågor till teammedlemmarna:

  • ⇒ levererar de värde?
  • är produkten lätt att släppa?
  • Brasilien har teammedlemmar kul?
  • är produkten hälsosam?
  • är det hållbart och stödbart?
  • är teammedlemmar lärande?
  • Brasilien förstår de produktmålen?
  • Brasilien känner de sig som bönder eller spelare?
  • Brasilien känner de ägande?
  • är deras hastighet tillräcklig?
  • Brasilien känner de att de har en lämplig process?
  • känner de sig stödda?
  • arbetar de bra som ett team?
  • Brasilien bidrar företaget till medarbetarnas utveckling?

DevCom Nexus Team Hälsokontroll

Nexus Händelser

1.Förfining

förfining resulterar i en produktbacklog som är tillräckligt granulär för att Scrum-Team ska kunna dra arbete utan att skapa ohanterliga beroenden. Under förfining bör Scrum-teamen fokusera på dessa frågor:

  • ⇒ vilket arbete kommer varje lag att dra?
  • i vilken ordning behöver det arbetet göras för att leverera det största affärsvärdet tidigast, samtidigt som risken och komplexiteten minimeras?

Nexus Sprint planering

Nexus Sprint planering består av:

  • ⇒ validera produktbacklog. Scrumteamen granskar PBI: erna och gör nödvändiga justeringar som behövs för arbetet från Förfiningsevenemanget. Alla Scrum-Team bör delta och bidra till att minimera kommunikationsproblem; men bara lämpliga representanter (de som känner att de kan bidra till att förfina PBIs) från vart och ett av Scrum-lagen behöver delta.
  • Brasilien formulera Nexus målet. Nexus-målet är ett sprintmål som uppnås genom implementering av PBIs av flera lag.
  • bisexuell Scrum team Sprint planering. När Nexus-målet för sprinten är förstått kommer varje Scrum-team att genomföra sina individuella Sprintplaneringsevenemang där medlemmarna skapar sina egna Sprintbacklogs. När de identifierar beroenden med andra team arbetar de med dessa team för att minimera eller eliminera beroenden. De flesta sprintplanering bör ta 8 timmar.

i vissa fall kommer detta att innebära att arbetssekvensen mellan lag kan behöva justeras för att låta ett lag avsluta sitt arbete innan ett annat börjar.

Nexus Daily Scrum

Nexus Daily Scrum meeting omfattar de viktigaste frågorna:

  • ⇒ var föregående dags arbete framgångsrikt integrerat, och om inte, varför?
  • har några nya beroenden identifierats?
  • Brasilien vilken information behöver delas mellan teamen i Nexus?

vanligtvis hålls den på samma tid och plats.

Nexus Sprint Review

Sprint Review innehåller följande element:

  • ⇒ deltagare inkluderar Scrum-teamen och viktiga intressenter som bjudits in av produktägaren;
  • Brasilien produktägaren förklarar vilka Produktbackloggar som har “gjorts” och vad som inte har”gjorts”;
  • ie utvecklingsteamen diskuterar vad som gick bra under sprinten, vilka problem det stötte på och hur dessa problem löstes;
  • ie utvecklingsteamen visar det arbete som det har “gjort” och svarar på frågor om inkrementet;
  • Ie produktägaren diskuterar produktbackloggen som den ser ut. Han eller hon projekterar sannolika mål – och leveransdatum baserat på framsteg hittills (om det behövs);
  • Brasilien hela gruppen samarbetar om vad man ska göra nästa så att sprintgranskningen ger värdefull input till efterföljande sprintplanering;
  • granskning av hur marknadsplatsen eller den potentiella användningen av produkten kan ha förändrat vad som är det mest värdefulla att göra härnäst;
  • granskning av tidslinjen, budgeten, potentiella möjligheter och marknadsplats för nästa förväntade versioner av produktens funktionalitet eller kapacitet.

resultatet av Sprint Review är en reviderad produktbacklog som definierar de sannolika produktbackloggen för nästa Sprint. Produktbackloggen kan också anpassas totalt sett för att möta nya möjligheter.

denna aktivitet bör inte ta mer än 3 timmar att slutföra.

Nexus Retrospektivt Möte

5.1. Nit retrospektiv

eftersom det finns vanliga skalningsdysfunktioner bör varje retrospektiv ta upp följande frågor.

  • ⇒ har de nått Nexus-målet? Om inte, varför inte?
  • var något arbete kvar ogjort? Genererade Nexus teknisk skuld?
  • var alla artefakter, särskilt kod, ofta (helst kontinuerligt) och framgångsrikt integrerade?
  • har programvaran framgångsrikt byggts, testats och distribuerats tillräckligt ofta för att förhindra den överväldigande ackumuleringen av olösta beroenden?

när problem upptäcks måste representanterna fråga:

  • ⇒ Varför hände detta?
  • Brasilien hur kan problemet åtgärdas?
  • hur kan återfall förhindras?

efter Nexus Retrospective-mötet är det viktigt att definiera åtgärdsposter att arbeta med inom alla Scrum-Team. NIT måste hålla reda på sådana föremål och kan använda en tabell nedan.

DevCom Nexus Åtgärdsposter

5.2. Scrum Team retrospektiv

varje Scrum team kan använda en styrelse för att visualisera objekt som behöver bearbetas. Dessutom rekommenderas det att formellt hålla reda på sådana register på ett strukturerat sätt. Högst tar det 4 timmar att diskutera med laget hur en Sprint gick.

Scrum teams retrospektiv

produktägare

produktägaren ansvarar för att maximera produktens värde.

produktägaren är den enda personen som ansvarar för att hantera produktbackloggen. Produktbacklogghantering inkluderar:

  • ⇒ att tydligt uttrycka produktbacklog poster;
  • Brasilien beställa artiklarna i produktbackloggen för att bäst uppnå mål och uppdrag;
  • Brasilien optimera värdet på det arbete som Nexus-teamet utför;
  • Brasilien se till att produktbackloggen är synlig, transparent och tydlig för alla, och visar vad Scrum-teamen kommer att arbeta med nästa;
  • för att säkerställa att Scrumteamen förstår objekt i produktbackloggen till den nivå som behövs;
  • för att definiera Nexus-målet för varje Sprint (liknande milestone).

produktägaren kan göra ovanstående arbete eller låta Nexus-teamet göra det. Produktägaren är dock ansvarig.

Key Takeaways

  1. Scaled Agile works, och med hjälp av en skalningsramverk hjälper du dig att få en snabb start.
  2. Scaling Scrum är bara Scrum. Du ändrar inte hur du arbetar som ett Scrum-team och du ändrar inte heller det arbete som levereras.
  3. genom att lägga till Nexus-ramverket ovanpå Scrum ger det team ett sätt att hantera teamberoende och se till att de alla arbetar tillsammans mot ett gemensamt mål och produktökning.
  4. om du känner till Scrum riktigt bra är Nexus framework “no-brainer” – ramverket för skalning av mjukvaruutvecklingsteam, och du kanske aldrig behöver något annat.
  5. Nexus är ett användbart diskussionsramverk för dem som redan har flera Scrum-team på plats som fungerar tillsammans.
  6. alternativt, om du vill beskriva din process, är Nexus framework en bra utgångspunkt så att du inte missar några perspektiv.
  7. som alltid, när det gäller att skala agile, kom ihåg dessa tre viktiga saker:
  • ⇒ anpassa metoden så att den passar din organisation.
  • Brasilien ständigt reflektera över situationen.
  • Brasilien förbättra hur du arbetar tillsammans.

har du fler förslag på” bortom laget ” tekniker? Vill du ha hjälp med att genomföra dessa förslag?

sedan 2000 har DevCom anpassat branschstandard agila metoder utformade för att skapa snabba, effektiva och effektiva lösningar för att uppnå våra kunders mål. Dessa metoder representerar en iterativ utvecklingsmodell där den övergripande ansträngningen delas upp i flera utgåvor för att uppnå de mål som skisseras för en viss fas. Vi lägger stor vikt vid tre delar av utvecklingslivscykeln: inledande projektbedömning och planering, Kvalitetsprojektledning, kvalitetssäkring.

vår utvecklingsstrategi minskar projektrisker och arbetar för att kontrollera time-to-market och budget. Vi delar den erfarenheten och kunskapen med våra nya kunder så att alla kan lyckas vid skalning.

få bättre resultat genom lagarbete: kontakta oss på DevCom idag!

Lämna ett svar

Din e-postadress kommer inte publiceras.