Posts Tagged ‘scrum’

h1

Gratis frukostseminarie; Scrum för ledning, ledare och kravställare – Om att arbeta mot en agil leverans

lördag, 13 mars, 2010

Jag höll detta seminarie i Sundsvall och Oxelösund under januari och ser nu fram emot nästa vecka då det är dags för Stockholm.

Båda tidigare tillfällen blev både välbesökta och uppskattade och jag hoppas det blir precis lika roligt på torsdag med mycket frågor och intressanta diskussioner. Har du inte tid eller möjlighet att komma själv, tipsa gärna kollegan eller varför inte den motsträviga chefen som inte verkar gilla ordet ”agile”?

Välkommen!

.

Scrum för ledning, ledare och kravställare – Om att arbeta mot en agil leverans

Precis som i traditionella projekt är utmaningarna många, men vad som dessutom sker i agila projekt är att behovet av samarbete och kommunikation mellan IT, kravställare och ledning ökar.

Högre krav ställs på att det sker kvalitativ och löpande dialog mellan alla parter. Ledning och kravställare erbjuds helt nya verktyg för planering, uppföljning och prognostisering. För första gången ges möjligheten att kontinuerligt se ett projekts sanna status. Problem, konflikter och risker synliggörs tidigt och kan därmed också adresseras för att maximera projektets framgång.

Tid: Torsdagen den 18 mars, klockan 08.00-10.00. Frukost serveras från klockan 07.30.

Plats: Sogetis kontor i Solna Business Park, Svetsarv 4, våning 5.

Seminariet (inkl. frukost) är kostnadfritt.
Mer information och anmälan här
.

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

Scrum på 10 minuter

torsdag, 11 mars, 2010

Hittade denna video på YouTube för en liten tid sedan. En riktigt ok sammanfattning av Scrum på endast tio minuter.

Håller kanske inte med om hans påstående att man är redo att tuta och köra efteråt men videon ger ändå en bra introduktion och förklar bra de grundläggande momenten och scrums roller.

h1

Belönar Scrum dåliga beteenden?

onsdag, 10 mars, 2010

En fråga jag ibland klurar på är om Scrum belönar vissa former av ”dåliga” beteenden? Dvs. finns det mekanismer i Scrum som uppmuntrar till fusk eller genvägar i någon form inom något område?

Jobbar jag exempelvis som utvecklare i ett vattenfallsprojekt vågar jag efter ett tag inte ge uppriktiga estimat då jag blir bestraffad om min arbetsprognos inte matchar den faktiska tid det tog för mig att göra jobbet. Konsekvensen blir att jag ger pessimistiska estimat med mycket luft. Detta blir jag såklart belönad för då jag nu lyckas hålla mina deadlines. Att jag får massa tid över för att klicka refresh på aftonbladet är ju iofs trevligt för mig – men ett ordentligt slöseri med tid och pengar. Detta är ett  exempel på när en process riskerar belönar ett dåligt beteende.

Frågan blir således: Om projektet drivs enligt Scrums alla regler skulle teammedlemmar kunna praktisera ”dåliga” beteenden som de senare belönas för?

Om svaret är ”nej” betyder det att Scrum är den magiska projektmodell som alla borde köra.

Är det så?

h1

Bygg inga pussel. Utveckla vertikalt!

tisdag, 9 mars, 2010

Vad innebär det att jobba inkrementellt? Hur levererar man en komplex lösning med en komplex arkitektur i små steg enligt en iterativ process såsom Scrum?

Iterativt = Upprepbar, lärande process. Små steg. Förvänta dig inte att få det rätt första gången. (Sprint = Iteration)

Inkrementellt = Bygg i vertikala tårtbitar (Stories) hellre än i lager, dvs. bygg inte en modul i taget för att i slutskedet försöka foga ihop dem. Bygg och leverera en liten del av helheten i varje iteration.

Så, vad är det man ska undvika?

  • Dela inte upp team efter applikationens lager.
  • Bygg inte en komponent i taget bara för att i projektets slutskede (under exempelvis integrationstestningen, eller än värre – efter leverans) upptäcka att bitarna inte passar ihop och måste skrivas om.
  • Bygg inte något under sprinten som inte resulterar i någonting som inte är av värde för slutanvändaren och som inte kan demonstreras på Sprint Demo.
  • Brodera inte ut komponenter med extra funktioner som kan ”vara bra att ha” eller som inte är nödvändiga just nu för den Story som ska levereras. (Med största sannolikhet är det antagligen ogjort jobb. ”Bra att ha”-funktioner visar sig ofta överflödig eller nödvändiga att skriva om när de väl ska anropas/användas.)

Hur ska vi göra istället?

  • Gruppera Stories i områden och bygg tvärfunktionella team runt varje område (som har kunskap som krävs för att utveckla och testa alla lager, exempelvis UI, server och databas).
  • Bygg en Story i taget och bygg alla funktioner som behövs (dvs. bygg det som behövs i UI, det som behövs på servern och det som behövs i databasen), och inget annat än det som behövs för Storyn.
  • Se till att Storyn som utvecklas under Sprint är tillräckligt avgränsad för att bli KLAR (dvs. kodad, testad, integrationstestad, dokumenterad, levererbar och installerbar)

Meh!?

…kanske någon tänker, ”Är det inte svårt att bygga något varje sprint som slutanvändaren kan använda och som har faktiskt värde för verksamheten?”

Svar ja.

De första Sprintarna kommer mycket energi och tid gå till att bygga skelettet och ramverket i arkitekturen. Och det måste det få göra annars riskerar man att få en slarvig struktur som inte går att bygga vidare från. Men ledordet även här måste vara – ”Bygg enbart och endast det du behöver, men gör det bra”. Försök inte förutse framtida behov utan bygg en arkitektur som är tillräckligt flexibel och stabil för att kunna anpassas, byggas ut och justeras i framtiden.

Balansgången är svår men däri ligger också nyckeln till förmågan att kunna leverera värdefull mjukvara efter varje Sprint och en av hemligheterna till hur man uppnår snabbhet och flexibilitet.

(Ursprungligen publicerad på blogg.sogeti.se)

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

Tidrapportering känns som Waste

söndag, 7 mars, 2010

Känner mig alltid lite frustrerad av att behöva summera förra veckans timmar för avrapportering i ett mail. Inte för att det är speciellt krångligt eller för att jag tycker att kunden inte förtjänar dem. Uppgiften att summera i ett mail (som brukar ta mellan 15-30 minuter) känns bara väldigt överflödig och som waste.

Kunden vet exakt hur många vi är i projektet per sprint sedan lång tid och känner till vår ungefärliga beläggningsgrad, dvs. om någon jobbar 100% i projektet eller 50%. Givet dessa faktorer kan man snabbt prognostisera vad varje sprint (eller vecka för den delen) kommer att kosta. Fakturan (baserad på mina faktiskt inrapporterade timmar i tidsrapporteringssystemet) kommer ju trots allt en gång i månaden. Till vilken nytta kan de mellanliggande veckorapporterna vara och vilken åtgärd föreställer sig kunden kunna hinna innan fakturan kommer?

Personer x Beläggningsgrad (dvs. Timmar/Vecka) x Veckor/Sprint x Pris/Timme = Pris per Sprint. Eller?

Fattar inte. Någonting är dolt för mig. Det är antagligen det som gör mig så frustrerad.

Det måste finnas ett ”hemligt” skäl till varför jag krävs på denna summering varje vecka.

Veckans statusrapport känns bättre. Den fokuserar på läget just nu, återstående arbete, risker och actions framåt. Värdefullt och användbart.

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

Rekord i Sprint planering

fredag, 5 mars, 2010

Wow. 50 minuter tog det idag. Över telefon- och webbkonferans dessutom!

Måste vara ett rekord för oss i projektet. Nu var vi iofs ovanligt väl förberedda och hade ovanligt bra koll på sprintens User Stories. Men ändå. Teamet committade till Sprint Mål, alla stories definerades, bröts ner i tasks och estimerades.

Tråkigt nog har vi inte lyxen med en Sprint Plan på väggen i vårt projektrum. Teamet är nämligen utspritt på fyra städer så vi får nöja oss med JIRA. Smått trubbigt verktyg när det kommer till att administrera större och längre projekt men vi har lyckats få det att fungera för oss iallafall.

Denna sprints frågetecken kanske är demon. Vi har deadlines mitt i sprinten pga av en mässa så frågan är vad som återstår att dema på Sprint Demon? Och såklart att vi som vanligt tvingas arbeta mot tre olika beställare som inte har en gemensam proxy som kan agera Product Owner för teamet.

Sprint-planerar själv framför JIRA. Teamet finns iofs live i andra änden av telefon konferansen.