Jag har börjat ett nytt uppdrag som agil coach i en organisation som tidigare anammat en del agila tankar och som nu vill prova på ett ännu mer agilt arbetssätt. Jag arbetar tillsammans med ett av teamen i organisationen. Mitt främsta mål med uppdraget är att teamet ska tycka det är ett roligare sätt att arbeta. Det tror jag är största chansen att det nya arbetssättet hänger kvar när mitt uppdrag är slut.
Inför detta uppdrag köpte jag boken Agile coaching av Rachel Davies och Liz Sedley. Jag gillade verkligen boken och sög i mig ny kunskap direkt. Boken är skriven utifrån Rachel och Liz erfarenheter och jag gillar att det finns exempel och praktiska tips, det är inte bara ”så här ska du göra” utan mer tips på olika sätt och mer hur man ska tänka än konkret lösning. Om du jobbar eller vill börja jobba agilt kan jag verkligen tipsa om boken, den är nyttig oavsett roll i teamet. Är du agil coach känns den nästan som ett måste.
Det som var allra mest nyttigt för mig var tips och tankar kring hur man är en bra agil coach, eftersom jag tidigare varit teammedlem eller scrum master. Det som blir den största omställningen för mig är nog att jag inte har något som jag direkt producerar och att mycket tid borde gå ut till att iaktta och fundera på lösningar på problem och förbättringar.
Ett tidigt råd till en scrum coach var ”led genom exempel” där man fick tipset att skriva ner vilka agila principer man vill visa och hur. Jag fick bla ned dessa punkter i min lista:
- Kommunikation öga mot öga istället för via mail.
- Inspect and adapt
- Fråga teamet: vad tycker ni jag ska göra? Vad funkar bra/dåligt?
- Ge direkt feedback (extra viktigt för mig som är lite konflikträdd)
- Se till att säga ”Vad tycker målgruppen” och prata utifrån våra beteendebeskrivningar och inte prata utifrån mig som användare. Detta är ju egentligen ingen agil princip utan en princip från användarcentrerad utveckling, vilket jag tycker är minst lika viktigt.
- Säg inte bara ”Det går inte”, utan hitta ett sätt att komma runt. Titta på vad vi som team kan göra.
En viktig del som jag behöver fundera på hur vi löser i mitt team nu är buggrapportering. I boken skriver de mycket om att när man har ett separat system för att logga buggar resulterar det i en andra gömd backlog. Utöver den vanliga product backlogen finns också bugglistan. Då hamnar vi i ett läge där user stories och buggar inte prioriteras lika och mot varandra. I vissa team sätter man en fast tid till att rätta buggar, men det kan ju göra att man lägger tid på något som ger mindre värde om det är så att det finns user stories som ger högre värde än att rätta de buggar som finns. Eller så är det tvärt om, det finns inte tillräckligt tid att rätta buggar som skulle ge högre värde än de user stories som finns i backlogen. Lösningen på detta skulle vara att se till att buggar som inte hanteras i sprinten hamnar i produktbacklogen tillsammans med user stories med nya önskemål. Jag tror själv att det oftast är den bästa lösningen, men är lite rädd för att hamna i en situation där produktägaren har svårt att värdera värdet av att få en viss bugg rättad jämför med ny utveckling. Ofta kan det ju vara så att varje enskild bugg inte har så stor påverkan, men totalt drar det ner produkten om det finns många buggar. Det går ju också helt emot Broken window tanken och Stop the line inom lean. Jag får klura på den ett tag till helt enkelt och se till att teamet testar sig fram.
Det enda som jag inte gillade med boken var att de verkar tänka på user experience som ett eget team. Det dröjde en ganska lång bit in i boken innan jag läste orden ”user experience team” och därmed insåg att de antagligen hela tiden tänkt att ux inte fanns med i teamet. För mig är det så självklart att ett riktigt scrumteam är tvärfunktionellt och har all kompetens som behövs för att klara uppgiften, vilket måste innebära att user experience kompetensen finns i teamet och inte i nåt annat team. Är UX i ett annat team så blir det ju något slags vattenfall i alla fall där ux behöver göra skisser innan de kan ges till utvecklingsteamet. Då blir det inte så lätt att styra om eftersom teamet inte kan utveckla nåt som ux-teamet inte har skissat. Dessutom missar man ju hela samarbetsbiten där alla kompetenser tillsammans kommer fram till den bästa lösningen och det finns chans att bolla fram och tillbaka under utvecklingen. Som tur var påverkade den här skillnaden i synsätt inte min chans att ta till mig en massa nyttigheter från boken utan för det mesta innehållet spelar frågan ingen roll.
Min nästa bok är Coaching agile teams av Lyssa Adkins, jag hoppas den är lika bra. Har ni några fler boktips?
Tack för intressant, kunnig och personlig text!