Blogg

Agil kravställning i en föränderlig värld

  • 26 april 2017
  • 1

Agil kravställning bygger på empiriska erfarenheter från tidigare lärdomar och anpassar sig efter de fakta och data som historiskt påvisat rätt väg framåt. En viktigt ingrediens till framgångsreceptet bygger på att vänta med beslut så länge som möjligt, då man i regel har mer och bättre underlag.

Artikelverktyg:

Agila kontrakt vs traditionella

När en kund-leverantörsrelation består av parter som är olika juridiska enheter så behövs det olika former av kontrakt tidigt i processen för att förplikta leveranser i enlighet med kontraktet före det att resurser allokeras och arbetet påbörjas. Detta kan tvinga fram för omogna beslut.

Vi som arbetar direkt mot externa kunder styrs ofta av ingående kontrakt och överenskommelser kring vad som skall levereras med en detaljerad kravspecifikation. Det som återstår att justera är då tid och resurser, något som agila metoder helt enkelt avser att ändra på genom att utmana traditionell logik med nya mer snabbfotade tankemönster. Ett sådant mönster är att låsa tid och resurser i så kallade iterationer och därmed låta omfånget (scopet) vara mer flexibelt, något som sedvanligt brukar hanteras precis tvärtom i traditionella projekt.

Kommunikation i ett agilt projekt

Transparens, ärlighet och tillit mellan medarbetarna är centralt i agila arbetsformer. För att kunna anpassa organisationen för att möta en kontinuerlig ström av förändringar och omställningar förväntas all kommunikation vara öppen och tillgänglig för alla.

Men funkar det verkligen så?

Moderna utvecklingsprojekt innehåller många rörliga delar och kraven kan ändras ofta samtidigt som mängden kommunikationsvägar ökar i takt med antalet medarbetare. Antalet kommunikationsvägar kan räknas ut med formeln C=N*(N-1). Lägger man sedan till att det finns många olika verktyg att kommunicera med hjälp av så blir antalet kommunikationsvägar upphöjt till antalet verktyg snabbt många olika kommunikationskanaler som medarbetarna behöver kommunicera via och risken ökar att kommunikation inte når avsedd mottagare på rätt sätt.

Svaret på frågan om all kommunikation är öppen och tillgänglig för alla i agila arbetsformer kan ha flera olika djup, men grunden är att det är bättre med öppen och tillgänglig kommunikation även om det inte alltid innebär att mottagaren har konsumerat budskapet på det sätt som avsetts. Genom att ha täta intervaller med kortare avstämningar och därmed erbjuder fler repetitionstillfällem, exempelvis stående morgonmöten med projektgruppen, minskar du risken för misskommunikation i takt med ökade repetitionstillfällen.

Kravställning i agila projekt

När företag snabbt anpassar sig till agila arbetsmetodiker så är det enkelt att förbise behov och processer för kravställning samt godkännande av kravställning mot leveranser. Detta kan bero på att man fokuserar uteslutande på interaktioner mellan människor i enlighet med agila värdegrunder och värderar samarbete med kunden framför att förhandla om kontrakt.

Att skriva bindande avtal kan vara utmanande om man försöker behålla styrfrihet och agilitet. För att säkerställa spårbarhet och auktoritet i besluten så skapas det nästan omänskliga förväntningar på att produktägaren skall kunna lösa alla beslut på egen hand. Tidigare beslutskedjor som påvisar att beslut har förankrats djupt i organisationen i fråga kan bli marginaliserade och istället skapas förväntningar att enskilda resurser ska kunna fatta nödvändiga beslut, helst på stående fot och med övertygande självsäkerhet.

Backloggen - en nyckel till icke funktionell kravställning

Det är produktägaren som ytterst ansvarar för att backloggen är prioriterad efter affärsmässigt värde och redo för att teamet skall kunna plocka arbetspaket från toppen av backloggen.

Men är så det fungerar i verkligheten?

En backlogg som endast är prioriterad efter affärsmässiga värden är inte alltid det mest lämpliga. Det finns ibland ambitioner som ämnar att fokusera på att reducera Teknisk Skuld, d.v.s saker som inte har överenskommen kvalitet och som behöver korrigeras för att inte bli en för stor belastning. Att kontinuerligt kvantifiera den tekniska skulden är viktigt då det har direkt bäring på livscykelhantering, effektmål och framtida beslut. Teknisk skuld kan jämföras med ränta på ett banklån. Har du för mycket räntebetalningar så håller det dig tillbaka från nya investeringar och på samma sätt fungerar refaktorering av den tekniska skulden. Det finns även andra likvärdiga aspekter att väga in då en backlogg synas, som exempelvis resurstillgång och tekniska aspekter.

En väl fungerande backlogg är levande och förändras kontinuerligt och med många ögon på sig så säkerställs det att flera olika önskemål vägs in. Rekommendationen är att kontinuerligt trimma (grooma) backloggen baserat på tre huvudfunktioner - affären, teamet och tekniken. Ett komplement till standardrollerna i ett agilt team kan därför med fördel vara en utsedd teknisk ledare med mandat att påvisa tekniska värden – en så kallad Solution Lead (lösningsarkitekt), se bild nedan. På så sätt säkerställer du att den tekniska kravställningen inte glöms bort. 

Genom att tillämpa ovan roller för att kontinuerliga trimma backloggen så får du fler aspekter som vägs in mot prioriteringar och en dialog kring icke funktionella kravställningar möjliggörs.

Med icke-funktionella krav så menas de kvalitetsegenskaper och implicita kvalitetskrav som samexisterar med de funktionella kraven. Några exempel på icke-funktionella krav är säkerhet, skalbarhet, prestanda och tillgänglighet. Dessa är viktiga fundament för att möjliggöra DevOps-flöden och faciliteterar att byggen, tester, kvalitetensmätningar, konfiguration och styrning finns, efterlevs och ligger i linje med avtalade mål. Genom att förbättra samarbete och automatisera så mycket som möjligt så säkerställer DevOps positiva synergier som att det går snabbare och blir bättre kvalitet i leveranserna.

Nyckeltal behövs längs hela resan för att projekten skall säkerställa att rätt kvalitet byggs, varken mer eller mindre utan precis på målet.

Agil kravställning hanterar verkligheten

Den verklighet vi infinner oss i ryms inte inom ramen för en simpel modell och kraven ändras i takt med nya insikter. Detta sker ibland snabbare än att kontrakt och avtal hinner skrivas om. Förutsättningar kan idag ändras snabbare än organisationer hinner ställa om sig, vilket medför missade affärsmöjligheter och i vissa fall värre utgångar.

Genom att välkomna förändring och kontinuerligt lärande från tidigare erfarenheter, införa fler pilotprojekt och arbeta iterativt så är du på god väg. I synnerhet tillsammans med en partner som har gedigen erfarenhet av digitalisering, effektiv kommunikation och beprövade metoder så att du som kund kan komma till avgörande insikter och strategiskt kan anpassa målstyrningen även i en föränderlig värld.

Vill du veta mer om agil kravställning?

Varmt välkommen att kontakta oss via formuläret så berättar vi gärna mer. 

1 kommentar

Skriv kommentar

Just avtalsbiten är oerhört viktig - och komplex - att hantera för att kunna uppnå ett framgångsrikt agilt projekt på konsultbasis.
Ofta pratas det om "agilt" som om det helt och hållet skulle vara ett arbetssätt för teknisk utveckling. Det är givetvis inte sant, men även om man skulle göra en sådan avgränsning så krävs det ett avtal i botten som främjar Samarbete (!) mellan leverantör och konsult.
Idag säljs "agilt" in som ett självklart val i samband med en pitch exempelvis, men när pitchen är vunnen och avtal ska skrivas - jag då vill kunden/beställaren plötsligt veta EXAKT vad de kommer att få i termer av funktionalitet, vad det kommer att kosta på öret, och när det kommer att "vara klart". Ungefär som att en mjukvaruprodukt någonsin blir klar...
Inte konstigt att team runt om i världen sliter sitt hår med att få till en effektiv agil arbetsmetod när de är bakbundna av ett klassiskt, icke-agilt, leverantörsavtal.