Archive for maj, 2010

h1

Japan ♥ Lean & Agile?

torsdag, 27 maj, 2010

För några dagar sedan kom jag och min flickvän hem från en nästan två veckor lång visit till Japan.  Även om det var semester (och en riktigt bra sådan) kunde jag inte låta bli att reflektera över hur Lean och Agile passar ihop med den japanska kulturen och mentaliteten.

Fram tills nyligen trodde jag Leans hemland också kryllade av it-projekt som framgångsrikt kör Scrum eller andra agila utvecklingsmetoder. Men icke. Nyligen lärde jag mig att till och med Toytoa kör vattenfall på sin utvecklingsavdelning och efter att lärt känna Japan close-up så förstår jag att även om Lean fungerar perfekt i den japanska kulturen och mentaliteten så innehåller det agila manifestet och de agila principerna värderingar och utmaningar som för en japan kan ses som obegripliga, paradoxala eller till och med kanske förolämpande.

.

Ett välkänd japans ordspråk lyder ”Protect the Rules!”. Fundera över det en liten stund. Detta går helt stick i stäv med det agila manifestets ”Individuals and Interaction over Process and Tools”.

Individualism och självfötroende är skällsord. De äldre och dina ledarna är visare och utövar vist sin klokhet och makt. Ta inga initiativ själv utan att vänta på att ledaren i detalj beskriver uppgiften. Knappast en bra gryta för att koka ihop ett tight och kreativt team som upplever ”empowerment” och ”collective ownership”.

Vidare – precis som i Sverige, fast ännu mera, älskar man skyltar, områdeskartor, varningar och hänvisningar. Skulle du inte förstå skyltningen i tunnelbanan, gå vilse och sedan gå till kundtjänst och muttra på att det är svårt att hitta så kommer du självklart få fantastiskt artig och hövlig hjälp (på knacklig engelska). Vad du däremot inte får veta är huruvida personen som designade skyltningen och hänvisningarna kanske säger upp sig själv i skam över att han misslyckats att hjälpa dig hitta rätt. Detta sätt att se på ansvar och misslyckanden är inte något som uppmanar till kreativitet, mod eller viljan att ta initiativ.

Lean å andra sidan passar som fisken i handsken. Om man naivt och fördomsfullt tillåter sig förenkla kan man beskriva vissa aspekter av det japanska samhället som en effektiv och organiserad myrstack. Ingen är viktigare än någon annan och allt man gör är för kollektivets bästa. I fabriken ”myrstacken” är Lean (Toyota Production System) ett fantastiskt verktyg för effektivisering och förbättring, ett redskap som metodiskt och empiriskt analyserar och sedan formar om processen. Man behöver inte vara kreativ, blotta sina subjektiv åsikter eller ta initiativ för att applicera Lean, bara kunskap och analytisk förmåga krävs.

Japan har 0% arbetslöshet. ”Optimize the whole!”. Alla tar sitt jobb på största allvar och känner stor stolthet. Man jobbar långa dagar. Men vad man gör under timmarna på kontoret eller, om ett arbete går att göra mera effektivt, är nödvändigtvis inte alls lika intressant.

.

I Sverige har vi inga problem att klumpa ihop Agile och Lean. Vi ser massor med paralleller och likheter och för oss faller det sig naturligt att sträva efter båda värdegrunderna när vi formar vår utvecklingsprocess.

Utöver dessa reflektioner tog jag självklart med mig hem ett ton av andra intryck och upplevelser men dessa berättas någon annan gång, någon annan stans 🙂

.

PS. Jag ber om ursäkt i förväg om jag förargat någon med mitt naiva raljerande och smått fördomsfulla förenkling av det japanska samhället. Läs inlägget ovan med glimten i ögat och som en betraktelse som kanske berättar mer om mig själv än någon annan. DS.

h1

Tur & Retur till Japan

tisdag, 25 maj, 2010

.

Betraktelser rörande Japan, Japaner, Svenskar, Lean och Agile kommer inom några dagar… Idag tänker jag enbart njuta av att vara hemma i egna lägenheten.

h1

Agila Sverige 2010 över för denna gång

onsdag, 12 maj, 2010

Nu är Agila Sverige 2010 över för denna gång. Jag hade tyvärr inte själv möjlighet att delta men jag har följt eventet över Twitter och kommer fråga ut mina vänner som faktiskt var där hur de hade det, samt hålla utkik efter presentationer, filmer och material som läggs upp i efterhand.

Tyngdpunkten låg (som brukligt) på blixttal och OpenSpace. Har tyvärr inte kommit över något material rörande OpenSpace diskussionerna ännu men här hittar du summeringar över de två dagarnas blixttal.

Nästa år tänker jag verkligen se till att ha kalendern fri!

.

Summering Dag 1:
http://www.highlevelbits.com/2010/05/agila-sverige-reflections.html

Summering Dag 2:
http://www.highlevelbits.com/2010/05/agila-sverige-day-2-refelections.html

Vill du i efterhand läsa twitter strömmen så klicka här:
http://twitter.com/#search?q=%23agilasverige

.

Uppdatering 2010-05-12 kl 17:24

Läs Peter Antmans summering här: http://www.antman.se/archives/75

h1

Teknisk Skuld är mera än bara ful-kod

måndag, 10 maj, 2010

Medvetenheten kring Teknisk Skuld och dess betydelse för ett projekts agilitet sprider sig till snabbt. Detta är såklart en önskvärd trend, och troligen en livsavgörande insikt för vissa företag. Men om du förringar Teknisk Skuld till att enbart handla om kodens kvalitet så lurar du dig själv och risken blir stor att du kommer att ta beslut på felaktiga grunder.

Jag brukar påstå att Teknisk Skuld är den största fienden mot ett agilit projekt, dvs. förmågan att varje sprint ta sig an nya krav, lika många som förra sprinten, och känna tillit till att det man nyss levererat uppfyller DONE kriterierna och är av hög kvalitet. Ju högre Teknisk Skuld, desto dyrare att förändra och bygga vidare på koden och underhålla produkten.

Teknisk Skuld är ryggsäcken av ogjort, slarvigt eller dåligt utfört arbete, en ryggsäck vars tyngd gör att utvecklingen av en produkt går allt långsammare. Teknisk Skuld kan introduceras oavsiktligt (arkitekturen visade sig vara fel och svår att skala, den överarbetade programmeraren introducerar många buggar pga slarv), eller avsiktlig (genvägar tas och delar av arbete, såsom t.ex. dokumentation och test, skjuts upp för att hinna klart med releasen).

Oavsett orsak och härkomst så är teknisk skuld som ett kreditkort, förr eller senare måste du betala tillbaka din skuld om du vill göra nya stora inköp med kortet. Betalar du inte tillbaka utan väljer att ta ett sms-lån för att finansiera nästa utbyggnad sitter du snart fast i ränte-fällan.

.

Teknisk Skuld kan grupperas i följande kategorier:

Programmerings skuld
Dålig kod kvalitet. Slarvigt skriven. Samma kod förekommer på flera ställen. Skör kod (dvs. svår att ändra på utan att något går sönder). Obegriplig för någon annan än utvecklaren själv. Krånglig och besvärlig att bygga vidare på.

Design skuld
Dålig eller ingen design. Stel arkitektur. Avsaknad av (eller felaktigt skurna) lager. En snårskog av klasser och moduler. Det är enklare att bygga den nya funktionen som ett plåster utanpå istället för att utnyttja arkitekturen som tänkt.

Test skuld
Delar av systemet har inte testats, testats dåligt eller på fel sätt. Okänd testtäckning. Fallerar ett gammalt automatiserat test är det svårt att veta om testet är fel eller om koden gömmer en defekt.

Kunskapsskuld – Det finns isolerad och odokumenterad kunskap. Kod är svår att förstå pga av avsaknad av kommentarer. Samma fel upprepas pga att lessons learned inte sprids. Isolerad kunskap skapar resurs-flaskhalsar. Nya teammedlemmar har svårt att komma upp till ett produktivt tempo. Förvaltning står handfallen när något går galet pga avsaknad av rätt teknisk dokumentation.

.

Farliga och fördummande förenklingar

Dessvärre verkar vissa ”agila experter” enbart rikta in sig på kod-aspekten av teknisk skuld. En farlig och fördummande förenkling. Vissa försöker till och med göra pengar på detta. Bara för att programmeringsskulden är enklare att mäta (med hjälp av olika  analytiska verktyg) än de andra aspekterna betyder det inte att man får glömma bort test-, design- och kunskapsskulden, aspekter som tillsammans kan gömma betydligt högre kostnader än programmeringsskulden.

För att ta ett exempel; ”The Agile Executive” är en blogg jag följer. Den tar bland annat upp teknisk skuld från en mängd olika och spännande vinklar och har skrivit en radda mycket bra artiklar om ämnet. Grytan bubblade dock över för mig när de häromdagen annonserade ut och hyllade Cutter Consortiums nya tjänst, ”New service boils down technical debt to $$; ties it to cost and value”, i en artikel. Tjänsten fokuserar enbart kring kodens kvalitet och genom att förenkla ner detta till några mätetal extraherar Cutter sedan priset på den tekniska skulden i pengar eller man-dagar.

Här är ett annat exempel på när den tekniska skulden reduceras till kod-kvalitet:
http://www.infoq.com/news/2010/03/monetizing-technical-debt

.

Nödvändiga förenklingar?

Missförstå mig dock rätt, jag tycker det är en vacker och eftersträvansvärde tanke att kunna åskådliggöra teknisk skuld med ett konkret pris. Kanske t.o.m. nödvändig för att få förståelse och mandat från Produktägare och beställare för att adressera och förebygga tillväxten av Teknisk Skuld.

Jag anser dock att förenkla det till några enstaka kod-tekniska faktorer är dock farligt förenklande, till snudd på fördummande, och svaret blir inget annat än en delmängd av sanningen.

h1

9 besvärliga Scrum-teammedlemmar…

torsdag, 6 maj, 2010

Den bluffande optimisten ”Det där är superenkelt att bygga! Det slänger jag ihop på några timmar. Nemas problemas!” Uppgiften visar sig sedan ta fem gånger så lång tid. Det låga ursprungliga estimatet visar vara en vit lögn för att få tillåtelse att bygga en rolig funktion (alternativt testa på ny spännande teknik). ”Meh! Hade jag sagt <Insert realistiskt estimat> timmar då hade jag ju aldrig fått koda det!”

Den beskyddande experten ”Absolut inte! Jag var med och byggde upp <Insert namn på en viktig modul i systemet> och jag tolererar inte att någon annan är där inne och meckar runt och saboterar utan att veta vad dom pysslar med. Och nej, jag tänker inte hjälpa till med att <Insert random uppgift som ligger strax utanför personens expertområde> – det ingår inte i min arbetsbeskrivning.”

Den nervöse lögnaren – Vågar inte berätta om hinder för teamet och Scrum Master pga av rädsla för att ”avslöjas”. Säger dagligen ”Jag är nästan klar, bara några timmar kvar…” istället för att ärligt berätta hur många timmar han/hon faktiskt tror återstår. Kanske av rädsla för att få skäll för att han/hon inte jobbar snabbare…

Problemhittaren ”Oj oj oj. Nej, nej. Det där är svårt. Oj, oj. Nä, alltså – kan jag inte få göra något annat, jag vet inte ens var jag ska börja…” Problemhittaren förvandlar bekymmer och utmaningar till problemberg istället för att se lösningar och metoder för att stegvis bestiga berget. Superhjälteförmåga: Energislukare.

Den gamle i gemet ”Vadå inte dök upp på Daily Stand-Up? Vad kallar ni det sa ni? Scrum? Ja, ja. Jag har sett allt. Vart annat år omorganiseras det. Var fjärde år skiftar vi process. Igår var det RUP, idag Scrum. Jag bryr mig inte längre vad ni kallar det. Kör på som ni vill. Jag sitter hur som helst och jobbar på som jag alltid gjort på mitt kontor här borta.”

Den kreative ”Jo, jag satt och jobbade på det där sprintmålet förra veckan… och då kom jag på att jag med liten ansträngning kunde bygga den här funktionen istället! Sedan tänkte jag att den där featuren blir mer kraftfull och flexibel om jag gjorde så här. <Insert lång förklaring.> Och det är anledningen till att vi inte kan visa upp den nya dialogen här idag på Sprint Demon.”

Den självutnämnde agile-gurun ”Knappast. Vi jobbar agilt, vilket betyder att jag inte behöver dokumentera någonting. Vidare tycker jag vi borde byta till KanBan, det skulle lösa alla våra problem och konflikter. Bara min ödmjuka åsikt.”

Den paranoide emeriten – Längtar tillbaka vattenfallsland då arbetsuppgiften var väldefinierad, förväntningarna tydliga och var och ens ansvarområden knivskarpt uppdelade. En tid då man tilläts bygga gedigna saker i sin egen verkstad, ostört tills dom var klara, utan att dagligen tvingas avrapportera till projektledningssubstitutet [Scrum Mastern]. Gör sitt bästa för att simulera vattenfall i Scrum genom isolation och diffusa summeringar på Daily Scrum (om han/hon dyker upp alls).

Hulken – Fixar allt och tar på sig att hjälpa alla tills han eller hon en vacker dag förvandlas till en gigantisk flaskhals och single-point-of-failure för teamet.

.

.

h1

Ligger KY-utbildningarna före högskolan?

tisdag, 4 maj, 2010

Igår hittade jag några bloggar från studenter på en KY-utbildning som studerade och praktiserar Scrum i sina projektarbeten. Men varför verkar högskolor och universitet ignorera den revolution som pågår i sverige och i mjukvaru- utvecklingsbranchen?

Jag tror att alla företag förr eller senare kommer tvingas bemästra agila utvecklingsmetoder och styra mot en lean organisation. Desto hårdare konkurrens desto tidigare kommer det ske (eller så dukar de långsamt under). Att det inte finns fler universitets- eller högskoleutbildningar som lyfter fram agila utvecklingsmetoder idag handlar antingen om okunskap eller att de inte förstått att de konkurrerar med KY-utbildningarna runtom i landet.

Vidare, jag känner flera nyutexaminerade kollegor i branschen som nyligen tagit språnget ut i yrkeslivet. Under utbildningen har de lärt sig klassisk projektstyrning och ett visst sätt att angripa planering och utveckling (och med lite tur också hört ordet ”test”). Nu ”tvingas” de ut i projekt och företag som lever enligt agiles och leans principer och värderingar, varav vissa går rakt emot all rim och fason de lärt sig under sin fleråriga utbildning.

Även om detta säkert en spännande resa (och troligtvis också lite förvirrande och frustrerande) för dem tycker jag ändå det är mycket underligt att högskolor och universitet inte gör mera för att förbereda dem inför den rådande verkligheten.

Sedan är det i och för sig inte så underligt att KY utbildningen som lär ut Scrum är just ”Projektledning med inriktning spel” då Scrum nästan är standard inom spelindustrin. Tv- och dataspelsindustrin är som bekant extremt konkurransutsatt och omsätter dessutom lika mycket pengar (om inte mera) som film och musik. Spel måste träffa hårda deadlines och kunden (dvs. spelarna) är extrema kritiker och har ett stort utbud av andra tillgängliga spel. Inte konstigt att man har anpassat sig för att snabbt kunna möta och matcha marknades förväntningar och snabba svängningar.

.

KY-Utbildningar

Läs mer om AcadeMedia Masters KY-utbildning Projektledning med inriktning spel (2 årig), eller få en inblick i hur studenterna på utbildningen har det genom att t.ex läsa Jonas Tolfs eller Finn Lydänges bloggar.

Ett annat exempel på KY-utbildning är Agile Developer, Webb-& systemutveckling (2 årig,  Stockholm och Göteborg)

.

Högskola/Universitet

En snabb sökning avslöjar att det några kurser:

  1. Informatik B, systemutvecklingsprojekt med SCRUM och eXtreme Programming (Örebro)
  2. Agile development processes (Chalmers tekniska högskola och Göteborgs universitet)

.

PS. Finns det fler kurser därute så tipsa mig gärna så kompletterar jag ovanstående sammanställning. DS

h1

Den dysfunktionella produktägaren

måndag, 3 maj, 2010

Det vanligaste källan till dysfunktionella Scrum projekt är problem kring och rörande Produktägaren.

Det som kan ställa till det är hur rollen defineras i organisationen och projektet samt produktägarens engagemang och kommunikation med teamet, kund och beställare.

.

Product Owner Anti-Patterns

På 2010 Shanghai Scrum Gathering höll Monica Yap från SolutionsIQ ett seminarie som vackert listade upp sex stycken Produktägar anti-patterns. Gillar själva uttrycket ant-pattern, på sätt och vis en vacker omskrivning för ”gör inte så här”.

  • Frånvarande produktägaren – Produktägaren är otillgänglig och teamet ges ingen styrning eller snabb feadback.
  • Kopiering – ”Jag vet inte och bryr mig inte. Vi ska ju bara bygga om den gamla versionen av X så kolla hur den beter sig.”
  • Skenande Backloggen – Sprintmålen ändras frekvent under sprinten.
  • Vag DONE definitionen – Oklart vad teamet förväntas göra och uppnå för att få demonstrera och leverera en funktion/feature.
  • Ingen enskild produktägare – Produktägaren har inte mandat att ta beslut själv utan alltid måste vända sig till andra i organisationen för godkännande.
  • Saknade stakeholders – Nyckelpersoner som Produktägaren behöver konsultera och/eller samarbeta för att föra vision till leverans och avslut saknas

Hon radar både symptom, potentiella negativa konsekvenser men också botmedel.

.

Common Product Owner Mistakes

Likaså tar Roman Pichler upp sex stycken vanliga bekymmer rörande produktägaren i sin nya bok ”Agile Product Management With Scrum – Creating Products That Customers Love”. Vissa snarlika, andra nya:

  • Den kraftlöse produktägaren – Produktägaren saknar tillräcklig mandat.
  • Den överbelastade produktägaren – Produktägaren hinner inte engagera sig tillräckligt för att proaktivt kunna stötta teamet.
  • Den splittrade produktägaren – Flera personer delar på produktägarenrollen, dvs. ingen av produktägarna har helhetsansvaret.
  • Den avlägsne produktägaren – Produktägaren är otillgänglig eller nfsd fdsg fgsfd gsdg kjsdfkgjsdfklgjsfdlkg
  • Produktägar-ersättaren – För att hantera en kraftlös, överbelastad eller avlägsen produktägare brukar ofta någon i teamet (som inte har verksamhetskompetens eller bra kundförståelse) ta på sig rollen som produktägar-vikarie.
  • Produktägar-kommiten – En kommite fyller rollen som produktägare och delar på produktägarens ansvar och makt (vilket gärna riskerar sluta i ”Death by Committe”).

Även Roman tar upp konsekvenser men även råd och botmedel om man ser och märker av symptomen.

.

Ladda hem Monicy Yaps presentation ”Product Owner Anti Patterns” Scrum Alliance hemsida här.

Beställ Roman Pichlers bok exempelvis här (Amazon).