The agile manifesto – början på den agila eran

Under några dagar i Snowbird Utah formulerades ”The agile manifesto” som ett förslag till utgångspunkt för mera framgångsrik mjukvaruutveckling, utveckling där man hela tiden försäkrar sig om att man utgår ifrån aktuella och verkliga behov. Det agila manifestet la grunden för ett arbetssätt som nu tagit sig långt från mjukvaruutveckling.

Intresset för agila synsätt och metoder fortsätter att öka, inte så konstigt i en snabbföränderlig värld. Resonemang om agila metoder är nu så vardagliga och spretiga att det ibland verkar bortglömt vilka problem som låg bakom uppkomsten.

Populariteten till trots kan man nog utgå ifrån att den praktiska tillämpningen ännu är begränsad. Snacketoppen föregår normalt aktivitetstoppen med ett antal år när det gäller verksamhetsutveckling (och en hel del andra områden verkar det som).

Ursprung i ”the agile manifesto”

Innan ordet helt slitits upp (och vi drabbats av artiklar om Lean-Agile eller Agile-Lean-SixSigma eller Lean-Agile-Change-Management osv, vänta bara de kommer) kan det vara klokt att stanna upp och reflektera över den agila erans bakgrund. Ursprunget kan något förenklat sägas vara ”the agile manifesto” som sjutton personer tecknade ned i februari 2001. Alla sjutton hade på något sätt intresse och erfarenhet av mjukvaruutveckling och inte minst om hur den kan genomföras på bättre sätt än vad som var närmast regel vid den här tiden.

Bakgrunden till att man samlats i skidorten Snowbird utanför Salt Lake City i Utah var en vilja att skapa intresse för nya och bättre metoder för att utveckla mjukvara (jo, bilden är faktiskt från rätt bergområde i Utah, ifall du undrade). Kring millenniumskiftet levererade det typiska IT-projektet försent en felaktig lösning till för hög kostnad. Och om ett projekt händelsevis levererade det som beställts så visade det sig att det som beställts inte var det som behövdes.

Utgår från aktuella och verkliga behov

Under några dagar i Snowbird formulerades ”The agile manifesto” som ett förslag till utgångspunkt för mera framgångsrik mjukvaruutveckling, utveckling där man hela tiden försäkrar sig om att man utgår ifrån aktuella och verkliga behov. Manifestet föreslår fyra värderingar och tolv principer. De fyra värderingarna är (ursprunglig engelsk formulering):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

De fyra värderingarna är välspridda och presenteras ofta kort och gott som ovan (möjligtvis översatta till annat språk). Men i manifestet följer direkt följande mening: ”That is, while there is value in the items on the right, we value the items on the left more.” Om denna mening utelämnas, som ofta sker, så riskerar det att uppstå en rad missuppfattningar.

Balanserad mix

Alla sjutton som var med och formulerade det agila manifestet lever ännu. Förutom att det finns massor skrivet kring hur manifestet kan tolkas så har även upphovsmännen förklarat sig genom åren. Det är helt enkelt inte svårt att ta reda på avsikterna för de fyra värderingarna eller resten av manifestet. Det var inte tänkt att presentera fyra motsatsförhållanden där användaren ska välja antingen eller. Värderingarna presenterades som en balanserad mix där ”högersidan” inte får ta överhand. Komplicerade leveranser som mjukvara skapas av människor som samarbetar med varandra och med beställaren, inte av rigida metoder och kontrakt. Likväl är den ena sidan en förutsättning för effektiv användning av den andra, ofta pekas det på att det är när högersidan är på plats på en rimlig nivå som vänstersidan möjliggörs. Eller annorlunda uttryckt, den som slarvar med högersidan tappar fotfästet och har inte förutsättningar att arbeta agilt.

Bättre på att följa beställarens föränderliga behov

Att begreppet agile skulle användas för att namnge manifestet var inte självklart. En viktig ambition var att sänka kostnaderna för att förändra ett projekt och att därmed bli bättre på att följa beställarens föränderliga behov över tiden för projektets genomförande. Alistair Cockburn, en av de sjutton upphovsmännen, menar att istället för ”agile development” kunde man ha valt uttrycket ”business aligned development.”

Flera användningsområden

Det agila manifestet la grunden för ett arbetssätt som nu tagit sig långt från mjukvaruutveckling. Allra bäst lämpar sig det agila angreppssättet när förutsättningarna liknar de som mjukvaruutveckling präglas av:

  • problemet som ska lösas är komplext
  • lösningen är i sin helhet inte känd vid projektstart
  • produktkraven kommer sannolikt behöva ändras under projektet
  • utvecklingsarbetet kan delas upp i moduler eller delsystem
  • nära samarbete med slutanvändaren och snabb feedback från dem är möjligt
  • kreativa team löser uppgiften på ett sätt överlägset hierarkiskt ledda grupper av individer.

Mer om under vilka förutsättningar ett agilt arbetssätt fungerar bäst finner man i artikeln Embracing agilei Harvard Business Review. Produktutveckling är ett exempel på ett givet område som vanligen uppfyller många av kriterierna ovan. Men överensstämmelsen mellan det agila synsättet och hur verksamheter behöver förhålla sig till kunder, värdeskapande, utveckling och omvärld i stort har över tiden ökat och det är inte svårt att hitta användningsområden.

Artikeln publicerades först på bloggen andersljungberg.nu

Bild av Anders Ljungberg

Anders Ljungberg

Vd Trivector LogiQ, Styrelseordförande Trivector-gruppen

Kontakt ››
Dela med dina vänner

Relaterade inlägg

Inspiration

Designa agila processer? 10 tips

Många verksamheter vill bli mer agila och skapa agila arbetssätt och processer, agila team eller göra hela verksamheten agil. Men hur planerar man inför en

Inspiration

Kan vi använda Scrum inom organisationer som inte jobbar med IT? Del 1

Som ramverk under ”agila-metoder”-paraplyet hittar vi bland annat Scrum, Kanban, Lean och XP (”Extrem programmering”), men idag är det inte bara inom IT-projekt vi använder

Inspiration

Kan vi använda Scrum inom organisationer som inte jobbar med IT? Del 2

I detta inlägg går vi in på hur man kan använda Scrum i sin verksamhet. Hur man kan organiserar aktiviteter, skapa tydligheten i uppgifter och