Alla dessa projekt

Att på lång sikt utveckla sin verksamhet är ett absolut måste, annars kommer man inte klara av att överleva på den tuffa marknad som råder idag. För att underlätta och kunna se att det verkligen hela tiden sker utveckling och förbättringsarbete behövs lite struktur i detta arbete, så även hos oss.

Min första tanke var att använda Jira för detta men det blev förtungtför att komma igång snabbt och nu så istället valde jag ett annatverktygjag använt tidigare, Trello. Det viktiga var innehållet, inte verktyget.

I Trello har en grupp av oss nu jobbat ett tag med att fylla på med förbättringspunkter och saker vi vill göra. En hel del har vi redan hunnit pricka av men mycket mer finns här. Det är nu läge att bjuda in alla i bolaget i detta och som första steg kommer ni inom kort får en inbjudan till Trello och vår "Vår Verksamhetsutveckling". När du loggar in för första gången, ta dig tid att läsa kortet längst upp till vänster som heter "Läs detta först!". Då får du en beskrivning av hur det är tänkt att fungera och vad de olika kolumnerna innebär.

Min förhoppning med detta är att alla dels bidrar med input men även att vi alla kan se vad som händer och att detfaktisktgenomförs en massa saker.

Som vanligt är detta beta och vi testar oss fram så har du synpunkter eller idéerpå andra sätt, tveka inte att säga till.

Jag kommer testa en ny idé jag har funderat på ett tag, teamsamtal. Det handlar även det om kommunikation och samverkan vilket jag tycker är väldigt viktigt för oss.Min tanke är att boka upp möten med alla team ungefär en gång i månaden, startar med 1,5 h per tillfälle. Agendan för mötet är mycket öppen, få måste punkter och mer tid för samtal om det som känns viktigt just då.

Min förhoppning är just att få till samtal och dialog kring vad som fungerar och vad som inte fungerar lika bra. Kring Scrum, team, roller, verktyg och allt annat möjligt. Det kan handla om ekonomin, kompetensutveckling, projekt, kunder, etimeringar, mallar, testning osv. Alla de saker som teamet vill prata om. Det är en möjlighet för mig att förstå era behov och er möjlighet att få ställa frågor och kasta fram idéer. Jag kommer ha med mig in på mötet ett team att prata om om teamet inte själva har punkter men mitt tema är bara utifallatt så man behöver inte känna ett krav att förbereda sig till dessa samtal. Inbjudan utskickad till Team Cage, inom kort till övriga team.

Det är med lite blandade känslor jag idag varit med på en demo och en sprintplanering för Team 2. Det blev på dessa möten uppenbart ännu tydligare att vi har en stor utmaning kring detta med att estimera. Det finns alltid flera orsaker bakom men i grunden har vi enprocessoch modell för detta som inte fungerar idag. Kunden B som vi kör ett projekt till nu har vi estimerat till 280 timmar men vi har redan nu upparbetat 800 timmar och det ser ut som vi kommer behöva runt 50-110 timmar till vilket väl visar på problemen. Vill vara tydlig med att INGEN skugga vilar på teamet för detta, utan det är vår process som brister.

Modellen för att nå mer korrekta estimeringar är ganska enkel. Det viktiga är att sammaindividersom gör uppskattningen, estimeringen, som sedan gör jobbet. Ju fler som kan vara aktiva i estimeringen, desto bättre brukar det bli. Givetvis finns det någon form av gräns innan man når "ju fler kockar..." men om man kan få hela teamet att delta i estimeringen brukar man kunna uppnå den mest korrekt bedömningen. Det finns givetvis fler parametrar som är viktiga t.ex bra skrivna stories. User Storyn är det som ska ge det primära underlaget för teamet att göra sitt estimat men givetvis ska PO kunna svara på frågor som behöver klargöras. Det viktiga är att här hela tiden tänka på, hur kan vi snabbast uppnå det storyn ber oss om. Det finns mao utrymme för kreativitet och hitta smarta, effektiva lösningar. Målet är att med minsta möjliga arbete ge mestamöjliganytta till kunden.

Det är självklart så att trots vi involverar hela teamet kommer vi göra misstag i vår estimering. Det viktiga då är att teamet själva ser och förstår det så man kan ta lärdom av sina felbedömningar tills nästa tillfälle. Detta blir ganska automatiskt om det är samma team som bygger som estimerar och brukar bli ett självjusterande system. Sedan är det även viktig att man använder samma måttstock vid estimeringen som vid själva utförandet. Det är därför vi alltid ska prata storypoints, inte timmar. Att sedan översätta points till timmar är en helt annan övning som initialt inte kräver teamets inblandning.

Det är mycket besvärligt för oss som bolag att ha dessa brister, det skapar en omöjlig situation för PO och SM att planera våra projekt och det går inte att bortse från de ekonomiskaeffekternasom uppstår. Det är därför mycket viktigt att vi kan förbättra oss snabbt på detta området. Vi kommer behöva prioritera att få till estimeringarna med större precision framåt.

Lyckades knäppa en bild på MW vid dagens demo:

Jag och PB har idag lärt oss lite mer om detta med tester. Dagens fokus låg på last och prestanda vilket vi har en del att förbättra våra testprocesser inom. Att testning är otroligt viktigt är väl bevisat. T.ex att kostnaden för att rätta fel som upptäcks sent i processen eller till och med i produktion är otroligt mycket högre samtidigt som det ger kunden en negativ syn på vår tekniska förmåga. Idag blir prestandatester allt mer viktig för de som vill synas, detta då Google använder just responstiden som en parameter i hur men rankas. Vi fick se ett exempel där man sökte på begreppet "försäkring", alla dessa sökträffar var rankande helt enligt responstiden, tiden att ladda sidan. Detta borde vara ytterst intressant för vissa av våra kunder och idag har vi dåliga metoder för att mäta, testa och följa upp detta.

Vi fick se ett riktigt snyggt verktyg för att köra tester men dess verkliga stryka låg i hur det presenteras efteråt. Att kunna snabbt borra sig ner i resultatet och direkt se alla behövliga fakta för att kunna felsöka. Finns även ett bra gränssnitt för att titta på trender över tid. Om man låter vissa tester köras löpande varje dygn kan man få fram många intressanta data att jobba med. Bäst av allt är det möjligt att koppla verktyget till vår CI-server och få den att exikvera lasttester. Det går även utmärkt att återanvända de testscript som vi redan har byggt i CI-servern, så inget dubbelarbete krävs.

Nedan vår egen testledare i samspråk med föreläsaren. 1

BTW. Upptäckte till min lycka att styrelsemötet är på kontoret så ingen resa i morgon.