Agila Sverige 2009

Förra året hade jag, tillsammans med ett par goda vänner, förmånen att få arrangera en agil konferens om agil systemutveckling. Under två dagar träffades ca. 150 personer, från hela Sverige, i Stockholm för att utbyta erfarenheter via blixttal och open space.

I år återkommer konferensen och jag är stolt över att åter få stå som medarrangör. Ett huvudmål med konferensen är att vara tillgänglig. Det kostar bara 1000:- för två dagar inklusive en trevlig och god middag. Som deltagare kan man räkna med att få träffa engagerade och kunniga systemutvecklare som, mer än gärna, delar med sig av sina erfarenheter i drygt 50 blixttal och i ett 20-tal open space-sessioner. Förra året gavs deltagarna konferensen betyget 9,3 av 10. Kom och hjälp oss göra årets upplaga ännu bättre.

Adaptiv startar

Den 1:a april börjar jag på nytt jobb. Egentligen är det inget nytt jobb för jag kommer göra precis samma saker som tidigare. Agila införandeuppdrag och teknikkonsulting är det som jag gjort de senaste 5 åren och det är det jag kommer att fortsätta med. Det är snarare ett nytt liv. Joakim Holm, Johan Lind och jag kommer att tillsammans starta Adaptiv Sthlm AB (vi kallar det bara Adaptiv).

Det är naturligtvis spännande, roligt och stimulerande att få chansen att jobba med så duktiga medarbetare som Johan och Jocke, men jag tänkte ta tillfället att besvara de frågan som jag oftast får om detta.

Varför nu när krisen bryter över oss!?

Ptja, spelar det någon roll egentligen? Visst kan det bli så att krisen kan komma att pressa priser eller att man får gå någon månad utan uppdrag, men samma kris gäller ju även om man är kvar hos sin arbetsgivare. Dessutom är min uppfattning att kriserna blir mindre för mindre företag. Man behöver inte ta på sig några stora fasta kostnader och att hitta uppdrag åt tre seniora konsulter är betydligt enklare än att göra det åt 15 oerfarna.

Som konsulter med 10+ års arbetslivserfarenhet tror vi att det blir lättare för oss att märkas under en lågkonjunktur. Kostnadsskillnaden mellan en junior konsult och en seinor är skrattretande liten och vi kan visa på att vi kan utgöra en investering med hög avkastning vilket är det som efterlyses när marknaden är svag.

Även om det finns många fantastiskt duktiga och intressanta teknikgurus i Stockholm så är jag väldigt tacksam för att vi blev tre och att det blev vi tre. Det är tillräckligt svårt att hitta tider då alla tre kan ses och Johan och Joakim kommer att kunna stimulera mitt lärande under många bra år framöver. Det blir spännande att prova alla de mer eller mindre nya och galna idéer som vi har för företaget och jag hoppas på att vi kommer att få tillfälle att samarbeta med många andra mindre konsultfirmor i Sverige.

Ses!

Nytt kurstillfälle i TDD/BDD

Tillsammans med Joakim Holm har jag, under hösten, arbetat hårt med att vidareutveckla vår kurs i TDD/BDD. Våra elever har varit nöjda med våra tidigare kurser, men vi har hela tiden ansträngt oss för att hitta nya och inspirerande sätt att lära utt TDD och BDD. En nyhet är att vi delat upp kursen i flera kurser som riktar sig till personer på olika nivå. Vi har en kurs för nybörjare, en för erfarna och en för experter. I vår nybörjarkurs har vi utökat tiden för praktik, för det går inte att lära sig TDD utan att få utföra momenten själv.

Om du eller någon du känner är intresserad så kan jag tipsa om att kursen för nybörjare kommer att ges publikt igen, 9-10 mars i Stockholm, i arrangemang av Jaybis. Den här kursen är lämplig både om man är helt ny på området eller om man är erfaren på enhetstestning men inte på TDD. Vi kör i javamiljö, men det är inte viktigt, vi har haft många dotnetutvecklare som har gått kursen utan problem. Under de två dagarna får du en inblick i hur experterna arbetar framgångsrikt med TDD/BDD. I viss mån innebär TDD/BDD en kunskap om rätt verktyg och hur och när man bör använda dem. Men det är också en samling relaterade arbetssätt och tekniker som kräver studier och övning för att bemästra. Vissa arbetssätt kan finslipas under en livstid. Sett ur ett ännu högre perspektiv är TDD/BDD en attityd, ett sätt att se på hantverket att utveckla goda system och produkter. Vi vill tipsa om verktygen, få deltagarna att prova arbetssätten och utstråla attityden.

Noll fel

När jag gick min systemvetarutbildning så var man tydlig med att något som skulle kunna kallas buggfri programvara det finns inte. Även de enklaste av program är behäftade med buggar, helt enkelt för att även de är så komplexa.

Nu med agila (lättrörliga) metoder är noll fel en värdering och helt plötsligt anser vi att vi visst kan leverera buggfri programvara – hur kommer det sig?

Jag tänker försöka förklara vad vi menar med noll fel och sedan förklara i vilken utsträckning det idag är möjligt att komma dit.

Bugg eller brist

För att förstå hur vi kan börja tänka tanken på att leverera buggfri programvara så måste vi först fundera på vad en bugg är. En bugg i den här bemärkelsen är när programvara inte uppför sig som förväntat. En enkel variant skulle kunna vara att en svensk kalenderapplikation missar skottdagen eller att den tror att första dagen i veckan är en söndag (vilket är sant i många länder, men inte i Sverige). Detta skiljer sig från en brist som i kalenderapplikationen skulle kunna vara att man bara kan se innevarande månad. Många skulle idag kalla brister för buggar, men det tycker jag är konceptuellt fel. Att ha brister i programvara är ett normaltillstånd och allteftersom vårt användande utvecklas uppstår brister som vi kan välja rätta till i programvaran eller välja att leva med.

Med agil systemutveckling så har vi blivit väldigt duktiga på att uttrycka exakt vilket beteende som stöds av vår applikation. Alla de specifikationer i form av exekverbara tester som vi skapar under framtagandet av koden kan tala om för oss exakt hur vi kan förvänta oss att applikationen fungerar. Skulle något sätt att använda koden på vara odokumenterat så kan man säga att det beteendet inte stöds av applikationen.

Förutsatt att alla våra tester ”är gröna” så kan vi säga att vi inte har buggar i vår applikation, eventuellt har vi brister, men inte buggar.
Ok, då var det alltså klarlagt, vi kan ha noll fel. Nej, så enkelt är det inte.

Agila buggar

Först ett självklart undantag. När vi skriver våra exekverbara programspecifikationer så försöker vi helatiden göra det i så små isolerade enheter som möjligt, helt enkelt för att kunna ta så små och kontrollerade steg som möjligt. Skulle vi bara lita till de tester som vi har på lägsta nivå (och många gör det fortfarande) så kan vi inte uttala oss om hur de små enheterna fungerar tillsammans. Därför proklamerar agila metoder för att man ska låta de små testerna komma av större tester som baseras på användarscenarier. Men även för de lyckliga få som använder den typen av automatiserade scenarietester så finns små kryphål. Idag utvecklas nästan alla applikationer för användande på Internet. Det innebär att vi är många användare som samsas om appliktionsresurserna. Även tämligen avancerade scenarietester kan komma att missa konsekvensen av väldigt många samtidiga användare och det gäller inte bara prestanda utan även logiska fel som i hanterandet av tillstånd. Att hantera tillstånd trådsäkert är inte svårt i sig men misstag är svåra att upptäcka. Klart mest problematiskt är dock det faktum att våra specificerande tester bara tjänar som exempel på användandet. Vi kanske tror att vi har kommunicerat all funktionalitet när vi i själva verket har missat delar, eller missförstått i det tysta. NLP lär oss att det kan bero på att vi inte lyckats avtäcka de djupstrukturer som döljer sig bakom beställarens ord alternativt att vi omedvetet väljer att förstå beställningen på ett sätt som är felaktigt för att det förenklar lösningen.

Ögonbrynshöjare

Sammantaget får vi nog vänja oss vid att, även i framtiden, se buggar dyka upp i våra applikationer. Min erfarenhet säger mig dock att buggar kommer att vara ögonbrynshöjare. Vi kommer inte behöva buggrapporteringssystem där vi registrerar de hundratals buggar som upptäcks under användandet. Istället kan en whiteboard med uttrymme för 1 – 10 buggar noterade på Post-Its eller indexkort vara tillräckligt.

Ledarskapet borde vara Ledsagarskapet

Jag hade en chef för en tid sedan som stolt förklarade för mig att anställda vill ha en chef som säger nej. Jag är helt säker på att han hade vissa belägg för sitt påstående, men jag är lika säker på att det finns en mer nyanserad formulering som ligger ännu närmre sanningen. Personligen vill jag ha en chef som skapar goda förutsättningar för de anställda att själva förstå hur de ska tackla de problem som de ställs inför. Jag kallar det ”management från sidan”.

En chef, eller gruppledare, ska se sig som en ledsagare som har en god idé av vilket klimat han vill skapa på arbetsplatsen och sedan gör allt för att det klimatet ska uppstå genom de anställdas engagemang. Problem som uppstår i organisationen ska inte gömmas undan i något styrelserum, det ska upp på den största whiteboard man har och sedan ska alla känna att de har rätt att bidra till en lösning av problemet. Likadant med företagets framtidsvisioner. Som ledsagare kan man visa på framkomliga vägar men man behöver inte se till att alla ”rättar sig i ledet”, ofta kan kunskaperna hos kollektivet hitta en ännu mer framkomlig väg som ger samma resultat och då ska de inte hindras från att få välja den vägen.

Jag känner mig manad att ge alla ni chefer därute (som tyvärr aldrig kommer läsa detta…) en lista på vad ni borde tänka på:

• Lita på dina anställda – de vill också känna sig engagerade.
• Var öppen med organisationens problem om du vill ha dem lösta.
• Även ”fotfolk” förstår problem som ett företag ställs inför.
• Att lösa problem är roligt, du kommer att ha många frivilliga medhjälpare.
• Att låta de anställda vara med och besluta om vad som är företagets största problem kommer vara intressant både för dig och de anställda.
• Förståelsen mellan arbetsgivare och anställd kommer att öka och, rentav, bli god.
• Var inte rädd att säga vad du tycker men se till att du inte underkänner någon annans åsikt. De vet att du har sista ordet – du behöver inte hävda dig på den punkten.
• Se till att du förstår de synpunkter som kommer in – vissa åsikter kan te sig helt galna, men de är också de mest intressanta. Kanske kan ni, tillsammans, förädla dem.
• Eftersom ni troligen inte arbetat såhär tidigare så får du tänka på att det kan ta lite tid för dina anställda att vänja sig vid det nya arbetssättet.

Slutligen – försök att inte vara en semafor-chef, föreställ dig istället att du står vid sidan om organisationen och iaktar lite som en lugn fotbollstränare. Finn glädje i att coacha dina anställda när du tror att det är välkommet och när du tror att du har något att bidra med, men det är de som ska lösa problmen och de måste få den information de behöver för att kunna hitta den bästa lösningen.

Samarbete fortfarande kontroversiellt

För en tid sedan träffade jag en gammal skolkamrat på väg hem från jobbet. Det slog mig då att, sist jag träffade honom, formulerade han en så sympatisk syn på samhällsekonomiska system. Nu ska jag väl genast infoga att jag inte är speciellt bevandrad i idéhistoria så det behöver ju inte nödvändigtvis vara han själv som är upphovsmannen, men för mig var det en ”ögon-öppnare”. Till dess hade jag mest fått höra för och mot plan- och marknadsekonomiska system och mest insett att det hela är en fråga om mänskliga värderingar. Så som min vän formulerade det så kan ett samhälle värderas utifrån hur mycket samarbete respektive motarbete som finns inom samhällsstrukturerna. Sålunda kan man exempelvis säga att marknadsekonomins tendens till att skapa konkurrens är dess svaghet. Det är ett resursslöseri att motarbeta varandra på det viset. Samtidigt kan man i planekonomin se att korruption är en typ av motarbete där en person inte ser till samhällets bästa utan sätter sin egen privata ekonomi först.

Jag ser klara paralleller till hur olika utvecklingsmetoder kan bedömas. Det har blivit mycket populärt att prata om projekt som agila (lättrörliga) kontra traditionella a’la vattenfall. Kanske är det ännu mer intressant att bedöma dem efter hur mycket samarbete respektive motarbete de stipulerar?

Inom lättrörliga metoder ligger stor fokus på att kommunicera väl och på ett begripligt vis (informell verbal kommunikation, enhetliga språk där kundens egna termer används och koncisa dokument där de behövs), traditionella metoder har en artefakttyngd värdering där, lite hårddraget, inget finns som inte är dokumenterat i ett godkänt dokument. Här har vi verbal kommunikation mot dokumentation. Den verbala kommunikationen förutsätter samarbete – ni måste finnas på samma plats vid samma tidpunkt. Dokumentationen låter det vara öppet. Visserligen finns det inget som hindrar att du skriver ett dokument till någon som står bredvid dig eller att ni t.o.m. skriver det tillsammans, men det är ofta mer frestande att skriva sina dokument ensam och skicka dokument över e-mail och låta den andra parten få läsa dokumentet ”i lugn och ro”.

I traditionella projekt har man en tydlig rollfördelning där man har distinkt olika ansvar. Det finns, projektledare, beställare, utvecklare, arkitekter, testare och ibland även varianter på ovanstående med prefix såsom ”senior” eller ”junior”.

Man hamnar då i situationer där vissa uppenbara brister i organisationen kan vara ”någon annans problem”. Istället för att inse att alla problem som organisationen har är hela organisationens problem.

En av de mest kritiserade vanorna inom lättrörliga utvecklingsmetoder är vanan av att jobba i par om två. Logiken bakom det är att det aldrig finns bara en som kan någonting och att mindre erfarna utvecklare för lära sig en massa praktiska knep av mer erfarna utvecklare. Mot det står givetvis den fördyrande omständigheten att ha två personer som utför samma arbete – till synes utan någon hastighetsökning. Den kritiken är dock inte helt berättigad eftersom kvaliteten på det producerade blir högre och det, annars obligatoriska, efterarbetet med buggrättning begränsas; samtidigt som man har investerat i en försäkring som ger dig möjligheten att, med kort varsel, förlora en projektmedarbetare utan att projektets hastighet rubbas nämnvärt.

Jag har ofta konfronterats med personer som, när de stirrat nederlaget i vitögat, gjort allt för att skjuta över problemet till ett annat bord utan att ha försökt rätta till skadan. Nyligen var det en som försökte skjuta över en hög smuts på mig. Jag frågade honom vad han förväntade sig skulle hända nu när han tog avstånd från problemet i förvissningen om att han inte skulle få skit för det. Svaret var fascinerade frankt: – Ja, alltså, jag förstår att du inte har möjlighet att fixa de här problemen, men jag vill ju ha ryggen fri, så att säga…

Då frågade jag honom om han trodde att någon konstellation på företaget tillsammans var kapabla att lösa problemen och, jo det trodde han nog. Jaha, men då är det väl bättre att vi försöker samla den skaran för att se om vi kan komma tillrätta med det hela. Jag påpekade också att det här med att skylla ifrån sig kan han väl vänta med till dess slaget är förlorat, jag menar mitt under ett projekt är det ju mest en form av sabotage. Hans minspel ändrades något och han verkade nästan roat försöka förstå vad jag höll på med.

Jag försökte samarbeta. Kontroversiellt, måhända, men vansinnigt effektivt. Tyvärr kan jag inte säga att problemen är lösta än, men nu jobbar man i alla fall kreativt på att lösa dem.

Istället för att fundera över vad som är lättrörligt eller inte så kan man ta avstamp i att arbetsmetoder ska främja samarbete. Det kollektiva engagemanget och den kollektiva ansvarskänslan leder till ett produktivt arbetsklimat.