Jimmy Janlén "Den Scrummande Konsulten"

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.