Agilt är en attityd styrd av värderingar
Alldeles nyligen fick jag möjlighet att lyssna på deltagare som gick en kurs i agil kravhantering där det fördes bra diskussioner kring en sådan brännhet fråga som agilitet och kravdokumentation. Av deltagarnas berättelser och funderingar framgick det att det fanns personer i deras omgivning som hävdar saker om agila metoder som inte är korrekta. Inte förvånande men beklämmande. Tyvärr sprids det fortfarande missförstånd som är direkt värdehämmande. Speciellt när det gäller kravhantering ställer detta till det för många verksamheter. Scrum, Kanban, XP, Test-driven development (TDD), etc., är alla vägledande paketeringar av hur man kan arbeta agilt. Men paketeringarna är på intet sätt kompletta eller dogmatiska. Agilt arbetssätt garanteras inte av en metod. Agilt är en attityd styrt av värderingar.
Källan till det agila förhållningssättet är sammanfattat i det agila manifestet. Ett manifest, generellt sett, är en programförklaring och således det som utgör grunden för en ideologi och som uttrycker principer, policies eller intentioner. Det agila manifestet är således fundamenetet och principerna som ska leda vårt arbetssätt. Det sammanfattas i 4 meningar och ett förtydligande.
- Individer och interaktioner framför processer och verktyg.
- Fungerande programvara framför omfattande dokumentation.
- Kundarbete framför kontraktsförhandling.
- Anpassning till förändring framför att följa en plan
Det vill säga, medan det finns värde i punkterna till höger, värdesätter vi punkterna till vänster mer.
Det finns alltså värde i det till höger. Allt annat är en vantolkning av det agila manifestet.
Missförstånd 1: Agilt innebär att man inte dokumenterar krav.
Ett agilt arbetssätt gör i grunden upp med kravhanteringsprocesser som säger att alla krav ska samlas in och komplett dokumenteras innan utvecklingsarbetet tar vid. Men det agila manifestet säger ingenting om att man inte ska dokumentera krav. Det agila manifestet försöker kommunicera en inställning som säger att det inte är värdefullt att fokusera på att skriva omfattande kravspecifikationer – syftet är ju trots allt att skapa ett fungerande system. Agilt innebär att man reflekterar över hur mycket som ska skrivas och när – om alls – man ska skriva färdigt dem. Följande bild illustrerar alltså principiellt ett icke-agilt angreppssätt:
Notera: icke-agilt angreppssätt. Det betyder inte att kravdokumentationen måste elimineras. Den stora utmaningen är istället att avgöra om det finns kravdokument som eventuellt är värdefulla, hur de ska se ut och på vilket sätt de ska tas fram. Detta är något som varje organisationen själv måste komma fram till. Fråga exempelvis vad som händer om de tas bort. Vem saknar dem och varför? Vilka problem uppstår? För kortlivade system eller produkter så kan det vara direkt värdeslösande att dokumentera krav. För mer långlivande eller komplexa system eller i en föränderlig organisation kan det vara mer värdefullt.
Om någon ser ett värde i att strukturerat dokumentera krav så kanske det finns ett värde i det och då ska det kanske göras. Beskriv gärna det värdet och kommunicera till alla involverade. Och tänk på att bara för att du inte har hört någon säga det betyder inte att det inte finns någon som har behovet. Lika lite som det kan vara programmerna som kommer att använda systemet, lika lite kan det vara programmerna som har användning av dokumentationen. Kanske är det produktägaren som har stöd av ett sammanhang och en förståelse för all egenimplementerad funktionalitet i ett standardsystem? En begränsad, användbar dokumentation fyller därmed ett värde och kan på ett agilt sätt tas fram inkrementellt. Det agila förhållningssätt kan således se ut så här:
Hur kraven sedan ska dokumenteras för att nå det rätta värdet kan diskuteras. Och då kommer vi till missförstånd #2.
Missförstånd 2: Användningsfall är inte agilt och definitivt inte Scrum.
Vi börjar med att användningsfall inte är agilt. För det första har jag tidigare konstaterat att det agila manifestet förtydligar att det finns ett värde i dokumentation. För det andra måste inte användningsfall betyda omfattande dokumentation. Faktum är att de väldigt sällan bör betyda det. Om ni exempelvis har över hundra användningsfall för ett system har ni troligen gjort något fel (troligen råkat göra funktionell nedbrytning).
För det tredje måste inte alla användningsfall bli ”färdiga” innan inkrementen påbörjas. Faktum är att det är en utopi att tro att ens ett enstaka användningsfall kan skrivas helt korrekt och komplett innan implementation tar vid. 60-90% färdigt kan det möjligen bli innan första kodraden skrivs men komplett kan det inte bli förrän under utvecklingsarbetet. Det betyder inte att det måste göras komplett. Vill man förvalta sin kravdokumentation, vilket betyder att den ska beskriva faktisk implementerad funktionalitet, så bör man ha en aktivitet i sina inkrement som innebär uppdatering av kravdokumentationen.
Det går således utmärkt att ha ett agilt förhållningssätt till användningsfall. De är ett utmärkt modelleringsverktyg för att förstå vad man ska göra innan man börjar designa och implementera. Och du måste alltså inte förvalta dem.
Och så lite mer ved på elden: Alistair Cockburn /ˈkoʊbərn/, en av de som varit med och formulerat och undertecknat det agila manifestet, har också skrivit boken ”Writing effective use cases”. Och tidigare har jag skrivit om Ivar Jacobssons Användningsfall 2.0. Till och med Dean Leffingwell tar i sin bok ”Agile software requirements” upp användningsfall (och hänvisar till Alistair!).
Scrum då? Är inte det synonymt med användarhistorier? Nja, Scrum i sig förespråkar inte användarhistorier. Visst har användarhistorier blivit i det närmaste synonymt med agila metoder i allmänhet men det är inte ett måste att använda det. Ken Schwaber och Jeff Sutherland, upphovsmännen till Scrum, har skrivit den definitiva guiden till Scrum. Inte på ett enda ställe står det att krav ska skrivas som användarhistorier. Vad det däremot står är backlogen fylls på med poster – men ingenting om att dessa poster ska vara användarhistorier. Det kan alltså vara det men måste inte.
Användarhistorier är ett sätt att beskriva vad användare vill göra med systemet och fungerar som en bas för att utveckla systemfunktionalitet. Det används mycket i agila angreppssätt men det är inte nödvändigt att göra så i Scrum och det är definitivt inte det enda sättet att fånga underlaget för att bygga systemfunktionalitet. Användarhistorier räcker inte för att förstå vad som ska byggas (kvalitetskrav, acceptanstest, …). Och det är sannerligen inte det bästa sättet att dokumentera förvaltningsbart (sammanhang saknas).
Beteenden är lätta att påverka, attityder är svårare att ändra, värderingar upplevs ofta som orubbliga. Kanske är det därför agilt arbetssätt kan vara svårt att få till?
Sammanfattningsvis: agilt är en attityd som styrs av värderingar. Det är allt. Paketeringar i form av Scrum, Kanban, etc., ger dig praktiska råd och riktlinjer – ett beteende – att följa. Resten måste anpassas till din organisations behov. Bilden ovan är en generell illustration av vad som styr individuella handlingar. Beteendet är det omgivningen tar del av. Detta styrs av de under ytan dolda attityderna som i sin tur styrs av de grundläggande värderingarna.
Långsiktigt förändring kräver förändring av värderingar och framförallt attityder. Att direkt applicera Scrum eller Kanban kan ses som kognitiv beteendeterapi men alla svaren ligger inte i metoden. Det finns inte heller en färdig metod eller ett färdigt arbetssätt som passar för alla organisationer och verksamheter. På sikt måste man förstå principerna, attityderna och förhållningssättet. Arbeta med ledarskapet. Finns inte förutsättningarna eller om du bryter mot någon princip – ja, då kan du naturligtvis inte förvänta dig att få alla de vinster som angreppssättet utlovar.
Intressant och vi kan bara bekräfta att människors värderingar styr deras ageranden och skapar energi men också tar energi. Förmågan att ha ett agilt agerande varje dag och ta till sig nya kunskaper och applicera dem på varje given ny situation, det är så dagens uppdrag och utmaningar är i arbetslivet.
Därför är det viktigt att kunna vara konkret i denna fråga och ge sig själv och andra insikt samt skapa medvetenhet vad det är hos mig som styr detta beteende och om det överhuvudtaget är något jag gillar.
Alla är inte nyfikna eller förändringsbenägna och det finns heller ingen värdering i sig i detta. Om ni inte redan tittat på detta finns det en analys som vi arbetar med som heter ArbetsrelateratDNA™ och som hjälper individer och företag att skapa medvetenhet kring denna fråga.
Ett ArbetsrelateratDNA™ kan sen kopplas mot VerksamhetensDNA™.
Vi tar gärna en dialog kring detta för att skapa nytta och öka medvetenheten.
Tack Marika för din kommentar! Håller verkligen med om att det är viktigt att själv bli medveten om sina drivkrafter och egenskaper och att inte lägga en värdering i sig i vad som är ”rätt” eller ”fel”.
Intressant med ArbetsrelateratDNA™. Tack för tipset!
Johan, väldigt bra skrivet. Jag håller fullständigt med och gillar verkligen sista bilden. Den visualiserar så bra vad man måste jobba med för att på riktigt genomföra en förändring i en organisation.
Tack för din feedback, Thomas!
Ja, det är i alla fall EN bild som hävdar att det finns en koppling mellan värderingar, attityder och beteenden.
En studie från 1969 påvisade att kopplingen mellan attityder och beteenden är låg eller obefintlig men senare studier (2005) har visat att det visst finns ett samband. Men kopplingen mellan ALLMÄNNA värderingar och specifika attityder och beteenden ska tydligen vara låg.
Källa: http://lennartsjoberg.blogspot.se/2009/11/vardegrunder-attityder-och-beteende.html
Nå, fortsatt forskning får visa. Jag tycker dock också att modellen tjänar sitt syfte bra här.
Hej Johan! Jag jobbar med att arrangera och leda UGL-kurser och får allt fler deltagare från IT-sektorn. De pratar om agilt arbetssätt, vilket har gjort mig nyfiken på att veta vad det handlar om. Har googlat på detta och hamnade då på din sida. Såg till min glädje att du har med bilden på bojen som var en del av deltagarmaterialet i UGL före 2008. Numera är den borttagen ur deltagarmaterialet, men jag brukar använda den för att påvisa vad jag som chef måste arbeta med d v s påverka beteende.
Av det jag hittills förstått (tror jag) om agilt arbetssätt, tycker jag att UGL är en utbildning som passar som hand i handske för dem som leder agila projekt. UGL beskriver vad som händer i gruppers utvecklingsfaser, hur jag som ledare kan förstå i vilken fas gruppen befinner sig och hur jag skall styra gruppen i resp fas mot mognad och självständigt arbete. Jag tolkar att när man lyckas med det agila arbetssättet är man en mogen och effektiv grupp. Kan det stämma?
Därtill kommer OBM – Organizational Behavior Management, som kan sägas vara kbt tillämpad på ledarskap och organisationer. OBM säger att vi människor styrs mer av konsekvenser (positiva eller negativa) på mitt beteende än av kommunikation t ex vad jag blir tillsagd att göra. Feed-back är är den enklaste, men kraftfullaste konsekvensen, och positiv feedback är det mest effektiva i att påverka beteende. Vi erbjuder utöver UGL även kurser i OBM, vilket har blivit mycket uppskattat av deltagarna. Bilden på bojen tydliggör varför det är svårt att påverka människors beteende genom att försöka ändra värderingar. Däremot säger OBM, att om man påverkar beteende och det så småningom blir det naturliga beteendet i gruppen, har man skapat en värdering/norm i gruppen. För detta krävs förstås både självinsikt, insikt om mycket annat och idogt arbete hos den som leder gruppen.
Lästips: Susan A Wheelan: Att skapa effektiva team
Leif E Andersson: OBM – Ledarskapets psykologi.
Hälsningar
Elisabeth Berggård
Tack för ditt inlägg och intressant koppling till UGL, Elisabeth!
Jag tycker du har många bra poänger med behovet av ett gott ledarskap för agilt arbetssätt. Det krävs – förtuom kunskap – självinsikt och erfarenhet för att lyckas riktigt bra med agila metoder. Först då kan man bli effektiv. Så jag tycker du har rätt i att det behövs en mogen grupp för att lyckas.
Jag vill passa på att poängtera följande: utvecklingsteamet är självorganiserande och leder sig själv. De bestämmer i princip själv hur de ska jobba, när de ska jobba och vem som ska jobba med vad. Den icke-teammedlem som ska ”leda” ett sådant projekt måste naturligtvis vara tillräckligt kompetent för att kunna förhålla sig till detta på rätt sätt vare sig det är chefen eller den som agerar ”Agile Master” (metodexperten som leder teamet rätt). Naturligtvis finns det inte sällan en utmaning i att inte alla i ett team gillar att ta allt det ansvar som det innebär. Det kan vara en faktor som försvårar införandet av agila metoder.
Att den där V-A-B-modellen är borttagen ur UGL-kuren beror kanske på att den inte har stöd överallt och att det är svårt att finna forskning som stödjer den rent allmänt. Men den tjänar sitt syfte gott här och det är en rätt bra modell tills ytterligare forskning gör oss klokare. Se min kommentar på Thomas inlägg. Ytterligare en invändning:
”Värderingar styr inte beteende – det är tvärtom”
http://leffee.blogspot.se/2009/11/varderingar-styr-inte-beteende-det-ar.html
Detta tycker jag relaterar lite till det du skriver om OBM och att konsekvenserna styr oss. Ja: vi gör väl mest det vi mäts på.
Snabb återkoppling är annars en ytterst viktig faktor i agil utveckling. En anledning är att det är mycket lättare att värdera det som man ser och kan testa än att värdera det som är beskrivet ”på papper”. Men en annan anledning är att ge möjlighet att anpassa sig baserat på just konsekvenser av den senaste månadens arbetssätt (”inspect and adapt”).
Tack för lästipsen!
Tack för mer input i mitt sökande efter att förstå hur det agila arbetssättet är tänkt att fungera. Försvarshögskolan tog bort ”Bojen” ur UGL-materialet just för att den inte hade vetenskaplig förankring.
Kul med bloggen du hänvisar till. Det är just Leif E Andersson som har skrivit den, han som har skrivit boken jag tipsade om, ”OBM-Ledarskapets psykologi” .Det är också Leif som kommer att leda kursen som vi arrangerar i november. När jag pratade med Leif om ”Bojen” så ritade han upp att påverkan går i huvudsak från beteendet ner till värderingar, inte som man skulle tro att värderingar styr beteende. Det bästa med bilden, är att man förstår att man måste försöka påverka det som är synligt, det som är ovanför ytan. Det gäller att ha tydliga ”spelregler”. Folk kan spela fotboll och nå gott resultat oavsett varifrån man kommer och oavsett vilka värderingar man har, eftersom spelreglerna är tydliga. Så borde det vara också i arbetslivet.
Minsann! Var det densamme Leif E – det lyckades jag förbise. Vad roligt att det var densamma.
Mycket intressant och ett bra förtydligande! Leif E skriver ju också:
”Om det du kallar värderingar är din inlärningshistoria av konsekvenser så håller jag med om att värderingar påverkar beteenden. Det svåra med det vi vet om jaget idag är att det ställer våra inlärda föreställningar på huvudet. Begrepp som värdering får en annan mening när man förstår att jaget är en uppdiktad berättelse, en sorts efterrationalisering av beteendet.”
Trevligt med dialog kring värderingar!
Vad som är rätt eller fel är kanske inte i sig är viktigt. Vi arbetar med att ge folk en rimlig chans att förstå sina värderingar, vart de kommer ifrån och hur de påverkar dem i sitt agerande och hur de reagerar.
Det intressanta med detta är att människor, oavsett vad som satts upp i form av spelregler, ändå strävar, undermedvetet att leva sina värderingar eller undvika andra vars värderingar krockar med deras. De som gör detta med medvetenhet, kan också lättare hantera och agera i det professionella sammanhanget.
Forskningen visar vilka värderingar mänskligheten har och att det kanske inte är helt klart eller på en medvetandenivå för de flesta och att du kan leva någon annansvärdering utan att du är medveten om det.
Genom att bli varse detta ökar också självmedvetenheten och möjligheten att agera tillsammans med andra, välja de vägar som är bäst för en själv och prestera.