Archive for mars, 2010

h1

Scrum myt #4: Zoomar man in är Scrum bara små, små vattenfall

onsdag, 31 mars, 2010

”Om man zoomar in tillräckligt mycket i Scrum, in i en sprint så är det ju bara små, små vattenfall. Inget nytt under solen.” FEL!

.
.
.

Scrum är inte små, små vattenfall.

Det grundläggande arbetssättet:
1) planera,
2) utföra,
3) kontrollera och
4) agera

dvs. att man tänker och planerar innan man handlar är inte synonymt med vattenfall.  Så gör man i alla situationer, oavsett uppgift.

.

Så, till skillnad från vattenfall så…

  • Levererar Scrum affärsvärde och ROI väldigt tidigt.
  • Scrums korta feedback cykler förändrar dagligen planen och planering.
  • Planering i Scrum fokuserar på att leverera affärsvärde (inte sprida ut arbetsuppgifter och deadlines i en kalender).
  • Scrum processen är själv-justerande och själv-förbättrande genom kontinuerlig utvärdering och granskning (i motsats till att ha en projektutvärdering i slutet).
  • Scrum välkomnar förändringar, till och med sent i processen, och detta är en naturlig del av processen.
  • Springer man in i bekymmer och tidsnöd så anpassar man i Scrum omfattningen (i motsats till att låta arbetsuppgifterna i planen skjutas framåt som ett tåg av dominobrickor).
  • I Scrum räknas inte framgång i antalet implementerade krav per deadline utan i levererat affärsvärde och kundnytta per sprint.
  • Levereras projektet enligt Scrum kan beställaren efter valfri* Sprint säga ”Nu är jag nöjd” (till skillnad från vattenfallsapproachen då allt eller inget levereras).
  • Scrum levererar potentiellt installerbar system/levererbar produkt varje sprint. Dvs. dokumentation, test, förvaltningsöverlämning etc. ska ske kontinuerligt (i stället för att komma som faser i slutet).

* Brasklapp. Det kan såklart dröja några sprintar innan man nått en minimal nivå av funktioner för att produkten ska gå att använda över huvud taget. Och ibland kanske det också krävs en stabiliserings- och Deploy sprint efter att beställaren ”är nöjd”.

.

Jag kan fortsätta rada upp skillnader. Jag hoppas dock i och med detta utbrott att det en gång för alla är vederlagt och fastslaget att det är stor skillnad mellan sekvensiell up-front planering/big-bang leverans (a la vattenfall) och agil planering/iterativ inkrementell leverans (Scrum). Fast att tro något sådant kanske vore nog naivt…

h1

Project Manager – to be, or not to be?

tisdag, 30 mars, 2010

En PMI certifierad  project manager ställer sig frågan ”Can a ScrumMaster be a project manager — are the positions one in the same?” i en nyligen publicerad artikel. Vidare hävdar hon att ”The project manager is the overarching manager and person accountable at the project level, while the ScrumMaster is the one responsible for the product development.”

Redan i ingressen känner jag i magtrakten att det är något knepigt i hennes tankengångar. Det tog ett tag innan jag lyckades formulera det för mig själv.

Låt oss vända på det hela.

.

Anta att vi har ett projekt som omfattar:

  • en Scrum Master som ser till att alla följer Scrum, utbildar, inspirerar, möjliggör teamet, kontinuerligt provocerar till förbättringar och sköter den dagliga adminstrationen,
  • ett agilt team (cross-functional, self-organizing and empowered) som estimerar storys i produktbackloggen, formar sina egna sprintmål efter produktbackloggens prioritering och bygger den faktiska mjukvaran,
  • en Product Owner som ser till att produktbackloggen är uppdaterad och prioriterad, för tät dialogen med teamet samt sköter release planering, samt eventuellt (men inte nödvändigtvis)
  • en styrgrupp, aka Meta-Scrum, som stöttar teamet med t.ex. resurser, staffing, etc.

Vad återstår? Är inte alla planerings-, koordinerings- och ansvarsfrågor omhändertagna? Om man ser behovet att behålla rollen ”Project Manager” har man inte lyckats (eller inte vågat) gå hela vägen mot en agil leverans och organisation!

Lisa A. Grant skriver vidare i sin artikel; ”The project manager ensures that the business case is clearly defined, compliance documents are completed in a timely manner, product deployment activities are executed — and he or she manages all other business aspects of the new product launch.”

Det här är ju perfekta uppgifter för produktägaren att ta ansvar för och prioritera in i release planering. Produktägaren initierar projektet (genom att formulera visionen, förankra visionen och kontinuerligt bygga upp och underhålla produktbackloggen) och är självklart med hela resan tills systemet/produkten är klar och sjösatt. Däremot kanske scrum teamets konstellation och storlek varierar med tiden.

.

Jag tycker att Lisa istället borde acceptera att hennes roll i ett agilt projekt, i en lean organisation, kanske är överspelad. Hennes kunskaper och erfarenheter är det såklart dock inte! Sedan om hon passar bäst som Scrum Master, Produkt Owner eller annan organisatorisk roll har jag ingen aning om.

h1

Scrum – Fake it until you make it!

måndag, 29 mars, 2010

Hur gör man för att köra mera utav Scrum och göra det bättre? Hur gör man för att person X och Y ska ”fatta”?

Det enda sättet är tyvärr att jobba på, experimentera, våga göra misstag och dra lärdom av vad som fungerade bra och vad som fungerade sämre och ta tillvara på de tillfällen som ges att lyfta Scrum (och personerna i och runt Scrum projektet) när möjlighet ges!

Joe Little publicerade precis två artiklar där han funderar och tänker högt kring ämnet. Han ger inte direkt några knivskarpa och enkla råd men han lyckas rada upp några riktigt fina ordspråk:

.

We are as likely to act ourselves into a new way of thinking as to think ourselves into a new way of acting.

Fake it. Pretend that you want to do it. Feign optimism. Just do it. Do it as an experiment.

”Going through the motions can trigger the emotions.”

.

”Vadå? Vilka floskler!” kan man kanske tycka.

Kanske det kanske men jag gillar ändå hans budskap. Genom att föregå med gott exempel och helhjärtat anstränga sig att följa Scrum och praktisera de agila värderingarna  så kommer involverade och berörda med tiden bli bättre på att jobba enligt Scrum och så småningom även få djupare förståelse för varför Scrum fungerar och hur det fungerar.

Precis som överallt annars så har människor man försöker inspirera eller lära en tendens att göra som man själv gör – och inte som man säger…

.

Yoda uttrycker det hela lite enklare:

”Do. Or do not.
There is no try.”

.

Läs Joe Littles artiklar här:
A re-write och Changing people (that includes you)

h1

Varvar ner och försöker landa

lördag, 27 mars, 2010

Denna vecka kanske inte blev lika fartfylld som förra veckan, men jag tyckte gott det räckte till. Fick en liten andningspaus och möjlighet att förbereda mig lite inför kommande utmaningar.

Summering av veckan:

  • Åtskilliga timmar av webb- och telefonkonferenser med bl.a. letter, ester och ryssar för att diskutera integration.
  • Flera ”beställningar” på Scrum kurser från helt nya kunder har trillat in. Mycket skoj!
  • Diskussioner om utbyggnad/anpassning av Sogetis kvalitetsprocesser för agila projekt.
  • Workshop kring outsourcening av test i agila projekt.
  • Blandade mail och telefonsamtal rörande Sogetis kompetensområde för Agila utvecklingsmetoder (KO Agile).
  • Revidering av vårens Release planering.

Bäst allt var dock att jag tror jag har hittat en bra och effektiv teknik för mig själv för att hålla koll på alla bollarna som jag har i luften 🙂

.

Just-Nu Att-Göra Listor

Varje uppslag i mitt block representerar en dag. Till höger har jag dagens ”Att-Göra”. Till vänster blandade anteckningar, t.ex. från dagens Daily Scrum. Poppar det upp något jag ska fixa i övermorgon, då bläddrar jag fram till den sidan, lägger till en checkbox och glömmer sedan bort uppgiften. I slutet av dagen går jag igenom de punkter jag inte hunnit med för att avgöra om jag ska stryka dem (de kanske känns överspelade eller oviktiga pga av andra omständigheter) eller flytta fram dem till morgondagens lista. På så sätt behöver jag aldrig backa för att se om jag glömt något från tidigare dagar eller komma ihåg vad som väntar imorgon. Jag kan fokusera på dagen!

Inget rocket science direkt men funkar toppen för mig. Avverkar dock anteckningsblock i rasande fart…

.

Men nu är det helg och den ska det njutas av! 🙂

h1

Fingervotering – Blixtsnabb konsensus check

fredag, 26 mars, 2010

Fingervotering, ”Fist of Five”, är en simpel men effektiv teknik för att se om ett förslag har stöd i en grupp.

När det är dags formuleras det eventuella beslutet teamet ska ta (exempelvis av Scrum Mastern). Sedan ombeds varje teammedlem visa vilket stöd de känner för förslaget genom att hålla upp ett antal fingrar som representerar hur mycket de stöttar förslaget, alternativt en sluten näven.

Mycket effektivare än att t.ex. gå varvet runt och be alla uttrycka och förklara sitt stöd (eller ogillande av förslaget) med ord – speciellt när alla är ense ;-p

Sluten näve = ”Jag vill diskutera förslaget ytterligare för jag kan inte gå med på det som presenteras just nu”. Ett sätt att blockera konsensus.

1 finger = ”Jag vill diskutera mera, belysa vissa problem och/eller föreslå några ändringar.”

2 fingrar = ”Jag är ok med förslaget men vill diskutera några detaljer lite ytterligare.”

3 fingrar = ”Jag håller inte med till 100% men kan vara ok med det. Behöver ingen ytterligare diskussioner.”

4 fingrar = ”Gillar förslaget och kommer jobba för dess sak.”

5 fingrar = ”Grymt förslag! Jag leder gärna arbetet!”

.

Konsensus?

Om alla håller upp tre eller fler fingrar antas förslaget ha stöd i gruppen och teamet nått konsensus.

Om någon håller två eller färre fingrar ska dessa ges en chans att förklara sina argument eller tvivel. Teamet diskuterar och argument bemöts. Sedan fingervoterar man igen och fortsätter tills teamet nått konsensus – eller beslutat sig för att lägga förslaget på hyllan och gå vidare.

h1

Försöker placera bloggen på kartan

torsdag, 25 mars, 2010

Vet inte varför men jag kan inte sluta refresha min besöksstatistik flera gången om dagen. Så rafflande mycket händer faktiskt inte där – än.

Ivrig och otålig...

Förstår att man kanske inte ska ha dom högsta förväntningarna på en två veckor gammal blogg. Gillar folk den kommer flera att upptäcka den tids nog. Men i väntan på dessa tider och som ett led i att försöka nå flera besökare har jag placerat min blogg i Stockholmbloggkartan.se efter tips från en vän.

Nu dyker bloggen iallafall upp i träfflistan om man googlar ”scrum konsult sverige”,  eller söker efter ”scrum” på t.ex. Bloggar.se.

Det artar sig 🙂
/Mr. Otålig

.

PS. Du får ju såklart mer än gärna tipsa kollegor och vänner som också är intresserade eller nyfiken på Scrum och agila utvecklingsmetoder att bloggen finns. DS.

h1

EVE Online goes Scrum

onsdag, 24 mars, 2010

Intressant föreläsning från Fanfest 2009. CCP utvecklar EVE Online och på konventet höll Adalsteinn ”Alli” Ottarsson (Technical Producer) och Noah Ward (Lead Game Designer) en uppskattad föreläsning som blivit upplagd på YouTube.

De berättade bland annat om hur de gick från (en för dem framgångsfull) vattenfalls baserad utvecklingsmodell till att jobba enligt Scrum inför Apocrypha expansionen (deras största expansion hittills). De berättade om hur de skalade upp och anpassa Scrum för att klara av deras 11 team vilka är utspridda över tre länder (Island, USA och Indien).

De gick igenom lite hur de jobbar med ”krav”, dvs. hur de såg på och hanterade Epics, Features och User Stories. Avslutningsvis berättade de om vilka utmaningar de står inför just nu. Jag uppskattar alltid när folk ärligt berättar om misstag, bekymmer och frustrationen – däri ligger mest att lära.

Riktigt intressant om man tycker om att lyssna på föreläsningar! Nu har dom släppt precis nästa expansion, Dominion. Jag är nyfiken på hur det har gått för dem…

Men jag kan jag inte låta bli att undra… Scrum är nästan en standard i spelbranschen för att kunna möta strikta deadlines, hålla budgetar och leverera kvalitativa spel till en krävande och kräsen publik. Varför sprider sig inte denna insikt om styrkan med agil utveckling snabbare än vad den gör till andra branscher?

h1

Scrum myt #3: Agil utveckling är odisciplinerad

tisdag, 23 mars, 2010

”Agila metoder är bara utvecklarnas ursäkt för att få göra som dom vill”, eller Extreme Programming är ju bara ett fint ord för fulkodning eller hack-n-fix” är påstående jag hört från olika håll, och ibland fortfarande känner bubbla under ytan. Sanningen är snarare motsatta.

För att överhuvud taget lyckats producera högkvalitativ, levererbar kod varje sprint i ett Scrum projekt, och samtidigt undvika att bygga på teknisk, skuld behövs ordentlig disciplin i teamet. Scrum beskriver inga best-practices för programmering eller test – det gör däremot XP och därför är XP ett kraftfullt,  populärt och nästintill nödvändigt komplement till Scrum (vissa XP principer är t.o.m. inbyggda i Scrum).

Men det är absolut inget extremt alls med XP principerna. Var och en av dem beskriver ett verktyg, eller trycker på vikten av olika metoder eller tekniker för att utveckla kod på ett strukturerat sätt som i sin tur skapar högre kvalitet. Ingen av dem säger ”Gör som du vill så blir det bra”. Jag vet inget som kräver så mycket disciplin, tålamod och ödmjukhet som till exempel par programmering. Jag har å andra sidan svårt att komma på något som höjer kvaliten så mycket som just par programmering.

Nu kan det ju dock såklart vara så att du har en person i Scrum teamet som gått på myten och tagit med sig missuppfattningen in i teamet och som hävdar att alla förslag på att införa stuktur, design patterns, templates, etc. går emot Agile värderingar och principer. Det finns inget enklare sätt att uttrycka det på – den personen är låååångt ute på åkern och cyklar.

Agil utveckling och Scrum kräver disciplin!

h1

Lägg krut på rätt ställe med ”Focus Scales”

måndag, 22 mars, 2010

Hur vet man att man lägger krutet på rätt saker? Hur kan man förenkla utmaningen med att kommunicera kundens vision in i Scrum-teamet? Räcker Produktbackloggens prioritering för att nå maximal verksamhetsnytta? ”Focus Scales” kan vara ett kraftfullt verktyg för att fylla gapet mellan kundens behov och teamets ansträngningar.

.

Agiles projektledningstriangel

Scrums verktyg för att ena kunden och Scrum-teamen under samma ledstjärna är ett Vision Statement. Denna beskriver visionen för IT-lösningen, dvs. vad dess syfte är, mål och önskat resultat. Agiles projektledningstriangel säger vidare att vi aldrig får kompromissar med kvaliteten utan att vi anpassar scoopet för att nå tid och budget.

Även fast vi aldrig tummar på kvalitét gör vi fortfarande kontinuerligt andra typer av val; dels avgör vi löpande i vilken ordning vi utvecklar funktionerna (dvs. vad som ska levereras efter nästa sprint). Men vi avgör också löpande hur mycket krut vi ska lägga ner på varje funktion, dvs. hur avancerad eller minimalistisk implementering av varje User Story ska göras.

.

Focus Scales

Själva prioriteringen av Produktbackloggen gör Produktägaren givetvis löpande i dialog med kunden. Det är dock en mycket god idé att samtidigt som man tar fram ”Vision Statement” även målar upp några enkla tumregler för vad man ska lägga extra tid och energi på och vad man ska hålla enkelt.

Som ett diskussionsunderlag för Produktägaren (och teamet) i sin dialog med kunden kan man använda sig av något jag kallar Fokus Scales. Dessa kan även teamet använda internt när de designar funktionerna och funderar över hur pass avancerad eller enkel lösning de ska sikta på.

Att dessutom ta fram dessa vågskålar under en workshop där både kund och teamet är med (eller åtminstone representanter för teamet) öppnar upp för en fantastisk möjlighet att diskutera idéer, koncept och nå konsensus över vad man vill åstadkomma och vad som är viktigt.

Ett exempel på ett projekts fokus vågskålar…


Varje vågskål beskriver hur balansen ska läggas när man väljer mellan två olika kriterier. Observera att kriterierna absolut inte behöver vara motsatser eller utesluta varandra, de ska endast vara vägledande och fungera som diskussionsunderlag. Kriterier som är vettiga i ett projekt kanske helt saknar relevans och betydelse i ett annat. Det är en god idé att begränsa antalet vågskålar till ett fåtal (kanske 3-5 stycken). Med för många vågskålar riskerar summan av dem bli svårbegripliga och motsägelsefulla.

.

Tydligare ledstjärna!

Genom att börja med att ta fram Vision Statement och Focus Scales etableras och kommuniceras en tydlig målsättning och gemensam ledstjärna för både kund och team från början. En framgångsfaktor för alla agila projekt.

(Ursprungligen publicerad på sogeti.blogg.se)

h1

<tatoo>…</tatoo>

söndag, 21 mars, 2010

Låter bilden tala för sig själv. Som gammal utvecklare kan jag inte sluta le när jag tittar på den. (Minns dock inte var jag hittade bilden första gången.)