Som scrum master, agil coach eller allmänt passionerad problemlösare behöver du många verktyg i ditt bälte. Ett sådant verktyg är kunskapen om att det finns mer än ett sätt att hantera problem. Faktum är att det finns precis fyra olika sätt – och bara ett av dem passar dig som vill bli av med ett problem för gott.
Har du tänkt på hur lätt det är att fastna i ett mönster där du och ditt team betar av problem efter problem, bara för att i slutänden se problemen dyka upp igen – trots allt hårt arbete med att bli av med dem? Har du funderat över varför det blir så?
Effektiv problemhantering kräver att du är medveten om vilken approach du faktiskt valt, så att du kan förstå varför du får de resultat du får.
Organisationsvetaren Russell Ackoff identifierade fyra olika sätt att ta sig an ett problem. På engelska kallade han typerna för absolve, resolve, solve och dissolve. Rytmen i ramsan gör mycket för minnet, så på svenska har jag valt att kalla dem för ignorera, reparera, optimera och eliminera (även om det inte är en helt perfekt översättning – men jag väljer att ignorera det problemet).
Ackoffs uppdelning gör det tydligt att vi har ett val. Alla de fyra vägarna är rätt någon gång. Att ignorera ett problem är till exempel helt rätt väg att gå när en aktiv insats snarare skulle göra situationen värre – eller när vi inte har tillräcklig kunskap än för att kunna agera klokt. Här är ett par exempel:
- En av dina kollegor beter sig märkligt. Du överväger att ge feedback men väljer att vänta och se om det var en engångsföreteelse, eller om det är ett mönster som upprepar sig.
- Trivselmätningen ni gör varje månad dyker plötsligt kraftigt. Som agil coach väljer du att notera förändringen men gräver inte djupare just nu, eftersom du misstänker att den har att göra med särskild händelse som inträffade under sprinten.
- Som produktägare märker du att resten av teamet gärna vill låsa ned detaljerna kring en funktion som ligger en bit framåt i priolistan. Du förklarar att du vill vänta tills efter att ni granskat feedbacken från nästa release, när ni lärt er mer om vad användarna verkligen behöver.
Att reparera, det Ackoff kallar “resolve”, handlar om bygga på våra tidigare erfarenheter och kunskaper för att hitta en väg framåt. Ofta kan vi hitta lösningen genom analogi: har vi löst ett liknande problem tidigare? Kanske kan vi ta den lösningen och anpassa den till den aktuella situationen. I sin extrema form urartar reparation till rena brandsläckningar. I sin mer rimliga form handlar det om att hitta tillräckligt bra lösningar – det Herbert Simon kallade “satisficing”. Likväl är risken stor att vi senare upptäcker att vi hanterat symptomen, men inte botat sjukdomen.
När vi optimerar (Ackoffs “solve”) använder vi ett närmast vetenskapligt sätt att analysera problemet och utforma den bästa tänkbara lösningen. Vi samlar data om situationen, identifierar alternativa vägar framåt och beräknar vilket alternativ som skulle ge bäst effekt på alla nyckelområden.
Som systemtänkare är eliminering (“dissolution”) den väg jag personligen får mest energi från (och kanske därför överanvänder). Här är målet att forma om förutsättningarna så att problemet inte kan uppstå igen. Design är nyckelordet här, i bemärkelsen att vi försöker utforma en situation där problemet helt löses upp.
- Många team störs av akuta problem som skjuter sönder lagda planer. Vissa team går till källan och undersöker problemens ursprung. Svaret blir inte sällan “från oss själva”. Många av problemen visar sig handla om defekter som teamet själva skulle kunna lösa som en del av det dagliga arbetet. Team som utvecklar sitt arbetssätt så att de släpper produkter med färre fel upptäcker snart att även brandsläckningarna blir färre.
Hur är det för dig och ditt team? Fundera på om ni sitter fast i ett mönster. Om ni aldrig tar er tiden att eliminera – då är det kanske inte så konstigt att samma problem dyker upp igen och igen.
Helt ärligt (och utan att berätta för någon annan): Hur många av problemen du jobbat med under senaste veckan har du verkligen eliminerat? Hur många har du optimerat? Hur många har du reparerat eller ignorerat?