3 domande contro il micromanagement in Scrum

Uno dei principi fondamentali di Agile e Scrum è l'esatto opposto del micromanagement: la fiducia nel potere dei team auto-organizzati. Proprio per questo, un capo, Scrum Master o Product Owner che pratica il micromanagement rappresenta un problema particolarmente difficile per i team agili.

Ho trovato tre domande utili per affrontare i micromanager:

Chi?

La prima domanda è "Chi?". Chi subisce il micromanagement? Se sei tu a subirlo, ma il resto dello Scrum Team no, questo potrebbe indicare che qualcuno è preoccupato per le tue prestazioni. In tal caso, devi lavorare sulle tue prestazioni e migliorare la percezione che questo Stakeholder ha di te.

Se, invece, l'intero team è sottoposto a micromanagement, questo comportamento è probabilmente attribuibile allo Stakeholder stesso.

Per scoprire se solo tu o tutto il team siete colpiti dal micromanagement, dovresti annotare per uno o due Sprint su quali aspetti il micromanager si concentra particolarmente. Protocolla tutte le attività di micromanagement, in modo da poter riesaminare questi dati in seguito e scoprire chi ne è concretamente interessato.

Quando?

Tenere un protocollo del micromanagement ti aiuterà anche a rispondere alla seconda domanda: quando si verifica il micromanagement?

Il micromanagement si verifica piuttosto prima o dopo un meeting? Ad esempio, il Product Owner potrebbe uscire stressato ogni martedì dalla telefonata con il cliente e avere quindi una maggiore tendenza al micromanagement. Oppure lo Scrum Master tende al micromanagement il giorno prima del meeting mensile con il VP Engineering.

A volte le persone tendono al micromanagement in un determinato momento della giornata. Un mio ex capo tendeva al micromanagement soprattutto prima della sua prima tazza di caffè.

Altri ancora tendono al micromanagement in determinati momenti dell'iterazione. Forse una persona con cui hai a che fare tende particolarmente al micromanagement durante gli ultimi giorni di un'iterazione, perché diventa nervosa e si chiede se tutto sarà completato. Anche in questo caso, dovresti protocollare queste informazioni per poter riconoscere eventuali pattern in seguito.

Uso una tabella con le seguenti colonne:

Data: La data specifica (es. 8 marzo 2017). Questo di solito non rivela pattern, ma ti permette di riesaminare i dati quando vuoi ricordare cosa stava succedendo nell'organizzazione in quel momento.

Giorno della settimana: Il micromanagement potrebbe verificarsi solo in determinati giorni della settimana (es. il venerdì). Per questo dovresti annotare il giorno della settimana.

Giorno nello Sprint: Per riconoscere se il micromanagement si verifica regolarmente in un determinato momento dello Sprint, annota a quale giorno dello Sprint si è verificato. Può essere semplicemente "Giorno 3" oppure "7/10" per indicare che si tratta del settimo giorno in uno Sprint di 10 giorni.

Ora: Annota anche l'orario (es. 10:15).

Chi è stato colpito dal micromanagement: Ha riguardato te stesso, l'intero Scrum Team o un collega del team?

Di cosa si trattava: Annota in questa colonna di cosa si trattava il micromanagement.

Il contesto: C'erano eventi particolari nello Sprint, nel progetto o nell'organizzazione nello stesso periodo? Il micromanagement si è verificato subito prima o dopo un meeting? Quale meeting era? E cosa stava succedendo in generale durante l'iterazione?

Note: Annota qui tutto ciò che ritieni importante in relazione al micromanagement. Come esempio serve la tabella seguente.

Perché?

Dopo aver protocollato le attività di micromanagement per alcune settimane, è il momento di porsi la terza domanda: perché si è verificato il micromanagement?

Esamina il tuo protocollo alla ricerca di pattern. Cerca di trovare i fattori scatenanti.

Forse il tuo Product Owner tende al micromanagement dopo il meeting settimanale con il suo capo.

Forse il tuo superiore diretto tende al micromanagement alla fine del mese, quando deve scrivere un report per il suo capo.

Sulla base di questi pattern, dovresti cercare di avviare conversazioni costruttive con le persone interessate. Con grande probabilità non avrai successo se dici semplicemente: "Per favore, smettila con il micromanagement!" Cerca invece di parlare con loro di ciò che li preoccupa e quindi della causa di questo comportamento.

Una volta identificate alcune delle cause del micromanagement, dovresti essere in grado di prevederle e eliminarle in futuro.

Prevedere ed eliminare i fattori scatenanti

Se riesci a prevedere un comportamento indesiderato attraverso un'osservazione attenta, dovresti lavorare all'eliminazione dei fattori scatenanti. Spesso lo si ottiene avvicinandosi proattivamente al micromanager e fornendogli informazioni.

Se, ad esempio, il tuo Product Owner è regolarmente stressato dopo il meeting settimanale con il capo e ricade nel micromanagement, siediti con il Product Owner prima di questo meeting. Assicurati che il tuo Product Owner sia ben informato e preparato per il meeting con il capo.

Avvicinati attivamente agli Stakeholder inclini al micromanagement e fornisci loro le informazioni necessarie. Cerca di farlo poco prima che si verifichi il rispettivo fattore scatenante. In questo modo ti assicuri che queste persone abbiano tutte le informazioni importanti o se le ricordino.

Stai però attento a non creare nuovi processi onerosi per te stesso. Hai però il controllo sulla relazione con lo Stakeholder (o capo) se offri attivamente informazioni, invece di aspettare finché non ti vengono chieste e doverti poi adattare ai tempi degli altri.

Alcune persone sono irrecuperabili

Anche con questi consigli, non sarai sempre in grado di eliminare ogni forma di micromanagement. Alcuni Stakeholder sono micromanager incorreggibili. I consigli qui elencati ti aiuteranno però a ottenere più controllo sulla maggior parte delle situazioni e a renderle quindi più sopportabili.

Questo testo proviene dal blog di Mike Cohn ed è stato tradotto in italiano.

Cos'è la produttività

=> Sfatiamo i più grandi miti sulla produttività.

Prioritizzazione e obiettivi a medio termine

=> Scopri come puoi prioritizzare meglio come Product Owner.

Processo decisionale nel team

=> Ecco come arrivare più velocemente a decisioni migliori con Scrum.