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.

Lean vs Agile

I had the opportunity to discuss knowledge-based product development over a dinner with Don Reinertsen the other day.