Förbättra dina agila ceremonier

Sprint Planering

På detta möte gäller det att se till att alla är engagerade och är med i diskussionerna. Det kan vara svårt då det ofta är så att alla inte är lika berörda av alla uppgifter i backloggen. En annan svårighet är att hålla mötet lagom långt så det inte drar iväg i tid för mycket.

Bra saker att försöka få till är:

• Se till att göra Backlog Refinement tillräckligt ofta så att översta delen i backloggen är väl förberedd, då går Sprint Planning smidigare.
• Fastna inte i för långa tekniska detaljdiskussioner, då tappar de teammedlemmar som inte är inblandade i aktuell story fokus. Här får Scrum Master hålla lite koll och fråga teamet ibland om de verkligen behöver reda ut alla tekniska svårigheter redan på Planning eller om det kan vänta tills jobbet görs. Ibland fastnar man i spännande tekniska diskussioner och fokuserar mer på att lösa problemet snarare än att skapa en Sprint Backlog.
• Om vissa personer i teamet tappar fokus beror det troligen på att de inte är så inblandade i aktuell story och inte har något att tillföra i pågående diskussion. För att lösa det behöver ni bli mer T-shapade. Alltså att alla behöver kunna lite om allt så man ändå kan vara med i diskussionen. Det kan också behövas ett tydligare mål för teamet som alla känner är viktigt. Här kan ni får fler tips på sidan ”Skapa bra laganda ”. Lösningen att förbjuda laptops och mobiler (för att de inte ska stjäla uppmärksamhet) på Sprint Planning är en dålig idé, det gäller att locka till engagemang inte försöka tvinga in det.
• Ta en kort rast varje timma. Gärna utomhus en stund om det går. Försök inte tjäna in tid genom att skippa rasterna, det slutar bara i långa sega diskussioner som stjäl ännu mer tid.

Daily Scrum

Detta möte är kanske det viktigaste av alla möten, det är här vi skapar laganda samarbete och fart framåt. Tyvärr blir Daily Scrum ofta för långa då vi fastnar i tekniska diskussioner. Nedan ser ni ett antal bra saker att tänka på som Scrum Master.

• Se till att det inte blir en rapportering av status till Scrum Mastern, det är ganska vanligt. Här gäller det som Scrum Master att förklara att målet med mötet är att teamet ska planera vad de ska göra idag, inte rapportera status till någon projektledare som ändå inte finns.
• Kör gärna ”Walk the board style”, alltså att gå igenom Scrum boarden uppifrån och ner, inte laget runt. Viktigt dock som Scrum Master att hålla koll på att alla säger något om sin situation och är med i något av arbetspaketen. Om någon varit tyst under mötet bör Scrum Mastern fråga den personen om hen vet vad som ska göras idag och om det finns några problem. Det händer ibland att någon är tyst hela mötet och sedan inte har något konkret att göra under dagen.
• Om ni inte kör ”Walk the board style” så kan det vara bra att ha en maskot att skicka runt i laget. Den som får maskoten ska prata och beskriva sin situation, sedan skickas den vidare till nästa person. Maskoten skulle faktiskt kunna vara en äggklocka som man ställt på 15 min 😊
• Håll mötet kort. Absolut max 15 minuter. Långa Daily Scrums gör att mötet blir något som känns som onödigt och tråkigt. Ofta resulterar det i att teamet vill ha mötet mer sällan. Det är dock viktigt att ha Daily Scrum varje dag så vi hela tiden säkerställer att vi samarbetar bra och har fart framåt. Här måste Scrum Mastern styra hårt och hålla diskussionen till ”Vad gjorde vi igår?”, ”Vad gör vi idag?” och ”Har vi några problem?”. Alla tekniska diskussioner måste snabbt styras åt sidan, berörda kan ta upp diskussionen igen direkt efter Daily Scrum. Det finns dock situationer i små team där alla kan vara intresserad av diskussionen och då man bör låta den fortgå. Scrum Mastern kan då fråga teamet om alla vill vara med i denna diskussion eller om den ska tas senare. Scrum Mastern kan även hålla koll på om alla verkar vara intresserade och deltar i diskussionen, då bör man inte avbryta utan låta den fortgå. Det är inte lätt att vara Scrum Master alltid. 😊
• Se Daily Scrum som en Timeout i en match. Alla går åt siden en kort stund och pratar ihop sig snabbt. Man beskriver situationen i matchen och bestämmer vad man ska göra och springer sedan ut på plan igen och gör som man just kommit överens om. Det är en kort samling där alla är 100% fokuserade för att komma fram till hur vi ska göra den närmaste stunden i matchen. Så ska även en bra Daily Scrum vara.

Backlog Refinement

Detta möte brukar inte vara så problematisk utan brukar gå smidigt. Problemet kan dock vara att man slarvar med att ha det. Ofta märker man vid Sprint Planning och vid Retrospective om man gör för lite Backlog Refinement. Dra er inte för att boka in detta, om det visar sig inte behövas kan man bara ställa in eller köra väldigt kort. Kör man 2-veckorsprintar är det väldigt passande att ha Backlog Refinement samma veckodag som man brukar ha Sprint Planning, fast mitt i sprinten, då har man ju ändå inte Sprint Planning och bör ha tid för detta möte.

Sprint Review

Detta ska vara ett möte i positiv anda där utvecklarteamet med stor stolthet får visa upp vad de lyckats åstadkomma. För att få mötet att bli så bra och givande som möjligt är nedan tips bra att ta till sig:

• Fokusera på det som blivit klart och presentera det. Fastna inte på vad som strulat och inte blivit klart, det hamnar i backloggen igen och tas upp för diskussion på nästa Sprint Planning. Det räcker att säga att denna story tyvärr inte blev klar pga. av … (en kort förklaring, ingen fullständig redogörelse). För att slippa denna typ av diskussioner är det bra att inte planera in för mycket i sprinten utan bara dra in det man känner sig ganska säker på att kunna avsluta, se mer på sidan ”Lyckas avsluta allt i era sprintar ”
• Förbered Sprint Review genom att bestämma vem som ska prata om vad. Det är bra om så många som möjligt kan berätta något. Den som inte har något att säga på ena Reviewn bör vara först till kvarn att få något att prata om på nästa.
• Bjud in stakeholders och intressenter till mötet, vi vill att många ska komma. I organisationer som kör en uppskalad variant, så som t.ex. SAFe, är det risk att det bara blir själva Scrum Teamet som är med. Det är lite synd för de vet ju redan allt. Bjud in linjechefer, personer från andra team och andra ARTs, högre chefer och ledning. Försök få dit så många som möjligt så ni får chans att få uppmärksamhet och feedback utifrån.
• Ta er tid att lyssna på feedback. Låt inte mötet bara bestå i att visa vad ni gjort utan avsätt också tid till att samla in synpunkter från åhörarna, det är ju det som är kärnan i agilt mindset och anledningen till att vi arbetar agilt.

Sprint Retrospective

Här har vi en fantastisk möjlighet att hitta förbättringar, ta vara på den. Sprint Retrospective ska vara ett tillfälle då Scrumteamet verkligen får komma nära varandra och delge sina tankar om problem att lösa och nya saker att testa. Det finns många olika varianter av retrospective, ett par beskrivs nedan. Alla retrospective bör dock innehålla samma struktur på själva mötet. Ett bra sätt att lägga upp mötet på är följande:

• • Bestäm vilken variant av retrospective ni vill köra. Har teamet förslag så lyssna på det, om inte får Scrum Mastern bestämma. Kör göra olika varianter olika gånger.  Kör man samma för ofta blir det ett tråkigt möte.
  • Ge alla en tid att skriva gula lappar, det brukar vara lagom med ca sju minuter. Som Scrum Master kan man ha koll på hur många lappar det blir. Man får avsluta skrivandet om det antingen: a) är så att alla verkar ha skrivit klart eller b) om det är så att det blivit många lappar, vi ska ju hinna ta hand om dem också. Under denna del av mötet ska det vara helt tyst. Alla skriver, ingen pratar. När det är helt tyst ett par minuter kommer man på massor av saker som man vill ta upp på retrospective. Är det ljud och personer som pratar kommer man aldrig så djupt i sina egna tankar och idéer.
  • Låt var och en gå fram till whiteboarden och sätta upp sina lappar samtidigt som de förklarar vad de skrivit och alla andra lyssnar.
  • När alla satt upp sina lappar är det dags att rösta. Alla röstar på de lappar man anser viktigast att agera på. Alla får tre röster och går fram och markerar sina röster med ett sträck på lapparna.
  • Scrum Mastern tar sedan lapparna i turordning efter antal röster och ber teamet komma med förslag på actions att göra. I detta skede är det en öppen diskussion och alla får bidraga med idéer på åtgärder. Scrum Mastern för anteckningar på whiteboarden och åtgärder beslutas.
  • Alla actions bör dokumenteras någonstans där teamet kan hitta dem. De som passar i backloggen bör läggas in där.

En sista sak att tänka på gällande Retrospective är att den inte blir för lång. Scrum Masterna måste här stämma av med teamet vad som är lagom längd. Kör ni mer än 60 minuter bör ni ta en rast i mitten.

Luftballongen​

Rita en luftballong på whiteboarden. ​

Man sätter lappar som lyfter oss eller som skulle lyfta oss om vi gjorde det på ballongen.​

Man sätter lappar som sänker oss runt korgen.

Har du frågor om agil organisation?