Försvinner utvecklingssamtalet i en agil organisation?

Läser med ett öga (barnpassning med det andra ögat) Peter Antmans “Riv pyramiderna igen”:

de agila värderingarna (teamet är ansvarigt, betoning av inre motivation, återkopplingar hela tiden, systemtänkande, vid behov) skar sig mot de värderingar som ligger bakom individuella utvecklingssamtal (bedömning, extern motivation, individinriktat, sällan förekommande, förutbestämt).

Spontant håller jag inte med. Möjligen (eller troligen) har vi olika bild av hur utvecklingssamtal genomförs och varför. Min erfarenhet säger mig att utbildningssamtal ger möjlighet till inspect & adapt.

Negativt?

“Bedömning”, ja mot egna uppsatta och antagna mål borde ju vara ett minimum. Vilken transparens har vi annars att jobba utifrån? Att få en extern vy på sina förehavanden och mål är sällan skadligt utan positivt – på samma sätt som att lära någon befäster sina egna kunskaper, att kunna visa och motivera sin bedömning för någon annan kan hjälpa till med att vässa sina argument och ställa djupare krav på eftertanke.

“Extern motivation”, detta ämne förstår jag inte.

“Individinriktat”, går visserligen bokstavligt stick i stäv med “teamet är ansvarigt” men inte bildligt. Det går inte att skapa grupper utan att ha individer. Att stötta individer till att växa och utvecklas borde göra teamet starkare.

“sällan förekommande”, detta håller jag med om. Min erfarenhet är att det sker sällan (varje kvartal). I för långa och för korta cykler är det svårt att se orsak och verkan.

“förutbestämt”, förstår inte riktigt vad Peter menar med detta. Förutbestämda datum behöver inte vara något negativt – i Scrum-ramverket ger det möjlighet till just att se orsak och verkan genom regelbunden inspektion. Ett metodiskt angrepp att försöka öka kontroll/riktning i en komplex miljö/omgivning/verklighet (och på så sätt reducera risken att komma ut i fel ände). Förutbestämd agenda kan vara jättebra för att komma igång, de flesta retrospectives jag deltagit i tror jag haft nytta av detta. Givetvis behöver man variera sig, men att ha något att börja titta på kan hjälpa till. Det kan också baseline:a och begränsa resultatet genom att det avgränsar tankerymden.

Positiva agila värden

“Teamet är ansvarigt” – vilket innebär personligt ansvar för den egna insatsen (inför teamet och sig själv).

“betoning av inre motivation” – kan man kanske se hänga ihop med Software Craftsmanship (för de som känner att det är vad de gör). En bra mentor/coach/chef bör kunna hjälpa till att hitta och formulera, och kanske även “maximera”, de aktiveter och den omgivning som stöttar en individs motivation. Att varje team skall bestå av personer vars innersta inre motivation kommer till fullt utlopp genom arbetsplatsens åtaganden känns eutopiskt.

“återkopplingar hela tiden” – instämmer att det traditionella utvecklingssamtalet är långt från tillräckligt här (samtidigt som viss ledtid måste finnas i “långa” processer)

“systemtänkande” – här tänker jag att utvecklingssamtalet inte bidrar till “systemtänkandet”, men inte heller skadar. Troligen optimerar man inte endast “flaskhalsen” genom att se till varje individ i teamet, vilket då skulle medföra “waste” i att se alla som inte är flaskhalsen. Jag skulle bli förvånad om det ändå är kostsamt att genomföra bra utvecklingssamtal, regelbundet.

“vid behov” – nja: visst som värde; nej som aktivitet för styrning. Om vi har komplex miljö vill vi göra kontinuerlig inspect & adapt, inte “vid behov”. I en enkel och repetitiv aktivitet vill vi minska waste, men att kalla individers utveckling inom arbetet för potentiell waste tror jag inte är lyckat. Det är antagligen inte heller vad Peter menar, så jag missförstår säkert hur utvecklingssamtalet “vid behov”.

Coach, mentor eller chef?

Givetvis får man kanske fundera över grundinställningen till utvecklingssamtalet. Om det är ett halvårsvis avstämningsmöte, eller förtäckt lönesamtal så är det väl tveksamma incitament för transparens etc.

Kanske Peter förtydligar sina tankar senare i boken.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>