Vad bör man kräva av ett team?

Jag har deltagit i – eller observerat – många olika diskussioner om krav, kravställning och om vad man egentligen bör kräva av team. Ibland går sådana diskussioner bra men ibland går de snett eller fastnar i något. Oavsett hur bra diskussionerna går så ser jag ändå ett mönster: De flesta diskuterar krav som om de bara skulle komma utifrån.

Dags att prova krav inifrån?

Kraven som kunder eller ‘stakeholders’ ställer på teamet, eller på produkten som teamet utvecklar, kan sägas komma utifrån. På samma sätt kan ledningens krav på en chef eller en avdelning sägas komma utifrån eller uppifrån; i alla fall inte inifrån. När det gäller krav som ställs på ett team och på det som teamet producerar så diskuteras krav rätt ofta i termer som ‘kundkrav’, ‘produktägarens önskemål’, ‘chefen vill’ och så vidare. De kan alla sägas komma utifrån.

Vad sägs om att be teamet ställa kraven?

En sak som jag har provat ganska många gånger och oftast med stor framgång är att be teamet att själva ställa krav. Då menar jag inte bara krav på den produkt som teamet utvecklar, utan om krav på teamet som sådant. Det går att uttrycka det som att mina krav på teamen då har varit att de själva ställer kraven på sig själva. Det har i stort sett alltid fungerat riktigt bra, så jag är inte orolig för att det ska gå tokigt. Om någon tänker att teamet kanske skulle ställa för låga krav bara för att de får göra det själva så skulle jag säga ”McGregors X&Y”. Läs mer om den teorin på Wikipedia. Det kan förstås vara olämpligt av andra skäl. Till exempel kanske teamet inte mår så bra som team betraktat och i så fall behöver vi hantera det först. Det kan å andra sidan vara så enkelt att teamet bara aldrig tidigare har blivit ombedda att ställa krav, så de kanske vill ha lite utbildning eller tips. Det är inget konstigt med det i så fall och det är lätt att hantera.

Förslag på teamets krav på teamet

Här är några förslag på krav som ett team kan ställa på sig själva. Förslagen är inte färdiga eller perfekta; se dem som diskussionsstartare: 

Krav 1: ”Vi ska förtydliga vår agila process så att alla andra förstår hur de ska interagera med den.” 

Krav 2: ”Vi ska förbättra kvaliteten på det vi släpper ifrån oss så att andra anser att den är hög och pålitlig.” 

Krav 3: ”Vi ska sprida kunskap i teamet snabbare och mer strukturerat för att göra oss mindre individberoende och på så vis lättare kunna dela på allt arbete.” 

Krav 4: ”Vi ska öka vår produktivitet genom att förbättra möten och effektivisera administration.”

Hur vet vi om det gick bra?

Varför inte låta teamet fundera på det också? Kanske vill de testa något i stil med det här?: 

Mätning 1: Fråga alla, kanske? 

Mätning 2: Prata med folk och ställa samma fråga med jämna mellanrum, medan vi gör olika sorters förbättringar? 

Mätning 3: Rita en tabell över alla speciella ansvar och uppgifter i teamet och sedan markera hur bekväma alla känner sig med respektive ansvar? Det ger också en tydlig bild av var utbildningsinsatser skulle göra störts nytta.  Kanske finns ett internt utbildningsprogram på plats så att utbildningen är lättillgänglig? 

Mätning 4: Vi kunde helt enkelt fråga efter varje möte hur nöjda alla är med just möteskvaliteten och be alla gradera frustrationen de upplever i alla administrativa saker?

Stöd kan behövas i vilket fall som helst

Även om ett team har fått ställa upp krav på sig själva så kan de förstås komma att behöva hjälp och stöd från andra för att lyckas. Det beror i så fall inte på att teamet själva ställde kraven, så kan det ju vara ändå i olika sammanhang.

Blev det inte perfekt direkt? 

Vi jobbar förhoppningsvis agilt med hela utvecklingen, inklusive kravens väg till att bli produktfunktioner, så då är det ganska självklart att jobba agilt med teamets egen kravställning också. Det fungerar bra att teamet är transparenta både med sina krav på sig själva (skriv upp och följ upp) och med sina krav på produkten och det fungerar fint att teamet till exempel efter varannan sprint gör justeringar i hur de arbetar med kravställningen. 

Varannan sprint? Varför inte varje sprint, kanske någon tänker? Det kan fungera bra med varje sprint också, men jag brukar tänka att en gång är ingen gång. Om vi ändrar för ofta kan det göra att slumpen får för stor inverkan så att beslut tas på felaktiga grunder.

Men kraven på produkten då?

Om vi involverar teamet i även de kraven så behöver det inte alls betyda att teamet bara skulle fokusera på sina egna favoriter, kodkvalitet eller balla features som vissa verkar tro.Om vi på ett seriöst sätt diskuterar med teamet kring försäljning, besöksstatistik, kundnöjdhet, konverteringsgrader, konkurrensen, eller vad det nu må vara så kommer ett välfungerande (*) team gott och väl att kunna komma med bra förslag på hur produkten bäst kan utvecklas, dvs vilka krav som bör ställas och hur de kan prioriteras.

Författare: Björn Lindqvist