Burocrati del push, avete vita corta

E sono qui a fare retrospezione dopo che una veloce ricerca nel mio inbox mi ha riportato a galla una mail di cui dovrei un pò vergognarmi:

Ciao gente,

domani si conclude la X iterazione per il progetto Y,
quello che chiude temporaneamente il ciclo di sviluppo.

Non nascondo una certa preoccupazione per i non-feedback ricevuti
l'iterazione precedente, ma al momento è inutile preoccuparsene.

Lascio alcune indicazioni "personali":
@$persona: domani concentrati nell'integrazione di $sistema, testa il
caricamento e visualizzazione di banner SWF sul sito ( frontend e
backend ), integra un sistema di automatizzazione dei metatag ( ne
parliamo insieme ) e rilascia la piattaforma alle 17.50, prima di
andartene dall'ufficio. Per istruirti sul rilascio, ma non è cosa
complicata, ci pensiamo direttamente io e te domani.

Ecco. Push, push, push: che fallimento!

Come factoryphysics ci mostra

in a pull system, releases are authorized.

Dove ho largamente sbagliato io?

Impartendo azioni si cade nella più banale delle trappole, ovvero quella di non permettere alle persone di agire in maniera pull, lasciandole responsabilizzare  ( o meno ) a dovere. In fondo, anche se tu ne sei convinto, non è detto che:

  • una persona sia in grado di assolvere un compito
  • una persona sia in grado di assolverlo bene
  • una persona si senta in grado di assolverlo
  • una persona si senta in grado di assolverlo bene

Secondo erroraccio: ad una persona vengono assegnate, contemporaneamente 4 task, il che rende il WIP, prima di partire, una pipeline già satura.

Terzo errore, potenzialmente letale, quello di assegnare a dei task degli orari ( il casus di cui sopra non lo richiedeva esplicitamente ) specifici assumendo la produttività e la giornata media della persona come elementi assodati, immanenti e in nessuna misura aleatori.

Con me, questo genere di comportamenti hanno avuto, hanno e avranno, vita corta, perchè credendo in determinati principi, valori e metodi non esiterei un minuto a mettere in discussione la mia posizione e la produttività del team all'interno di un sistema push.

Però ci possono essere delle ricadute, o degli sbagli di inesperienza: ne prendo atto e faccio un mea culpa prendendomi, metaforicamente, a pesci in faccia.

nella foto Bam Marghera in non so che contesto :)

So what? Ecco come riformulerei questo veramente cattivo esempio di comunicazione:

[...]

Lascio alcune indicazioni "personali":
@$persona: Ci rimangono 3 attività e un deploy da effettuare nella giornata di domani, l'ultima che ci resta a disposizione al momento.
Direi che la priorità fondamentale è di, nel caso riuscissimo ad assolverne almeno un'attività, almeno deployare quella.
Nell'ordine di priorità abbiamo:
* integrazione $sistema ( www.ourissuetracker.it/issue/X )
* test degli SWF ( www.ourissuetracker.it/issue/Y
* automatizzazione metatag ( www.ourissuetracker.it/issue/Z
Per il deploy non ricordo se l'abbiamo mai fatto insieme: nel caso mi fossi dimenticato di fartelo vedere - mea culpa - gli diamo un occhio insieme domani.
Todo claro?

Al di là del tono più gentile risaltano almeno un paio di FTW in questa nuova comunicazione:

  • non si delega, apparentemente, si parla di attività che il team deve compiere ( se poi l'effort erogato dal team domani sarà quello di una persona, magari $persona, è un discorso che esula totalmente )
  • vengono assegnate delle priorità ad ognuna delle attività da svolgere, e vengono elencate in maniera veloce ed efficacie, lasciando ulteriori approfondimenti all'issue tracker di turno o simili
  • $persona non viene istruito sul come deployare, ma gli viene fatto vedere semplicemente ( si, i toni cambiano un bel pò )
  • persona viene stimolata a produrre un feedback ( Todo claro? )

Hai detto niente.