scrum | Jimmy Janlén "Den Scrummande Konsulten"

Posts Tagged ‘scrum’

Den dysfunktionella produktägaren

måndag, 3 maj, 2010

Det vanligaste källan till dysfunktionella Scrum projekt är problem kring och rörande Produktägaren.

Det som kan ställa till det är hur rollen defineras i organisationen och projektet samt produktägarens engagemang och kommunikation med teamet, kund och beställare.

Product Owner Anti-Patterns

På 2010 Shanghai Scrum Gathering höll Monica Yap från SolutionsIQ ett seminarie som vackert listade upp sex stycken Produktägar anti-patterns. Gillar själva uttrycket ant-pattern, på sätt och vis en vacker omskrivning för ”gör inte så här”.

Frånvarande produktägaren – Produktägaren är otillgänglig och teamet ges ingen styrning eller snabb feadback.
Kopiering – ”Jag vet inte och bryr mig inte. Vi ska ju bara bygga om den gamla versionen av X så kolla hur den beter sig.”
Skenande Backloggen – Sprintmålen ändras frekvent under sprinten.
Vag DONE definitionen – Oklart vad teamet förväntas göra och uppnå för att få demonstrera och leverera en funktion/feature.
Ingen enskild produktägare – Produktägaren har inte mandat att ta beslut själv utan alltid måste vända sig till andra i organisationen för godkännande.
Saknade stakeholders – Nyckelpersoner som Produktägaren behöver konsultera och/eller samarbeta för att föra vision till leverans och avslut saknas

Hon radar både symptom, potentiella negativa konsekvenser men också botmedel.

Common Product Owner Mistakes

Likaså tar Roman Pichler upp sex stycken vanliga bekymmer rörande produktägaren i sin nya bok ”Agile Product Management With Scrum – Creating Products That Customers Love”. Vissa snarlika, andra nya:

Den kraftlöse produktägaren – Produktägaren saknar tillräcklig mandat.
Den överbelastade produktägaren – Produktägaren hinner inte engagera sig tillräckligt för att proaktivt kunna stötta teamet.
Den splittrade produktägaren – Flera personer delar på produktägarenrollen, dvs. ingen av produktägarna har helhetsansvaret.
Den avlägsne produktägaren – Produktägaren är otillgänglig eller nfsd fdsg fgsfd gsdg kjsdfkgjsdfklgjsfdlkg
Produktägar-ersättaren – För att hantera en kraftlös, överbelastad eller avlägsen produktägare brukar ofta någon i teamet (som inte har verksamhetskompetens eller bra kundförståelse) ta på sig rollen som produktägar-vikarie.
Produktägar-kommiten – En kommite fyller rollen som produktägare och delar på produktägarens ansvar och makt (vilket gärna riskerar sluta i ”Death by Committe”).

Även Roman tar upp konsekvenser men även råd och botmedel om man ser och märker av symptomen.

Ladda hem Monicy Yaps presentation ”Product Owner Anti Patterns” Scrum Alliance hemsida här.

Beställ Roman Pichlers bok exempelvis här (Amazon).

Publicerat i Scrum metodik | Märkt bok, customer, misstag, organisation, product_owner, scrum, stakehold, stakeholders, user | Leave a Comment »

Prototype Driven Development – En utopi?

torsdag, 29 april, 2010

Denna vecka har jag fått seriösa griller i huvudet. Företaget jag höll kurs för i tisdags arbetade hårt med prototyping för att undersöka vilka koncept som fungerade och inte fungerade. Tänk om hela produktbackloggen kunde ersättas med en levande prototyp?

Fram tills i tisdags betraktade jag prototyping endast som ett verktyg för teamet och produktägaren för att flytta en funktioner och features från ”Anarchy” or ”Complex” space ner mot ”Complicated” eller ”Simple” space.

Prototypen blir närmast ett verktyg för groomingen av produkt-backloggen. När produktägare och kund sett och klickat runt i prototypen kan EPIC User Stories brytas ner, detaljeras och prioriteras (eller förkastas). När detta arbete är gjort har prototypen spelat ut sin roll. Den fungerar alltså bara som ett ”hur”, ett verktyg att förstå vad man vill ha och vad som fungerar bäst, ett steg i utvecklingsprocessen på resan mot att leverera värdefull och användbar mjukvara.

Med lite tur kan man ibland återanvända lite kod från prototypen till den ”riktiga” produkten men oftast har den spelat ut sin roll och förkastas till skräpkorgen (eller arkivet).

Men nu snurrar (för mig) många nya tankar, åtminstone kring prototyping av gränssnitt och dialoger. POC:ar för att undanröja tekniska frågetecken eller risker lämnar jag därhän för tillfället.

För, tänk om…

Vi inte alls förkastar våra olika prototyper utan prototypen föds i tidig analysfas och fortsätter sedan leva, förändras och växa genom hela projektet.
.
Prototypen är så enkel att bygga ut och laborera med att Produktägaren själv kan experimentera med att lägga till dialoger, skapa dummy-funktioner och koppla ihop systemet på olika sätt. (Kanske har produktägaren ett prototyp-team till sin hjälp eller så spenderar ordinarie team en viss tid av sin sprint för att skulptera prototypen som ett steg i det kontinuerliga analys- och designarbetet.)
.
Prototypen kan ”spelas upp” i olika skepnader. Man bygger inte en helt ny prototyp för att gestalta en annan variant av dialogen utan prototypen kan ställa in i vilket version vi vill experimentera med denna testkörning. Skepnader och flödesvarianter kan enkelt konfigureras on the fly.
.
Vissa delar av prototyp-produkten består av luddiga dialoger och grova funktioner medans andra är tydligare, mer detaljerade och närmare en implementerbar nivå.
.
Prototypen låter sig delas upp i funktioner och komponenter som teamet kan estimera.
.
Estimaten behöver inte lagras i en separat lista någon stans utan är en del av modellen och kopplas till ”prototyp-komponenter”.
.
Komponenterna kan innehålla dolda attachments som inte syns vid körning. Exempelvis word dokument, sökvägar in i wikin, osv.
.
Komponenterna kan innehålla annan meta-information som t.ex:
- Prioritet
- Att-Göra-lista med öppna frågor för produktägaren
- Vilket team som eventuellt ska bygga funktionen
- Vilken release/sprint funktionen eventuellt är planerad till
  .
Slutligen så går prototypens komponenter att skriva ut som en prioriterad lista. Denna lista kommer snarare likna ett träd med grenar som spretar iväg. Ibland lever flera varianter av samma funktion (User Story) fram tills dess att en av dem implementeras och andra förkastats.

Kommentar: När jag skriver ”komponent” ovan menar jag inte modul eller klass, jag syftar till en dialog eller en specifik funktion i användargränssnittet.

.
.

Om denna fantasi besannas har vi då helt och fullt lyckats ersätta produktbackloggen med en prototyp?

Men varför stanna där? Anta att plattformen och språket vi bygger prototypen med är samma som vi använder när vi bygger den ”riktiga” produkten och att implementera en komponent/funktion i prototypen enbart handlar om reda ut återstående detaljer, skriva koden bakom, testa av samt rensa bort döda versioner och aspekter?

Når vi hela vägen hit är vår release-branch helt enkelt en specifik konfigurering av prototypen. Känns definitivt som en utopi men kanske ett vision att arbeta mot?

Publicerat i Scrum metodik | Märkt agile_planning, collaboration, grooming, iterative_incremental, product_backlog, product_owner, prototype, scrum | 5 Comments »

Nästa Scrum User Group Sweden är 19:e maj

måndag, 26 april, 2010

Häromdagen sattes datumet för nästa Scrum User Group Sweden. Den sjätte träffen i ordningen. Denna gång är teamat ”Scrum och andra gila metoder”, gissningsvis kommer det bli mycket diskussioner kring Kanban då detta är på modet inom den agila världen just.

Är du intresserad och vill anmäla dig så se till att göra det så snart du kan då antalet platser är begränsade till 40 stycken. Träffen sker precis som vanligt i Stockholm (vilket jag tycker är lite tråkigt men jag eftersom grundarna och drivkrafterna bakom gruppen finns i Stockholm så är detta kanske bara naturligt). Agendan ser ut som den brykar, först några blixttal följt av ett Open Space. Mycket lyckat och roligt upplägg tycker jag!

Du anmäler dig och hittar mer info på google groups.
Gruppen ”Scrum User Group Sweden” hittar du här:
http://groups.google.com/group/scrum-user-group-sweden.

Publicerat i Aktiviteter | Märkt scrum, scrum_user_group_sweden, stockholm | Leave a Comment »

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)

Publicerat i Konsultliv | Märkt scaling_scrum, scrum, sprint_demo, team | Leave a Comment »

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.

Visa förtroende för teamet
Välj leveransordning
”Beställ” det som är av mest värde först
Inspirera teamet
Överbelasta inte teamet
Ge teamet bra förutsättningar
Finns till hands
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.

Publicerat i Konsultliv | Märkt product_backlog, product_owner, scrum, team | Leave a Comment »

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?	Scrum Team
.	.	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

Publicerat i Konsultliv | Märkt agile_planning, product_owner, scrum, scrum_master, team, vattenfall | Leave a Comment »

I gränslandet mellan Scrum och Vattenfall

tisdag, 13 april, 2010

Nu så har dedikerad testare vaknat till och engagerat sig i ett av projektet jag är engagerade i just nu. Arbetsmetoder börjar ta form, ansvarsgränser målas upp men det tighta schemat genomsyrar hela tiden diskussioner, taktik-snack och projektgruppsmöten.

Test Planen ska diskuteras nästa vecka men jag gissar att jag kommer ha mycket åsikter och synpunkter då den tagits fram med en stor kappsäck av vattenfallsmentalitet trots att projektets testcoach vet om att vi angriper utvecklingsfasen i projektet med Scrum. Min egen roll i projektet är Technical Lead och Scrum Master.

En annan utmaning jag tampas med på daglig basis är kommunikationen med projektledaren. Hon gör ett fantastiskt jobb att koordinera alla parter (stort integrationsprojekt) men hennes angreppssätt är att strikt rada upp allting sekvensiellt och mäta progress i %, oavsett vad det rör sig om. Allt eller inget. Antingen är det inte påbörjat, X% klart eller helt klart. Inget utrymme för förändring i målbild eller utförande. Dvs. vattenfall. Tilläggas kan att programmeringen och test tar upp ca 10 rader i hennes 120 rader långa detaljplanering. ”Do not touch my perfect plan” får vara dagens citat. (Levererades när jag försökte påpeka att planen kanske borde uppdateras med hänsyn till vår nya kunskap).

Det kommer att bli några spännande sprintar framöver för utvecklingsteamet och mig själv när vi ska försöka leva, leverera och överleva i gränslandet mellan Scrum och Vattenfall. Den uppenbara risken är såklart att eventuella förseningar och/eller problem skylls på den nya kompisen i gänget (Scrum) istället för de sanna grundorskarna (som t.ex. skulle kunna vara dåliga estimat, dåliga förustättningar eller yttre störningsmoment för att nämna några) och att den nyväckta glöden till Scrum i utvecklingsteamet släcks.

Men det är också såklart väldigt utmande och spännande att få vara med att påverka en organisation till att jobba mera agilt och att lära sig fokusera mer på det levererade affärsvärdet, eliminera arbete som är tidsslöseri samt maximera kontaktytan mellan utveckling och beställare för att bygga så bra lösningar som möjligt. Speciellt roligt är det såklart när stakeholders och teammedlemmar själva kommer med förslag som gör processen och arbetssättet mera agil.

Skulle det börja regna för mycket i vattenfalls-land är det bara göra som man brukar, ta på sig regnjackan och kavla upp ärmarna och jobba på så gott man kan tills man kommer i mål.

För eller senare så tror jag att alla företag som är intresserade av att överleva i en hårt konkurransutsatt marknad måste övergå till en lean organisation som utvecklar agilt.

Jag kommer med stor säkerhet få anledning att återkomma med fler reflektioner, kommentarer och summeringar hur det går för oss att leverera mjukvaran enligt Scrum till ett projekt som i övrigt drivs enligt vattenfall.

Fram tills dess tänker jag falla tillbaka på mantrat:
”Fake it until you make it”!

Publicerat i Konsultliv | Märkt coaching, scrum, test, vattenfall | Leave a Comment »

Min nya Impediments-wall

torsdag, 8 april, 2010

Igår fick jag krypa till korset. På retrospectiven i tisdags var det någon som sa; ”Ska inte en Scrum Master ha en synlig Impediment lista?”. Jovisst är det så…

Det blev en action. Bara att inse att det är en sak att föreläsa och dela ut uppmaningar och utmaningar och en helt annan att leva upp till vad man pratar om i vardagen. **

Nu var detta kanske inte en så allvarlig Scrum-synd, kanske mest jag som tyckte det var lite pinsamt. Med ändå. Självklart är transparans och synbarhet en grundläggande agil princip. Det ska vara enkelt för vilken stakeholder som helst att med minimal ansträngning få en direkt och ”sann” insyn i hur det går för projektet. (En Impediments lista består av hinder och frågetecken som Scrum Masters ska undanröja för teamet så att de kan jobba effektivt och oavbrutet.)

Så igår skapade jag mig utrymme på en av mina väggar och kontstruerade mig en ”Impediments wall”. Flyttade över delar av punkterna i min rullande dags-check-lista till väggen. (Gillade den skarpt eftersom den var enkel och portabel. Väggen står ju där den står.)

Inget rocket sciense direkt. Några lappar, lite svart isoleringstejp, massa post-its i olika färger och en tuschpenna samt någon minuts funderande.

Jag gissar dessutom att väggen kommer förändras med tiden och att färgerna kommer att skifta i antal och betydelse. Så här ser den ut just nu iallafall. Lapparna skiftar såklart i antal och i position tätt under dagen.

Och här är en schematisk bild av min Impediments-wall. (Bilden tog förövrigt längre tid att rita än det tog att sätta upp den faktiska väggen.) Jag hoppas bilden är självförklarande, annars får du mer än gärna skriva en kommentar och fråga.

[Dåliga] Ursäkter för att jag inte haft en Impediment-wall tidigare:

Jag tyckte om min portabla att-göra-lista (fast det var iofs bara jag som kunde se den)
Teamet sitter inte på samma kontor och besöker sällan kontorsrummet (dvs. de skulle sällan sett den ändå)
Stakeholders har inte frågat efter den (med de har å andra sidan inte vetat om vad de saknat)

Så! Nu känns det bättre 🙂

** Jag är förövrigt aldrig så nervös som när jag föreläser och representanter från kunden jag just nu jobbar för sitter i publiken. Jag är livrädd för att dom efteråt ska komma till mig och anklagande fråga; ”När du förelästa berättade du för oss att man borde göra <si> annars <så>. Jag håller med och det låter vettigt. Men varför gör du inte så?”

UPDATE: Historien fortsätter på ”Hantera och spåra riks med en Risk-Burndown”

Publicerat i Agila verktyg, Konsultliv | Märkt agil_teknik, impediments, retrospective, scrum, scrum_master, stakeholders, transparency | 3 Comments »

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

Publicerat i Scrum metodik | Märkt hyperproductive, myt, organisation, product_owner, scrum, stakeholders, team | Leave a Comment »

”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

Publicerat i Konsultliv | Märkt collaboration, retrospective, scrum, team | 6 Comments »

Jimmy Janlén "Den Scrummande Konsulten"