Posts Tagged ‘team’

h1

”Slack” ger högre kvalitet och effektivitet!

torsdag, 24 juni, 2010

Bakom Agiles princip ”The sponsors, developers, and users should be able to maintain a constant pace indefinitely” döljer sig mycket visdom.

Det kanske mest uppenbara principen säger är ”Sprinta [som i att rusa fort framåt] inte”, se till att ha ett jämt tempo för alla inblandade.

.

Lagom tempo

  • Skapa inte falska förhoppningar om produktivitet (genom att t.ex. jobba för mycket övertid) som leder till att varje sprint blir en stressad kamp för teamet att hinna klart med alla löften.
  • Ha inte för långa Sprintar som tillåter teamet producera mera än verksamheten hinner absorbera och ge feedback på.
  • Ha en bra balans av kompetenser inom teamet så att det inte uppstår trafikstockningar i slutet (för t.ex. testning, integrering, dokumentation, etc).

Blir varje sprint stressad kommer snart vissa bränna ut sig, andra tröttnar på att anstränga sig och troligtvis kommer teamet så småningom att hitta ”hemliga” sätt att hantera detta på för att få en drägligare tillvaro. Detta i sin tur leder till att teamet kommer att prestera olika mycket varje sprint. Förutsägbarheten (och förmågan att planera framåt) och kvalitén undermineras och saboteras.

”Om du alltid spurtar så joggar du i själva verket bara!”

Pauser

Vidare ges ofta rådet att ha en paus mellan två sprintar, så kallad ”Slack Time”, dvs. ha inte Sprint demo på förmiddagen och Sprint planeringen på eftermiddagen. Ge teamet en chans att återhämta sig och vila upp sig. Både produktägare och teamet kan dessutom behöva en liten stund att fundera och smälta feedbacken och tankarna från Sprint demon och Sprint retrospective och för att samla sig för nästa iteration. Se till att åtminstone ha en natt eller en helg emellan.

.

Projekt-fria dagar!

Det kanske mest kontra-intuitiva rådet är att inte enbart ha en naturlig paus (som t.ex. en helg) mellan två sprintar, utan en eller två fria arbetsdagar under vilka teammedlemmarna får ägna sig åt precis vad de vill. Uppmuntra självstudier, laborationer, test av nya verktyg och tekniker osv. men ställ absolut inga krav på resultat! Låt kreativiteten, nyfikenheten och det personliga intresset stå i fokus.

Men, skulle det dock dyka upp buggrapporter på det teamet nyss levererat måsta de släppa det de håller på med och återgå till arbetsbänken till dess att problemen är lösta.

.

Kvalité blir heligt

Dessa projekt-fria dagar blir snart heliga för varje teammedlem. Teamet kommer att göra sitt yttersta för att inte riskera bli bestulna på sin ledighet!

Teamet kommer göra sitt allra bästa för att uppfinna metoder och tekniker för att bättre säkra kvalitén (genom t.ex. automatiserade tester, m.m.) och kommer att föra djupare och bättre dialoger med produktägaren, kund och beställare för att inte missförstå kraven. Ingen vill vara ”orsaken” till att resten av teamet fick avbryta sina projekt-fria dagar för att lösa ett problem man borde fångat upp under sprinten.

Jag låter det vara osagt om teamets arbete att höja kvaliten med detta grepp föds ur höjd teamkänsla eller grupptryck. Det lämnar jag öppet för diskussion…

.

.
Ursprungligen publicerad på sogeti.blogg.se

.

h1

Vår dagliga Sprint Burndown

tisdag, 1 juni, 2010

Dagens sprintplanering är precis avklarad. Lite bökigare än vanligt eftersom våra sprintmål denna sprint var väldigt spretiga men vi nådde i land till slut. Spretiga sprintmål riskerar sluta i att det blir svårt att fokusera och samlat och disciplinerat jobba mot en sprint demo. Dock borde vi kunna hålla bra koll på våra framsteg med hjälp av JIRA och vår dagliga Sprint Burndown, verktyg som vi blir allt bättre på att använda och utnyttja.

Då teamet sitter distribuerat har vi inga daglig Stand-Up Meeting utan kör istället med ”Daily Call-Up”. Strax innan telefonkonferensen mötet skickar jag också ut en fräsch och uppdaterad Burndown-chart för att vi ska kunna lyfta blicken och inte bara fokusera på ”här och nu”. Bäst hade såklart varit att träffas fysisk IRL runt en vägg med sprint planeringen och flytta runt på lappar istället för att uppdatera tasks i JIRA, men men, vi arbetar kontinuerligt med att göra det bästa av situationen.

Vår Sprint Burndown är absolut ingen rocket-sciense men tänkte att det alltid är någon som uppskattar att se exempel från verkligheten. Denna screenshot är några veckor gammal men passar ändå bra som exempel.

(Klicka på bilden för att se en större version)

.

Utöver att spåra återstående tid har vi längs med resan lagt till ytterligare dimensioner på vår burndown (information som extraheras från JIRA). Alla värden och estimat i tabellen ovan är i timmar.

Total – Summan av orginal-estimeringar för alla tasks. Vissa sprintar ”uppstår” arbete när vi lär oss mer om de tekniska utmaningarna. Ibland stryks detaljer funktioner (pga av det antingen blir inaktuellt att implementera dem eller för att de scoopas ut från sprinten). Vi har lärt oss att vår velocity ligger på ungefär 3,5 – 4,5 per dag och teammedlem och det är vi planerar efter.

Remaining – Återstående arbete, dvs. summan av uppskattad återstående tid (Remaining Estimate) för alla tasks som inte är ”Resolved”.

DONE – Avklarat arbete. När en tasks går från ”In Progress” till ”Resolved” ökar DONE med taskens ursprungliga estimat.

In Work – Original estimate summeras för de tasks som är ”In Progress” just nu. Denna försöker jag hålla så låg som möjligt så att det inte jobbas på för mycket parallellt.

.

Det jag saknar och eventuellt överväger att lägga till är:

Added/Removed Work – Möjlighet att se hur mycket arbete som läggs till eller tas bort under sprintens gång. Just nu ser vi bara hur totalen växer och minskar. Om en task tas bort och en annan läggs till syns ingen skillnad i grafen.

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

Super Sprint Demo – Alla team samtidigt!

fredag, 23 april, 2010

Tydligen jobbar aftonbladets IT avdelning enligt Scrum. Inte bara så har de en stor öppen demo för alla intresserade på företaget, de publicerar också en summering av demon på blogg.aftonblandet.se/dev för alla andra nyfikna långt utanför projektets väggar. Texten ger en kort men rolig insyn i deras arbete, specifikt deras nya upplägg kring sprint-demos.

Jag har varit med om att flera team schemalagt sina demos spridda över en och samma dag för att man ska kunna delta på alla som intresserar en.

Jag gillar dock detta grepp ännu bättre, dvs. Aftonbladets 6 Scrum team organiserar ihop sig för en gemensam demo varannan vecka (dvs. deras sprintar är två veckor långa). På detta sätt blir det en naturlig företags-happening som drar uppmärksamhet till sig och förhoppningsvis skapar engagemang och intresse. Gissningsvis växer också engagemanget och motiveringen att nå sprint-målen i varje team då demons publik är mycket större.

Dock undrar jag hur de gör med dialogen och feedbacken… Måste bli smått ineffektivt att samla in synpunkter, idéer och feedback från en så stor publik (som bilden skvallrar om) i slutet av demon. Jag misstänker kanske att blogg-inlägget missar att beskriva detta (eller så är det så att varje team bygger efter egen drivkraft och kanske inte är speciellt beroende av återkoppling från kund eller stakeholders).

Hur som, jag hoppas jag snart får möjlighet att beskåda något liknande med egna ögon och vara med och uppleva vad en dylik förändring innebär för motivation, fokus och kommunikation mellan IT, verksamhet och beställare.

Finns det andra därute som har erfarenhet av motsvarande upplägg, dvs. stor gemensam team-överskridande sprint demo?

.

Läs hela artikeln på Aftonbladets ”Utvecklingsbloggen”.
(Bilden är hämtad ifrån utvecklingsbloggens flickr
album)

h1

Råd till den girige produktägaren

måndag, 19 april, 2010

Dras dit team med en person som fått rollen som produktägare och som envisas med att sätta ”Måste”-prioritering på allt? Eller hör du kanske själv till skaran beställare som blir frustrerad när teamet ber dig prioritera ”User Stories” och som inte förstår dig när du försöker förklara för dem att ”alla dom här funktionerna är oerhört viktiga”?

Det är bra att du i rollen som Product Owner har en klar och tydligt bild av vad systemet minimalt måste bestå av för att det ska vara driftbart eller säljbart. Det är en viktig funktion. Men det är ännu viktigare att löpande omvärdera och ompröva omfattning och release planeringen för att kontinuerligt säkerställa att teamet just nu, i den aktuella sprinten, jobbar på det som ger dig mest värde för pengarna. Och att teamet gör det varje sprint.

Och stämmer det verkligen att systemet måste innehålla precis allt för att över huvud taget vara användbart? Troligtvis inte.

Så, här följer nu…

.

8 Råd till den Girige Produktägaren:

Jag har prioriterat råden efter den ordning jag tycker man ska följa dem  😉 Vidare, när jag skriver ”Story” i texten nedan syftar jag till User Story/Feature/Funktion.

  1. Visa förtroende för teamet
  2. Välj leveransordning
  3. ”Beställ” det som är av mest värde först
  4. Inspirera teamet
  5. Överbelasta inte teamet
  6. Ge teamet bra förutsättningar
  7. Finns till hands
  8. Ha tålamod

.

1. Visa förtroende för teamet

Lita på att teamet gör sitt yttersta för att lyckas – varje sprint. Visa att du har förtroende för att de har den kompetens som behövs och visa tillit till att de sköter sitt jobb.

Försäkra dig om att teamets Scrum Master gör ett bra jobb vad gäller att skydda teamet från yttre störmoment så att teamet ostört kan fokusera på att leverera de funktioner de lovat.

(Blir du motbevisad och det visar sig någon i teamet grovt missköter sitt jobb är detta något som såklart behöver adresseras, kanske t.o.m. i projektets styrgrupp.)

.

2. Prioritera efter leveransordning

Teamet hinner bara bygga och leverera ett begränsat antal färdiga funktioner/features per sprint. Att designa, utveckla och testa av funktioner och features tar tid.  Hur mycket du som produktägaren än vill så kan inte teamet leverera hela produktbackloggen på en sprint. Att sätta Måste-prio på allt hjälper vare sig teamet eller dig. Det skapar snarare enbart frustration.

Om du istället betraktar prioriteringen som leveransordning (i motsats till hur viktig eller oviktig Storyn är) så borde uppgiften bli enklare. Vilken funktionen vill du helst se ska visas upp på nästa sprint demo?  Låt sedan teamet plocka så många de förmår ifrån ”leverans-kön” när de planerar sin nästa sprint.

Ser du till att göra ”leveransobjektet” (dvs. User Storyn) lagom liten och tydligt avgränsad, och dessutom enbart innehåller det du är säker på att du vill ha, då minimeras risken att teamet bygger något som senare behöver göras om eller förkastas.

.

3. ”Beställ” det som är av mest värde först

Prioritera först och främst efter affärsvärde och verksamhetsnytta. Vilken funktion uppfyller affärsmålen bäst? Vilken features skulle glädja flest användare mest?

Ibland kan dock andra faktorer spela in din prioritering:

  • Risk – Bakom en viss funktion kanske höga tekniska risker och svårigheter döljer sig. Då kan det vara en god idé att undanröja eller bekräfta dessa risker tidigt.
  • Osäkerhet – Misstänker du att du som Product Owner kommer ha mycket åsikter och feedback kring något, se till att den Storyn levereras tidigt så att det finns tid innan release att prioritera med eventuella ändringsförslag och justeringar.
  • Beroenden – Det kan vara så att teamet upplyser dig om tekniska beroenden Storys emellan, dvs. det är kanske omöjligt att först (eller åtminstone mycket dyrare)att utveckla X om inte Y är utvecklat först.

.

4. Inspirera teamet

För att teamet ska bygga så ”rätt” som möjligt är det såklart bra om de förstår varför du vill att en funktion ska bete sig på ett speciellt sätt eller varför just den featuren är viktig för användare. Bjud in teamet att vara delaktig i den större visionen.

Om teamet förstår nyttan, och känner att det de utvecklar faktiskt kommer att glädja användarna, stiger såklart motivationen och engagemanget.

.

5.   Överbelasta inte teamet

Stressa inte teamet till att lova för mycket under en sprint. Låt inte teamet heller lura sig själva till överoptimistiska löften. Om teamet till exempel helt plötsligt och omotiverat ändrar sina estimat till mer optimistiska värden under sprint planeringen bör du vara vaksam.

Det sista du vill är att teamet tvingas (eller själva väljer) att ta genvägar och fuska med design, test och kvalitet för att hinna leverera allt det de åtagit sig. Halvfärdiga, slafsiga och otestade funktioner innebär bara framtida kostnader i form av dyrare underhåll och högre teknisk skuld. Ju högre teknisk skuld, desto mindre kommer teamet klara av per sprint framöver.

Väldigt kontraproduktivt med andra ord.

.

6. Ge teamet bra förutsättningar

För att teamet ska kunna ge så bra sprint mål som möjligt och för att teamet ska kunna vara så effektiva som möjligt under sprinten behöver de såklart bra förutsättningar för detta.

  • Innan sprint planeringen, se till att produktbackloggen är uppdaterad och prioriterad.
  • Försäkra dig om att dina högst prioriterade storys är detaljerade (dvs. tillräckligt detaljerade för att teamet träffsäkert ska kunna estimera och bryta ner i sub-tasks)
  • Bjud in teamet till Story Time Session några dagar innan sprint planeringen. Här presenteras och diskuteras nyheter i produktbackloggen, teamet ställer frågor och uppdaterar eventuellt estimeringar. (Behövs finns nu tid innan sprint planeringen för dig att kolla upp detaljer och för teamet att undersöka tekniska frågetecken.)

.

7. Finns till hands

Se till att du är tillgänglig för teamet så att de snabbt kan få tag i dig för att ställa frågor om detaljer eller behöver din feedback. Jag gissar att du inte vill att teamet sitter och rullarna tummarna istället för att bygga funktioner åt dig…

Försök närvara på teamets dagliga möten för att fånga upp eventuell bekymmer som du kan hjälpa till med. Se dock till att inte störa teamet! Antingen håller dig tyst i bakgrunden under Daily Scrum och ställ dina frågor till Scrum Mastern efteråt, eller så ställer du dig i ledet som vilken teammedlem som helst och svarar på de tre frågorna när det är din tur.

När teamet väl har demonstrerat så utöva din makt att utvärdera, prioritera om och kanske till och med ändra release planen för projektet.

.

8. Ha tålamod (en liten stund)

Självklart ska du ställa höga krav och förvänta dig att teamet presterar sitt bästa, men när teamet väl har börjat sin sprint och ni har skakat hand på sprintens mål, ge dem arbetsro och möjlighet att fokusera på sitt arbete. Riv inte upp deras planer genom att förändra sprintens målsättningar eller introducera helt nya krav. Var delaktig i arbetet men sabotera inte teamets möjligheter att lyckas.

Om du ofta finner dig i en situation där du avbryter teamet och ber dem jobba på något annat som blivit viktigare (och som inte kan vänta till nästa sprint) kanske det är dags att diskutera kortare sprintar? Eller också kanske Scrum Master ska läxas upp eftersom han uppenbart misslyckas skydda teamet från yttre störmoment 😉

.

Varför följa ovanstående råd?

För varje råd du följer ovan desto bättre förutsättningar och möjligheter får teamet att lyckas med sin leverans under pågående sprint. Det de bygger blir rätt, behöver inte göras om och håller hög kvalitet. Du ger dem också möjlighet att hålla samma (och förutsägbara) tempo, effektivitet och kvalitet varje sprint.

Det är väl precis det du vill? Få ut så mycket av värde som möjligt från teamet.

Varje sprint.

h1

Projektledningsaspekter i Scrum?

torsdag, 15 april, 2010

När jag är ute och föreläser om Scrum för en publik som är nyfiken på agila utvecklingsmetoder så är det oftast projektledare och arkitekter som skruvar på sig mest och ställer flest frågor.

Speciellt projektledare verkar ha svårt att se hur sin egen yrkesroll passar in i Scrum. Uppgifter och ansvar som typiskt åligger en ”klassisk” projektledare förekommer naturligtvis i Scrum också, fast i annan skepnad och ansvaret distribueras mellan flera olika personer. Jag ska därför försöka mig på att presentera en översikt över hur de olika ansvarsområden som en projektledare har i ett vattenfallsprojekt hanteras i ett Scrum projekt.

.

Projektledningsaspekter i Scrum

(eller ”Vem ansvarar för vad?”)

.

Varför? Hur ser visionen ut?
Varför bygger vi detta system?
Product Owner
(och kund)
Vad? Vilka features är användbara och värdefulla för kund och användare?
När? Vilka features har mest värde för kund och användare? (Dvs. i vilken ordning ska vi bygga och leverera för att maximera Return of Investment och minimera Time To Market?)
. . .
Kostnad? Hur jobbigt är det att bygga en viss funktion?
Hur lång tid tar det?

Vilka kunskaper behövs?

Scrum Team


Hur? Hur ska funktionen byggas (från ett tekniskt perspektiv)?

Vilken arkitektur och design är bäst?

. . A
Hur? Efter vilka spelregler (process) jobbar vi?

Hur förbättrar vi processen och våra metoder?

Vem ansvarar för att teamet får förutsättningar och möjlighet att utföra ett bra jobb?

Scrum Master


. . .
Problem? Lyfta frågor rörande…

  • Resurser och behov
  • Förändringar i Release planer (omfattning eller tid)
  • Tekniska beroenden mot andra team

…till Meta-Scrum (Styrgrupp) eller till Scrum-of-Scrums?

Alla

h1

OpenAgile – Scrum för icke-IT

måndag, 12 april, 2010

Sprang nyligen på OpenAgile när jag klickade mig fram igenom bloggartiklar om Scrum och Agila utvecklingsmetoder. Att det fångade mitt intresse tror jag beror på att OpenAgile är en agil utvecklingsprocess anpassad och designad för att vara tillämpar på ett bredare spektra än enbart mjukvaruutveckling.

Jag har tidigare jobbat som projektledare i stora ideella projekt där man inte har lyxen att kunna säga ”Gör ditt jobb annars får du ingen lön!” utan allt handlade om frivilligt engagemang, motivation, ansvarskänslaoch att det skulle vara roligt att jobba. OpenAgile hade nog fungerat riktigt bra där.

Vidare så är det svårt att tillämpa Scrum utanför mjukvaruutvecklingsprojekt. Man kanske inte har resurser på heltid i ett team, det är kanske omöjligt att hålla korta sprintar i verksamhetsprojekt, involverade personer variera kraftigt eller förändras mycket med tiden, för att nämna några exempel. OpenAgile försöker lösa även dessa bekymmer.

Jag tror nog att OpenAgile kan fungera bra för vissa organisatoner som har en lös struktur eller för projekt som inte har strikta deadlines i tiden. Den har några intressanta vinklingar (beskriver t.ex. fler roller än Scrum även om bara en av dem är obligatorisk), den är betydligt lättviktigare än Scrum, fokuserar hårt på teamet och teamanda, tillåter avbrott i arbetet.

Det som jag finner mest spännande och roligast är dock kanske att detta är just en variant av Scrum som (förhoppningsvis) fungerar fint i alla sammanhang och miljöer. 🙂

.

OpenAgile in a nutshell

OpenAgile är en Agil utvecklingsprocess som fokuserar på att leverera värde. Till skillnad från Scrum som ägs av Scrum Alliance så är OpenAgile open source och under utveckling (av naturliga skäl eftersom det är open source men jag tror det också beror på att det väldigt nytt också).

I korthet så fungerar det så här: Teamet (det finns bara en obligatorisk roll, nämligen team-medlemmen) jobbar i cykler (iteration). Under en cykel träffas man minst fyra gånger för ett Progress Meeting för att diskutera hur det går, vad man lärt sig och vilka tasks man ska göra härnäst, dvs. under nästa Work Period (som kan vara allt ifrån några timmar till flera veckor). Alla väljer på frivillig basis vilka och hur många tasks.

En cykel inleds med tre möten:

  • Reflection (Vad hände förra cykeln? Vilka blev resultaten?),
  • Learning (Vad lärde vi oss? Vilka nya principer har vi identifierat? Vilka nya färdigheter har vi utvecklat?) oc
  • Planning (Vad ska vi göra denna cykel? Vilka tasks krävs för att leverera uppsatta mål?).

OpenAgile säger inget om hur korta (eller långa) cykler ska vara, bara att man ska ha några stycken innan slutmålet är nått.

OpenAgile lutar sig på tre grundvärderingar:

  • Ärlighet (dvs. ljug inte, fuska inte, lär från dina misstag),
  • Rådgivande beslutsprocess (dvs. alla ska delta och bidra i beslutfattandet och vara eniga om beslutet) och
  • Läro-cykeln (smått förenklat: 1) Reflect, 2) Learning, 3) Planning och 4) ActionI denna process ska vi vara objektiva, kunskapssökande, tycka om det vi gör och vara modiga).

Det verkar som om OpenAgile visat sig vara extra populär just i idéella projekt som inte har med IT att göra. För lite bättre, korrektare och längre förklaringar av OpenAgile kika gärna på länkarna under illustrationerna.

.


.

Jämförelse av OpenAgile och Scrum:
http://www.agileadvice.com/2010/02/01/uncategorized/comparison-of-openagile-with-scrum/

En wiki för OpenAgile (under utveckling)
http://wiki.openagile.org

Enkel summerande presentation på 22 slides
http://www.slideshare.net/mberteig/introduction-to-the-openagile-learning-system

En sida med presentationer, use-case studies, m.m.
http://www.openagile.com/

OpenAgile Primer (PDF, 1.22MB)
http://www.openagile.com/sites/default/files/OpenAgile Primer.pdf

h1

Genvägarna till det hyperproduktiva teamet

onsdag, 7 april, 2010

Det hyperproduktiva teamet är ett uttryck som ofta florerar i Scrum litteratur och i diverse bloggar och som syftar på teamet som har nått en nivå av ansvarstagande, hängivelse, produktivitet och samarbete som låter dem vara långt mer effektiva i sin leverans av kvalitativa och värdehöjande funktioner och features än ”normalt” – hyperproduktivitet. Här och nu avslöjar jag genvägarna dit!

.

*trumvirvel och en konstpaus*

.

Dom genvägarna finns såklart inte. Tyvärr. Förlåt om jag i ingressen ingöt falska förhoppningar. Det innebär såklart hårt arbete, mycket träning och ibland en stor dos tålamod. Men – jag tror å andra sidan följande punkter är förutsättningar för att över huvud taget nå en högre nivå av produktivitet inom ett team:

  • Följ och efterlev agiles värderingar och de agila principerna. Kör projektet Scrum – kör Scrum fullt ut! Varje moment och regel finns där av ett skäl. Bemästra processen och verktygen.
  • Stakeholders och produktägaren måste visa (och bevisa) för teamet att teamet har  mandat att organisera och styra sig själva och att de (stekeholders och produktägaren) har förtroende och tillit till teamet.
  • Praktisera ”Inspect Adapt Improve”. Ta Sprint Retrospectives på allvar. Säkra stöd hos styrgrupp och organisation att genomdriva nödvändiga förändringar.

Jag är övertygad om att ifall teamet upplever stöd och tillit från ledare och ledning och ges tid att organisera sig själva så kommer dom nå ett tillstånd av hyperproduktivitet.

.

Om du fick samla nio valfria polare, skulle ni också kunna bygga ett hus på en helg?

.

Om du ändå gärna vill tro på att det verkligen existerar enkla genvägar till hyperproduktivitet föreslår jag följande länkar:

Self-Organization in Scrum
Powerpoint från Jeff Sutherland,
http://jeffsutherland.com/SelfOrganizationGoogle5Sep2008.pdf

The Secret Sauce for Improving your Scrum team
Google techtalk från februari 2009. Talare Jeff Sutherland.
http://www.youtube.com/watch?v=M1q6b9JI2Wc

Shock Therapy:  A Bootstrap for Hyper-Productive Scrum
Artikel på rapidscrum.com,
http://www.rapidscrum.com/Shock_Therapy.html

h1

”Hur rolig var sprinten?”

tisdag, 6 april, 2010

Idag brände vi av en radda produktiva och roliga team-workshoppar. Först ut på morgonen var en nästan 3,5 timme lång retrospective. Kändes förlösande att konstruktivt och kritiskt granska oss själva, vårt samarbete, vår dialog med (och beroende gentemot) organisationen och styrgruppen.

.

1. Etablerade agenda

Först etablerades dagens syfte och agendan med tidshållpunkter presenterades. Detta dels för att time-boxa passen men också för att skapa en helhetsbild att hänga upp arbetet på.

Tog 2 minuter.

.

2. Tog teamets temp

Det första jag gjorde var att be teamet snabbt och individuellt svara på en rad frågor.

1) Hur rolig var sprinten?

2) Hur nöjd är du med
din egen insats/prestation?

3) Hur nöjd är du med teamets
insats/prestation?

4) Hur bra var teamets förutsättningar
efter avklarad Sprint Planering?

5) Hur hög arbetsro rådde under sprinten?

Skalan gick från 9 (superbra) till 1 (värdelöst). Dessa temp-frågor kommer upprepas varje retrospective. Svaren kommer sparas och trackas (genomsnittliga värdet) över tiden och kan sedan analyseras och diskuteras (t.ex. jämföras mot velocity, drag, etc.)

(Nästa gång kommer vi skriva ner våra poäng först i hemlighet var för sig innan vi sätter upp prickarna. Detta för att minimera risken att påverkas av redan uppsatta prickar. )

När alla hade besvarat frågorna med sina prickar gjorde vi en super kort reflektion men stannade inte upp för djupare analys utan gick raskt vidare till nästa punkt. Syftet med övningen är endast att snabbt få igång tankeverksamheten, minnas tillbaka till den gångna sprinten och få upp energin i rummet.

Totalt tog detta cirka 10 minuter.

.

3. Brainstorming

Efter att vi tagit temperaturen på teamet gick vi snabbt vidare till ”Brainstormning”. Alla tilldelades små post-its på vilka man skulle skriva ner sina reflektioner, åsikter, tankar m.m. och sätta upp dem på väggen. Detta gjordes utan struktur och med högt till tak. Inga åsikter eller känslor är för dumma för att inte tas upp och synliggöras. Närhelst man skrivit en lapp sattes den upp och teamet diskuterade punkten tills alla förstått vad författaren ville säga eller ge uttryck för.

Detta är teamets tillfälle för självreflektion, självgranskning, förlösning, diskussion, tänka högt, dela med sig av gjädje och frustration, fånga upp idéer och förslag på förbättringar.

Om dynamiken i gruppen är sådan att vissa talar högt, mycket och gärna medans andra är tysta och blyga behöver denna del av retrospectiven en struktur och utformning för att alla ska få komma till tals och känna sig delaktiga.

Andreas klurar på sin egen nyss uppsatta lapp

Lapparna sorterades in i följande kategorier:

Roligt! Bra!
Saker som blev lyckade och som teamet ska fortsätta med. Något som var speciellt roligt eller gick speciellt smidigt? Roliga händelser. Bra – men vi kan ännu bättre!
.

Dåligt! Frustrerande! Tråkigt.
Saker som inte gick som planerat. Olyckliga omständigheter. Frustration! Rutiner eller processer som inte funkar som de ska. Saboterande omständigheter.
.

En blomma till…
Speciella tack till speciella insatser. Tack för hjälpen! Beröm. Klapp på axeln.
.
.

Funderingar. Frågetecken.
”Varför …?”, ”Jag önskar jag visste hur … ?”, ”Hur kan vi … ?”, ”Hur lyckas vi … ?”, ”Hur kommer det sig att … ?”
.
.

Ideér. Förslag.
Förslag på förbättringar, saker som kan göras annorlunda. Idéer på hur teamet kan samarbeta bättre, kommunicera bättre, minimera waste, förebygga teknisk skuld, första kund och krav bättre.
.

Denna övning tog nästan ca 90 minuter innan vi kände att vi tömt ut allt vi ville få sagt och tyckt till om det vi ville tycka till om.

OBS! Under denna övning har Scrum Mastern ett stort ansvar. Ingen kritik. Allt ska upp. Scrum Mastern får inte  bete sig defensivt eller sabotera viljan att tala och tänka fritt och högt. Scrum Mastern får inte ta bort eller formulera om lappar. Det skulle hämma möjligheten att nå insikter och få fram allas tankar och synpunkter.

.

4. Summera actions

Efter en fem minuters paus samlade vi våra tankar och gick tillbaka in i vårt war room. Nu var det dags att summera, finna bakomliggande orsaker till frustationer, konkretisera förändringsförslag och idéer.

Alla lapparna gicks igenom, var för sig. Kunde vi komma på en action till lappen satte vi upp den i ”!” rutan. Ibland fick vi klura en stund, kanske backa för att se den större bilden och diskutera en stund innan vi kunde enas om vad lämpligast och effektivast action var. Men vi tog oss igenom alla lapparna och var efteråt oerhört tillfreds med oss själva, vår analys och vår lista över actions.

När vi var färdiga med actions grupperade vi dem. Grupperna denna gång råkade bli ”Sprint Planering”, ”Dagligen”, ”Arbetsro och Övrig-prio”, ”Attidyd/Mentalitet” och ”Externt”. Kanske inte säger dig något men för oss är betydelsen solklar 😉

Detta tog cirka 60 minuter.

Denna övning kan med fördel timeboxas. Gäller såklart övriga övningar beskrivna här också. Det är enkelt att skena iväg och förlora sig i detaljer.

Listan över actions som kräver en arbetsinsats bör inte vara för lång så att den blir en belastning i sig under sprinten. Likaså kan man inte hoppas på att förändra allt man vill på en gång. Ett steg i taget leder troligtvis till beständigare förändringar. Behövs det hjälper Scrum Mastern teamet prioritera det som känns viktigast och ger störst impact.

.

5. Summering för styrgrupp

Denna gång kände vi att det var viktigt att få framföra våra idéer och förslag till styrgruppen samt dela med oss av det vi upplevde var frustrerande för att få ökad förståelse för våra förändringsförslag. Vi presenterade alla actions, svarade på frågor, diskuterade. Mycket givande! Ytterligare några actions kom upp på väggen.

Vi hade mycket att prata om och fick många frågor om våra lappar så innan denna sista övning var över hade ytterligare cirka 60 minuter förflutit.

.

6. Reflektera

Sist reflekterade vi som hastigast över förmiddagens arbete, vad som var bra/dåligt med upplägget och vad vi tyckte om vår prestation och vår gemensamma prestation. Tror det syns på bilden nedan att vi var ganska belåtna 🙂

Nu återstår bara att se hur väl vi lyckas med att genomföra våra actions och följa våra egna förmaningar till oss själva.

Teamet (från vänster): Jag, Andreas, Henrik och Peter

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.