ProAgile blog

Här kan du följa vad vi tänker på och jobbar med.

Följ vår RSS-feed eller lägg till bloggen på Feedly, så får du alltid de senaste bloggposterna.

Vad är ett korsfunktionellt team för dig?

Att ett utvecklingsteam bör vara korsfunktionellt är något som de flesta vet, men när man diskuterar vad som menas med ett korsfunktionellt team går åsikterna förvånansvärt ofta isär.

En vanlig uppfattning jag har stött på, är att man bör sträva mot alla i teamet ska kunna allting lika bra. Att en teammedlem är utbytbar mot vilken annan som helst. Lite som klonerna i Star Wars. Det låter ju väldigt effektivt att när någon, låt oss säga Boba Fett, är sjuk eller upptagen med andra uppgifter, kan vem som helst i teamet rycka in och göra ett lika bra jobb.

team of clones

Det kan nog fungera bra, men det finns även risk för vissa bieffekter. I ett team jag jobbade med visade det sig att teammedlemmar tjuvhöll på information och kunskap istället för att dela det till sina arbetskamrater. Detta för att känna att de ändå kunde lite mer än de andra inom ett område och inte riskera att bli utbytbara.

Forskning på hur man bygger effektiva team (exempelvis R. Hackman, "Leading Teams") har visat att det behövs ett visst mått av beroende mellan teammedlemmarna i arbetet med att uppnå de gemensamma målen. Om alla kan arbeta oberoende av varandra för att lösa uppgiften är man snarare en arbetsgrupp än ett team. Ett team behöver samarbeta för att nå sina mål.

Ett annat team jag var i, delade förvisso all kunskap och information, men området var helt enkelt för stort för att alla skulle kunna lära sig alla detaljer. Inte ens tillsammans hade de tillräckligt med kunskap för att kunna lösa alla uppgifterna riktigt bra.

Om alla är experter?

Med det resonemanget borde ju motsatsen vara det allra bästa, där alla är experter på varsitt område. Teamet kan fortfarande lösa alla uppgifter, men det är bara en person som kan lösa uppgifter av en viss sort. Det borde väl bli effektivt och bra? Dessvärre blir det ju oftast inte det. Ett sådant team får ofta vänta på varandra, arbetsbelastningen blir ojämn och medlemmarna i teamet är inte alltid speciellt intresserade vad de andra gör eftersom de precis som i exemplet ovan inte heller här är beroende av att hjälpa varandra.

Den magiska formeln

Så man ska inte ha ett team med bara experter och inte heller ett team där alla kan precis allting lika bra. Ni har säkert hört termen T-formad. Att varje teammedlem har sitt eller sina ”expertområde”, men även kan göra andra saker och hjälpa sina kollegor med andra uppgifter vid behov. Det minskar risken, ger redundans om expert A skulle bli sjuk eller sluta och kan även minska arbetsbelastningen.

Hur hittar man då den optimala fördelningen på expertis och bredd, vad är den magiska formeln när man bygger ett effektivt och väl fungerande team? Som så ofta annars är svaret; det beror på. Det är olika från team till team. Jag vet, det är ett jättetråkigt svar. Men man kan trösta sig med att det som har störst påverkan om ett team blir effektivt eller inte är helt andra faktorer.

Mina bästa team

De mest välfungerande team som jag har jobbat med har ofta varit en samling helt olika individer, vissa personer mer olika än andra, var och en med olika egenheter. De har sällan inte speciellt mycket gemensamt utöver ett brinnande intresse för utveckling. Men det som har varit gemensamt för de här teamen är att ingen har sett olikheterna dem emellan som ett problem. Istället känner alla varandras sämre sidor såväl som goda och accepterar dem.  Alla känner en väldig trygghet i att få vara sig själv.

Efter att ha sett det här över åren, men inte ha mer än min egen magkänsla som bevis, var det väldigt häftigt för mig att läsa om Google’s Aristotelesprojekt, som ju pekar på precis det här, att de mest effektiva teamen får man när alla teammedlemmar känner sig psykologiskt trygga.

Så ett bra recept för ett lyckat korsfunktionellt team tänker jag är att teammedlemmarna samarbetar för att nå de gemensamma målen, att varje individ generöst delar med sig av sin kunskap och expertis, men behåller och får känna sig trygg och avslappnad i sin personlighet.

Så istället för att skapa team där alla är precis lika, våga variera! Det finns troligtvis alltid någon som kan ersätta din kompetens, men det finns ingen annan som är precis som DU!

 

Mångfald i team

Parjobba

Du kanske har hört talas om parprogrammering? Det är när två utvecklare sitter vid samma dator och skriver kod tillsammans. En del som inte provat eller inte fått det att fungera kan hävda att det är ineffektivt. Jag skulle vilja hävda motsatsen. Man lär sig mer, det blir högre kvalitet, man behöver inte vänta på att någon annan ska granska resultatet. Man blir klar med en uppgift snabbare. Det blir ett bättre flöde helt enkelt. Jag vill hellre kalla det att parjobba. För det funkar på så mycket mer än att programmera. Det kräver dock övning för att man ska bli bra på det, som allting annat.

Vi på ProAgile vill parjobba. Inte bara när det gäller utveckling av kod. Utan även när det gäller utveckling av människor, team och organisationer. Så vi försöker parjobba när vi skapar kurser, när vi förbereder kurser samt när vi håller kurser. Vi försöker även parjobba när vi skriver offerter, bloggar eller skriver nyhetsbrev eller när vi faciliterar workshops, meetups eller andra event.

Parjobba som facilitator

I fredags hade vi vår månatliga PA-dag. Det är en dag då vi jobbar med utveckling av oss själva och vårt bolag. Dessa dagar har traditionellt faciliterats av någon av oss. Vem som faciliterar bestäms i stunden. Det kan variera från moment till moment.

Inför PA-dagen i förra veckan så tog jag och min kollega Bodil på oss ansvaret att facilitera hela dagen. Vi skulle parjobba som facilitatorer. Det innebar lite planering och förberedelse av dagen, facilitering under dagen samt lite efterarbete med att dokumentera resultatet. Vi planerade agendan (strukturen) tillsammans, dvs de olika blocken men inte innehållet. Vi tog fram ett förslag till en agenda som vi sen förankrade med de andra innan vi satte igång.

Vi turades om att vara drivande i faciliterandet. Då blir det lättare att ha fokus på det pågående momentet. Den som inte driver just nu kan fokusera på nästa moment. Det blir bättre flyt och mindre påfrestande. Dessutom ger det möjligheter till lärande, jag kan få direkt feedback på mitt faciliterande. Jag kan också inspireras av min kollega Bodil i hur hon tog sig an vissa moment.

Parjobba i lärande

Vid en tidigare PA-dag så organiserade vi s.k. lärandepar. Dessa lärande par har till syfte att öka vår möjlighet att parjobba. Vad vi jobbar med i paren är upp till de enskilda paren. Jag och Bodil bildade då ett lärandepar. Vi har jobbat med att skriva offerter, coacha varandra, förbereda tal inför Agila Sverige, förbereda vår sommarfest och en hel del annat. Jag upplever att jag lär mig massor av att parjobba. Vi lär också känna varandra bättre och det bygger samman vårt team.

Vad tänker Du om att parjobba?

Parfacilitera
Parjobba

Under min karriär med att jobba i team och coacha team har jag haft en enkel inställning till vad som är viktigt för kontorslokaler och att få ett utvecklingsteam att trivas och jobba bra:

“Ge teamet möjlighet att sitta tillsammans!”

Utmaningar

Det kan låta enkelt men i praktiken har jag stött på en hel del utmaningar med att få till det, tex:

  • Vi behöver riva den där väggen för att få till en större yta!

med svaret

  • Det går inte, det kostar 50 tkr att ta ner den väggen

…trots att studier som visar att samlokalisering fördubblar teamets förmåga, värt miljoner på årsbasis.

eller

  • Det är så trångt att varje ändring kräver att alla flyttar på sig i en sorts femtonspel.
Femtonspel

Vanliga lösningar...

Jag har sett några olika sätt att lösa det genom åren:

  • När Agilt var ungt tog ett team och flyttade ut ur sina kontor och ockuperade något mötesrum och använde det som teamrum
  • I ett öppet landskap flyttar man ihop skrivbord och använder lite skärmväggar för ljudavgränsning

Jag har även träffat företag med så kallade “aktivitetsbaserade” lösningar i sina lokaler. Jag har hittills trott att det innebär företaget försöker spara pengar och lokalyta genom att ha färre sittplatser än det finns anställda (eftersom några alltid är på tjänsteresa, sjuka eller lediga) och man tar ett rullbart skåp med sina grejer och går till ett ledigt skrivbord på morgonen. Jag har tänkt att detta inte passar ihop med agila team… tills jag fick förmånen att prata med en expert på området.

Expertens syn

Efter att ha pratat med Jonas Hurtigh Grabe på Veldhoen, som är expert på aktivitetsbaserade arbetsplatser, inser jag att vi delar väldigt mycket i vad som är viktigt för en bra arbetsplats.

Jonas menar att det handlar om

  • Den fysiska arbetsplatsen
  • Den digitala (möjlighet till videomöten etc)
  • Ledarskapet

Ett bra kontor ska ha en variationsrikedom och för ett agilt team innebär det att det finns möjlighet att sitta tillsammans för samarbete och även rum i närheten för ostört arbete.

En Arbetsplats

Jonas säger vidare att han sett exempel på kontor som varit så flexibla och innehållit så mycket variationsrikedom att man inte har behövt möblera om på 16 år. Man har förstås haft ändringar i arbetssätt, team har kommit till eller försvunnit. Team har växt eller minskat, men istället för att flytta möblerna har människorna kunnat röra sig i befintlig miljö.

Vad jag kan se, efter att ha pratat med Jonas, så delar det agila och hans sätt att se aktivitetsbaserat många värderingar tex:

  • Bättre samarbete och kommunikation
  • Kunna attrahera och behålla personal
  • En miljö som underlättar innovation

Vad är dina erfarenheter?

Kanske har du sett aktivitetsbaserat och agilt fungera bra ihop? Hör gärna av dig i så fall och dela med dig av dina erfarenheter.

Jag är glad att ha fått omvärdera min egen syn på aktivitetsbaserade arbetsplatser och hoppas på möjligheter framöver där det agila och moderna kontorslösningar kan samverka för bättre arbetsplatser.

Agila Sverige 2018

maj 31, 2018

Agila Sverige 2018

Jag sitter på tåget hem från Stockholm där jag varit på konferensen Agila Sverige 2018. Den hålls varje år i slutet av maj. Den är lite som en firmafest för oss som jobbar med att hjälp andra att bli lite bättre, vi som ibland kallar oss agila coacher.

Detta var andra gången för mig och denna gång hade jag förmånen att få dela med mig av mina erfarenheter i ett blixttal. Jag är full av intryck och försöker skriva av mig lite för att sorterar mina tankar. Det är ett sätt att hantera alla impulserna. För några år sen snubblade jag över en artikel på nätet från några agila coacher i Sydafrika om hur man kan dra mest nytta av en konferens. Ett av deras tips var att skriva om det man varit med om. Så håll till godo. Här kommer det och jag kommer sluta skriva när tåget är framme i Göteborg så det blir så mycket som jag hinner med på vägen hem. Det blir en utmaning i sig själv. En liten timebox för mig att skapa ett blogginlägg.

Spontana intryck från Agila Sverige 2018

Min känsla efter första dagen på Agila Sverige 2018 var att arkitektur är viktigt och att det kan hjälpa oss i vår strävan att bli mer agila. Det är också mycket intressant arkitekturen är starkt kopplat till organisationens struktur, hur organisationen är uppbyggd. Flera talare nämnde (eller lät bli att nämna) Conway’s Law som definierar dessa samband. En spännande sak med denna lag är att den är 50 år gammal och fortfarande stämmer. Är det en självuppfyllande profetia?

Min känsla efter dag två var att vad vi än gör så ska vi försöka dela ner det i mindre delar. Batchstorlek spelar roll för hur snabbt vi kan få fram nåt resultat som vi kan få feedback på. Det är nödvändigt för att ha så korta feedbackloppar som möjligt. Vare sig det gäller produkten, organisationen eller processen.

Blixttal på Agila Sverige 2018

Dagarna började med blixttal uppdelade i två separata spår, så vi besökare var tvungna att välja det ena eller det andra ur programmet. Ibland var det svårare än vid andra sessioner. Fördelen att man får in många blixttal under kort tid. En nackdel är att man kanske missar ett intressant tal för det ligger samtidigt som ett annat som man också är intresserad av. Men då kan man kolla in talen i efterhand eftersom alla tal spelas in och publiceras online.

Vi på ProAgile hade förmånen att hålla tre stycken blixttal:

Jag ska inte försöka mig på att rangordna eller ens nämna något specifikt tal (förutom de tre ovan) men det var många bra talare med många intressanta ämnen att välja mellan.

Open space på Agila Sverige 2018

Efter lunch båda dagarna, var det dags för oss alla bidra. Då var det dags för open space. Alla fick möjlighet att vara med och skapa innehållet i det som skulle diskuteras.

Jag fastnade för diskussioner om vilka som är med i ett team och vilka som är utanför. Hur ska vi tänka när vi vill att alla ska bidra på bästa sätt till utfallet och att maximera värdet i en organisation. Vi vill ju inte att personer ska sitta i sina silos och bara göra det som de är anställda för att göra. Vi vill att de ska tänka utanför hierarkiska strukturer och rollbeskrivningar.

Jag var också med i diskussioner kring teal-organisationer. Hur har andra gjort? Vilka utmaningar står de inför? Hur har de löst specifika problem? Det var en hel del intressanta tankar som delades där. Jag deltog också i en open space om hur man kan ta beslut med medgivande (consent decision making) som var mycket bra och givande.

Slutligen

Jag tycker det är roligt att mingla och knyta nya kontakter så jag gillar verkligen denna typ av konferenser. Ingen nyhet för er som känner mig kanske. Jag ser också detta som ett bra sätt att lära mig nya saker, skaffa nya kontakter, lära känna sådana jag redan känner lite till och att inspireras.

Tack alla som gjorde Agila Sverige 2018. Jag hoppas vi syns nästa år.

Gemensamt mål
Organisera tavlan
Utnyttja tavlan uppifrån och höger
Vad är viktigast nu
Minnesramsorna

Börja uppifrån och från höger

I ett tidigare inlägg har jag beskrivit hur man kan attackera scrumtavlan för att få ut det mesta av det dagliga mötet. Vad som oxå kan påverka hur värdefullt mötet känns, är hur man kan organisera scrumtavlan. Om det bara är lappar (eller motsvarande i ett digitalt verktyg) som är oorganiserade så är det svårt att få en gemensam bild av vad man håller på med. Jag har oxå sett team som filtrerar (den digitala) tavlan per person. Då får man ingen överblick och man kan missa beroenden mellan saker. Då är det oxå svårt att avgöra vad man måste göra för att komma framåt. Det är som i skogen eller på sjön, man måste veta var man är för kunna komma dit man vill i okänd terräng.

Organisera scrumtavlan för vad som är viktigast nu

Syftet med det dagliga mötet i Scrum är att teamet ska samplanera för att lyckas nå sprintmålet. Om man inte har ett sprintmål (och sålunda inte använder Scrum) så har man ändå nytta av mötet för att planera vad som är viktigast just nu.

Ett sätt att tänka som jag brukar lära ut är att fundera på hur man vinner. När och hur får man poäng i vårt spel? Det agila manifestet ger en fingervisning, "fungerande mjukvara...". Jag skulle vilja göra tillägget, "i rätt miljö". Räcker det med att ha fungerande mjukvara på min utvecklardator? Eller måste det ska vara hos kunden eller i produktionsmiljön?

Jag brukar ta hjälp av följande ordlek/förkortning på engelska. WIN = What's Important Now. Vad är viktigt att jobba med nu? Är det att färdigställa nåt som nästan är klart? Är det att starta nåt nytt?

De team som jag sett använda detta har haft stora framgångar i att jobba med rätt saker just nu.

Fyra områden att adressera varje dag

Genom att ha en tanke på vad vi behöver prata om vid det dagliga mötet så kan vi hantera både det akuta, det nödvändiga, samt förbättringar och framtiden. Jag brukar rekommendera att man kan prova att organisera scrumtavlan i fyra delar. Fyra olika rader/sektioner där överst är viktigast och underst sålunda minst viktigt, men inte oviktigt. De fyra delarna är:

  1. Akuta saker (hot issues, unplanned stuff) - tex buggar, störningar i driftmiljön och liknande saker som man måste ta tag i direkt. Gemensamt för dessa saker är att de är oplanerade saker som helt plötsligt dyker upp och som vi då måste hantera mer eller mindre direkt. Kanske att man måste släppa nåt annat ur någon annan kategori. Eller om det inte är så akut att det kan vänta till imorgon.
  2. Planerade saker (planned stuff) - tex funktionstillväxt mm. Saker som vi har förfinat och planerat att jobba med, helst nedbrutet till lagom stora paket (mer om lagom storlek en annan gång). Denna del av tavlan kan med fördel bestå av flera olika rader. En för varje värdefull sak (i form av user story eller liknande).
  3. Förbättringar (improvements) - saker som utvecklarna själva har funderat på som ger värde nu eller senare men som produktägaren inte ser kundnyttan med direkt.
  4. Framtiden (future, refinement) - undersökningar, nedbrytning och lärande om saker som vi ska jobba med senare. Sånt som vi måste förfina för att kunna ta med i nästa sprint.

Oplanerat och planerat arbete

En invändning mot detta sätt att organisera scrumtavlan kan vara att vi har bara user stories på vår tavla eftersom vi kör Scrum. Det är en helt legitim invändning. Jag har dock ALDRIG mött ett team (med eller utan Scrum), som slipper att hantera akuta saker på daglig basis. Därför är jag övertygad om att den första raden kommer till nytta. Sen kan man använda de andra för sina planerade saker och det är där Scrums styrka kommer in. Att fokusera på några få saker under en kort tid och se till att få det klart.

Sen hade det självklart varit fantastiskt om fler team kunde sluta skapa så många buggar. Då skulle den första raden inte behöva användas så ofta.

Bättre flyt och fokus

Genom att organisera scrumtavlan på detta sätt lyckas man adressera ett antal problem.

  • Vi kan hantera det viktigaste först. Är det buggar eller andra problem som vi måste ta tag i så släpper vi det andra för nu.
  • Vi glömmer inte bort förbättringar, de synliggörs genom att det finns plats för dem på tavlan. Sen måste man se till att prata om dem. Eller frånvaron av dem, om det inte finns några.
  • Vi påminns om att vi måste fundera på och jobba med framtiden. Om vi inte förfinar, undersöker och bryter ner planerat arbete så kommer vi att drabbas av små och stora överraskningar när vi jobbar med våra planerade saker längre fram i tiden.

Jag hade förmånen att hålla ett blixttal på Agila Sverige 2018 på detta ämne.

Utveckla visionen - utveckla oss själva

När vi har våra utvecklingsdagar så vill vi få ut så mycket värde av varandra och samarbetet oss emellan som möjligt under dagen. De brukar innehålla en del skapande, lärande, administration, bygga team, strategi, marknadsföring och rekrytering mm. Eftersom vi inte har några chefer på ProAgile kan inte en person bestämma vilka som ska göra vad. Vi har inte heller några specifika roller så vi får tillsammans välja vilka frågor vi ska ta upp i helgrupp och vilka ärenden som kan hanteras i subgrupper.

Vi börjar dagen med att skapa en agenda baserat på dessa områden och sen röstar vi fram det vi vill prata om. Agendan drivs ofta av passion (saker som folk brinner för) eller spänningar som vi upplever. Nåt som inte funkar tillräckligt bra. Det som kallas navigation by tension i Sociokrati 3.0. Vi vill att denna dag ska faciliteras, för att vi inte helt ska hamna på villovägar. Denna gången var det vår nyaste medarbetare Emelie som gjorde det med bravur. Tack Emelie för att du ledde oss igenom denna dag.

Utveckla visionen - tillsammans

En av lapparna/ämnena som kom upp på agendan var att vi skulle utveckla visionen ytterligare. Några veckor tidigare spenderade vi en helg tillsammans för att bygga ihop ProAgile-laget. Då jobbade vi vidare med vår vision. Den kom att innehålla vissa värdeord eller fraser som vi övade på att sätta in i vår personlig berättelse om varför vi vill jobba på ProAgile. Vi har insett att vår vision hänger starkt ihop med varför vi vill jobba på ProAgile. Detta var de värdeord/värderingar som vi kom fram till då.

  • Samarbeta, jobba tillsammans för att lära av varandra och göra större skillnad för våra kunder.
  • Blomstra och spira, vi vill utveckla andra och oss själva.
  • Skapa engagemang, att ge människor en bättre arbetsupplevelse och ett bättre liv.
  • Dela med oss av det vi kan och det vi lär oss.

Utveckla visionen - nästa steg

Vi tog oss tid (om än lite motvilligt) att öva på vår vision. Vi parade ihop oss för att öva. Jag fick förmånen att vara med Stefan och vi tränade på att berätta vår historia om varför vi vill jobba på ProAgile. När vi skulle börja skrev vi upp värdeorden ovan, på en whiteboard för att komma ihåg dem. Då skedde det magiska, som det ibland bara gör, när man är några personer framför en whiteboard. Stefan såg ett mönster och justerade våra ord lite. Samma innebörd, men annan ordning och lite annorlunda formulering. Samarbete, spira/blomstra, skapa engagemang och sprida kunskap.

Alla börjar på s. Nu hade vi fyra s (4 ess i leken eller i rockärmen). Det skapade nya tankebanor och mönster. Det blir lite snyggare och lite lättare att komma ihåg. När vi återsamlades i storgrupp så påpekade David att han saknade en ord, självbestämmande. Nu var det fem s. Vi övade lite till i par och då hittade vi ett ord till. Vi vill göra skillnad. Helt plötsligt har vi sex ord på s (6 ess). Det gör att vi har en hel del trumf på hand.

  • Samarbete
  • Spira/blomstra
  • Skapa engagemang
  • Sprida kunskap
  • Självbestämmande
  • Skillnad

Utveckla visionen - min vision

Jag försökte sammanfatta dessa ord i en mening som beskriver vårt syfte. Som tidigare nämnts så hänger detta tätt ihop med varför jag vill jobba på ProAgile. Min mening låter så här:

Jag vill jobba på ProAgile för att sprida kunskapskapa engagemang och göra skillnad genom samarbete och med självbestämmande så att vi alla spirar och utvecklas.

Men en mening kan inte förklara en vision. En vision för mig är nåt som tänder en passion i andra. Som skapar en längtan få att vara med. Ett engagemang. Det kommer inte ur meningen som sådan, utan mer ur hur vi berättar vår berättelse. Hur vi lever i och lever ut vår vision. Kan vi med våra egna ord förmedla den känslan till en annan individ och därmed tända en eld så kanske vi kan göra världen till en bättre plats.

En vision måste vara levande och aktuell samt nåt som alla känner delaktighet i. Om en ledare står och mässar en vision så brukar sällan massorna vara med. Vi måste alla leva i vår vision för att kunna hitta vägen mot den. Hur lever du i er vision?

Vision = vad man vill!

En av mina stora inspirationspersoner är Kjell Enhager. Senast jag lyssnade på honom så förklarade han ordet vision som nåt man vill. Då kom jag till insikt. Min vision är det jag vill. Så det som lite fluffigt kan kallas vision är egentligen så enkelt som det man vill! Då blir det lite lättare att förstå vad det handlar om och lite lättare att ta på. Vad vill jag? Jag vill göra världen lite bättre, ett team, en organisation i taget! Det gör jag på ProAgile. Vad är din vision? Dvs vad vill du?

Innehåll PA-dag
En feedback loop

Va? Är inte Sprint Demo en fantastisk idé?

Visst, grundtanken när man kör en Sprint Demo är ofta god. Man vill ha feedback. Så långt är allt bra, men att köra Sprint Demo för med sig ett antal problem också.

Att köra en demo efter varje sprint leder oftast till missade releasedatum, teknisk skuld och till felaktiga prioriteringar!

Så många och stora problem orsakas av Sprint Demos att jag skulle vilja be er alla att genast plocka bort dem från era kalendrar.

Men Sprint Demo är väl en del av Scrum?

Nej, faktiskt inte. Det finns en liknande sak i Scrum som heter sprintgranskning (eng. Sprint Review), men det är en väldigt annorlunda aktivitet jämfört med det som oftast kallas “demo”.

Inte för att det spelar någon roll om ni följer Scrum eller inte, men i just det här fallet tror jag att de flesta skulle kunna få ut mer värde genom att byta från “demo” till “granskning”.

Vad är skillnaden på en demo och en granskning?

Syftet

  • Tänk dig att en försäljare demonstrerar en produkt för dig. Syftet är att få den att se bra ut. Kanske att ge en applåd från publiken när de ser hur snyggt och bra allt ser ut!

  • En granskning har däremot syftet att skapa en verklig förståelse av hur det ligger till med något. Utan försköning. Bra eller dåligt. Om man vet hur man ligger till kan man göra planer, prioriteringar och fatta beslut som bygger på fakta. Får man en felaktig uppfattning om hur man ligger till blir planerna opålitliga och besluten fel.

Samspelet

  • En demo är oftast en enkelriktad aktivitet. Någon visar upp/demonstrerar något.

  • Deltagarna i en granskning däremot är aktiva och letar efter fel som kan åtgärdas och förbättringar som kan göras.

Kvalité

  • Jag har varit med och byggt demos för många olika kunder. Det kan vara för en kundpresentation eller för en mässa t ex. Stressen är ofta stor för att få med så mycket som möjligt och för att få produkten att se bra ut.

    Tillfälliga lösningar och genvägar tas till för att hinna. Kvalitén är långt ifrån det man vill ha i produktion och alltihopa borde helst kastas bort och göras om för att kunna vara en del av en kvalitetsprodukt. Kunderna får dock intrycket av att det är klart vilket ökar pressen ännu mer. Dålig kvalité börjar smyga sig in i produkten.

  • På en sprintgranskning går man bara igenom de saker som lagts till i produkten och som uppfyller Definition of Done. Dvs de har full tekniskt kvalitet och är klara för produktion.

    En bra Definition of Done innebär att man kan lägga en story/feature åt sidan när den passerat. Man behöver inte gå tillbaks till den för att göra klart någon del eller rätta tekniska defekter i framtiden.

    Eftersom man inte behöver gå tillbaka till en feature/story kommer den inte att påverka de framtida planerna.

    Det kan ta ett par år att komma hit som organisation. Automatisering av test/regressionstest brukar t ex vara en utmaning. Likaså brukar det ta ett tag att införa vanan att refaktorera fungerande kod tills den är lätt att läsa och ändra innan man räknar den som “Done”. Men när man lyckats blir allt mycket lättare. Tid som man förr lade på att rätta gamla saker frigörs. Man kan fokusera på nya saker, får snabbare progress och en roligare arbetsmiljö.

Ett exempel

 

15 teams som integrerar

I en organisation som jag jobbade med hade vi ca 15 teams och körde demos efter varje sprint. Alla teams hade jobbat hårt och gjort en massa saker. På demon berättade de om allt de gjort och visade små filmer. Alla var glada och det verkade rulla på bra med utvecklingen. Det verkade dock som att det alltid var något lite kvar att göra för varje sak innan den var riktigt klar. Det mesta var 90% klart…

Efter demon skulle produktägarna uppdatera sina prognoser/tidplaner. Det här var en del av en stor organisation med många beroenden utåt, så det var viktigt att kunna visa hyfsade prognoser mot externa teams så att de kunde anpassa sin planering.

Vad var problemet?

Hur mycket utvecklingstid återstår då på en feature som är 90% klar? Vad skulle produktägarna räkna med i sina planer? Problemet är att ingen vet det. Innan vi är helt klara kan det alltid dyka upp nya oväntade problem. Små som stora. När det är 90% klart, kanske 90% återstår...

Effekten av att jobba så här är att när man närmar sig någon viktig leverans så är allt 90% klart och ingen har en aning om hur man ligger till. Alla får jobba övertid och endera missar man leveransen eller så släpper man ut en tekniskt undermålig produkt. Felen strömmar in och man får betala dyrt i form av bortslösad tid. Rättningar tar normalt sett minst 5-10 gånger längre tid än vad det tagit att göra rätt från början. Stressen ökar och kvalitén sjunker ännu mer.

Omgivningen blir missnöjd över kvalitén och den dåliga precisionen i planeringen. För att få koll börjar ledningen kräva mätvärden och detaljstyra teamen. Statusrapportering av felrapporter kommer i fokus istället för nyutveckling och innovation. Mätvärden i form av “velocity” gör att kvalitén försämras ytterligare när teamen tar genvägar för att visa upp bra resultat.

Vad vi gjorde

Det här var fortfarande i ett ganska tidigt skede i ett nytt utvecklingsinitiativ. För att förekomma alla de här dåliga konsekvenserna bytte vi namn på Sprint Demo till sprintgranskning och införde nya regler. Bara det som uppfyller Definition of Done får visas på sprintgranskning. Definition of Done i det här fallet innebar bl a att automatiska testfall ska finnas i CI-kedjan och att all integration mellan de 15 lokala teamen ska vara gjord.

Förändrings-smärtan

 

Irriterade teams

Förändringen gav upphov till en hel del missnöje. T ex

  • “Varför får inte vi visa vad vi gjort? Vi är ju klara. Vi väntar ju bara på att kunna integrera med det andra teamet!”

  • Våra saker är så stora att då kommer vi ju aldrig att få visa något!

  • Vi är ju klara nu! Det är ju bara problem med CI-miljön som gör att vi inte kan skriva klart testerna!

  • Energin är väldigt låg nu med det nya sprintgransknings formatet, vi måste ändra agendan för att uppmuntra våra team!

  • “Den dumma som har hittat på det här med integrerade end-to-end-feature-slices (jag ? 😉 ) kan göra nedbrytningen själv!”

När vi började hålla på de nya reglerna för sprintgranskning visade det sig också att det inte var lätt att få något helt klart. De första 3 sprintarna lyckades inget team få klart någon av totalt ca 30 saker de räknat med att göra under perioden! Efter ett kvartal började det släppa och slutligen lyckades teamen få klart ca 10 av de 60 funktioner som de själva lagt som prognos för kvartalet.

Förbättringen

Innan tyckte man alltså att det gick i stort sett bra och enligt plan. Nu visste vi mer om hur lång tid det tar att verkligen tar att göra klart något och kunde vara mer trovärdiga i våra planer/prognoser mot vår omgivning.

När slutligen progressen började komma, kom glädjen och energin tillbaka i sprintgranskingen.

Saker som är “Done” har nu automatiserade regressionstester och kommer att ställa till med mindre problem och störningar i framtiden.

Fokus på att få klart saker drev också många bra diskussioner/beteenden:

  • Fokus på samarbete/samplanering mellan team så att integration kan göras under sprinten. Mindset-förändring: I en miljö med många team och beroenden kan inte ett team vara klara utan att de andra är klara. Innan allt går att köra i den gemensamma integrerade målmiljön är det inte “Done”. Innan dess återstår ju nämligen integration, vilket är ett av de största problemen/riskerna i stora organisationer, så det vill vi inte skjuta upp, utan helst göra kontinuerligt (CI). Som senast ska det vara gjort inom sprinten.

  • Fokus på nedbrytning i mindre end-to-end slices av funktioner som kan avslutas inom sprintarna. Det ger tidigare integration, bättre förutsägbarhet och gör det lättare att alltid har en releasebar produkt. Dvs ingen övertidshets eller dålig kvalité när det närmar sig leverans.

    Mindre arbetspaket förbättrar också flödet och ökar farten. Det vet den som har koll på idéerna i Lean. 
  • Fokus på teststrategier och samarbete mellan teamen på att lösa svåra testfall drev fram bättre tekniker för test. 

Invändningar

Om vi väntar tills något är “Done” innan vi visar det på vår sprintgranskning, går vi inte miste om feedback då?

Nej, se till att ha ett nära samarbete under sprintarna med era intressenter och fånga feedbacken där. Att hitta problem på sprintgranskning är i senaste laget. Mycket arbete kan ju vara nedlagt förgäves om man väntar till sprintgranskningen med att få feedback. Låt den vara en sammanfattning istället där vi gör en sista koll av att alla är överens om att en feature/story är “Done”. Försök även så långt som möjligt granska om den löser det verkliga behovet/levererar tänkt värde.

Spelar det någon roll vad det heter? Vi kan väl kalla det Sprint Demo och ha fokus på “Done”?

Nyord

Tyvärr funkar det inte i praktiken. Många försök att ändra betydelsen av olika ord har gjorts i agile-värden. T ex att kalla något för en demo men att köra en granskning. Men vilka ord man använder påverkar mer än vad man kan tro.

Kallar man det demo så blir fokus på att visa saker och få det att se bra ut. Prio läggs på det som är lätt att presentera istället för det som har högst prio. Saker som inte går att demonstrera tas inte ens upp till granskning. Kvalitén sänks för att få saker att se bra ut.

Dvs; det går inte! Ord har en betydelse och det går inte att ändra med en annan agenda. Ni måste byta namn på er Sprint Demo om ni vill få fördelarna av en sprintgranskning.

Sammanfattning

Genom att gå över från Sprint Demo till sprintgranskning så lärde sig organisationen i exemplet ovan relativt snabbt en hel del om vad som krävs för att många teams ska kunna bygga en produkt tillsammans.

Att byta sin Sprint Demo mot en sprintgranskning är inte en helt enkel ändring att göra. Helt plötsligt blir den verkliga progressen synlig. Likaså blir alla problem som hindrar organisationen från att ta sig framåt smärtsamt tydliga.

Men fördelen med det är ju att när man vet vad man har för problem kan man åtgärda dem. Utvecklingen kommer då bara att flyta på bättre och bättre ju fler saker man lyckas åtgärda. Trivseln kommer att öka och man kan såsmåningom löpande leverera kvalitetsprodukter som alla kan vara stolta över, utan panikartade övertidsrace.

Har ni “demos” hos er, på sprintnivå eller på andra skalningsnivåer? Fundera på om det inte är dags att gå vidare och börja köra en granskning istället!

Fredrik Wendt

I maj i år började Fredrik Wendt hos oss. Han är en mycket erfaren utbildare och agil coach. Han kommer att komplettera oss väldigt bra med sitt stora intresse och sin erfarenhet inom den tekniska sidan av mjukvaruutveckling. T.ex. inom TDD, Continuous Integration, Delivery och Deployment. Det vi dagligdags kallar för software craftmanship och som vi ser ökat behov av hos alla våra kunder.

Han brinner för att hjälpa andra att växa och utvecklas. Därmed passar han väldigt bra på ProAgile.

Välkommen till ProAgile, Fredrik Wendt!

Var det här inlägget intressant? Gilla och dela!

LinkedIn
Facebook
Facebook
Instagram
Follow by Email