Category: Agile

Efter ett alldeles för långt uppehåll tar jag åter upp skrivandet av serien Men vad kan jag göra? – tips om saker som du kan göra idag, helt utan att be om tillstånd, för att förbättra tillståndet i ditt aktuella projekt.

Varje gång jag hör någon berätta om ett stycke särskilt hemsk kod de sprungit på kommer jag att tänka på när jag hittade en klass som var 17000 rader lång. Någonstans mitt i denna kompakta massa text fanns två metoder. Den ena hette “up”, den andra “down”. Båda var ganska långa och, visade det sig, helt identiska. Eller inte helt – ett tecken skilde faktiskt. Där det stod ett plus i den ena stod det ett minus i den andra. Det tog en stunds betraktande och ett diff-program för att ställa diagnosen. Sådan är klipp-och-klistra-programmeringens logik. Den enes snabba fix blir den andres huvudbry. Denna monsterklass var representativ för hela kodbasen.

Mitt uppdrag i projektet var väldigt tydligt definierat. Jag skulle vidareutveckla en viss modul i koden. Minnet av hur det kändes när jag först såg den kod jag förväntades bygga vidare på lever kvar. Självklart var den, som man brukar säga, nästan klar och bara några små tillägg skulle göras.

Den del av koden jag fick tilldelad var inte 17000 rader lång. Tvärtom var det en ganska kort klass. En kort och kompakt klass. En tät massa av kryptiska variabler och villkorssatser. Det jag kände när jag tittade på den var fruktan. Fruktan att jag inte skulle klara den uppgift jag fått tilldelad.

Jag minns inte om jag köpte Martin Fowlers lysande bok om refactoring efter min sammanstötning med detta monster till källkod, eller om jag just hade råkat köpa den. Hur det än var så räddade den boken mig.

Fowler beskrev i sin bok hur man kunde jobba i små kontrollerade steg för att omvandla oläsbar kod till läsbar kod. Han visade hur man försiktigt men målmedvetet kunde omforma spaghettikod till små kontrollerbara bitar.

Jag skred till verket metodiskt och omsorgsfullt. Eftersom jag jobbade i Visual Basic 6 hade jag inte tillgång till några automatiska verktyg för refactoring, men Fowlers instruktioner kunde följas steg för steg. Långsamt gjorde jag koden mer hanterbar. Jag bytte obegripliga variabelnamn mot begripliga. Jag bröt ned långa metoder i kortare, och gav dem mer passande namn. Jag tog bort överflödig kod. Jag strukturerade och städade, hela tiden efter Fowlers recept som visade hur jag kunde göra ändringarna på ett tryggt sätt. För första gången kände jag mig som en riktig programmerare (språket till trots skulle vissa säga). Till slut kunde jag göra de tillägg jag blivit ombedd att göra.

Fowlers definition på refactoring var “små designförändringar som inte ändrar kodens beteende”. Idag verkar en vanligare tolkning av termen vara “blandade tekniska förändringar av större och mindre sort”. Den sortens ändringar har vi redan tillräckligt av, men den sort Fowler avsåg är det fortfarande brist på. Därför, om du vill göra en skillnad redan idag, lär dig först vad refactoring betyder. Lär dig sedan att använda tekniken i praktiken. Förmodligen har du redan upptäckt att det finns inbyggt stöd för refactoring i ditt utvecklingsverktyg, så idag är det lättare än någonsin att börja skriva kod som andra inte behöver frukta att ta över, och det – det är att göra världen till en lite bättre plats.

– – –

Övningar

1. Vilken bok skulle kunna rädda dig ur situationen du befinner dig i just nu? Beskriv din situation för en vän eller kollega du litar på och fråga om de har ett tips på en bok som skulle kunna hjälpa dig.
2. Är begreppet refactoring känt bland de du jobbar med? Fråga några kollegor om hur de definierar refactoring.

A couple of weeks ago, Magnus Ljadas and I interviewed consultant, author, and PSL host Johanna Rothman over Skype. I just received an email from Johanna telling me that she’s just published the first part of the interview on her website. You should go ahead and download it at http://johannarothman.libsyn.com/index.php?post_id=388435.

IDG-bloggaren Niklas Andersson har fått en fråga som handlar om hur man kan få lite av den fart och fläkt som finns i open source-världen i sitt egna projekt, och eftersöker fler tankar på ämnet. Jag har ingen egen erfarenhet från open source-utveckling, men jag tror ändå att jag kan identifiera åtminstone en egenskap som går att låna över till kommersiella projekt.

Först och främst, en egenskap som är lika ovanlig som kontroversiell i näringslivet: frivillighet. Deltagare i open source-projekt väljer själva att delta. Deltagare i företags projekt blir ofta ditkommenderade av någon annan. Är det egentligen inte ganska uppenbart?

När människor själva får välja, då väljer de att engagera sig i något de vill ge sitt fulla stöd. När någon annan väljer åt oss blir det sällan lika bra. Synd då att det verkar så sällsynt att människor i företag själva får välja vart de vill rikta sitt engagemang.

Den som vill se kraften i frivillighet kan pröva att delta i ett open space-möte, t.ex något av de som Citerus är med och sponsrar under de kommande månaderna, dels Scrum Gathering i Stockholm, dels Engagemangsdagen 2008, där open space-skaparen Harrison Owen besöker Uppsala.

Harrison Owen fick idén om open space som en reaktion på den feedback han fick efter att ha arbetat länge och hårt med att arrangera och genomföra en större konferens. En inte helt ovanlig kommentar, som säkert känns igen, var: “Konferensen var bra, men det bästa var alla samtal man hade under fikapauserna”. Man kan väl säga att Owen fick idén att göra en konferens baserad på fikapausens filosofi.

Ett open space-möte börjar med en inbjudan att delta och konferera på ett tema. Under mötet börjar deltagarna, som alltså frivilligt valt att vara med, med att själva utforma schemat för konferensen, och teckna upp sig för sessioner som föreslagits på plats. Sedan drar man igång. Folk deltar där man vill. Grundregeln är att man röstar med fötterna även under själva genomförandet av mötet. Känner man vid något tillfälle att man kan göra och ha mer nytta av att vara på en annan plats så byter man helt enkelt plats. Dessa frivillighetsregler gör att rätt människor gör rätt saker hela tiden.

På Citerus använder vi open space-konceptet i ett miniformat minst en gång i månaden, när alla medarbetare träffas under en heldag för lärande och skapande. Skillnaden mot ett centralt planerat och obligatoriskt schema är uppenbar. Folk väljer själva att investera sin talang där den ger både mest nytta och mest tillfredsställelse – och varför skulle någon vilja ha det på något annat sätt?

… till att fortsätta arbetet med att försöka ändra vår bransch tragiska track record: Försäkringskassan blöder miljoner, Computer Sweden.

Spekulation helt utan insikt i Försäkringskassans verksamhet följer.

Deras nästa projekt kommer att gå ännu värre. Varför? Därför att de omskrivna budgetmissarna kommer att öka trycket på att ännu mer tid läggs på att i förhand berätta vad slutresultatet kommer att kosta. Det kommer att leda till att man försöker skriva ännu mer detaljerade planer, och ha ännu lägre tolerans för osäkerhet. Effekten av detta blir mer spekulation och mer gissningar under en utdragen “förstudieperiod”, som till slut kommer att glida över i en “genomförandefas” antingen lite av sig själv, eller som ett resultatet av att någon högt upp tröttnar och pressar projektet vidare. Slutresultatet: ytterligare ett projekt som förvånar alla inblandade genom att dra över budget.

Jag har startat en ny blogg: Scrumtips. På Scrumtips-bloggen kommer jag att samla tips för dig som använder Scrum. Från fallgropar till praktiska how-tos, från nyttiga metaforer till boktips, allt på en blog, sökbart och indexerat. Om du har vägarna förbi, lämna gärna en kommentar och berätta vad du skulle vilja läsa om, och du får en fin stjärna i mjukvaruhimlen om du tipsar fler om bloggen!

Oh. My. God! If these 3M cards are half as neat as they seem, I want a stack for my next workshop, right now!

http://www.3m.com/us/office/postit/cards/index.html

In an article on pragmaticmarketing.com, Stacey Weber discusses at what level of control the product owner in Scrum is supposed to operate. She points out that the product owner needs to interact with the team at a problem statement level, not on the level of detailed specifications. I agree. If the product owner feels the need to control the team’s work at a very granular level, this is a bad smell. An efficient Scrum team can take fairly high-level requirements from the product owner and act on them. Such a team does not need to be spoon fed detailed specs and screen shots, because it already has all the skills it needs to take a requirement and run with it. If great user experience is a key target, a user experience person is right there in the team, committing to the sprint goal. The product owner gets to do what he or she is good at – identify and work towards delivering to market needs. The team gets leeway and is able to find the best possible solution to a stated problem.

More generally: in an efficient organization, there is rarely a need to micro manage.

Idag har jag deltagit på konferensen Agila Sveriges första dag. Förmiddagen bestod av blixttal begränsade till tio minuters längd. Efter lunch övergick formatet till öppet forum, och deltagarna delade upp sig i mindre grupper för att behandla de ämnen de själva föreslagit. Konferensen har anordnats av personer som är aktiva på mailinglistan Agile Sweden: Joakim Holm, Marcus Ahnve, Måns Sandström, Ola Ellnestam och Matti Hjelm. En mängd bolag som är verksamma inom området har skjutit in stöd som sponsorer, bland dem Citerus såklart.

Blixttals-upplägget fungerade lysande. Samtliga talare var fullt kapabla att leverera något intressant på de tilldelade minuterna. En tanke jag fick, och fick höra även från en annan deltagare, är att det känns som om det får plats lika mycket informaton i en tio minuters blixtdragning som i ett traditionellt fyrtiominuterstal. Det som fått stryka på foten är långa talarpresentationer, upprepningar och uppradningar av långa punktlistor.

Förmiddagens föreläsningar genomfördes i två spår. Utan att ha analyserat innehållet i dem noggrannare kunde jag inte se något uppenbart tema för respektive spår. Det gjorde emellertid ingenting alls för mig, jag navigerade fram och tillbaks för att lyssna på det som lät mest intressant. En oväntad sidoeffekt av detta var att det var uppiggande att halvpspringa några steg mellan föreläsningslokalarna i konferensanläggning.

Eftermiddagens open space genomfördes i tre pass, med, tror jag, runt ett halvdussin sessioner per pass. Jag deltog i en session om förändringsmotstånd och en om förtroende i team. Under det sista passet surrade jag in en stund på en session som handlade om value stream mapping, men surrade ut igen och pratade med Chris och Markus från BluePlane istället.
Minst lika givande som föreläsningarna var att träffa andra lättrörlighetsnördar jag känner sedan gammalt, och en hel del nya. Många namn var bekanta från Agile Sweden-listan och olika bloggar, och sådana namn känns det extra bra att kunna knyta ett ansikte och ett handslag till.

Nu ikväll är det en konferensmiddag som jag tyvärr fick hoppa över den här gången.

Så här i halvtid (konferensen fortsätter hela dagen imorgon) känns det inte alls förhastat att kalla konferensen en succé. Väl anordnat av arrangörerna, och av deltagarna, som ju i extra hög grad byggt just denna konferens. Jag håller tummarna för att detta blir ett återkommande arrangemang, minst årligen.

Nästa vecka åker jag ned till Malmö för att hålla ett kort tal på Öresund Agile. Jag dyker in mellan de populära talarna Jeff Sutherland och Henrik Kniberg, så det blir helt säkert en lärorik upplevelse. Mitt tal kommer att sammanfatta några viktiga personliga erfarenheter jag gjort under de fem år jag jobbat med att använda, lära ut och införa Scrum. Jag hoppas att innehållet kommer att vara till nytta för alla som på något sätt vill förändra saker och ting till det bättre, och särskilt för dem som gillar lättrörliga arbetsmetoder som Scrum.