2008-05-28

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.

2008-05-19

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.

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!

2008-05-18

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.