Per una consulenza con un cliente stavo ripassando alcuni concetti di Kanban dal libro Agile Project Management with Kanban di Brechner e ti voglio proporre questo estratto.
Pianificazione (estratto)
La pianificazione dei grandi progetti in Microsoft inizia tipicamente dal basso verso l’alto e si conclude dall’alto verso il basso. Ogni piccolo team elenca il lavoro che vorrebbe svolgere. Questi elenchi vengono raccolti a livello di gruppo e poi revisionati a livello di divisione e di organizzazione. Parallelamente, ricerche di mercato, pianificazione del prodotto, pianificazione aziendale e design definiscono il lavoro di alto livello che vorrebbero assegnare ai feature team. Tutti questi input vengono trasformati in una visione di prodotto, un’architettura e un calendario. Il calendario viene poi adattato in base a dipendenze e altri fattori mentre viene fatto ridiscendere attraverso le divisioni, i gruppi e i team. Alla fine, ogni team dispone di un elenco ordinato di attività.
La pianificazione dei grandi progetti richiede spesso alcuni mesi e viene quindi usata solo per la pianificazione a lungo termine e per progetti di grande portata, come Windows 10 o il lancio iniziale di Xbox One. Quando Microsoft distribuiva prodotti confezionati ogni pochi anni, quei mesi di pianificazione venivano anche usati per concedere ferie, lavorare su prototipi, analizzare problemi del prodotto, migliorare l’infrastruttura e ridurre varie forme di debito tecnico.
Bottom-up
Probabilmente nella tua realtà non si tratta di orchestrare decine di team, ma di pianificare le attività di uno solo, magari con un margine operativo ridotto o nullo. Se lavori su progetto o a commessa, la possibilità di scegliere cosa fare semplicemente non esiste: il lavoro arriva già impacchettato, con obiettivi, tempi e spesso anche soluzioni predefinite.
Tuttavia, il punto da cogliere nell’estratto di Brechner non è la scala, ma la dinamica: sono i team a proporre il piano, non il management a imporlo. La revisione avviene a posteriori, con la pianificazione che emerge dal basso e viene successivamente armonizzata ai livelli superiori. Questo è in contrasto netto con il modello top down prevalente, in cui la direzione definisce roadmap e scadenze e gli engineer si limitano ad adeguarsi.
Ma la pianificazione bottom up è l’unica che abbia senso: solo chi scrive codice è in grado di stimare il lavoro in modo attendibile. Chi è distante dall’esecuzione opera inevitabilmente per approssimazioni grossolane o arbitrarie.