Start altid en tale med en joke. Sådan lyder et gammelt råd til offentlige talere. Det er et godt råd. Altså bortset fra, at nogle taler ville være katastrofale, hvis de startede med en joke.

På samme måde som nogle projekter ville være katastrofale, hvis de blev kørt for agilt. Ingen regel uden undtagelse. Men stiller vi egentlig spørgsmålstegn ved, hvad det vil sige at være agil - og især, hvad det vil sige for os på vores projekt i vores virksomhed og med vores kunder?

Tager vi ikke selv stilling, bliver agilitet bare til det, vi læser om i bøger og hører om på konferencer. Måske derfor er vi blevet en industri, hvor alle går rundt med kronisk dårlig samvittighed over ikke at være agile nok. Vores forretning er ikke agile, vi kommer ikke hurtigt nok i produktion, vores kontrakter er ikke agile, vores kunder er ikke agile, vores PO skriver ikke "korrekte" user stories, osv. Vi taler om True Scrum uden at blinke. Man kunne lige så meningsfuldt tale om Sand Medister.

Det er som den gamle joke om familien på feriecenteret, der spørger i receptionen, hvor swimmingpool'en er? I brochuren, svarer receptionisten. Underforstået "kun i brochueren". "Sand Agilitet - det finder du kun på konferencerne".

Tilbud er der nok af. Brug Spotifymodellen! Don't estimate. Pull - don't push. Release oftere. Omlæg til Micro Services. To for ens pris. Er det dyrt? Nej, det er billigt. Sand Medister.

Det er en industri af TV Shop-agilitet, hvor sælgerne står i kø med nemme, billige løsninger. Og så har "forretningen" i øvrigt misforstået det hele. Og er det ikke forretningen, den er gal med, så er det kunderne.

Vi har fået agilitet galt i halsen. Hvis agilitet kun kan se ud på én bestemt måde, risikerer vi at bedømme agilitet på, hvordan det ser ud, og ikke på hvilke af vores problemer det løser.

Hvordan ser agilitet ud?

Hvordan ser agilitet ud? Det havde Nokia faktisk et svar på i 0'erne. Det blev kaldt Nokia-testen. Hvis du levede op til Nokia-testen, så var du agil. Punktum.

Og vi så måbende til, da Nokia-testen som bekendt ikke var tilstrækkeligt til at redde Nokia. Hvorfor? Fordi testen handlede om, hvordan agilitet ser ud, og ikke om hvilke problemer agilitet skulle løse hos Nokia. Ja, egentlig forholdt den sig slet ikke til, hvad Nokias problem var. Og det var nok det egentlig problem.

For agilitet er selvfølgelig ikke længden på sprintet, hvem der prioriterer backloggen, eller hvordan teamet estimerer. Agilitet er heller ikke, om user stories er skåret vertikalt, eller om teamet bruger test driven development. Og agilitet er slet ikke, om vi estimerer i story points eller timer, eller om vi overhovedet estimerer.

It depends

Allen Holub foreslår at erstatte ordet agil med ordet fleksibel. Det er nemmere at forstå. Jeg har lyst til at tilføje "fleksibilitet igennem feedback loops". Vi lærer som vi kører, og vi bruger den læring. Vi tager ting i små bider for at kunne bruge læringen. Og vi bruger den. Vi tilpasser os.

Så spørg dig selv, hvor fleksibel du har behov for at være.

Hvad er karakteren af dit projekt eller af din forretning. Og læg dig så lidt på den ambitiøse side, for du har sikkert brug for at være lidt mere fleksibel, end du umiddelbart kan retfærdiggøre.

Eksempel: Den korrekte sprintlængde er 2 uger

Scrum Guiden siger, at et sprint har en længde på en måned eller mindre. Det lyder ikke helt urimeligt, men der er stor forskel på et sprint på en uge og et sprint på en måned. Hvis du har behov for høj agilitet - altså høj fleksibilitet i forhold til skiftende opgaver, så overvej et kort sprint, men kender du din backlog langt ud i fremtiden og dine opgaver har en karakter, hvor du sjældent bliver overrasket, så sker der altså ikke noget ved at have et langt sprint.

Og overvej også, om de små sprints bliver dyrere i transaktionsomkostninger. Sprints på 2 uger er formodentlig et godt match til langt de fleste teams, men har du ikke brug for det, kan du sikkert høste stordriftsfordele af et længere sprint. Du skal blot være villig til at acceptere, at du også bliver mindre fleksibel - ellers sætter du tiden til igen.

Det er sikkert ikke True Scrum. Og so what.

Eksempel: Release early

For nogle opgaver giver det god mening at release tidligt. Få noget ud i hænderne på brugerne. Det øger din fleksibilitet, fordi du får tidlig feedback. Tidlig kundefeedback kan være noget af det mest afgørende for et projekts succes.

Men på nogle projekter kan det ikke lade sig gøre. Det betyder ikke, at projektet er forkert eller ikke er True Agile. Det betyder bare, at behovet for fleksibilitet er lavere, og at du skal bruge nogle andre håndtag. Hvis du presser en early release ud til nogle brugere, der ikke kan håndtere den, er det helt sikkert værre end at release senere.

Du kan stadig bringe kunden ind og demoe for kunden løbende. Du kan også deploye til produktion uden at release - dvs. at koden får lov til at snurre derude, og måske kan du selv se den nye funktionalitet, måske kan du se data trille korrekt igennem din kode, måske kan du se, at du får logget de ting, du forventer, men funktionaliteten er ikke i hænderne på brugeren, før de kan håndtere det. Eller du kan organisere dig, så du anvender pilotkunder (eller pilotbrugere) - kunder med en særlig modenhed, der godt kan forstå og acceptere, at de oplever større fleksibilitet.

Eksempel: Backloggen skal være prioriteret

En prioriteret backlog giver os mulighed for altid at arbejde på det mest værdiskabende. Det er selvfølgelig vigtigt. Men igen er det udtryk for, hvor fleksibel du har behov for at være. Hvis du kan slække på fleksibiliteten, kan det sagtens give mening også at bundle backlogopgaver efter, hvordan de løses mest effektivt. Vær blot opmærksom på, at det reducerer din fleksibilitet, for så har du måske rykket noget arbejde frem, som du i en True Agile verden kunne have undgået at lave. Og når først arbejdet er lavet... ja, så er det jo lavet, og så har du brugt tiden på det.

Pointen er bare, at der er masser af projekter, hvor backloggen er fyldt med Must do-opgaver, som man ved skal laves, uanset hvor meget man hopper og danser, og så skal man passe på med at lege agil. Vær i stedet opmærksom på den skillelinje i backloggen, hvor du bevæger dig mellem Must haves og Nice to haves - for den findes altid.

Igen - hvis du har et projekt, hvor du kan være så agil, at det er meningsfyldt at have en strengt prioriteret backlog, er det selvfølgelig det helt rette værktøj. Men lad være med at lege agil, hvis din verden ikke er det.

Eksempel: Tag altid fra toppen af bugloggen

Udviklere er mennesker. Det behøvede ikke være nødvendigt at sige til agilister, men mennesker har forskellige kompetencer. De fjollehoveder, der insisterer på, at alle udviklere altid skal tage den øverste backlog-item, skal i hvert fald være sikre på, at de forstår, at de betaler en høj pris for den fleksibilitet, de køber. Det kan være en pris i kvalitet såvel som i arbejdsglæde, men det kan selvfølgelig være det værd.

Eksempel: The Cross functional team falacy

Et team med mange kompetencer sikrer, at teamet ikke behøver hand-offs. Teamet er selv i stand til at udføre opgaven fra ende til anden. Det er et enormt kraftfuldt team-design, som både sikrer maksimal agilitet, og som samtidig kan skalere ret flot. Men også her kommer gevinsten med en omkostning. Der kan nemlig være mange andre hensyn, som gør det attraktivt at samle kompetencerne i ét team.

Tag som eksempel et centralt DevOps-team. Det fjerner ganske vist DevOps-kompetencer fra feature-teamet, men det kan være med til at danne rammerne for en langt bedre grundinfrastruktur, som også kommer feature-teamet til gode. Omvendt kan manglen på et centralt DevOps-team bidrage negativt til en knopskudt infrastruktur, hvor der ikke bliver investeret ordentligt. Noget lignende kan gøre sig gældende for andre faggrupper. Jo, nogle gange giver det faktisk værdi at have et dedikeret frontend-team. It depends.

Vær agil i stedet for at lege agil

Hvad blev der egentlig af bare at spørge, hvad teamet har brug for? Snakke med forretningen om deres behov. Tale med kunderne om, hvordan en release ser ud hos dem.

Lad dig ikke forblænde af alle historierne på konferencerne. Spotify-modellen passer bedst til virksomheder, der leverer online musik-tjenester. Og er i øvrigt forældet... ifølge Spotify.

Spørg i stedet dig selv... "Hvor fleksibel behøver jeg være?". Og design din agilitet efter at være lidt mere fleksibel, end du tror. Og få så feedback på din agilitet, før du fortsætter.