Idag avslutades vi en serie workshoppar vars målsättning var att klura ut hur vi höjer sättet vi testar på till nästa nivå. Initiativet har pågått över tre veckor och idag knöts säcken ihop. För att ge diskussionerna struktur och fokus använde vi oss av genomgående av konceptet ”Problem Exploration Poster – P.E.P”.
Söker du efter ett verktyg som har förmågan att utmana teamet och sätta igång spännande diskussioner? Diskussioner som kanske till och med inspirerar till förändring? Då tycker jag du ska prova ”Jimmy Cards”!
I söndags kväll publicerade jag en blogg på blog.crisp.se och berättade om ”Jimmy Cards”, en kortlek jag precis fått till en MVP av. Redan efter fem minuter hade första beställningen kommit in och fler beställningar har stadigt trillat in sedan dess.
Kortleken är en uppsättning frågor och används fördelaktigt som ice-breaker på scrum teamets retrospective eller för att välja ett utmanande ämne för teamets onsdagsfika.
Nyfiken på att veta mera? Klicka då här för att komma till blogg-inlägget 🙂
Exploratory Heat Map – Tänk om teamet i en och samma rapport kunde se en snapshot över systemets hälsa, hur tillförlitlig snapshoten är, samt ge er vägledning om var ni bör lägga testenergin härnäst.
Förra veckan hade jag förmånen att få ta del av en Open Space kring Exploratory Testing på Extenda i Stockholm. Det blev en väldigt lyckad tillställning med ca 20 agila testare från flera olika företag. Väldigt roligt att möta kollegor i branschen och väldigt spännande diskussioner uppstod. Tack Linda Haglund för arrangerandet!
På vägen därifrån, och dagarna som följde, samlade jag mina tankar och började fundera…
.
Denna karta, denna Exploratory Heat Map, skulle ge en fantastisk översikt. Bilden ovan är ett exempel på hur en Exploratory Heat Map skulle kunna se ut.
.
Exploratory Heat Map
Diagrammet i bakgrunden representerar systemets olika delar. Huruvida man delar upp systemet i funktionella delar, moduler eller komponenter tror jag är mindre viktigt. Det viktiga är Defekter och ET-Session rapporter använder samma meta-data för klassificering. (Namngivning av delarna saknas i bilden ovan.)
Cirklarnas storlek representerar hur mycket exploratory test tid som delen blivit utsatt för och färgen antalet just nu öppna rapporterade buggar.
Kartan berättar dels hur systemet mår just nu, men också hur vi ska prioritera Exploratory Testing Charter Backloggen inför nästa Exploratory Torsdag. Varje dag kommer kartan förändras. Allteftersom buggar fixas kommer de röda färgerna blekna. Beroende på vilka ET-Charters som körs kommer vissa cirklar krympa medans andra växer.
.
Självklart går en dylik karta inte att underhålla genom att manuellt uppdatera en powerpoint varje dag utan det behövs ett bra verktygsstöd. Antingen skriver man ett eget verktyg som integrerar med det befintligt defect tracking system, eller så bygger man en egen plug-in till det verktyg man redan använder, vilket t.ex. är möjligt man kör JIRA GreenHopper. Och då skulle det kanske kunna se ut såhär:
.
Tankar och reflektioner? Hur värdefull och användbar vore en Exploratory Heat Map för er i ert team? Behövs återkommande ETT (Exploratory Testing Torsdagar) eller ”duger” något annat lika bra som bas för test täcknings input?
Är det någon som idag gör någonting liknande?
.
.
Är du intresserad av att jobba med agil testning som konsult Sogeti? I Stockholm finns sedan första januari ett nytt team – Team Agil Testning & Automatisering. Kolla in vår annons på monster.se!
Under åren jag jobbat med Scrum i rollen som utvecklare, testare, produktägar-proxy men framförallt som Scrum Master och Scrum Coach har jag skapat mig en liten portfölj med verktyg och mallar jag tänkte jag skulle dela med mig lite av.
Det döljer sig ingen rocket-science bakom något av dem och jag påstår inte heller att det är de bästa tänkbara, men förhoppningvis finner någon dem användbara eller blir inspirerad av dem.
.
Första verktyget är ”Team Thermometer”, en enkel övning för teamet att öppna upp Sprint Retrospectiven med. Läs mer om övningen i detta gamla inlägg: ‘‘Hur rolig var sprinten?”.
Jag kommer fylla på med fler verktyg och mallar allt eftersom. Länken till sidan ”Agila Verktyg och Mallar” hittar du i höger-spalten.
För mig har Pomodoro tekniken varit fantastiskt! Jag har äntligen fått både ett botemedel mot oinspiration och ett verktyg för att ta itu med de dagar som känns övermäktiga. Pomodoro funkar nästan som hypnos för mig!
Pomodoro är en teknik för att strukturerat och effektivt jobba av en att-göra lista, ett verktyg för att maximera nyttan av sin egen tid. De dagar då min att-göra lista verkar oövervinnerlig eller de dagar jag totalt saknar inspiration tar jag fram min äggklocka och kör Pomodoro. Idag är en sådan dag.
I korthet fungerar det så här:
Skriv ner dagens att-göra punkter. (Ta inte med mer än vad du tror är rimligt att du hinner med under dagen.)Några regler:
Verktyg: Papper, penna och en äggklocka.
Nu måste man inte använda en äggklocka, det fungerar bra med en vanlig klocka, en iPhone app, en Android widget eller valfri annan timer. Men det är något lätt hypnotiserande med det tickande ljudet som jag varmt rekommenderar.
.
BoktipsStaffan Nöteberg har skrivit en riktigt bra och djupgående bok om Pomodor tekniken: Pomodoro Technique Illustrated.
Den är välskriven och innehåller mängder med fina och tydliga illustrationer. Den är fylld till bredden med råd och djupgående analyser av teknikens underliggande mekanismer samt en mini-kurs i det mänskliga beteendet och hur vi ser på tid och arbete.
Kanske lite väl utsvävande emellanåt men riktigt läsvärd och den har definitivt hjälp mig hantera min tid mycket effektivare och faktiskt skapa en tillvaro med mindre stress. Ingen liten bedrift!
.
Tidigare inlägg om Pomodoro:
.
Har upptäckt att det finns en hel del små fiffiga appar på min Android som kan vara bra att ha till hands för utvecklarna i det agila teamet och den gadget-glade Scrum Mastern. (Jag är säker på att samma appar eller motsvarande går att hitta till iPhone också.)
När jag började skriva detta inlägg tänkte jag ta upp alla appar jag hittat hittills men då hade inlägget återigen blivit på tok för långt så därför fokuserar jag denna gång på några time-managment appar.
.
Har precis börjat studera Pomodoro och praktiserar det faktiskt just nu! Därför blev jag glad när jag upptäckte en radda appar för ändamålet. Pomodoro går kort och gott ut på att man gör en To Do lista för dagen, angriper den punkt man tycker är viktigast, vrider upp timern på 25 minuter, jobbar oavbrutet och fokuserat på vald uppgift tills klockan ringer, tar en kort paus och väljer sedan den punkt i To Do listan som känns viktigast nu (eller så väljer man att fortsätta på uppgiften man höll på med om man inte blev klar). Jag föredrar dock alltid en riktig timer framför dessa appar men det är inte alltid man har en till hands och det är inte alltid folk runtomkring en uppskattar tickandet och ringandet.
Pomodroid
(Utvecklad av: Neto Marin)
En simpel timer man kan start och stoppa. Startar alltid om på 25 minuter (ej konfigurerbart). När man klickar på skärmen startar timern och tomaten blir röd. När 25 minuter har gått ringer och vibrerar telefonen. Kort och gott. Gillar appen för dess renhet och enkelhet.
.
Pomodoro Tasks
(Utvecklad av: Kavan Puranik)
Denna Pomodoro app är lite mer avancerad. Du sätter upp din To Do lista innan du startar timern för en vald uppgift. Listan kan sorteras om, tasks stryks enkelt med en fingerdragning och lite andra funktioner finns.
Även om det är en fin idé så faller appen också lite på just dess utbud av funktioner, det finns helt enkelt inte stöd för allt man vill göra (som t.ex. anteckna hur många pomodoros en uppgift tog m.m.). Känner själv att verktyget begränsar mer än hjälper.
.
Meeting Time Tracker
(Utvecklad av: Espinassous Etienne)
Ett enkelt verktyg i första hand designat för Scrum Mastern eller mötesordföranden för att se till att möten inte överskrider Time-boxningen.
Du stället helt enkelt in hur långt mötet är och startar timern. Utöver att skriva ut tiden visar den även hur status på hur långt det är kvar; hälften, 15 minuter, 10 minuter och 5 minuter. (Planerar att använda själv den på fredag när det är dags för nästa seminarie för att enkelt hålla koll på om jag hinner med dom slides jag tänkt mig innan nästa paus.)
Sprang nyligen på OpenAgile när jag klickade mig fram igenom bloggartiklar om Scrum och Agila utvecklingsmetoder. Att det fångade mitt intresse tror jag beror på att OpenAgile är en agil utvecklingsprocess anpassad och designad för att vara tillämpar på ett bredare spektra än enbart mjukvaruutveckling.
Jag har tidigare jobbat som projektledare i stora ideella projekt där man inte har lyxen att kunna säga ”Gör ditt jobb annars får du ingen lön!” utan allt handlade om frivilligt engagemang, motivation, ansvarskänslaoch att det skulle vara roligt att jobba. OpenAgile hade nog fungerat riktigt bra där.
Vidare så är det svårt att tillämpa Scrum utanför mjukvaruutvecklingsprojekt. Man kanske inte har resurser på heltid i ett team, det är kanske omöjligt att hålla korta sprintar i verksamhetsprojekt, involverade personer variera kraftigt eller förändras mycket med tiden, för att nämna några exempel. OpenAgile försöker lösa även dessa bekymmer.
Jag tror nog att OpenAgile kan fungera bra för vissa organisatoner som har en lös struktur eller för projekt som inte har strikta deadlines i tiden. Den har några intressanta vinklingar (beskriver t.ex. fler roller än Scrum även om bara en av dem är obligatorisk), den är betydligt lättviktigare än Scrum, fokuserar hårt på teamet och teamanda, tillåter avbrott i arbetet.
Det som jag finner mest spännande och roligast är dock kanske att detta är just en variant av Scrum som (förhoppningsvis) fungerar fint i alla sammanhang och miljöer. 🙂
.
OpenAgile är en Agil utvecklingsprocess som fokuserar på att leverera värde. Till skillnad från Scrum som ägs av Scrum Alliance så är OpenAgile open source och under utveckling (av naturliga skäl eftersom det är open source men jag tror det också beror på att det väldigt nytt också).
I korthet så fungerar det så här: Teamet (det finns bara en obligatorisk roll, nämligen team-medlemmen) jobbar i cykler (iteration). Under en cykel träffas man minst fyra gånger för ett Progress Meeting för att diskutera hur det går, vad man lärt sig och vilka tasks man ska göra härnäst, dvs. under nästa Work Period (som kan vara allt ifrån några timmar till flera veckor). Alla väljer på frivillig basis vilka och hur många tasks.
En cykel inleds med tre möten:
OpenAgile säger inget om hur korta (eller långa) cykler ska vara, bara att man ska ha några stycken innan slutmålet är nått.
OpenAgile lutar sig på tre grundvärderingar:
Det verkar som om OpenAgile visat sig vara extra populär just i idéella projekt som inte har med IT att göra. För lite bättre, korrektare och längre förklaringar av OpenAgile kika gärna på länkarna under illustrationerna.
.
.
Jämförelse av OpenAgile och Scrum:
http://www.agileadvice.com/2010/02/01/uncategorized/comparison-of-openagile-with-scrum/En wiki för OpenAgile (under utveckling)
http://wiki.openagile.orgEnkel summerande presentation på 22 slides
http://www.slideshare.net/mberteig/introduction-to-the-openagile-learning-systemEn sida med presentationer, use-case studies, m.m.
http://www.openagile.com/OpenAgile Primer (PDF, 1.22MB)
http://www.openagile.com/sites/default/files/OpenAgile Primer.pdf
Jag har redan hittat flera sätt att förbättra teamets Impediment-wall, bland annat med en Impediments Tracker, och en Risk Burndown. Har med andra ord gjort lite re-factoring och optimization på vår arbetsmetodik.
Läste under lunchen en nytt mycket intressant blogg-inlägg av Mike Cohn, Managing Risk on Agile Projects with the Risk Burndown Chart. Agila utvecklingsmetoder såsom Scrum hanterar risk på daglig basis naturligt med sina korta feedback-cykler, dagliga möten, öppen insyn i teamets progress, ärlighet med status gentemot stakeholders samt tät dialog i teamet och kontinuerlig hantering av impediments. Men Mike argumenterar för att det trots det kan vara en god idé att synliggöra de risker som finns och hur de förändras och hanteras under projektets gång.
Jag nappade genast på Mikes förslag och insåg att jag med minimal ansträngning kunde implementera hans förslag hos oss.
För varje risk-lapp bedöms risken för att ”det” inträffar samt ”kostnaden” i antal dagar försening om risken inträffar. Dessa två värden multipliceras med varandra och lappens risk-värde. Måndag varje vecka summeras risk-poängen för alla risk-lapar och Risk-Burndownen uppdateras.
När projektet närmar sig release ska självklart denna risk helst nått noll. Risk-Burndownen kommer från och med nästa vecka dessutom bli ett eget stycke i veckans statusrapport för att ytterligare synliggöra gentemot stakeholders.
Så, nu ser väggen ut som på bilden till höger. (Ett skarpt öga ser också att det tillkommit ytterligare en burndown. Vet inte riktigt hur jag ska använda denna ännu utöver att synliggöra den övergripande progressen på Impediment-wallen. Jag räknar helt enkelt antalet öppna Impediments, Risks, Questions och Tasks på daglig basis. Kanske skriver om denna senare beroende på hur experimentet faller ut.)
.
Och här följer mer begripliga illustrationer över Risk-Burndownen samt ett exempel på en Risk post-it.
.
Igår fick jag krypa till korset. På retrospectiven i tisdags var det någon som sa; ”Ska inte en Scrum Master ha en synlig Impediment lista?”. Jovisst är det så…
Det blev en action. Bara att inse att det är en sak att föreläsa och dela ut uppmaningar och utmaningar och en helt annan att leva upp till vad man pratar om i vardagen. **
Nu var detta kanske inte en så allvarlig Scrum-synd, kanske mest jag som tyckte det var lite pinsamt. Med ändå. Självklart är transparans och synbarhet en grundläggande agil princip. Det ska vara enkelt för vilken stakeholder som helst att med minimal ansträngning få en direkt och ”sann” insyn i hur det går för projektet. (En Impediments lista består av hinder och frågetecken som Scrum Masters ska undanröja för teamet så att de kan jobba effektivt och oavbrutet.)
Så igår skapade jag mig utrymme på en av mina väggar och kontstruerade mig en ”Impediments wall”. Flyttade över delar av punkterna i min rullande dags-check-lista till väggen. (Gillade den skarpt eftersom den var enkel och portabel. Väggen står ju där den står.)
Inget rocket sciense direkt. Några lappar, lite svart isoleringstejp, massa post-its i olika färger och en tuschpenna samt någon minuts funderande.
Jag gissar dessutom att väggen kommer förändras med tiden och att färgerna kommer att skifta i antal och betydelse. Så här ser den ut just nu iallafall. Lapparna skiftar såklart i antal och i position tätt under dagen.
.
Och här är en schematisk bild av min Impediments-wall. (Bilden tog förövrigt längre tid att rita än det tog att sätta upp den faktiska väggen.) Jag hoppas bilden är självförklarande, annars får du mer än gärna skriva en kommentar och fråga.
..
[Dåliga] Ursäkter för att jag inte haft en Impediment-wall tidigare:
Så! Nu känns det bättre 🙂
.
** Jag är förövrigt aldrig så nervös som när jag föreläser och representanter från kunden jag just nu jobbar för sitter i publiken. Jag är livrädd för att dom efteråt ska komma till mig och anklagande fråga; ”När du förelästa berättade du för oss att man borde göra <si> annars <så>. Jag håller med och det låter vettigt. Men varför gör du inte så?”
.
UPDATE: Historien fortsätter på ”Hantera och spåra riks med en Risk-Burndown”
Fingervotering, ”Fist of Five”, är en simpel men effektiv teknik för att se om ett förslag har stöd i en grupp.
När det är dags formuleras det eventuella beslutet teamet ska ta (exempelvis av Scrum Mastern). Sedan ombeds varje teammedlem visa vilket stöd de känner för förslaget genom att hålla upp ett antal fingrar som representerar hur mycket de stöttar förslaget, alternativt en sluten näven.
Mycket effektivare än att t.ex. gå varvet runt och be alla uttrycka och förklara sitt stöd (eller ogillande av förslaget) med ord – speciellt när alla är ense ;-p
Sluten näve = ”Jag vill diskutera förslaget ytterligare för jag kan inte gå med på det som presenteras just nu”. Ett sätt att blockera konsensus.
1 finger = ”Jag vill diskutera mera, belysa vissa problem och/eller föreslå några ändringar.”
2 fingrar = ”Jag är ok med förslaget men vill diskutera några detaljer lite ytterligare.”
3 fingrar = ”Jag håller inte med till 100% men kan vara ok med det. Behöver ingen ytterligare diskussioner.”
4 fingrar = ”Gillar förslaget och kommer jobba för dess sak.”
5 fingrar = ”Grymt förslag! Jag leder gärna arbetet!”
.
Konsensus?
Om alla håller upp tre eller fler fingrar antas förslaget ha stöd i gruppen och teamet nått konsensus.
Om någon håller två eller färre fingrar ska dessa ges en chans att förklara sina argument eller tvivel. Teamet diskuterar och argument bemöts. Sedan fingervoterar man igen och fortsätter tills teamet nått konsensus – eller beslutat sig för att lägga förslaget på hyllan och gå vidare.
Jimmy Janlén "Den Scrummande Konsulten" 