The scaling challenge of agile

Af: Pia Petersen og Henrik Sternberg

Manøvredygtighed i komplekse organisationer – hvad og hvordan ?

”The process war is over – agile won”. Sådan tænker og skriver de fleste udviklere og metodefolk i dag, som en helt naturlig konsekvens af den store udbredelse og de mange positive resultater, den agile bevægelse har medført. Positive resultater vi først og fremmest har set i relativt små, ko-lokerede projekter og teams, der har kunnet samarbejde intenst, bevidst og målrettet med brug af sunde udviklingspraktikker. Men vi sidder også med en fornemmelse af, at det først lige er begyndt.

Hvis den agile bevægelse for alvor skal kunne øge kvaliteten af vores løsninger - så skal vi vende blikket mod softwareudvikling i endnu mere komplekse organisationer. Vi skal skifte perspektiv fra at have projekter og teams som vores primære omdrejningspunkt til også at tænke på organisationen som helhed. Her er der stadig langt igen, førend iterationer/sprints bliver kilde til såvel projektmæssig som til organisatorisk læring og før, selvorganisering og medledelse i projektteams bliver anerkendt som et reelt alternativt til den klassiske tilgang til projektledelse.

Komplekse projekter og genbrug af gode erfaringer

De gode erfaringer, der er høstet indenfor de seneste 10-15 år på det agile felt, er overvejende høstet i mindre komplekse sammenhænge. Små, ko-lokerede projekter med engagerede og fagligt dygtige projektdeltagere. Erfaringen her er, at det altid kan betale sig at fokusere på nærhed og gensidig læring igennem motoren i agil udvikling: ”inspect and adapt”. Naturligvis går det heller ikke i små projekter altid bare af sig selv. Men når kompleksiteten i projekterne og deres omgivelser stiger, så stiger vanskelighederne eksponentielt. Og endnu værre: samtidig med kompleksiteten stiger også behovet for arbejdsprocesser, der kan skabe gennemsigtighed og effektivitet.

Figur 1. Det er ikke trivielt at overføre viden fra enkeltstående projekter til komplekse organisationer, når vi vil genbruge de gode erfaringer fra det agile felt. Transfer af erfaringer er ikke 1:1 men 1:1+n (egen model)

Den første udfordring, vi står med her, er at erkende, at vi ikke direkte kan overføre vores erfaringer fra de første agile succeser til mere komplekse situationer. Komplekse situationer indebærer naturligt meget mere kompleks kommunikation, og dermed også større udfordringer for at skabe den gennemsigtighed, manøvredygtighed og synkronisering, vi ønsker. Derfor må vi også forvente, at denne type projekter må anvende andre agile rammer, praktikker og teknikker. For eksempel er den mest effektive teknik til inspiration og udveksling af ideer, to personer med to tuscher og en whiteboard tavle. Denne teknik skalerer dog rigtig dårligt. Man kan ikke umiddelbart sætte 100 mand med 100 tuscher til at generere ideer og udveksle modeller ved 50 tavler og få det til at give værdi. Men principperne om nærhed og gensidig læring gælder stadig. Så vi har behov for at anvende andre rammer og teknikker til at opnå målet om effektivitet og gennemsigtighed, når vi i det komplekse projekt skal kompensere for f.eks.:

Geografisk distribution
Kulturel diversitet
Domænekompleksitet
Teamstørrelse
Organisatoriske krav om governance og enterprise arkitektur på flere ledelsesniveauer

Manøvredygtighed i komplekse organisationer

Vi oversætter gerne ”agile” til manøvredygtig. Det gør vi for at understrege, at behovet for agile principper og praktikker ikke forsvinder fordi kompleksiteten stiger, tvært imod. Manøvredygtighed er evnen til at kunne træffe beslutninger og styre på baggrund af erkendt og up-to-date viden og indsigt. Det kræver to ting: Stor gennemsigtighed og velegnede styringsredskaber. Behovet for manøvredygtighed er mindst lige så stort i en 40 tons 16 hjuls lastbil, som en personbil. Men designerne har ikke de samme teknikker til rådighed for at opnå målet og det er klart at en 16-wheeler ikke kan opnå samme grad af manøvredygtighed som en VW UP, men målet for begge er at opnå den størst mulige.

På samme måde kan et stort komplekst projekt ikke opnå samme forandringshastighed og gennemsigtighed, som et mindre. Men det er afgørende, at man som projektdesigner og metodeansvarlig gør sig anstrengelser for at vælge de teknikker og praktikker, der giver den størst mulige manøvredygtighed i den organisation, man befinder sig i.

I systemudviklingsprojekter anvender vi metoder for at styrke samarbejde og kommunikationen – og vi skal være særligt opmærksomme på systematisk anvendelse, når betingelserne bliver vanskeligere og kompleksitetsfaktorerne stiger. Anvendte metoder og praktikker skal ikke blot understøtte samarbejde i teamet og i projekterne, men også, at hver enkelt medarbejder i alle teams og alle projekter først og fremmest tænker og handler som organisationsmedlemmer: Alle beslutninger i et projekt skal naturligvis understøtte og koordineres i forhold til organisationens mål og enterprise-arkitektur. Vores erfaringer er, at 14 dages lokale projektsprints i et projekt i en stor organisation, IKKE er designet til automatisk at understøtte dette dette. Tværtimod øges risikoen for at skabe større tekniske gæld, at sænke den tvær-organisatoriske effektivitet og for at konflikter eskalerer til at være direkte kontraproduktive.

I forordet til sin bog ”Disciplined Agile Delivery” giver Scott Ambler et billede af et pendul, der er svinget fra de tunge bureaukratiske dokumentdrevne metoder i 80’erne og 90’erne til ”næsten ingenting undtaget kode” og stiller spørgsmålet, om ikke pendulet er svinget lidt for langt, i hvert fald når vi taler om store komplekse organisationer? Og man kan også spørge, om vores faglighed som systemudviklere og projektledere er fulgt med denne bevægelse? Har vi husket at tage vores kompetencer og viden om f.eks. modellering og sund udviklingspraksis med os på vores agile rejse? Scott Amblers billede antyder, at vi i bestræbelserne på at skabe effektivitet og dynamik, har tabt noget væsentligt af syne: evnen til at skabe og fastholde sammenhænge på tværs i organisationer samtidig med, at ønsket om effektivisering i udviklingsarbejdet bliver opfyldt.

Sund systemudvikling hviler på solid faglighed. Vi mener bestemt, det er muligt og nødvendigt at skærpe vores fokus på begge disse syn indenfor den agile bevægelse. De agile principper og praktikker er i dag (for) ofte indpakket i ”letfordøjelige” metoder - det skal være let at sælge ideen om den hurtige effektivisering. Men vi tror det er nødvendigt at tage et skridt tilbage og se på, hvad der er tabt i svinget, i vores søgen efter hurtige fremskridt. Vi tror ikke på de lette løsninger. Vi tror på forankring af solid faglighed. Vi tror på, at vi konstant skal udforske vores profession. Og vi tror på, at de agile principper er værd at arbejde videre med og løbende forbedre, for de afspejler langt hen ad vejen det vi kalder ”sund systemudvikling”.

Den bevægelse, som for alvor blev igangsat i 2001, kan hjælpe os med at se nødvendigheden af, at vi som fagområde kan udvikle sunde praktikker og metoder, der passer til de faglige udfordringer vores komplekse organisationer kræver. Og nødvendigheden af til stadighed at udvikle de kompetencer, der skal understøttes af metoderne. For igen: det er jo ikke metoderne og praktikkerne (heller ikke Scrum), der sikrer succesen af projekterne til gavn for organisationen og forretningen, men den faglige ekspertise hos deltagerne - ligesom i alle andre fag.

Komplekse projekter kan godt være agile

Vi ser heldigvis i dag mange bevægelser hen imod dette. Skalering af agile metoder og udviklingen af mere solide agile platforme og rammeværk er på vej frem. Scott Amblers ”Disciplined Agile Delivery” og Dean Leffingwells ”Scaled Agile Framework” er f.eks. gode og nødvendige eksempler på dette.

Vores ønske er – med denne type afsæt - at udvide det agile råderum så langt som muligt, op og ud i alle typer organisationer og projekter. Vi ønsker at bidrage til, at de agile principper og praktikker også kan få fodfæste i store projekter og i store og komplekse organisationer, der udvikler de løsninger, som har den største indflydelse på både organisationens og brugernes liv. For selvom agile måske har ”sejret”, er rejsen kun lige begyndt.