Posts Tagged ‘agile’

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

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

Skälet till varför Agil utveckling lönar sig

fredag, 12 mars, 2010

Denna fem minuter långa video beskriver enkelt och övertygande varför det lönar sig att jobba agilt, dvs. varför levererat värde och ROI (Return Of Investment) blir högre när man…

  • arbetar i korta iterationer
  • ofta leverera små inkrement av systemet/produkten
  • leverar första versionen av systemet/produkten så tidigt som möjligt
  • har tät feedback från kund och verksamhet

Med andra ord, varför det lönar sig att jobba Scrum.

h1

Flitig värre = Nyhetsbrev och Scrum-kurs-utkast

måndag, 8 mars, 2010

Verkar vara inne i ett stimm av flitighet just nu. Bara tacka och ta emot så länge det varar.

Under eftermiddagen idag lyckades jag få iväg ett sedan länge försenat nyhetsbrev till Sogetis nätverket för agila utvecklingsmetoder (för vilket jag är driver för). Skyller uteblivet fokus på högt tempo i uppdraget, kvällskurser och seminarier, samt en touch med utbrändhet i höstas. Men det kändes dock härligt att återigen pumpa energi i den riktningen också. Nästa steg blir att planera och bjuda in till möte.

Under kvällen lyckades jag också få till ett utkast till ramen för en ny Scrum kurs som riktar sig till beställare och mottagare av Scrum-projekt. Alltid lika klura att försöka summera något på få meningar men jag tror det blir bra. Berättar mera när arbetet kommit längre.

Vem var det som sa att morgonstund har guld i mun?

h1

Gratis frukost och irländare som pratar Agil Testning

måndag, 8 mars, 2010

Befinner du dig i Lund imorgon bitti tycker jag definitivt du ska ta en sväng till Sogetis kontor för ett spännande seminarie och lite gratis frukost. Ämnet är Agil testning och en riktigt tung expert inom området, Ken Brennock som hälsar på från Irland, håller i seminariet.

Agenda:

  • Genomgång av de viktigaste agila metoderna och hur varianter av dessa ibland används
  • Skapa en förståelse för det agila sättet att tänka
  • Typiska kvalitets- och testfrågor som kan uppstå i agila projekt
  • De viktigaste sakerna att tänka på ur kvalitets- och testsynpunkt när du skall börja arbeta agilt
  • Erfarenheter från agila projekt- fallgropar och framgångsfaktorer

Ken Brennock (Den ENDA bilden jag lyckades hitta)

Önskar jag själv hade möjlighet att komma och lyssna…

Mer info om seminariet på:
http://www.sogeti.se/Kundevents/Ta-tempen-pa-din-testverksamhet-och-fa-konkreta-forbattringforslag1/

Ken Brennocks sida:
http://www.softwaretestingclub.com/
profile/KenBrennock

h1

Scrum myt #2: Scrum är en hype

lördag, 6 mars, 2010

”Scrum är bara en hype. Det är bara coolt just nu att säga att man jobbar agilt men eftersom allt fler bevisligen springer in i bekymmer med Scrum kommer det snart självdö.”

Visst, fler och fler byter från tradionella sekvensiellt planerade projekt (a la vattenfall) till agila utvecklingsmetoder vilket byter att allt fler exempelvis kör Scrum. Scrum har en fantastisk förmåga att snabbt lyfta fram och synliggöra brister i organisationen, i rutiner och processer och i samarbete och kommunikationen kollegor och kund emellan, etc. Dessa ”brister” görs synliga genom Scrum. De skapas inte av Scrum utan har alltid funnits där. Misstaget är att anklaga Scrum för dessa problem och att inte utnyttja tillfället att addressera dem.

Dessa är definitivt en kortvarig hype! Eller är det bara jag som inser det?

Men visst, det är väldigt populärt att vilja säga att man jobbar agilt. Ordets hypade betydelse kommer dock förhoppnings svalna allt eftersom folk förstår den faktiska innebörden av att en utvecklignsprocess är agil.

Och visst, Scrum kanske är den populäraste projektmodellen just nu och kommer kanske om några år ersätts av Scrum 2. Men agila utvecklingsmetoder är definitivt här för att stanna! Var så säker på det.

h1

Scrum myt #1: Agilt betyder ”Ad hoc”

fredag, 5 mars, 2010

Överhörde häromdagen ”Jag angriper det här väldigt agilt, det vill säga jag tar det som det kommer”.

Suck.

Om personen ifråga menade ”Jag planerar inte mitt hobbyprojekt utan gör vad jag känner för från dag till dag” är det ändå verkligen långt ifrån Just-In-Time and Just-Enough planering, ett angreppssätt som tillämpas i Scrum. Att jobba ”Ad Hoc” är inte att jobba agilt.

Det vore som att säga att man är kristen bara för att man håller med om att ett slumpvis valt budorden verkar vettigt att följa, t.ex. ”Du skall icke dräpa”.