Undvika fallgropar i SAFe 5 - evig analys

Se till att teamet har tydliga och mätbara mål samt en klar förståelse för vilka initiativ och uppgifter som har högsta prioritet. Fokusera på det som ger mest värde till kunderna och affären och undvik att fastna i överdrivna diskussioner om mindre viktiga detaljer. Det är lätt att diskussioner under möten och ceremonier drar iväg och att involverade börjar diskutera lösningar på problem och på så sätt påbörjar arbetet som egentligen ska starta under sprinten.

Försök att styra upp detta och hänvisa diskussioner till andra tillfällen, men var samtidigt lite varsam och ha lite fingertoppskänsla så att du inte upplevs som teamets diktator som alltid avbryter intressanta diskussioner.

Tänk på att vi alla är människor och har ett behov av att kommunicera och få bekräftelse för olika saker. Om du ständigt avbryter alla diskussioner kommer teammedlemmarna till slut att uppleva att du inte känner sympati med dem och bara tänker på hårda, kalla resultat.

Vi har också tidigare pratat om hur viktigt det är att alla intressenter och alla i teamet är har en förståelse för prioriteringen som har gjorts och är med på varför det ser ut som det gör.

Använd agila principer som "Fail fast, fail forward" och "Iterativt arbete" för att uppmuntra till snabba prototyper och experiment. Detta hjälper teamet att komma igång snabbt och få feedback tidigt i processen istället för att fastna i oändliga teoretiska diskussioner.

"Fail fast, fail forward" innebär att om det uppstår problem eller om ett experiment misslyckas, ska teamet inte fastna i problemet utan snabbt identifiera orsaken och dra lärdomar. Istället för att se misslyckanden som hinder ser man dem som en möjlighet att lära sig något nytt och förbättra framöver. Detta uppmuntrar ett klimat där teamet inte är rädda för att prova nya saker, eftersom de vet att om något inte fungerar som förväntat, kommer de snabbt att kunna justera och gå vidare i rätt riktning.

Självklart ska du inte köra så hårt med teamet så att de ständigt ska hoppa på nya spår. Ni måste få tid att reflektera över saker och ting och utnyttja de erfarenheter ni bygger upp i teamet.

Om ett team skapar en snabb prototyp och inser att användargränssnittet inte är intuitivt, så ska de inte fastna i försöket att förfina gränssnittet utan snabbt anpassa sig efter användarnas feedback, identifiera de problematiska områdena och snabbt iterera på designen. Det här påminner lite om samma problem som konstnärer möter när de skapar sina verk.

Ett konstverk kan man slipa, förfina till det oändliga, men i något läge måste man släppa det och betrakta det som klart.

Det iterativa arbetssättet innebär att teamet delar upp arbetet i små, hanterbara delar och arbetar med dem i korta cykler, vanligtvis kallade "sprintar" eller "iterationer". Teamet levererar värde i små inkrement istället för att försöka slutföra hela projektet på en gång. Detta möjliggör regelbunden feedback och validering från kunder och intressenter, vilket gör det möjligt att anpassa och förbättra produkten baserat på verkliga reaktioner och behov.

Om ett utvecklingsteam till exempel arbetar med att implementera en ny funktion, bör de inte vänta tills hela funktionen är klar för att börja testa den. Istället bör de bryta ner arbetet i mindre delar, implementera en del och testa det så snart som möjligt. Därefter kan de iterera och förbättra funktionen baserat på användarfeedback.

Med dagens verktyg är det väldigt enkelt att presentera ett antal parallella spår med alternativa lösningar, speciellt om det gäller användargränssnitt.

Sträva efter att snabbt bygga ett Minimal Viable Product (MVP) som kan leverera grundläggande funktionalitet till kunderna. Detta gör det möjligt för teamet att börja leverera värde snabbt och kontinuerligt förbättra produkten baserat på kundfeedback. Förr var inte detta lika enkelt eftersom det ibland krävdes ganska stora utvecklingsinsatser för att få fram en fungerande prototyp. Tankebanorna är däremot inte nya på något sätt.

Prototyping är något som använts i olika former ända sedan 1970-talet, men skillnaden med dagens miljöer är att det ofta går extremt fort att få fram något som kan visas upp för intressenterna. Det finns mängder med olika verktyg som är riktigt bra på att ta fram prototyper i olika former, oavsett om det rör sig om användargränssnitt, javakod, pythonkod, javascript, databaskopplingar, APIer, CRUD-operationer med mera.

Genomför regelbundna retrospektiv för att reflektera över teamets arbete och identifiera förbättringsområden. Detta hjälper teamet att ständigt utvecklas och undvika att fastna i samma mönster av överanalysering. Att anordna regelbundna retrospektiv är en viktig i det ständiga arbetet med att förbättra teamet.

Här är några tips för att göra retrospektiven mer framgångsrika och undvika överanalysering och oändliga diskussioner:

• Sätt en fast tidsram - Bestäm en tydlig tidsram för retrospektiven och håll er till den.

• Förbered en agenda - Ta dig tid att förbereda en agenda med de ämnen som ska diskuteras. 

• Använd olika metoder - Variera retrospektivens format och metoder.

• Skapa en trygg miljö - Se till att alla i teamet känner sig bekväma att dela sina åsikter.

• Fokusera på konkreta åtgärder - Se till att fokuserar på konkreta åtgärder för att adressera dem. 

• Följ upp tidigare åtgärder - Följ upp tidigare åtgärder och se om de hade önskad effekt.

• Utvärdera effektivitet - Efter varje retrospektiv, utvärdera mötets effektivitet.

Genom att använda dessa strategier kan du hjälpa teamet att få ut det mesta av sina retrospektiv och skapa en kultur av kontinuerlig förbättring och lärande. Detta kommer hjälpa teamet att undvika stagnation och fastna i ineffektiva mönster och istället ständigt utvecklas och förbättras.

Genom att följa dessa tips kan du undvika "analys-förlamning" och istället främja handlingskraft och resultatfokuserat arbete inom ditt team och din organisation. Kom ihåg att SAFe-ramverket är ett verktyg, och det är viktigare att använda det som en grund och anpassa det efter ditt teams unika behov och situation än att följa det slaviskt.

I nästa artikel tar vi oss en titt på hur du kan involvera PM/SA/BO i teamets operativa arbete på ett annat sätt.