Skala Agile till stora team

Orden big och Agile används inte ofta i samma mening. Stora organisationer har förtjänat ryktet att vara långsamma. Men det förändras. Många stora programvaruorganisationer gör omvandlingen till Agile. De lär sig att skala agila principer med eller utan populära ramverk som SAFe, LeSS eller Nexus.

På Microsoft använder en sådan organisation Agile för att skapa produkter och tjänster som levereras under varumärket Azure DevOps. Den här gruppen har 35 funktionsteam som släpps till produktion var tredje vecka.

Alla team i Azure DevOps äger funktioner från början till slut och därefter. De äger kundrelationer. De hanterar sina egna kvarvarande produkter. De skriver och kontrollerar kod i produktionsgrenen. Var tredje vecka implementeras produktionsmiljön och versionen blir offentlig. Teamen övervakar sedan systemets hälsotillstånd och åtgärdar problem på den aktiva webbplatsen.

Enligt agila principer är autonoma team mer produktiva. En agil organisation vill att deras team ska ha kontroll över sin dagliga arbete. Men autonomi utan anpassning skulle leda till kaos. Dussintals team som arbetar självständigt skulle inte producera en enhetlig produkt av hög kvalitet. Anpassning ger teamen sitt syfte och säkerställer att de uppfyller organisationens mål. Utan anpassning skulle även de bäst presterande teamen misslyckas.

Om du vill skala Agile måste du aktivera autonomi för teamet samtidigt som du säkerställer anpassningen till organisationen.

För att hantera den känsliga balansen mellan anpassning och autonomi måste DevOps-ledare definiera en taxonomi, definiera en planeringsprocess och använda funktionschatter.

Definiera en taxonomi

Ett agilt team, och den större agila organisation som det tillhör, behöver en tydligt definierad kvarvarande information för att lyckas. Teams kommer att kämpa för att lyckas om organisationens mål är oklara.

För att kunna ange tydliga mål och ange hur varje team bidrar till dem måste organisationen definiera en taxonomi. En tydligt definierad taxonomi skapar nomenklaturen för en organisation.

En vanlig taxonomi är epos, funktioner, berättelser och uppgifter.

Epos

Epics beskriver initiativ som är viktiga för organisationens framgång. Epos kan ta flera lag och flera sprintar att slutföra, men de har alltid ett slut. Epos har ett tydligt definierat mål. När det har uppnåtts avslutas eposet. Antalet episka berättelser som är i arbete bör vara hanterbart för att hålla organisationen fokuserad. Epos är uppdelade i funktioner.

Features

Funktioner definierar nya funktioner som krävs för att förverkliga ett epos mål. Funktioner är release-enhet; de representerar det som distribueras till kunden. Publicerade releaseanteckningar kan skapas baserat på listan över nyligen slutförda funktioner. Funktioner kan ta flera sprintar att slutföra, men bör vara storleksanpassade för att säkerställa ett konsekvent flöde av värde till kunden. Funktioner är uppdelade i berättelser.

Berättelser

Berättelser definierar inkrementellt värde som teamet måste leverera för att skapa en funktion. Teamet delar upp funktionen i inkrementella delar. En enskild slutförd artikel kanske inte ger kunden ett meningsfullt värde. En färdig berättelse representerar dock programvara av produktionskvalitet. Berättelser är teamets arbetsenhet. Teamet definierar de berättelser som krävs för att slutföra en funktion. Berättelser kan valfritt delas upp i uppgifter.

Tasks

Arbetsuppgifter definierar det arbete som krävs för att slutföra en berättelse.

Initiativ

Den här taxonomi är inte ett system som passar alla. Många organisationer introducerar en nivå över epos som kallas initiativ.

Namnen på varje nivå kan skräddarsys för din organisation. Namnen som definieras ovan (epos, funktioner, berättelser) används dock ofta i branschen.

Linje av autonomi

När en taxonomi har angetts måste organisationen dra en linje av autonomi. Linjen av självbestämmande är den punkt där äganderätten på denna nivå övergår från ledningen till teamet. Ledningen ingriper inte i nivåer som ägs av teamet.

I följande exempel visas linjen för autonomi som ritas under funktionerna. Ledningen äger epos och funktioner som ger anpassning. Team äger berättelser och uppgifter och har självbestämmande över hur de utför.

I det här exemplet berättar inte ledningen för teamet hur de ska dela upp berättelser, planera sprintar eller köra arbete.

Teamet måste dock se till att deras utförande överensstämmer med ledningens mål. Även om ett team äger sina kvarvarande berättelser måste de anpassa sina kvarvarande uppgifter till de funktioner som tilldelats dem.

Planering

För att skala agil planering behöver ett team en plan för varje nivå av taxonomi. Det är dock viktigt att iterera och uppdatera planen. Den här processen kallas rullande vågplanering.

Planen ger vägledning för en fast tidsperiod med förväntad kalibrering med jämna mellanrum. Till exempel kan en 18-månaders plan kalibreras var sjätte månad.

Här är ett exempel på planeringsmetoder för varje nivå i en taxonomi: epos, funktioner, berättelser, uppgifter.

Vision

Visionen uttrycks genom epos och anger organisationens långsiktiga riktning. Epos definierar vad organisationen vill slutföra under de kommande 18 månaderna. Ledningen äger planen och kalibrerar den var sjätte månad.

Visionen presenteras vid ett personalmöte. Eftersom visionen är avsedd att vara ambitiös och mycket kan förändras under den tidsperioden, förväntar du dig att uppnå cirka 60% av visionen.

Årstid

En säsong beskrivs genom funktioner och anger strategin för de kommande sex månaderna. Funktioner avgör vad organisationen vill lysa upp för sina kunder. Ledningen äger säsongsplanen och presenterar visionen och säsongsplanerna vid ett all-hands-möte. Alla teamplaner måste överensstämma med ledningens säsongsplan. Förvänta dig att uppnå cirka 80% av säsongsplanen.

3-sprintplan

3-sprintplanen definierar berättelserna och funktionerna som teamet kommer att avsluta under de kommande tre sprintarna. Teamet äger planen och kalibrerar den varje sprint. Varje team presenterar sin plan för hantering via funktionschatten (se nedan). Planen anger hur teamets genomförande överensstämmer med den 6-månaders långa säsongsplanen. Räkna med att nå ungefär 90 % av 3-sprint-planen.

Sprintplan

Sprintplanen definierar de berättelser och funktioner som teamet kommer att avsluta i nästa sprint. Teamet äger sprintplanen och skickar den till hela organisationen för fullständig transparens. Planen innehåller vad laget åstadkom i den senaste sprinten och deras fokus för nästa sprint. Förvänta dig att uppnå cirka 95% av sprintplanen.

Linje av autonomi

I det här exemplet dras autonomilinjen för att visa var teamen har planeringsautonomi.

Som nämnts ovan utökar ledningen inte ägarskapet under självbestämmandelinjen. Ledningen ger vägledning med hjälp av visionen och säsongsplanerna och ger sedan lagen autonomi att skapa 3-sprint- och sprintplaner.

Funktionschattar: Där autonomi möter samordning

En funktionschatt är ett möte med låg ceremoni där varje team presenterar sin 3-sprintplan för ledningen. Det här mötet säkerställer att teamplaner överensstämmer med organisationens mål. Det hjälper också ledningen att hålla sig informerade om vad teamet gör. Medan 3-sprintplanen justeras varje sprint, hålls funktionsmöten efter behov, vanligtvis var en till tre sprintar.

Ett funktionschattmöte allokerar 15 minuter till varje team. Med 12 funktionsteam kan dessa möten schemaläggas att pågå i ungefär tre timmar. Varje team förbereder en 3-slidepresentation med följande bilder:

Features

Den första bilden beskriver de funktioner som teamet kommer att lysa upp i de kommande tre sprintarna.

Skuld

Nästa bild beskriver hur teamet hanterar tekniska skulder. Skuld är allt som inte uppfyller ledningens kvalitetsnormer. Ingenjörschefen sätter kvalitetskraven, som är desamma för alla team (samordning). Exempel på kvalitetsmått är antalet buggar per ingenjör, procentandel enhetstester som klaras och prestandamål.

Problem och beroenden

De problem och beroenden som anges i den sista bilden innehåller allt som påverkar teamets framsteg, till exempel problem som teamet inte kan lösa eller beroenden för andra team som behöver eskalering.

Varje team presenterar sina bilder direkt till ledningen. Teamet presenterar hur deras 3-sprintplan överensstämmer med den 6-månaders säsongsplan. Ledningen ställer klargörande frågor och föreslår förändringar i riktning. De kan också begära uppföljningsmöten för att lösa djupare problem.

Om ett teams plan inte överensstämmer med ledningens förväntningar kan ledningen begära en ny plan. I denna sällsynta händelse kommer teamet att planera om och schemalägga en andra funktionschatt för att granska den.

Förtroende: Limmet som håller samman justering och autonomi

När du tillämpar agila metoder i större skala är förtroende en dubbelriktad gata.

• Ledningen måste lita på att teamen gör det rätta. Om ledningen inte litar på teamen ger de inte teamen autonomi.

• Ett team får förtroende genom att konsekvent leverera kod av hög kvalitet. Om teamen inte är betrodda ger ledningen dem inte autonomi.

Ledningen måste tillhandahålla tydliga planer för team att anpassa till och sedan lita på att teamen genomför. Teamen måste anpassa sina planer till organisationen och köra dem på ett tillförlitligt sätt.

När organisationer vill skala Agile till större scenarier är nyckeln att ge teamen autonomi samtidigt som de är anpassade till organisationens mål. De kritiska byggstenarna är tydligt definierade ägarskap och en förtroendekultur. När en organisation har den här grunden på plats kommer de att upptäcka att Agile kan skalas mycket bra.

Nästa steg

Det finns många sätt för ett team av alla storlekar att börja se fördelar idag. Kolla in några av de här praktikerna som kan skalas.

Lär dig mer om Azure DevOps-funktioner för portföljhantering och synlighet i olika team.

Microsoft är ett av världens största agila företag. Läs mer om hur Microsoft skalar DevOps-planering.