Vad går bra i teamet och i projektet? Och vad inte? Vilka åtgärder kan härledas från detta? Retrospektiver är ett perfekt sätt att ge motivation och drivkraft till ditt företag eller byrå. Vi ska visa dig hur du ställer in en retro och vad Dos and Don'ts är.

En retrospektiv (kort: Retro) är en slags retrospektiv för att bestämma tillsammans i en grupp, ett team eller för en komplett organisation, vilka framgångar har uppnåtts under en angiven tidsperiod. Detta gör att du kan sätta din projektledning eller smidiga mjukvaruutveckling på prov, liksom något annat område i ditt företag. Samtidigt tydliggör retromöten frågan om lagarbete verkligen fungerar så friktionsfritt – och hur nöjda dina medarbetare är.

De grundläggande reglerna

Retros är särskilt effektiva. Varje enhet erbjuder tillräckligt med utrymme för förbättringsförslag, som omedelbart omsätts i konkreta projekt. Det är detta som gör retrospektiver så värdefulla och hållbara. Retros utförs korrekt på ett sätt som

1. Låt alla från gruppen eller teamet få säga sitt
2. ger utrymme för ett brett utbud av feedback utan att utvärdera den omedelbart
3. Konstruktivt, framåtblickande, respektfullt och transparent

Retrospektiver är inte bara lämpliga för företag eller byråer, utan också för icke-statliga organisationer, föreningar, frivilliggrupper, initiativ med öppen källkod eller sociala och politiska projekt. Särskilt miljön med öppen källkod eller WordPress uppskattar återkopplingsloopar baserat på retrospektiver. Slutligen tas hela utvecklingsteamet med och beslutsprocesser avslöjas.

Retros är lika bra för tekniska projekt som för att förbättra företagskulturen. Här är en kort översikt över de två varianterna:

Scrum Retrospektiv

Retrospektiv är klassiskt kända från projektledningsmetoden Scrum. Speciellt team från mjukvaruutveckling eller webbdesign förlitar sig på Scrum, eftersom det erbjuder en kontrapunkt till klassiskt hierarkiskt organiserade projekt av typen "Jag anger vad du måste göra när". I viss utsträckning organiserar utvecklarna i Scrum sig själva. Ändå finns det fasta strukturer (som Scrum Board) och fasta perioder ("Sprint"). Deluppgifter gör det hela särskilt flexibelt och därmed agilt. Själva retron går i fem faser:

1. Introduktion: Här är teamet justerat till retro, definierar målen för mötet, förklarar organisationsprocessen igen om det behövs eller introducerar nya deltagare: inuti.
2. Insamling av data: Detta steg är avsett att samla teman som kommer att belysas i retro. Så poäng som gick bra. Men också de med vilka man vill ha en optimering eller som orsakar konflikter. Först och främst är allt i input tillåtet här – den gemensamma prioriteringen sker först efter det.
3. Få insikt: De punkter som ingår kommer att diskuteras tillsammans. Vilka är anledningarna till positiv men också optimerad utveckling? Vad kan härledas från detta för de ytterligare projekten eller för samarbetet i teamet?
4. Härleda åtgärder: Omgången beslutar tillsammans vilka förbättringsåtgärder som ska gälla för de fortsatta sprintarna. Dessa åtgärder bör formuleras så konkret som möjligt ("vem gör vad och när") och registreras skriftligen.
5. Slutsats av retrospektivet: Här kan du sammanfatta resultaten, klargöra de sista öppna frågorna, plocka upp alla deltagare och göra en kort "retro av retro".

För vissa team, byråer och företag tar denna mycket öppna form av utbyte tid att vänja sig vid. Då kan det hända att det finns lite feedback till en början, eller att konflikter och ömsesidiga förebråelse ens uppstår. Detta kan undvikas, och några tips kan läggas till.

På kort eller lång sikt bör dock retrospektiven leda till följande förbättringar:

• Scheman i mjukvaruutveckling eller projekt kan planeras bättre, minska hinder tas bort
• Företaget skapar de nödvändiga resurserna av teknisk, strukturell eller mänsklig karaktär för att kunna arbeta förnuftigt
• Medarbetarna: medarbetarna hanterar konflikter mer öppet och löser dem tillsammans
• Teamet kommer inte bara ihåg vad som inte körs, utan de positiva punkterna och processoptimeringen
• Inte bara tekniska utmaningar är i förgrunden, men också samexistensen och stämningen i laget

Om en eller flera av dessa punkter inte nås kan du arbeta tillsammans med formatet, verktygen, beslutsprocesserna, deltagandet av alla deltagare: inuti eller på modereringen. Eller så noterar teamet att vissa förutsättningar först måste skapas. Det kan till exempel vara enhetliga utvecklingsprocesser eller bättre kommunikation eller motivation i företaget.

Team Retro

Och detta leder oss till den andra funktionen som retrospektiv kan ha. Förutom rent projektrelaterade processer eller som ett komplement till teknikretros kan de användas för att stärka sammanhållningen i byrån eller i företaget. Inget lag kan klara sig utan konflikter. Den avgörande faktorn är en öppen och lösningsorienterad hantering av dessa, så att organisationen inte bara sysslar med sig själv eller stannar kvar i "arbete enligt regelverk".

Free Team Retros, som inte är involverade i Scrum eller någon annan metod, använder främst följande tre frågor:

• Vad fungerade bra? I vilka fall har vi arbetat bra tillsammans och varför?
• Vad fungerade inte bra? Var kan något förbättras i samarbetet?
• Vad vi hoppas förbättra, kommer vi att försöka? Vem tar hand om genomförandet och när?

I det här fallet är en retrospektiv mindre strikt organiserad än på Scrum. I princip kan teamet fritt bestämma i vilket format frågorna som just listats klargörs. Ett regelbundet format (till exempel en recension varannan månad), ett representativt urval av deltagare, detaljerad dokumentation och skriftliga resultat är dock till hjälp. Även en person som tar över inbjudan, måttfullheten och renoveringen.

Temana om retros bör komma från de anställda själva, och ännu mer. För att initiera denna process är det vettigt att samla in regelbunden feedback redan i förväg. Och för att ge både hjälp och motivation. Till exempel i samband med (om nödvändigt anonyma) undersökningar eller genom en särskild roll i företaget. Du kan läsa hur detta kan se ut i vår artikel om psykisk hälsa i affärer.

Anställda som tidigare arbetat i ett mycket hierarkiskt strukturerat företag är inte vana vid att göra öppna och modiga bidrag till företagskulturen. I ditt företag kommer något bara att förändras om det finns ett ramverk där alla fritt kan uttrycka sin åsikt.

Gör i en Retro

Oavsett teknisk eller snarare kulturell retro finns det vissa förutsättningar och även verktyg som bidrar till mötets framgång:

• Måttfullhet: På Sprint Retrospective tar Scrum Master på sig denna roll. Med en icke-formell retro kan denna uppgift bestämmas fritt, kanske till och med som en del av en rotation.
• Platta hierarkier: Det är viktigt att moderatorerna leder mötet som jämlika deltagare, inte "uppifrån". Detsamma gäller personer från ledningen eller andra ledande befattningshavare.
• Definiera regler: Om det finns missförstånd eller tvister när man utför retros, hjälper det att komma ihåg gemensamma värderingar hos byrån eller företaget. Detta är inte en lista över förbud, utan i form av exempel som står för positiv kommunikation. Se till exempel Uppförandekoden för Raidboxes.
• Bindande avtal: Detta inkluderar inspelningsresultat i ett protokoll. Men inte heller att fatta beslut över huvudet på frånvarande gods. I tveksamma fall måste deltagarrundan förlängas. Eller, beroende på vilka ämnen som kan förväntas, kan du bjuda in gäster från andra avdelningar och team.
• Mäta framgång: Leder de åtgärder som hittills vidtagits till förbättringar? Om inte, hur kan en mer konkret slutsats av retro se ut? Kan framgångarna bevisas eller mätas? Kommer arbetsbördan att minskas på ett hållbart sätt eller kommer stämningen i teamet att förbättras?

Framför allt är den sista punkten viktig: Endast genom positiva resultat förankrar retron sig permanent och accepteras av alla. Eftersom inte alla i ditt team kommer att förstå innebörden av retrospektiv redan från början. Förevändningen "Det hjälper ändå inte" kan bara motbevisas om framgångarna blir synliga. Och om du hämtar alla roller i företaget regelbundet.

Gör inte en Retro

Don'ts härleds delvis från ovanstående punkter. Men även utöver det lurar risker om retrospektiverna inte är väl genomtänkta eller styrs på ett vagt sätt:

Improduktiv cirkel av deltagare:inuti

Öppenhet och ibland känslighet krävs här. Det gör ont om individer från laget inte känner sig involverade. Å andra sidan blir för stora rundor – eller om tematisk blandning är för hög – snabbt improduktiva. Om enskilda ämnen inte kan klargöras i den stora rundan, kan du sätta dem i det mindre laget retros om det behövs.

För lite transparens

När andra avdelningar känner sig oförmögna att få en inblick i resultatet av en retro uppstår snabbt oro eller frustration. Det är här offentligt tillgängliga protokoll eller regelbunden presentation av resultaten för all hjälp. Detta gäller även mätningen av de antagna punkternas framgång.

Skyddad ram

Samtidigt bör retrospektiven själv vara en skyddad plats, så det finns ingen reservation för att kritisera den. Vissa talar öppet om vad som behöver förbättras endast inom en sådan ram. Till exempel inom ditt eget team eller utan ledningsnivå. Vid behov kan retros delas upp för att hitta rätt balans mellan öppenhet och behov av skydd.

För strikt mål

Det är alltid samma deltagare: de som talar i efterhand? Skrotas snabbt förslagen? Eller är enskilda resultat ens fasta i förväg? Det kan inte fungera. Retros är endast lämpliga för byråer och företag där det finns en öppen kultur.

Uppgifter är felaktigt definierade eller hålls inte

Frågan om "vem gör vad och när" är oerhört viktig. Retrospektiv kräver att cirkeln definierar ansvar och tidsfrister för varje idé som ska genomföras.

När det gäller åtgärdernashållbarhet: Det är värt att förlita sig på ett projektledningsverktyg där de enskilda uppgifterna förs in. Då kan du alltid se i korthet inom vilka områden en retro går bra och var den behöver förbättras. Finns det flera retrospektiver i ditt företag? Då kan de mätas mot varandra eller utbyta idéer mot varandra.

Ren teknik, inte kultur

Oavsett om det är en Sprint Retro eller en annan variant handlar det inte bara om att lista och lösa rent tekniska utmaningar. På samma sätt bör den sociala och kulturella samexistensen i teamet belysas. Eftersom det ena (effektiva arbetet) inte fungerar utan det andra (laganda). Utvecklingsavdelningar kämpar ibland för att länka de två. Då hjälper lämpliga utbildningar, se till exempel vårt blogginlägg om icke-våldsam kommunikation.

Oklar struktur

Retros är avsedda att skapa utrymme för att tala fritt om konfliktfyllda ämnen. De behöver dock en tydlig ram och en solid struktur. Dessa inkluderar viktiga punkter som regelbunden körning, modereringsrollen, en separat roll för dokumentation eller protokoll, tidshantering och, om så önskas, användning av speciella retroverktyg. Ytterligare en ledtråd. De fem faserna av en retro (se ovan) hjälper dig att upprätthålla strukturen.

Du kan få hjälp med alla punkter som nämns om du inte har tillräckligt med kunskap i din byrå eller ditt företag. Till exempel genom utbildningar eller genom externa utbildare:

Retros @ Raidboxes

Vi på Raidboxes använd flera former av retros för att organisera oss. Å ena sidan de klassiska Scrum retrospektiverna av vår produktutveckling, genom vilken vi nu kan agera mycket snabbare. Dessutom använder vårt stöd – och snart även vi inom marknadsföring – teaminterna retros för att kontinuerligt förbättra kvaliteten.

Dessutom håller vi för närvarande på att upprätta ett format som gör det möjligt för alla kollegor på Raidboxes inkluderad. Här är vi fortfarande i upptäcktsfasen. På grund av vår nuvarande tillväxt är det inte längre så lätt att föra samman alla. En idé som vi undersöker: Varje team skickar två suppleanter till den företagsomfattande retrospektiven, i en roterande process. Detta skulle ge alla chansen att engagera sig.

Ämnen för Retro

De positiva punkterna och de utmaningar vi tar med oss till detta företagsomfattande format kommer delvis från våra medarbetare: intern undersökning. Vi utför det här var sjätte månad. Att prioritera frågorna är ganska enkelt: vi väger bland annat in hur ofta eller brådskande en poäng har klassificerats i denna undersökning.

Ett annat tillvägagångssätt kan vara att samla teman för retro i förväg i laget. Om det finns för många punkter för en retro är omröstningen: vilka vill vi diskutera? Alla andra poster migrerar sedan automatiskt till en eftersläpning för nästa retro.

Retro programvara: Echometer

Det finns nu några verktyg för att utföra en retrospektiv programvara som stöds. Vi arbetar själva med echometers, företaget är också baserat i Münster. Echometer är ett verktyg som hjälper till att systematiskt utföra ett team retro. För att fånga dina anställdas potential och humör: inuti.

Du kan välja mellan en pool av prefabricerade frågor valda enligt psykologiska tillvägagångssätt, som deltagarna svarar på. Alternativt kan du skicka in dina egna frågor. Från den här poolen med svar kommer Echometer sedan att vägleda ditt team steg för steg genom retrospektiven. En särskild fördel: Resultaten dokumenteras automatiskt och kan jämföras med varandra. Efter några retros kan du när som helst ta reda på var förbättringar sker eller var du fortfarande kan läsa.

Källor och länkar

Vill du introducera retros eller scrums i din byrå eller företag? Här är några mer avancerade källor:

• Sipgate Blog: Retrospektiver som en förbättringsmotor
• Projektmagazin.de: Vad är en Sprint Retrospective?
• t2informatik.de: Metoder för Scrum Retrospektiv
• echometer: Kreativa metoder för online retrospektiver
• Det gick inte att introducera Scrum
• Kompakt introduktion till Scrum