11 mest almindelige årsager til at bruge Scaled Agile Framework (SAFe) og hvordan man adresserer dette med uskalet Scrum

Og hvorfor dette er mere effektivt end at bruge SAFe

For at ordne ineffektiviteten, når man arbejder med flere teams, foreslår ofte nogen at indføre en skaleringsramme. Med flere hold overflader alle slags problemer. At introducere en skaleringsramme lyder som den perfekte løsning. Højre?

Det bedst kendte eksempel på sådanne rammer er Scaled Agile Framework (SAFe). På programtilvækstniveau bringer SAFe frem Scrum som en af ​​måderne til at oprette produktforøgelser på. Med denne er en tilpasset version af Scrum ofte en del af SAFe.

Når folk introducerer SAFe, introducerer de yderligere begivenheder, artefakter, roller og regler. Dette øger kompleksiteten i deres miljø yderligere, hvilket kan bringe deres egne udfordringer og problemer. Ofte er de risici, som folk indfører med SAFe, større end de problemer, de ønsker at løse med SAFe.

De mest almindelige grunde til at bruge SAFe kan dog kun adresseres ved kun at bruge Scrum, så let som det er. Jeg vil vise dig nu, at du ikke har brug for SAFe for at løse de mest almindelige skaleringsproblemer.

Af cocoparisienne hos Pixabay

1. Håndtering af team-afhængigheder for at levere et inkrement

Når flere teams arbejder på det samme produkt, er disse teams ofte afhængige af hinanden. Team A kan kræve handlinger fra Team B og vice versa. Med SAFe kan du identificere disse slags afhængigheder under planlægningen af ​​programforøgelse, typisk se på flere sprints.

Scrum har en fantastisk måde at fjerne dette problem på:

"Udviklingshold er tværfunktionelle med alle de færdigheder som et team, der er nødvendigt for at skabe et produktforøgelse;" - Scrum Guide 2017

Hvert udviklingsteam skal kunne levere et arbejdsstykke af produktet. Hvis der er afhængigheder mellem holdene, hvilket begrænser dem til at gøre dette, skal du se på måder til at omstrukturere holdene, så afhængighederne ikke længere er der. Dermed forsvinder den første grund til at bruge SAFe.

2. Fra vision til produkt / tilpasning af virksomhedsniveau med teamniveau

Ofte oprettes en produktvision langt væk fra Scrum-holdene, hvor de værdifulde produkter er bygget. Med SAFe er der yderligere lag (til portefølje og / eller store løsninger), der er beregnet til at hjælpe med at slynge visionen til teamets efterslæb.

Sådan kan du løse dette med Scrum:

”Produktets efterslæb er en ordnet liste over alt, hvad der vides at være nødvendigt i produktet. Det er den eneste kilde til krav, at der skal foretages ændringer i produktet. ” - Scrum Guide 2017

Ja, produktets efterslæb er det sted, hvor du bringer frem, hvordan du ønsker at komme fra vision til værdi. Ofte ser du, at kun de poster, som det opleves krævet til de næste par Sprints, logges. Scrum-guiden er imidlertid meget klar over, at alt, hvad der vides at være nødvendigt, skal være der. Det behøver ikke at være fuldt udkødet, du kan have vage genstande, der repræsenterer store arbejdsstykker.

3. Juster produkt beslutningstagere og produkt ejer

Ofte er beslutningerne om produktets retning uden for en produksejers rækkevidde. SAFe imødekommer dette med roller som forretningsejer og episk ejer.

Her er, hvordan du kan løse det med Scrum alene:

"Produktejer er ansvarlig for at maksimere værdien af ​​det produkt, der følger af arbejde i udviklingsholdet." - Scrum Guide 2017

Hvis du gør det muligt for produktsejeren at være ansvarlig for at maksimere værdien af ​​produktet, behøver du ikke de ekstra roller som defineret i SAFe.

Du befinder dig muligvis i en anden situation nu, hvor produktansvar og ansvar for produktets efterslæb adskilles. For at være mere effektiv i et produktmiljø med flere teams, skal du dog overveje at ændre dette ved at udvide rollen som produktejer.

4. Giv organisationens øverste niveau en kontrolmekanisme

Mennesker i det øverste lag i organisationen ved ofte ikke nøjagtigt, hvordan teams arbejder på at skabe værdifulde produkter. De har ikke lyst til, at de er involveret eller har kontrol. SAFe har et antal lag og begivenheder til dette. Men i de forkerte hænder kan dette misbruges til at tvinge top-down kontrol.

Scrum giver det perfekte - rene og enkle - sted at vurdere den aktuelle status og diskutere, hvad du skal gøre videre:

”Under Sprint-gennemgangen samarbejder Scrum-teamet og interessenter om, hvad der blev gjort i Sprint. Baseret på dette og eventuelle ændringer i produktets efterspørgsel under Sprint, deltager deltagerne om de næste ting, der kan gøres for at optimere værdien. ” - Scrum Guide 2017

Ja, Sprint Review er din begivenhed, hvis du ønsker at diskutere det aktuelle produkt og ting, der kan have indflydelse på beslutningerne om, hvad de skal gøre næste. Det er direkte, og det er effektivt, fordi alle involverede kan være en del af diskussionen.

Det betyder ikke noget, hvad din rolle er. Hvis du ønsker at påvirke produktets retning, skal du deltage i Sprint Review!

5. Synkronisering af levering / integration af trin

I et produktmiljø med flere teams er SAFes agile frigivelsestog der for at synkronisere leveringen mod frigivelser for flere hold.

Med Scrum har hold flere måder at synkronisere deres arbejde på. Det vigtigste i dette er:

”Flere Scrum-teams arbejder ofte sammen om det samme produkt. Ét produktets efterslæb bruges til at beskrive det kommende arbejde med produktet. ” - Scrum Guide 2017

Dette indebærer følgende:

1 Produktets efterslæb → 1 produktsejer → 1 produktforøgelse → 1 Sprint-gennemgang.

Med dette er synkroniseringen automatisk allerede på plads, fordi der er 1 produktforøgelse, der skal inspiceres under 1 Sprint Review. Scrums empiriske proceskontroltilgang bør ikke ugyldiggøres på grund af denne slags frigørelsessynkroniseringsproblemer. Det ville bryde feedback loop.

I stedet skal hold aktivt søge efter måder at gøre integration lettere på en ægte smidig måde:

”De samarbejder og samarbejder gennem sofistikerede udviklingsarkitekturer og målfrigivelsesmiljøer.” - Scrum Guide 2017

6. Forbedre produktiviteten

SAFe introduceres ofte for at øge holdets produktivitet. Årsagen til lavere produktivitet kan være en kombination af et hvilket som helst af de nævnte spørgsmål:

  • Håndtering af team-afhængigheder for at levere et inkrement;
  • Fra vision til produkt / tilpasning af virksomhedsniveau med teamniveau;
  • Giv organisationens øverste niveau en kontrolmekanisme;
  • Synkronisering af levering / integration af trin.

En forbedring af disse områder ville resultere i forbedret produktivitet. Produktivitetsforbedringerne sammenlignes stort set med traditionelle projektleveringsmetoder (i vandfaldsområdet).

Jeg har allerede diskuteret, hvordan disse forbedringer effektivt kan udføres inden for Scrum. Som et resultat hjælper Scrum dig allerede med at opnå betydelig produktionsforbedring. Til dette behøver du ikke bruge SAFe.

7. Forøg værdien levering

SAFe præsenteres som et alternativ til traditionel produktstyring. Med brugen af ​​Lean og Agile-principper og rammer som Scrum har SAFe fokus på at opbygge den rigtige ting. SAFe har regelmæssige refleksionsmomenter for at være i stand til at sikre dette.

De fleste af disse refleksionsmomenter er imidlertid allerede indgroet i Scrum. Heck, SAFe bruger reflektionsmomenterne som defineret i Scrum (som Sprint Review og Sprint Retrospective), hvilket kun kræver yderligere reflektionsmomenter på grund af den ekstra kompleksitet.

Det, der skiller sig ud med Scrum, er, at disse reflektionsmomenter - med de vigtigste interessenter - helt sikkert vil ske oftere, fordi de sker hver Sprint i stedet for hvert par Sprints (med SAFe). Dette giver mulighed for mere smidighed, flere muligheder for at tilpasse sig ny indsigt, hvilket som resultat fører til større chancer for at øge din værdiforsyning.

8. Forøg kvaliteten

SAFe har “Indbygget kvalitet”. Dette er en af ​​måderne at sikre, at de leverede produkter lever op til virksomhedens kvalitetsstandarder. En del af den indbyggede kvalitet er definitionen af ​​”Udført” af et team.

Scrum stræber dog efter at gøre det samme med definitionen af ​​"Udført". Det bør allerede omfatte virksomhedens kvalitetsstandarder. Definitionen af ​​"Udført" defineres typisk på udviklingsorganisationsniveau. Ikke på holdniveau.

SAFe fremhæver, at indbygget kvalitet er mere end Scrums definition af “Udført”. Jeg er uenig i dette. Definitionen af ​​"Udført" er, hvad en udviklingsorganisation gør af det. Det kan omfatte de samme ting som SAFes indbyggede kvalitet.

9. Organisationsplan - hvad skal man gøre med alle de mennesker, der arbejder på produktet?

SAFe har et praktisk svar på spørgsmålet, hvor alle mennesker fra organisationen passer sammen, når 'arbejder Agile'. Med de mange roller er der altid et sted for enhver smag (Business Management, Product Management, System Arkitekter, System Engineers, Release Train Engineer og endnu mere til de større løsninger).

Tilstedeværelsen af ​​alle disse roller i SAFe giver mulighed for en holdning, som den "passer så let med den eksisterende organisation." Dette kan fjerne behovet for at foretage reelle - smertefulde, men nødvendige - ændringer i organisationen. Dermed kan det resultere i, at en organisation, der ser 'Agile', men faktisk ikke er 'Agile', mangler alle fordelene ved at arbejde på en smidig måde.

Med Scrum er der ikke så let svar. Scrum kender kun tre roller (produktejer, Scrum master, medlem af udviklingsholdet) og interessenterne. Det er vigtigt at forstå, at dette er roller i Scrum. Dette er ikke / behøver ikke at være det samme som en virksomhedsfunktion.

Scrum er en ramme. Det giver dig et lærred, og hvordan du opretter dit maleri er op til dig. Men her er nogle eksempler, der løser spørgsmålet om, hvem der går hen:

  • En produktchef kan være Scrum-produktejer eller en nøgleinteresse;
  • En systemingeniør kan være en del af udviklingsholdet eller en nøgleinteresse;
  • En systemarkitekt kan være en del af udviklingsholdet eller en nøgleinteresse;
  • Produktejeren som defineret af SAFe (arbejder med en Team Backlog) kan være en del af Udviklingsholdet som en produktekspert eller være produktejer.

Scrum giver dig friheden til at implementere det, som du synes er mest fordelagtigt. Du har ikke brug for yderligere roller eller begivenheder for at imødekomme dette. Alle kan have et sted i din tilgang til at bruge Scrum-rammen.

10. Administrer et program med flere produkter

En anden grund til at introducere SAFe er at administrere et program med flere produkter med en masse afhængighed.

Du kan muligvis argumentere for, at jeg allerede diskuterede afhængigheder (emne 1 og 5 kommer i tankerne). Jeg vil dog især fremføre dette eksempel på flere produkter.

Første ting er: er dette ikke at blande projektstyring og produktstyring?

SAFe og Scrum er begge løsninger til at levere værdifulde produkter. Begge er IKKE projektstyringsrammer.

Hvis du har forskellige produkter med mange afhængigheder, skal du overveje, hvad du definerer som dit produkt. En ny vurdering af din definition af et produkt og som følge heraf kan en ny vurdering af din produktportefølje være i orden. Dette vil sandsynligvis øge gennemsigtigheden (som hvem der er ansvarlig som produktejer) og vil fjerne det tilsyneladende behov for at bruge SAFe.

11. Sådan justeres flere produktejere i retning af produktet

SAFe betragtes ofte også som en løsning til at tilpasse flere produktejere, der er ansvarlige for et produkt. Arbejdet kan derefter strømme ned fra program- eller porteføljeaftalen til teamets efterslæb, opdelt pr. Produktsejer.

Problemet med dette er, at et produkt kun skal have en produktejer (1 produktets efterslæb → 1 produktejer). Derfor er det et antimønster at have flere produktejere til et produkt. Hvis du fjerner dette problem, fjerner du også behovet for denne type justering og en grund til at bruge SAFe.

Bundlinie

Den skalerede agile ramme (SAFe) kommer med løsninger til mange almindelige problemer, hvis du ønsker at gå til en måde at arbejde mere agility på. Du behøver dog ikke alle bjælker og fløjter af SAFe, hvis du ønsker at løse dine problemer. Du kan løse de samme problemer med Scrum, en ramme, der virkelig er let. Ved at bruge Scrum alene undgår du unødvendig kompleksitet og overhead.

Min rådgivning er altid at bestemme, hvad dine virkelige behov er, og begynde i det små.

Det er lettere at tilføje kompleksitet end at fjerne det. Så vær altid forsigtig, når du tilføjer en masse kompleksitet på samme tid. Prøv at tilføje det gradvist og finde ud af, om du virkelig har brug for det, og hvis det virkelig løser dit problem. Når der først er der er det svært at fjerne.

Scrum er en af ​​måderne at begynde små på. Hvis du har mestret Scrum tilstrækkeligt, og du stadig føler, at der mangler noget, kan du altid lede efter måder at skalere på. Her er SAFe en af ​​mulighederne, men der er også LeSS, Nexus, Scrum @ Scale og andre.

Du vil blive behageligt overrasket over kraften fra Scrum. Skala blot med Scrum alene.

Skaleret Scrum er stadig Scrum. Enkel og kraftfuld.
Vil du skrive for Serious Scrum eller alvorligt diskutere Scrum?