Posts Tagged ‘product_owner’

h1

Q: Om Chief Product Owner, Managers och Kravägare?

fredag, 24 februari, 2012

Många företag och organisationer kämpar med att få till en bra dialog kring prioriteringar och kravdetaljer med beställare och verksamhet.

I större organisationer som inte i mål med att forma om sig för att stötta agila projekten i sina leveranser blir ofta just produktägaren (och verksamhets- experter) en flaskhals.

För några dagar sedan fick jag detta mail:

.


Hej Jimmy!

Tack för en bra blogg. Såg att du gärna mottog frågor om Scrum så tänkte maila om det jag funderar på.

Vår nuvarande Product Owner har inte varit närvarande och han har haft massa sidouppgifter. Tanken är nu att han ska blir Chief Product Owner med underordnade Product Owner för olka delar av vårt system då det är stort och komplext. Till detta så kommer det även för stories att finnas kravägare som man får för sig att varje team ska vända sig till med frågor. Mina funderingar om detta:

1. Om vi har en huvud produktägare, visst borde denna kallas Chief Product Owner istället för Product Manager?

2. De under ordnade produktägarna bord väl kallas Product Owner of Function A och inte Functional managers vilket ger associationer till något helt annat?

3. Ska verkligen kravägare vara den som teamet pratar med? Bör det inte vara produkägarna som teamet kommunicerar med i det? För som jag förstått det så ska produkägaren/ägarna har väldigt god koll på alla stories?

Mvh #####



Hej #####,

Roligt att du tycker om bloggen! Och tack också för din fråga. 

Såhär tänker jag…

1. Om vi har en huvud produktägare, visst borde denna kallas Chief Product Owner istället för Product Manager?

Jag håller med om att Chief Product Owner är ett lämpligare namn. Det är vedertaget och har en betydelse inom den agila litteraturen och inom Scrum-metodiken. Viktigare än namnet är dock såklart rollens syfte och förväntad roll i projektet.

.

2. De under ordnade produktägarna bord väl kallas Product Owner of Function A och inte Functional managers vilket ger associationer till något helt annat?

Personligen gillar jag beteckningen ”Area Product Owner <Functional Area>” fast ”Product Owner of Function A” tror jag säkert fungerar lika bra. Dock blir jag lite fundersam över begreppet ”Function” här. Det låter som om risken finns att det blir ett för smalt område, men å andra sidan har jag ju ingen insikt i ert system.

Men jag håller med om att ”manager” ger helt fel associationer. Att vara produktägare handlar inte om ”management”, det handlar om att representera kunden och förmedla en vision, roadmap och kunskap kring features och funktioner till teamet. Produktägaren är en del av teamet, inte en av teamets managers.

Vidare, om man har en hierarki med produktägare (vilket man bör ha när man skalar upp Scrum till flera team) så är det viktigt att definiera och farankra vilket mandat produktägarna har över sin egen produktbacklogg. På sätt och vis utgör produktägarna ett virtuellt team vars förmåga och vilja att samarbeta kring roadmaps och prioriteringar är centralt. Varje team ska inkludera en produktägare som bistår teamet i diskussioner kring vision, roadmaps och prioriteringar – på daglig basis, aktivt och proaktivt. Vidare ska varje team ha sin egen produktbacklogg. Om flera team delar samma produktbacklogg anser jag att man hamnar man i flera trassliga situationer.

I detta virtuella ”Product Owner Team” är det viktigt att diskutera och enas kring vilket mandat Chief Product Owner förväntas besitta? Vilket mandat och ansvar blir över till Area Product Owner?

.

3. Ska verkligen kravägare vara den som teamet pratar med? Bör det inte vara produkägarna som teamet kommunicerar med i det?

Jag kan ju bara gissa vad ”kravägare” betyder hos er.

Alt 1. Kravägaren är personen som beställt en viss funktion av produktägaren (alt. produktägarteamet). Personen har ingen detaljerad åsikt kring exakt hur funktionen ska implementeras men är väldigt mån om att få funktionen levererad.

Alt 2. Kravägaren har på uppdrag av produktägaren ett ansvar att konkretisera funktionen och har mandat att utforma detaljerna i kravet.

Alt 3. ?

Oavsett vad – om det finns någon utanför teamet som har speciell verksamhetsexpertis eller kunskap om vad användarna vill ha som inte produktägaren besitter ska denna person vara en del av teamet, åtminstone under den period man jobbar med det kravet.

Han eller hon ska stötta produktägaren i att konkretisera kravet till PBI:er (Product Backlog Items/User Stories), splittra upp det i flera beståndsdelar och sedan förklara affärsvärdet för var och en av de mindre delarna så att produktägaren kan göra en bra prioritering av produktbackloggen.

Vidare, när det är dags att förvandla kravet till värdefull fungerande mjukvara ska personen göras till en teammedlem som på deltar på det dagliga mötet, designworkshoppar och diskussioner samt kan vara med och diskutera de sista detaljerna med testare och utvecklare när kravet faktiskt överstätts till fungerande kod. Teamet (med eller utan ”kravställare”) har inte mandat att utöka/minska omfattningen av funktionen utan att rådgöra med produktägaren – teamets uppgift är att förvandla tydligt definierade och avgränsade krav (User Stories) till fungerande värdefull mjukvara efter produktägarens prioriteringar.

Har inte produktägaren tid till detta (dvs formedla kunskap eller ha åsikt kring kravdetaljerna), eller inte sitter inne med den verksamhetsexpertis eller kundkunskap som behövs, ja då ska teamet utökas med en person som faktiskt har det. Återigen, titeln är inte det viktiga – fokusera på syftet och samarbetsformen.

.

Jag hoppas dessa kommentarer och reflektioner ger dig något av värde och kan hjälpa er i ert arbete och diskussioner.

Jag kan också rekommendera en bra bok som bland annat adresserar dessa frågeställningar och utmaningarna när man skalar upp till flera Scrum team som tillsammans bygger en produkt/ett system.

Den heter ”Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum” och är skriven av Craig Larman och Bas Vodde.

Annonser
h1

Om att mäta det agila projektets framgång (2/6) – Resultat

tisdag, 15 juni, 2010

Hur vet man att investeringen i utvecklingen matchar förväntningarna? Hur håller man koll på att projektet levererar ”i tid”? Hur mäter vi att mottagarna och beställarna är nöjda? Scrum påstår sig leverera mera funktionalitet av högre kvalitet som bättre matchar förväntningar och behov. Men hur mäter man och följer upp detta? Detta är andra delen av min artikelserie om tips, trix och verktyg för att mäta det agila projekts framgång och status.

Nedan listar jag några verktyg och mätvärden användbara för projektets produktägare och styrgrupp (Meta-Scrum) för bland annat release- och resursplanering. Men som alltid ska man ställa sig frågan varför man mäter något? Vad ska statistiken användas till? För vem är mätvärdet värdefullt? Historisk statistik på ett mätvärde i sig har inget värde, det är först när vi omsätter det till kunskap, insikt och handling som det ger oss något tillbaka. Fram tills dess är insamlandet och sammanställandet waste och kanske t.o.m. kontraproduktivt. Vi riskerar att belysa fel saker och kanske luras försöka bota symptom istället för det bakomliggandet problemet.

.

Release Plan vs. Effektmål

Vilka effektmål/affärsmål har vi satt upp med nästa Release? Vilka verksamhetsproblem hoppas vi lösa? Kommer nästa Release nå dessa mål? Ser prognostiserad tidplan ut att hålla?

Med en Release Burndown kan man enkelt prognostisera när scoopet för releasen är klar. Release Burndownen är också ett enkelt verktyg för att anpassa release-scoopet för att nå önskat release datum. Finns tydliga mätbara effektmål kan Produktägaren också avgöra om tillräckligt många av dessa blir uppfyllda.

Release Burndownen ger en tidig indikation på hur projektet går. Produktägare och styrgrupp kan avgöra om release-scoopet ska justeras, deadline flyttas fram eller om teamet behöver förstärkas med ytterligare resurser.

.

ROI kontra Kostnad

Får vi valuta för pengarna? Är förväntad Return Of Investment (ROI) högre än sprintens kostnad? När ROI/Sprint sjunker under en viss gräns är det kanske dags att vara nöjd och avrunda projektet… eller se över Produktbackloggen, dvs. ta ett kreativt omtag och  klura ut nya funktioner som kan skapa högre affärsvärde än de som ligger i produktbackloggen just nu.

Att leverera enligt Scrum ger oss möjlighet att kontinuerligt försäkra oss om att teamet jobbar på just de saker som ger mest affärsvärde. Men det är inte bara en möjlighet utan även produktägarens skyldighet att se till att just så är fallet.

Utöver själva sprintens kostnad växer förvaltnings- och driftkostnader desto större och komplexare systemet blir. Denna aspekt återspeglas inte i illustrationen intill men bör finnas med som beslutsunderlag vid releaseplanering.

.

Rest/Släp

Hög rest-ratio (dvs. ration rest-tasks från föregående sprint/sprintar kontra ny funktionalitet) kan signalera många olika saker men framförallt en oförmåga att avsluta features och efter sprint demo ha en produkt som är ”klar”, dvs. redo för paketering och leverans. Ju fler features som är  ”work in progress” mellan sprintar desto mindre flexibilitet får produktägaren i sitt arbete med att prioritera produktbackloggen och desto mindre frihet över release-planeringen och större osäkerhet kring release-prognoser.

Vidare, om det alltid följer med rester från tidigare sprintar in i nästa sprint finns det en risk att man missa eventuella underliggande tekniska problem eller andra typer av hinder som gör att teamet har svårt att avsluta features. Inte nog med att produktägaren får allt mindre ”nytt” levererat per sprint, projektets sanna status blir allt svårare att utläsa.

.

Driftsättnings-/Packeteringsinsats

Hur stor är den faktiska insatsen att driftsätta (alt. paketera produkten) efter nästa Sprint Demo? Har projektet skjutit upp tasks rörande överlämning till förvaltning, dokumentation, acceptanstest, installationsscript, etc. betyder det inte att man är redo för leverans bara för att Release Burndownen närmar sig noll.

Så länge Scrum-projektet inte levererar en potentiellt installerbar/levererbar ny version av systemet/produkten varje sprint förlorar man den kontroll och flexibilitet som Scrum utlovar.

Skjuts vissa saker upp tills det ”är dags” måste detta förankras med produktägaren (och eventuellt styrgruppen) eftersom Release Burndownen inte längre berättar hela historien. (Alternativt lyfts dessa arbetsuppgifter in i produktbackloggen och görs till en del av releasen.)
.

Risk Burndown

Agila utvecklingsmetoder hanterar risk på daglig basis naturligt genom korta feedback-cykler, dagliga möten, öppen insyn i teamets progress, ärlighet, tät dialog osv. Trots detta kan det vara en god idé att synliggöra de risker som finns och hur de förändras och hanteras under projektets gång. När projektet närmar sig release ska självklart denna risk helst nått noll.

Läs mer om Risk Burndown Chart i ett tidigare inlägg.

.

Project Success Sliders

Project Success Sliders är ett enkelt men kraftfullt sätt för stakeholders och produktägaren att förmedla sina förväntningar till teamet. I projektets inledande fas defineras ett antal ”sliders” som var och en ger uttryck för hur projektets framgång kommer betygsättas och bedömas.

Hur bra (eller dåligt) stakeholders och produktägare upplever att projektet går i jämförelse med uppsatta ”kriterier” bör följas upp löpande så att projektet så ofta som möjligt får en chans till feedback och möjlighet att agera och reagera om så krävs.

.

Project Success Sliders beskrevs först av Rob Thomsett i sin bok ”Radical Project Managment”. Nyligen släppte Mountain Goat Software ett snyggt och enkelt webb-verktyg för att skapa och ställa in project sliders – ”Project Success Calculator”.

.

Detta är del 2 av 6. Läs vidare:

Om att mäta det agila projektets framgång (1/6) – Introduktion

Om att mäta det agila projektets framgång (2/6) – Resultat

Om att mäta det agila projektets framgång (3/6) – Produktivitet

Om att mäta det agila projektets framgång (4/6) – Kvalitet

Om att mäta det agila projektets framgång (5/6) – Teamets nivå

Om att mäta det agila projektets framgång (6/6) – Agera på kunskap

(Länkarna uppdateras allteftersom artiklarna publiseras.)

h1

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).

h1

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?

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

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