Fotboll och Kaizen

Så här i kölvattnet av fotbolls-EM kan man ju känna en viss tomhet om kvällarna - åtminstone om man är lite sportnörd som jag. Därför tänkte jag dröja mig kvar en smula vid ämnet.

Jag hörde nämligen ikväll på SVT att Kalmar fotbollsklubb arbetat med Kaizen som en del av sin filosofi kring lagets utveckling. Ständig förbättring som en del av att leda och utveckla ett fotbollslag.

Det är spännande, eftersom jag länge tyckt att det finns en del av ledarskapet inom idrotten som vi i industrin skulle kunna lära oss av. Coaching inom idrottsvärlden handlar om att bygga starka team som kan gå över berg för varandra, och individer som vill överträffa sig själva när det gäller. Det handlar om att bygga tillit, respekt, förtroende och glädje för det man åstadkommer.

Jag tycker att vår förre coach för handbollslandslaget, "Bengan" Johansson, kanske var en av Sveriges första Scrum Masters. I kritiska lägen i matchen såg Bengan till att spelarna kommunicerade med varandra, och stod upp för varandra. Under en timeout sade han sällan något, utan faciliterade tillfället, genom att se till att de informella ledarna klev fram och att laget själva enades om en taktik. (Ofta i bjärt kontrast till motståndarlagets coach som kunde stå och skrika sig röd inför sitt lag)

Låt oss hoppas bara att det inte går med fotbollsinitiativet som i en del företag - att tanken om ständig förbättring stannar på "utvecklingen" och aldrig når högsta ledningen och ekonomisidan...

Konferens: Agile Development 2008

I veckan var jag ordförande för konferensen Agile Development 2008 som arrangerades av Citerus AB och IBC Euroforum. Det börjar finnas rätt många olika konferenser med lättrörlighet på temat, men ändå kom en hygglig skara deltagare från olika erfarenhet och bakgrund. Idén vi hade med denna konferens var att ta ett brett grepp på lättrörlig utveckling genom att ta pulsen på industrin idag, och se vart trenderna är på väg. Jag tycker vi lyckades rätt bra, trots allt.

Något som irriterar mig är den ökande mängden förståsigpåare som utan att ha erfarenhet inom ett område fäller kategoriska uttalanden om detsamma. Om man nu inte vet något om Scrum, hur vet man då att det inte lämpar sig för projektarbete? Själv blir jag mer och mer försiktig med generaliseringar av denna typ ju mer erfarenhet jag får inom området. Säkert är att den bästa utvecklingsprocessen är den som utvecklats av de som gör arbetet, som hålls ständigt optimerad utefter förutsättningarna, och som aldrig blir tyngd av en mängd leverabler vars syfte är att uppfylla processens checklista, inte att bringa resultat till verksamheten i form av nöjda betalande kunder.

Jag aktar mig för processer som är alltför tyngda av pynt. Pynt är för mig leverabler som inte är resultatorienterade, utan hör till uppfyllande av processen. Det är ofta dokument av olika form som dessutom ofta ska signeras av någon ansvarig chef eller liknande. En effekt av pynt som jag ofta noterat är att det verkar bli en trygghet för kvalitet, på något märkligt sätt. Det gör inte så mycket att kunden blev nöjd, för vi har ju allt pynt som visar att vi följt processen.

Jag förbryllas av Lean-och-agile-gurus som förespråkar att man inte behöver arbeta med ständig förbättring. Jag antar att de har någon djupare grund i sitt resonemang som jag helt enkelt inte begriper, för ständig förbättring är ju en av de saker som får de mest framgångsrika företagen att hålla ledningen jämfört med sina konkurrenter. Jag anser att om det finns en sak man ska välja att göra, så är det att börja förbättra sin verksamhet, ett steg i taget, med puls.

Här måste jag fritt citera Daniel Berg på ASSA ABLOY: "Vi ska alltid vara mycket bättre om sex månader!" Tänk att ha det drivet i sin utvecklingsgrupp!

Jag glädjs åt att träffa nyanställda på en sådan här konferens, som har blivit ditskickade för att deras chef ser möjligheten i att låta dem få en orientering i lättrörlighet, och träffa andra med erfarenhet. Och jag blev glad av tjejen jag träffade som arbetar med test som specialitet, och tycker det är självklart att testare och programmerare samarbetar för att ta fram mjukvara med kvalitet. Det värmde.

Lundgrens Lag / Lundgren's Law

"Varje nytt sätt att bedriva produktutveckling på, som har potential att vara mycket bättre än de befintliga, kommer över tiden att perverteras till en variant på vattenfallsutveckling.

Sedan kommer den att avskrivas med ett 'vad var det vi sade, det fungerade ju inte' "

Jag hoppas innerligt att jag har fel. Men nu har jag sett det här hända lite väl många gånger.

---

"Every new way of developing products, that has potential of being a substantial improvement over the current ways, will eventually be corrupted into a form of waterfall process, at which point it will be dismissed with the conclusion 'we knew that it wouldn't be any better all along'"

I sincerely wish this would not happen. But I have seen it too many times already.

Produktägaren och Scrum

Lättrörliga processramverk som Scrum sätter affärsvärdet i förarsätet, vilket leder till att produktledningen förväntas styra utvecklingen. Detta ställer onekligen krav på marknadssidan att såväl förstå utmaningar och kostnader involverade med utveckling av mjukvara, men också prioritera och leda arbetet.

I takt med att dessa arbetssätt prövas, börjar nu affärssidan intressera sig (eller 'drabbas' som någon uttryckte det) och tankesätten börjar genomsyra även denna del av organisationen i många verksamheter. Viktigt, eftersom det i min mening är en förutsättning för att verkligen kunna komma framåt.

Jag träffade själv ett 50-tal produktägare i samband med ett evenemang tidigare i veckan, och gladdes åt den entusiasm inför att testa nya vägar som fanns. Dock förbryllades jag också över historien en produktägare berättade för mig, nämligen att hennes Scrum Master förbjudit henne att delta i olika möten och att vara nära teamet.

Detta påminner mig om hur viktigt det är att vara tydlig, när man förklarar saker. Självklart ska en produktägare vara nära sitt team, det är inte möjligt att kunna leda utvecklingsarbetet annars! Däremot måste denne följa spelreglerna, och inte agera som en störande kraft mot teamet heller. För att balansera detta använder lättrörliga ramverk ofta en coach som i Scrum kallas för Scrum Master. Det ligger i dennes ansvar att se till att kommunikationen mellan utvecklingsteam och produktägare fungerar på ett bra sätt, och att stänga ute produktägaren känns inte som den bästa vägen framåt.

Lättrörlig organisation

Hur organiserar man sig för att arbeta lättrörligt? De som följt Toyota under ett antal år är överens om att det krävs ett stort och kontinuerligt anpassningsarbete. Men alla förbättringar börjar ju i små steg, som floskeln säger, och det innebär turligt nog för oss att vi kan använda oss av granskning och anpassning för att iterativt och inkrementellt närma oss ett bättre läge.

På Agile Development 2008 kommer jag att hålla ett föredrag om lättrörlig organisation som jag hoppas kan inspirera i ämnet. För att få ytterligare verktyg kommer min kollega Patrik Fredriksson att prata om ett gemensamt designspråk för verksamheten, och Jonas Rundberg kommer att berätta om resan från ubåtsbefäl till lättrörlig utvecklingschef. För att plocka några godbitar ur kakan!

Den portabla Wikin

Jag är ju till del anhängare av filosofin bakom GTD och även om jag inte följer alla principer så har till exempel mailhanteringen varit till stor hjälp (och fick mig att komma ikapp med min mail för första gången på åtta år...) Därför söker jag efter finurliga idéer och verktyg för att hjälpa till med GTD-tänket.

Inget går ju upp mot ett skoj verktyg för att få entusiasm över att pröva något - eller hur?

Till min glädje och förvåning snubblade jag över en portabel Wiki häromveckan, som inte kräver vare sig webbserver eller databas, och vars installation bestod i att kopiera en webbsida till min dator! Föredömligt!

TiddlyWiki heter den, och den har hjälpt mig att organisera upp idéer, kom-ihåglistor och liknande.

Lean vs Agile

I had the opportunity to discuss knowledge-based product development over a dinner with Don Reinertsen the other day. More specifically, we discussed Lean vs. Agile, and I had the chance to pop my usual question: Why are almost always software companies exempt from the studies on how lean practices can improve the results? And, as usual, the answer is that we are portraying ourselves as being "too different to have general product development principles applied" to us - but he actually thought this would not necessary be the case.

Michael Kennedy has previously pointed out to me that he thought the software industry actually could be "more lean" because of the malleable nature of our products. And I have thought for quite some time now that we should be able to learn practices from other product development industries that they have been perfecting for decades now.

Perhaps it is time to realize that what we are doing involves a lot of handicraft, research, and trial and error, and need to be managed and controlled with apt practices.