In attesa di cosa?
Prendo a prestito il famoso episodio del “In ferie da cosa?” di Marchionne per crearne un meme e introdurre il tema di oggi, che non sono le ferie ma la colonna “in attesa” della vostra board Kanban — o qualsiasi approssimazione di Kanban stiate usando.
Tangenzialmente questo è anche un modo per provare a rispondere ad una delle domande che mi viene fatta più frequentemente, e che faccio più frequentemente a me stesso: “Come possono le pratiche agili aiutarmi anche se non faccio software?”.
Come possiamo usare, anche parzialmente, Kanban, Scrum o anche farci ispirare da alcuni selezionati principi del manifesto in un tipo di lavoro che non ha un prodotto o servizio software come obiettivo?
Il “dentro” e il “fuori” di una Kanban board
Quando un team fa software o offre un servizio digitale è abbastanza frequente il caso in cui la colonna “in attesa” contenga attività che ricadono abbastanza vicini alla sfera di controllo o influenza del team. Il tempo e l’oggetto dell’attesa è considerabile come una variabile principalmente endogena del flusso di lavoro del team stesso.
Ci sono poi alcune situazioni in cui, quella colonna, “in attesa”, assume un significato diverso.
Queste situazioni sono generalmente caratterizzate da:
- Un team non dedicato, che dovremmo chiamare, più correttamente, “gruppo di lavoro”
- Assenza di un prodotto o un progetto singolarmente o facilmente identificabili
- Un gruppo di lavoro estremamente esteso (fino a 20 o 30 persone)
- Stakeholder coinvolti ad ogni livello dell’organizzazione
- Obiettivi strategici chiari e condivisi, autonomia completa sul day-by-day o week-by-week, obiettivi intermedi e tattici da elaborare
In termini di pratiche agili alcuni di questi elementi che ho appena descrito vengono spesso categorizzati come “positivi”, altri “meno positivi”: Dobbiamo davvero forzare Scrum su un team di marketing? Ha senso parlare di throughput con un gruppo di designer? Dobbiamo davvero ridurre la dimensione del team da 30 a 10 persone perché ci piacciono i team piccoli? Dobbiamo davvero fare un sacrificio rituale agli dèi degli OKR?
Ma, soprattutto, che cosa significa quella colonna “In attesa” in questo specifico contesto? In questo caso infatti l’attesa e l’oggetto dell’attesa non sono considerabili come variabili endogene del flusso di lavoro del team, ma spesso sono esogene.
In questi casi — che, sia ben inteso, rappresentano una percentuale considerevole della realtà — mi sento di proporre una pratica forse poco ortodossa: prendi quella colonna “in attesa” della tua board, e tienila da parte. Trasforma qualsiasi titolo tu abbia messo sui tuoi cartellini “in attesa” in una decisione da prendere.
Parole, parole, parole (e decisioni)
Come dicevo prima, non tutti i team hanno il lusso o la necessità di farsi approvare user stories dal proprio product owner o mantenere stabile la propria velocity: se non hai capito quello che ho appena scritto, sei nel posto giusto – se invece hai capito quello che ho scritto sei comunque nel posto giusto.
La maggior parte dei team di questo mondo dipendono in qualche modo dallo sviluppo di software, ma non fanno software: l’applicazione di pratiche e metodi che derivano da quel mondo risulta aliena e disfunzionale.
Occorre quindi usare pratiche agili “quanto basta” per fare emergere quello di cui ha davvero bisogno un team: saper distinguere tra cosa è lavoro regolare del team, cosa invece è un problema, o un errore, o una ipotesi, o una decisione fa parte di un percorso per niente banale che può essere facilitato da alcune, e sottolineo “alcune”, pratiche agili, ma non solo.
Qualche tempo fa ho sentito dire che “Agile senza Lean è una paio di braccia senza cervello”: si può essere più o meno d’accordo con questa forte affermazione, che io estenderei in “Agile senza un processo decisionale chiaro, trasparente, condiviso, è un paio di braccia senza cervello”.
Parlare di come si prendono le decisioni in un gruppo ci porta fuori dal “seminato Agile” ma è un tema essenziale da affrontare anche e soprattutto se l’oggetto delle nostre attività non è solo ed esclusivamente sviluppare software.
“Fare Scrum” o “Fare Kanban” diventa assolutamente irrilevante se siamo sempre bloccati da decisioni che risiedono ad di fuori dalla sfera di controllo e di influenza del nostro gruppo di lavoro, o, peggio ancora, se non conosciamo a fondo il nostro processo decisionale.
Facilitare l’escalation
Escalation non è una parola brutta, eppure per molti motivi tendiamo ad associare una connotazione negativa a questa parola: probabilmente nel nostro passato e nel nostro presente abbiamo assistito ad episodi di escalation gestiti male.
Escalation fatte di nascosto. Escalation fatte via email. Escalation con componenti di ricatto. Escalation che cadono nel vuoto. Escalation che vengono rifiutate. E poi: l’escalation endemica, l’escalation come best practice e come unico modo per mandare avanti i progetti.
Nell’ottica di avere un processo di escalation condiviso, formale, regolato, trasparente, come dovrebbe essere, avere una review settimanale delle decisioni da prendere aiuta sia il gruppo di lavoro nel prendere le decisioni in autonomia, sia a portare in evidenza tutte quelle decisioni su cui non siamo, o pensiamo di non essere, autonomi.
È il primo passo verso la scoperta di quello che potrebbe essere considerato un value stream decisionale che in molte realtà è altrettanto se non più importante del value stream operativo.
Si fa presto a dire “autonomia”
Qualche tempo fa ho ascoltato qualcuno che prendeva la famosa citazione di Tolstoj, da Anna Karenina:
Tutte le famiglie felici si somigliano; ogni famiglia infelice è invece infelice a modo suo.
La trasformava, ribaltandola e applicandola alle aziende, così:
Tutte le aziende infelici si somigliano; ogni azienda felice è invece felice a modo suo.
Questo è per sottolineare ancora una volta come spesso siamo vittime dei nostri metodi: individuare i problemi di una azienda è molto spesso l’aspetto più facile e il risultato più immediato che ci offrono gli approcci agili.
Tutte le aziende soffrono di un certo periodo di latenza nelle proprie decisioni, ogni singola azienda dovrà però intraprendere un proprio percorso per trovare il proprio modo di prendere decisioni in maniera più rapida, puntuale ed efficace.
Ciao, sono Davide e sono un consulente organizzativo. Mi occupo di coaching, formazione e consulenza su pratiche agili. Miglioro il modo in cui le aziende organizzano i propri progetti, prodotti e servizi e aiuto i team che li sviluppano ad essere più autonomi.
Se vuoi ricevere articoli come questo via email, ti puoi iscrivere qui sotto.
Davide Tarasconi 