Archive for the ‘Konsultliv’ Category

h1

Hur tänkte jag nu… 3 nya seminarier på samma helg!?

fredag, 20 augusti, 2010

Det lät som en bra idé när det begav sig men nu undrar jag lite grann hur mina hjärnceller jobbade när jag skickade in förslag på tre seminarier till Sogetis årliga interna konferans.

Inte nog med att det är tre helt nya seminarier, jag hoppas dessutom hinna med att skapa en ny design och nya illustrationer. Till två av seminarierna har jag iofs redan nu mycket material som förhoppningsvis ”bara” behöver paketeras om. Det tredje däremot kommer bli en riktig utmaning, men också det jag ser fram emot mest att förbereda och genomföra. Den största utmaningen kommer dock troligtvis bli att konstruera seminarier som håller sig inom, för mig rekordfå, 35 minuter.

Seminarierna jag ska sätta ihop är som följer:
(hoppas bara jag hinner förbereda mig ordentligt innan så jag hinner ta del av alla inplanerade fritidsaktiviteter också):

.

.

Scrum för nyfikna och säljare

Vad betyder det att vara agil? Vilka är nyckelfaktorerna för att lyckas leverera ett projekt enligt Scrum? Vilka är fallgroparna? Hur säljer vi Scrum och hur skriver vi agila kontrakt? Hur mäter man ett Scrum-projekts framgång? Vilka verktyg har ledning och styrgrupp för planering, uppföljning och prognostisering? Och framförallt, exakt hur grönt är gräset på andra sidan?

Till detta seminarie hoppas jag alla anmäler sig för i mitt drömföretag har alla kollegor (utvecklare, testare, projektledare och säljare) god förståelse av Scrum och är överens om hur vi tar oss an Scrum under säljprocessen och under leverans.

.

Det hyperproduktiva Scrum Teamet

Hur når man sann agilitet? Vilka förutsättningar krävs för att skapa teamet som ansvarsfullt, disciplinerat, engagerat och produktivt utvecklar värdefulla funktioner i högt tempo med hög kvalitet – varje sprint? Om frihet under ansvar, teamet, ”Death by Technical Debt”, det agila teamets verktygslåda och om ständig förbättring.

Min erfarenhet från tidigare när jag kört liknande seminarier på samma tema är att det blivit väldigt spännande diskussioner så jag hoppas och ser fram emot detta.

.

Om att crowdsourca en vision

Om att bringa liv i en fantasi, crowdsourca en vision och skapa kollektivt ägarskap. Om engagemang, förtroendekapital om viljan att överträffa förväntningar. Ledarskap i ideella projekt kontra projektledning i ”riktiga” projekt med avlönade projektmedlemmar. Om att genom en kraftfull webportal om community skapa kommunikation och delaktighet. Om att bygga en medeltida stad med 100 hus på två dagar – och sedan blåsa liv i den.

Äntligen kommer jag få berätta om mina erfarenheter kring att arrangera lajv fast ur ett lite annorlunda perspektiv. Det kommer bli oerhört roligt (och utmanande) att paketera alla erfarenheter jag erhållit om lajvarrangerande och hur viktigt IT, samarbete, delaktighet lederskap och crowdsourcing är när man vill genomföra stårdåd.

.

Video till bloggen

Nu är det tyvärr så att dessa seminarier enbart kommer gå att besöka om man jobbar på Sogeti och ska till Sogetidagarna i Åre, men jag ska göra ett försök att åtminstone spela in det tredje (Om att crowdsourca en vision) på video och sedan publisera det här på bloggen.

h1

Gott och blandat från Sommaren

onsdag, 18 augusti, 2010

Har snart plöjt igenom alla mina RSS flöden och hittat några godbitar jag tänkte dela med mig av.

Jag trodde alla hade haft semester, men icke. Vissa är visst lika flitiga på att skriva och ha åsikter oavsett årstid. Här nedan kommer ett litet axplock av dom de jag uppskattat hittills. Har som sagt några ytterligare att plöja igenom… ca 67 stycken…

.

Agile Adoptation Anti-Patterns

Denna artikel från LeadingAnswers: Leadership and Agile Project Management Blog radar upp 5 ”populära” fallgropar organisationer gärna trillar ner i på sin resa till en agil organisation.

Läs artikeln här:
http://leadinganswers.typepad.com/leading_answers/2010/07/agile-adoption-antipatterns.html

.

Top 100 Agila Böcker

Jurgen Appelo har sammanställt en lista över de 100 populäraste böckerna på Agile ämnen genom att kombinera information från bland annat Amazon.com och GoodRead.com m.m. Visste knappt att det fanns hundra böcker om ämnet…

Se listan här: http://www.noop.nl/2010/08/top-100-agile-books.html

.

Övning ”Define your Definition of Done”

Tobias Fors beskriver ingående en övning för Scrum-teamet för att definiera Definition of DONE. Tobias går steg för steg igenom övningen på ett tydligt och bra sätt.

Läs artikeln här: http://www.tobiasfors.se/?p=575

.

Crowdsourced Testing, Changing the Game

InfoQ reflekterar över ”Crowdsourced Testing” och summerar åsikter och kommentarer på ämnet från olika bloggar. Själva konceptet tycker jag är mycket spännande och intressant, och jag är också övertygad om att denna approach kommer att växa snabbt inom de områden där det är möjligt.

Läs artikeln här:
http://www.infoq.com/news/2010/08/crowdsourced-testing

.

Your Scrum Checklist

Boris Gloger har släppt en ny version av ”Your Scrum Checklist” för gratis nedladdning på InfoQ (kräver inloggning).

Klicka här för att ladda hem den gratis som pdf (kräver inloggning):
http://www.infoq.com/minibooks/scrum-checklists

.

h1

Back in business

måndag, 16 augusti, 2010

Så var semestern över för denna gång och verkligeheten gör sig effektivt påmind. Första dagen på jobbet efter fem veckors ledighet är alltid lika förvirrad.

Medeltidsveckan i Visby fick bli semesterns final. Fantastiska dagar med sol, vänner, sång, gyckel, galenskaper och sena nätter. Smälter fortfarande minnen från veckan som varit, samtidigt som jag försöker komma ihåg vad det var man egentligen gjorde här på jobbet. Mailen har gåtts igenom, workshoppar och möten har bokats, en ny sprint börjar imorgon och nya seminarier förbereds.

Trixarnas fantastiska eldshow i Visby (Nordengravar) 2010-08-11

.

Det kommer nog dock dröja tills imorgon innan jag är helt med i gemet igen och fångat upp alla bollar som var i luften innan sommaren började. En boll som nu åter är i luften iallafall är ”Den Scrummande Konsulten”!

Nu kör vi! 🙂

h1

Sätt dina Scrum-kunskaper på prov

onsdag, 7 juli, 2010

Scrum.org har ett öppet och gratis prov man kan göra om man har en halvtimme över. Hittills har över 2500 personer gjort provet enligt Ken Schwaber.

”The Scrum Open assessment is available for free to anyone interested in testing their knowledge of Scrum” står det på scrum.orgs hemsida.  Testet består av 50 slumpvis utvalda kunskapsfrågor om Scum och utvecklades, förfinades och anpassades under en sex månaders period.

Jag gjorde testet nyss och fick 88% första gången. Efteråt får man en chans att kika igenom svaren och se vad man svarade fel på. Detta kunde jag såklart inte låta bli. (Btw, 75% krävdes för att få godkänt på provet.)

Dels måste jag säga att vissa frågor kände knepigt formulerade och att det ibland saknades ”rätt” svarsalternativ. Men jag upptäckte också att det dels fanns det svar jag faktiskt inte höll med om (som att det t.ex. är ok för två team att dela på en produkt backlogg eller att bara produktägaren har rätten att avbryta en sprint).

Hursomhelst, man får göra provat flera gånger om man vill. Sagt och gjort. Flera av frågorna från första omgången dyker upp igen och då korrigerade jag såklart mina tidigare ”felaktiga” svar efter vad jag lärt mig är det ”rätta” och nådde då 98%. Nu känns det mycket bättre.

Men jag måste också säga att jag gillar idéen och att de allra flesta av frågorna faktiskt var bra, intressanta och lärorika. Fick en att fundera till lite och tänka efter. Så om du har 20-30 minuter över och är nyfiken på hur dina Scrum-kunskaper (eller synpunkter på hur ett Scrum-projekt bör köras) värderas av Scrum.org rekommenderar jag dig klicka dig igenom testet. Eller varför inte använda provet som diskussionsunderlag på nästa Sprint Retrospective!?

.

.
Scrum.orgs Scrum Open assessment hittar du här:
http://www.scrum.org/scrumopen/
.

h1

Video: Vägen från PL till Agile Coach

torsdag, 1 juli, 2010

Blev genom en av bloggarna jag följer tipsad om en fantastisk videopresentation av Lyssa Adkins. Om du har rollen som Scrum Master eller Agile Coach kommer du nog finna den mycket inspirerande och givande.

Lyssa Adkins släppte i Maj 2010 boken ”Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches and Project Managers in Transition”. Efter att ha kikat igenom presentationen (två gånger faktiskt) är detta en boken som ligger högst just nu på min att-läsa-lista.

.

.

The Road from Project Manager to Agile Coach

Del ett (ca 10 min):

.

Del två (ca 10):

h1

Agil Testning och Molnbaserad Testning starkast trender inom kvalitetssäkring

torsdag, 17 juni, 2010

World Quality Report 2010-2011, en rapport som publicerades igår av Capgemini och HP bekräftade något som jag redan betraktade som ”kunskap” efter vad jag sett, hört, erfarit och upplevt i mitt kontaktnätverk på Sogeti och ute hos kunder, nämligen att fokuset kring Agil Testning, men även molnbaserade testtjänster, snabbt växer i mjukvaruutvecklingsbranchen.

I Sogetis pressmeddelande kan man läsa ett utdrag från rapporten:

”…kraven ökar, på både utvecklare och testare, för att skapa större effektivitet, konsekvent använda kvalitetssäkringsmetoder och öka återanvändningen av testautomatisering. Därför använder organisationer sig av allt mer agila och molnbaserade leveransmetoder för att modernisera sina applikationer.”

Man kan vidare läsa:

”Då kraven på IT-leveranser förändras, visar rapporten att även kraven på kvalitetssäkring ökar i betydelser. Morgondagens testare kommer att arbeta i mindre team som förväntas leverera användbar kod inom fyra till sex veckor. Korta deadlines och mindre team kommer sannolikt att leda till en framtid där prioriteringen av kompetensen i kvalitetssäkrings- och testteam kommer att förändrad.”

Den nya Agila Testaren?

.

Vidare presenteras också vad företag upplever som de största fördelarna med agil utveckling. Sådan statistik tycker jag alltid är spännande och intressant.

Detta är bara ytterligare en bekräftelse på att agila metoder vinner mark och att branchen kommit långt i en övergång till agila utvecklingsmetoder. Läs mer om de agila metodernas framfart i denna artikel.


Ladda hem rapporten i sin helhet här från Capgeminis hemsida. Kräver dock registrering.

h1

De agila metodernas framfart

onsdag, 16 juni, 2010

I en rapport från tidigare i år framgår det att vattenfall och iterative metoder tappar mark till fördel för agila utvecklingsmetoder. Rapporten berättar att 35% använder agila utvecklingsmetoder och att 10% av dessa kör Scrum. Men i rapporten finns många fler spännande siffror.

Det här är kanske inte rykande färska nyheter eftersom rapporten publicerades i januari 2010. Men å andra sidan tycker jag det är så pass spännande att det är värt att repetera och det är säkert många som inte hört talas om den tidigare. Rapporten baserar sig på svaren från 1300 läsare till Dr. Dobb’s Journal och undersökningen genomfördes Juli till Augusti 2009.

.

I bilden ovan kan man utläsa att det är ungeför lika många som använder sig av agila utvecklingsmetoder som vattenfall och iterativa, ca 35% vardera. Vad läskigt värre är dock att de resterande 30% föredrar att inte arbeta efter någon metod alls!

Vidare trodde jag att det skulle skilja stort mellan stora och små företag med hänsyn till utvecklingsprocess. Icke. Spridningen är stor i båda fallen.

Däremot verkar det över lag vara så att teammedlemmar och chefer har gravt olika uppfattning om vilken process man kör, om det är agilt eller inte. Detta känner jag dock definitivt igen!

.

Läs hela rapporten ”Agile Development: Mainstream Adoption Has Changed Agility – Trends In Real-World Adoption Of Agile Methods” skriven av Dave West och Tom Grant, Ph.D (samt Mary Gerush och David D’Silva).

h1

Stress, trötthet, rädsla och klantighet

fredag, 4 juni, 2010

Test Driven Utveckling och par programmering är de kraftfullaste tekniker jag känner till för att höja kvaliten och minska antalet fel i koden.

Men hur kommer det sig att det smyger sig in galenskaper och fel i koden över huvud taget? Varför kan vi inte ”bara” koda rätt från början?

Som jag ser på det finns det två övergripande kategorier av fel-källor:

.

1) Intellektuella

Tolkning
I alla steg när man tvingas tolka eller minnas vad det var man skulle bygga finns alltid risken att man missförstår kravet, user storyn eller problembilder. Vissa detaljer kanske man glömmer bort, andra introducerar man i felaktig krav-extrapolering.

Tankevurpor
Man tror att ett problem går att lösa på ett visst sätt, kodar utan vare sig introducera buggar, minnes läckage eller andra svagheter. När man sedan börjar testa visar det sig att man tänkt galet och att skriven kod inte alls klarar av att lösa problemet eller beter sig inte som man föreställde sig när koden skrevs.

.

2) Mänskliga

Okunskap
När man anropar funktioner och integrerar mot moduler som andra har skrivit gör man det ofta utan att förstå den koden ordentligt, dess krav på input-parametrar, etc.

Stress
Press och stress kan ibland kortsiktigt höja fokus och prestation, men efter en stund vänds effekten och man börjar missa detaljer och introducera slarvfel, eller helt missa koda vitala delar i sin flykt undan piskan.

Tristess
Är du uttråkad och totalt oinspirerad är det till och med ansträngande att göra ett hyffsat jobb. Man lockas till genvägar och snabb-hack.

Trötthet
Jobbat för mycket övertid? Svårt att sova? Är man trött går allt lite långsammare och ibland känns det som om kablarna i huvudet inte riktigt når hela vägen fram…

Repetition
Som människa är man inte speciellt duktig på att upprepa något monotomt många gånger utan variation.

Avbrott
Avbrott gör att man tappar fokus och kanske tar upp arbetet lite vid sidan av där man slutade.

Rädsla
Är vi rädda för att få skäll, blotta vår okunskap eller förmedla dåliga nyheter har vi en tendens att prata mindre, skydda oss från dålig feedback och slutar ställa frågor. I värsta fall börjar vi trevande gissa sig fram på egen hand utan att egentligen veta om vi gör rätt eller fel.

Klantigheter
Copy’N Paste slarv. Syntaxfel. Tangent-glidningar.

.

Felsäker kod?

Finns det metoder och tekniker som fullständigt eliminerar ovanstående källor och orsaker? Antagligen inte. Men som jag skrev inledningsvis är TDD och par programmering de kraftfullaste teknikerna jag känner till.

Sedan har jag idéer, synpunkter och erfarenhet kring andra tekniska tekniker och mjuka  metoder för att förebygga och skydda sig mot fel. Dessa finns det dock inte utrymme att skriva om här idag, och jag känner dessutom att de förtjänar en egen artikel.

.

Äldre relaterade inlägg:

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.

.

.