Ogni volta che David Heineimer Hansson (in arte DHH) o Jason Fried scrivono, si avverte un fremito nella comunità agile.

I due co-fondatori di Basecamp hanno sempre condiviso con trasparenza quelli che sono i loro processi per lo sviluppo dei prodotti e della loro organizzazione del lavoro, tanto da scriverne ben tre libri, una guida e innumerevoli articoli al riguardo.

L’approccio che DHH e Fried hanno alla organizzazione lavoro può essere definito iterativo e incrementale, ma non agile — per un dettaglio su cosa intendo quando dico “iterativo e incrementale, ma non agile” consiglio la lettura di questo ottimo articolo di Johanna Rothman.

Questo non significa che, al di là del tono saccente, tirannico e antipatico con cui spesso i due co-fondatori di Basecamp si esprimono, non ci siano approcci che meritano di essere presi in considerazione — giusto per chiarire, io sono tutt’altro che un fan di DHH e Fried.

È successo di nuovo, il fremito nella comunità agile, quando DHH ha scritto recentemente un articolo intitolato “Manage process before people” — Gestisci il processo prima delle persone.

Questo sembra all’apparenza andare in direzione opposta rispetto ad uno dei valori del Manifesto Agile, ovvero quello che dice “People and interactions over processes and tools” — Persone e interazioni prima dei processi e degli strumenti.

La prima considerazione che mi sento di fare è che i valori del Manifesto Agile sono espressi in maniera relativa e non assoluta, e questo ce lo ricorda anche il corollario ai quattro valori che spesso ci dimentichiamo di leggere: “[Ovvero] fermo restando il valore delle voci a destra [es. processi e strumenti, nota mia], consideriamo più importanti le voci a sinistra [es. persone e interazioni, nota mia]”.

Suggerisco sempre un certo livello di morbidezza quando si interpretano i valori e principi del Manifesto, come mirabilmente sintetizzato qui sotto.

fonte: LinkedIn

Questo evidentemente non significa che un team o un’azienda debba a fare meno di qualsiasi processo o strumento.

E infatti la seconda considerazione che mi sento di fare, invece di indignarsi e dire “nel Manifesto Agile non c’è scritto così!”, è di entrare nel merito di quello che DHH ha scritto relativamente ai processi di Basecamp e del motivo per cui sono strutturati così.

DHH fa una lista di cinque processi che Basecamp utilizza per fare in modo che le persone possano fare i manager part-time mentre dedicano parte del loro tempo al design e lo sviluppo (una esigenza comunissima alla stra-grande maggioranza delle aziende al mondo):

  1. Daily meeting asincroni: i membri di un team rispondono ad un questionario automatico che fa la domanda “Cosa farai oggi” a inizio giornata e la domanda “Cosa hai fatto oggi” alla fine della giornata. Niente Daily Scrum sincroni, è un abominio o una necessità? Quante volte per le persone “fare agile” si riduce a fare un Daily Scrum senza capo né coda, che dura tutto fuorché 15 minuti?

  2. Planning circoscritto: le decisioni di pianificazione si prendono una volta al mese. Basecamp lavora su cicli di sviluppo di sei settimane (+ due di “cooldown”), questo significa che ci sono circa sei momenti all’anno in cui si devono prendere decisioni su cosa sviluppare nella iterazione successiva. Siccome i momenti di pianificazione sono sempre estremamente critici, indipendentemente dal tipo di approccio scelto, agile o non-agile, trovo che limitarli arbitrariamente nella frequenza e nello scopo sia una soluzione legittima e di buon senso.

  3. Il lavoro è una collina: Basecamp si è inventata la visualizzazione “a collina” attraverso cui le persone possono indicare dal punto di vista dell’effort dove si trovano con maggiore efficacia rispetto a percentuali di progresso e Gantt. Commento personale: secondo me la Hill Chart è un colpo di genio.

  4. Timeboxing e gestione dello scopo: Basecamp non fa sprint come previsto da Scrum, ma comunque ha dei cicli di sviluppo di sei settimane entro le quali ogni singolo membro del team deve prendere delle decisioni riguardo a compromessi di scopo e qualità di quello che sta sviluppando, diminuendo la necessità di supervisione da parte del manager. Anche qui nulla di nuovo sotto il sole, si applica il principio di project management del “triangolo di ferro” invertito: dati tempistica e budget fissi, l’unico vincolo libero resta quello dello scopo, da negoziare.

  5. Review e mentoring: il compito di fare review delle attività fatte non spetta al o alla manager della persona ma ad un suo collega, che spesso spesso svolge questa attività sotto forma di mentoring, soprattutto per le persone più junior. Questo è un processo di decentralizzazione e delega che sembra sminuire il ruolo delle review plenarie come previste da Scrum (anche se nell’articolo non si affronta e in Basecamp ci sono anche l’equivalente delle review al termine delle iterazioni) ma sembra enfatizzare il ruolo di mentoring, che mi sembra un ottimo proposito.

Tutti questi piccoli-grandi processi mi sembrano ottimi modi di risolvere un problema specifico, esplicitamente dichiarato da DHH, ovvero: dover trovare un modo per garantire la sopravvivenza di tutte le persone che in Basecamp fanno i manager part-time, evitando di sovraccaricare la loro agenda di riunioni e atti di micro-management non ritenuti necessari.

Questi non sono processi per “fare agile” e nemmeno per “fare Scrum”: sono processi che Basecamp — ricordiamolo, azienda molto piccola e di prodotto, con opinioni estremamente forti su come organizzare il lavoro di sviluppo — ha adottato per semplificare la vita alle persone che ricoprono anche il ruolo di manager.

La terza considerazione che vorrei fare riguarda proprio il tema dei processi. “Processo” non è una parola brutta, anzi, se proprio dovessi scegliere una espressione da togliere dal linguaggio comune c’è proprio “gestire le persone”.

Si gestiscono “le cose” (come i processi) e non le persone: con le persone possiamo sviluppare delle relazioni (più o meno) collaborative. Qui sotto uno schema che illustra molto bene questo concetto di differenza tra leadership e management, spesso poco chiaro.

fonte: Psychological Safety

Sui processi propongo queste domande:

  1. Siamo sicuri di averli?

  2. Siamo sicuri di averli dove servono?

  3. Siamo stati in grado di co-progettarli e comunicarli con e a chi ne beneficerà?

  4. Applicando in maniera costruttiva i valori del Manifesto Agile: quali sono i processi attraverso cui riusciamo a far crescere le persone e migliorare le interazioni?

DHH stesso puntualizza mirabilmente che occorre separare quello che è gestione di processo da quello che è sviluppo delle relazioni con le persone, ci sono molti motivi estremamente validi per cui un o una manager dovrebbe parlare, dare e richiedere feedback e incontrarsi con i membri del proprio team, ma c’è anche una parte di queste interazioni che possono essere demandate a buoni processi:

“None of this is to say that managing people is bad. There are plenty of good reasons for why want to check-in with people directly, to help guide them in their career, to provide redirecting feedback if they’re off track. 

But it is to say that these functions of management can be divorced from much of the other routine supervision work that fills the weeks of a manager under the traditional paradigm.”

David Heineimer Hansson — “Manage process before people”

Immagine di testata: Jakob Owens