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.

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!

Emelie Nilefrost

Ännu en gång berikas vi på ProAgile med en väldigt duktigt person. I början av mars anslöt sig Emelie Nilefrost till oss. Det är med stor glädje vi välkomnar henne ombord. Hon är en duktig och erfaren Scrum Master och utvecklare med ambition att utvecklas till en fullfjädrad agil coach. Så här beskriver hon själv varför hon vill jobba på ProAgile.

Jag vill arbeta på ProAgile då jag drivs av att hjälpa och coacha människor. Något av det bästa som finns är att utvecklas tillsammans. På ProAgile finns det många duktiga coacher och jag är väldigt ödmjuk över att få chansen att hänga med - NU KÖR VI.

Välkommen med i ProAgile-laget Emelie!

Välkommen Lisa Sandberg

mars 27, 2018
Lisa Sandberg

I februari i år började Lisa Sandberg hos oss. Hon är en erfaren agil coach och Scrum Master som kommer att komplettera oss väldigt bra. Hon brinner för att hjälpa andra att växa och utvecklas. Därmed passar hon väldigt bra på ProAgile. Vi frågade Lisa några frågor, här är hennes svar.

Vilka 3-4 saker värdesätter du högst i (arbets-)livet, hur prioriterar du dessa mot varandra och varför?

-Frihet och flexibilitet, att kunna påverka, att ha kul på jobbet och att ständigt utvecklas.

Varför? Först och främst måste jag få HELA livet att funka, annars kommer jag inte vara en bra mamma eller prestera på jobbet.

Jag skulle tycka det var jättetråkigt att inte känna att det jag gör har betydelse, då skulle jag snart bli uttråkad.

Jag är en teamspelare och har alltid tyckt att det är viktigt att ha kul på jobbet. Har man kul och trivs så blir resultatet automatiskt bättre tror jag.

Slutligen är jag väldigt nyfiken av mig och vill gärna lära mig och prova nya saker. Jag kan nog stå ut med att inte utvecklas konstant ifall jag trivs på jobbet och med kollegorna. Samtidigt utvecklas man ständigt genom alla fantastiska människor man möter i det här jobbet.

Välkommen till ProAgile, Lisa Sandberg!

Vi bygger ProAgile-laget

Vi har under 2018 expanderat med ytterligare tre duktiga agila coacher, Stefan, Lisa och Emelie. Vi vill leva som vi lär och inser att vi måste avsätta tid för att lära känna varandra mer. Men att bygga ihop ProAgile-laget och lära känna varandra är inget som sker av sig själv. Det gäller inte bara vårt lag, det gäller alla lag.

ProAgile-laget

I förra veckan avsatte vi tid för att bygga ihop ProAgile-laget. Vi vet att vi måste spendera tid ihop för att lära känna varandra. Det är viktigt för att kunna lita på varandra och därmed kunna jobba bättre ihop. Vi är medvetna om att alla team går igenom olika faser. Dessa faser är kända som forming-storming-norming-performing, definierade av Bruce Tuckman på 60-talet. Genom medvetna handlingar kan man undvika att teamet fastnar i någon av de tidiga faserna. 

Fem felfunktioner i en grupp

Fem felfunktioner i en grupp - Patrick Lencioni

När jag läste Patrick Lencionis bok "Fem felfunktioner i en grupp" insåg jag hur viktigt det är att lära känna varandra i ett team. Den boken gav mig en aha-upplevelse om hur viktigt det är att skrapa lite mer på ytan och lära känna personen. Många team vill gärna gå på teambuildingaktiviteter såsom att bowla, köra gokart eller lösa deckarmysterier ihop. Inget ont om det och det kan vara bra och trevligt. Jag skulle dock rekommendera att man börjar mycket enklare, tex med att ta en fika tillsammans och prata om saker utanför jobbet. Detta leder till en större öppenhet i den mellanmänskliga kommunikationen och ökar vårt s.k. Joharifönster. Vilket är en förutsättning för mer och bättre samarbeten.

I boken så ger Patrick några tips på var man kan börja, tex hemort, familjeförhållanden mm. Han kallar det kapitlet "Avklädning" i boken (sidan 67 i min svenska version). Huvudpersoner ber alla svara på "fem inte alltför påträngande personliga frågor". Frågorna som är relativt oskyldiga (men de kan självklart bli väldigt känsliga beroende på vad en person har med sig i bagaget) låter så här, "Hemort? Hur många barn i familjen? Intressanta sysselsättningar under barndomen? Största utmaning under uppväxten? Första jobb?"

Min erfarenhet är att genom att börja prata med varandra om oskyldiga ämnen så kommer man varandra närmare och har lättare att jobba ihop. Man hittar gemensamma intressen och kontaktytor som gör att man bygger djupare relationer till varandra. 

Oskyldiga frågor i ProAgile-laget

Vi åkte till Pamporovo i Bulgarien för att lära känna varandra och för att prata om vår vision samt utveckla strategier för att kunna samarbeta ännu bättre inom ProAgile-laget. Anledningen till att vi valde Bulgarien är att en av våra medarbetare kommer därifrån och hon kunde då guida oss till en hel rad nya upplevelser. Alla dessa upplevelser delar vi numera i ProAgile-laget och detta stärker vår vi-känsla. Vi hade också möjlighet att åka lite skidor då Pamporovo är en skidort, en av de mest sydliga i Europa.

Som en liten förberedelse inför resan hade jag och Lisa satt ihop några frågor som vi ville att alla skulle fråga varandra. Dessa frågor var inspirerade av berättelsen i "Fem felfunktioner i en grupp". Våra frågor löd så här;

  • Var är du född?
  • Hur många barn var ni i din familj?
  • Vilka intressanta sysselsättningar hade du under barndomen?
  • Vilken var din största utmaning under barndomen?
  • Vilket var ditt första jobb?
  • Vilket är det mest oväntade jobb du haft?

Uppmaningen till var och en av oss var att försöka finna svaren till följande hos alla våra kollegor. Samt att ställa sig frågan, vilka fler frågor finns det att ställa? Med dessa frågor som grund uppstod många långa och djupa diskussioner om och mellan oss alla på ProAgile. Vi har genom detta lärt känna varandra lite mer.

Historia först, sen framtid

Detta moment att lära känna varandra har vi med som ett obligatoriskt steg i våra teamstarter. Då som en övning som heter livslinje (journey lines på engelska). Syftet med den övningen är densamma som med frågorna, att lära känna varandra. Vilket upplägg man väljer beror på omständigheterna. Med frågor så blir det mer parvis eller i smågrupper som man pratar. I en mer organiserad övning så lär alla känna en person i taget. Jag tror inte det ena sättet är bättre än det andra utan det viktigaste är att man gör det. På ProAgile har vi funderat en del kring hur vi kan dela vår livslinje med våra kollegor på ett smart och smidigt sätt. Jag tycker att vi lyckades bra på detta sätt.

Vision och strategi

När vi väl lärt känna varandra lite mer så var det dax för att titta framåt. Vart vill vi? Hur ska vi komma dit? Vi ville gärna hitta en "hisspitch" som vi kan använda för att presentera oss själva och vårt företag för andra. Vi hade ett antal välfaciliterade rundor av parvisa samtal kring vår vision och strategi. Inspirerade av den annorlunda miljön med granbeklädda bergssidor, solsken och snö, kom vi fram till några värdeord som vi vill ska ingå i vår personliga berättelse. Hur vi framför den, vilka exakta ord och formuleringar är upp till var och en av oss. Eftersom berättelsen är vår egna anledning till varför vi alla valt att jobba på ProAgile.

De värdeord som är viktiga för oss är

  • 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.

Detta är vad vi på ProAgile vill hjälpa världen med. Vi försöker varje dag med att hjälpa våra kunder att utvecklas och att utveckla produkter, tjänster, individer och organisationer.

Stefan Elmqvist

Välkommen Stefan!

Vi på ProAgile är väldigt glada över att Stefan Elmqvist har valt att ansluta sig till oss. Han är en mycket erfaren agil coach och utbildare.

Med sin långa och gedigna erfarenhet inom coachning, utbildning och ledarskap kommer han att stötta, lyfta och utmana oss alla att ta nästa steg. Välkommen Stefan, du är ett fantastiskt nästa steg för ProAgile!

 

Henrik Berglund

Förra tisdagen kickade vi igång vårens enda Professional Scrum Product Owner I (PSPO I), under ledning av Henrik Berglund. Sexton taggade och förväntansfulla deltagare tog plats för att lära sig om det senaste och mest värdefulla i Scrum, produktledning och produktägarskap. Deltagarna fick lära sig och diskutera agilitet, motivation, värdemaximering, visualisering och hantering av produktbacklog, varvat med många lärorika och engagerande övningar. Henrik guidade vant deltagarna igenom produktägarskapets vanligaste fallgropar, deltagarna berättade om sina nuvarande utmaningar och tipsade varandra om möjliga lösningar. Också mycket diskussion hur produktledningen kan och brukar transformeras till agilt. Kort sagt, två utvecklande dagar för såväl deltagare som deras hemmaorganisationer (samt inte minst mig själv, som deltog som kursassistent). På onsdagseftermiddagen skiljdes vi alla åt, trötta, men fyllda med nya idéer och tekniker för att skapa mer värde.

Om PSPO

Scrum.org's Professional Scrum Product Owner I är en gedigen introduktion till produktägarskap i en agil scrumorganisation. Efter kursen har deltagarna möjlighet att göra ett onlinetest och erhålla PSPO I, en globalt erkänd och respekterad certifiering. Deltagare på PSPO I har därefter möjlighet att få göra PSPO II till ett förmånligare pris (efter mycket studier och praktisk erfarenhet, såklart!).

Vi rekryterar inte, vi expanderar

 

Vår affärsidé är att hjälpa företag och organisationer att bli mer agila och att hitta nästa steg på sin agila resa. Därför behöver vi duktiga personer som kan hjälpa oss att hjälpa andra. Vi vill attrahera engagerade människor som brinner för samma saker som vi.

När vi träffar någon entusiast som delar våra värderingar och vår mission så blir vi intresserade. När vi hittar någon som vi tror kan berika oss så vill vi gärna etablera någon form av relation. Men det måste vara rätt person. Vi är otroligt kräsna och måna om vårt varumärke. Alla medarbetare i vårt lag är spelare i världsklass.

Vad intresserar oss?

Vi intresserar oss främst för agila coacher och Scrummasters. Just nu är vi inne i en fas där vi expanderar. Vi har vuxit från fyra till sju personer på mindre än ett halvår. Därför är det viktigt att de vi vill jobba tillsammans med passar in i vårt erbjudande. På sikt hoppas vi kunna bredda oss lite, så att vi blir ännu mer tvärfunktionella som bolag.

Vi är även nyfikna på systemutvecklare som har ett stort intresse för de agila principerna. Vi ser stora möjligheter att vara med och påverka individer, teams och hela organisationen även från ett utvecklarperspektiv. Då vill vi dock vara med som agila coacher eller Scrummaster hos samma kund för att kunna göra mest nytta. Potentialen är stor i många fall med en utvecklare som är T-formad och behärskar TDD, BDD och att mobjobba samt andas och lever enligt de agila värderingarna.

Den agila resan
ProAgile attraherar

Hur expanderar vi?

Eftersom vi är en autonom och chefslös organisation så blir vi alla inblandade när vi expanderar och hittar nya medarbetare. Oftast är det någon av oss befintliga medarbetare som har någon kontakt som är intresserad av oss. Det är en bra start. Vi vill inte rekrytera i traditionell mening, vi vill attrahera entusiaster. Då brukar en eller två av oss ta en kontakt och sondera terrängen. Vad vill vederbörande? Vad motiverar denna person? Vilka drivkrafter ser vi? Hur är dessa förenliga med vad vi på ProAgile vill?

Vi pratar också om hur ProAgile fungerar. Om tycke uppstår så går vi vidare och låter alla medarbetare på ProAgile träffa den potentiella medarbetaren. Ibland i stor grupp och ibland i mindre sammanhang. Ibland på vårt kontor och ibland på annan plats. Vi provar oss fram och lär oss hela tiden.

Vi berikas

Vid de flesta tillfällen som vi berikas men nya personer har det skett via personliga kontakter. Men vi får också in en del spontanansökningar, vilket vi tycker är väldigt kul och spännande. Det ställer dock lite högre krav på oss för då behöver vi lära känna personen på ett helt annat sätt genom en serie av interaktioner. För att förstå vad den individen söker. Samt huruvida den personen matchar in i ProAgile just nu. Motivation, drivkraft och intresse måste ligga i linje med vad vi på ProAgile värdesätter.

Vi har inte några monetära belöningar för att rekrytera nya medarbetare. Detta beror på att vi inte tror på belöningar i form av pengar. Belöningen med en ny medarbetare är att vi berikas och växer som individer och bolag. Som bolag, får vi in ny kompetens och nya infallsvinklar. Som individer får vi möjlighet till nya interaktioner och utbyte av idéer och tankar. Därmed växer vi alla!