Agile design planning

Nei mesi scorsi ho applicato l’#Agile design planning nella progettazione di prodotti #hardware all’interno di uno studio di progettazione. L'esperienza è stata molto positiva per i progettisti perchè si sono sentiti molto coinvolti nella autogestione visuale dei progetti, permettendo di rispondere meglio alle variazioni dei requisiti richieste dai clienti.

Uno dei feedback più interessanti che ho ricevuto da uno di loro è che la pianificazione visuale ha consentito loro di distribuire il carico in funzione della capacità disponibile e di gestire più efficacemente ed efficientemente più progetti in parallelo. Ma vengo al dettaglio dell'esperienza.

L'Agile design e la co-progettazione con il cliente: un caso-studio

È stata la prima volta che ho applicato l'approccio #agile per lo sviluppo hardware in uno studio di progettazione ed è stata una sfida complessa: una risposta corretta al problema da risolvere non esisteva e le soluzioni canoniche non erano applicabili. Siamo entrati, secondo il framwork #Cynefin, nel dominio delle soluzioni emergenti, dove è possibile trovare una correlazione tra causa ed effetto solo a posteriori, dopo aver creato lo spazio per sperimentazioni.

Gli elementi di complessità

Nel caso specifico questo studio sviluppa progetti di prodotti complessi in materiale plastico per conto di importanti aziende. E lo fanno in co-progettazione con i clienti fino alla loro industrializzazione, necessaria per la produzione di serie e sviluppando le attrezzature di stampaggio. Inoltre i progetti subiscono frequenti modifiche per l’aggiornamento dei requisiti da parte dei clienti.

Qual è l'impatto di questo processo?

E' che ci sono continui arresti in attesa di istruzioni o di approvazioni accompagnati da ripartenze nello sviluppo. A complicare la cosa, poi, è che la progettazione è legata al macchinario del fornitore che stamperà il prodotto e il fornitore viene spesso deciso durante le sviluppo del prodotto stesso.

Quale risposta dare?

Di fronte a questa variabilità la scelta naturale della direzione dello studio è stata quella di assegnare un solo progettista per ciascun progetto. I progettisti gestiscono più progetti in parallelo, perché passano da un progetto all’altro, quando sono in attesa di informazioni o approvazioni dal cliente. Il numero dei progetti in lavoro, inoltre, è superiore al numero delle persone, per i continui Stop e Go appena descritti. Questo consente grande flessibilità accompagnata però dalla difficoltà di accelerare lo sviluppo quando necessario.

Vale infatti in tutti i tipi di progetti la legge di Brooks nata dall’osservazione che, nel mondo del software, “aggiungere manodopera a un progetto in ritardo lo ritarda ulteriormente“.

Per la mia esperienza, questa legge si applica anche ai progetti di prodotti hardware, tanto da farmi affermare che l’aggiunta di più persone, è spesso inutile e persino controproducente.

Questo è dovuto al fatto che le nuove persone, che non conoscono il progetto, richiedono a quelle che già lavorano nel progetto, le informazioni loro necessarie, rallentando lo sviluppo.Vi è inoltre un tempo tecnico di apprendimento per entrare pienamente nel progetto e un maggior tempo per gli incontri del team di sviluppo.

L'auto-organizzazione Agile dei team

• La prima cosa che mi ha colpito, applicando principi e metodologia Agile, è stato l'aumento quasi immediato dello spirito di iniziativa e
• l'emersione nel team di progettisti di una maggiore predisposizione al supporto e aiuto reciproco.

Scomporre il lavoro (un #backlog via via sempre più definito e "fatto a fette sottilissime") che prima facevano solo con il titolare, è diventata una cosa normale, così come la stima del lavoro è diventata una cosa naturale. L'impatto più visibile per loro è stato nella gestione delle priorità e dei colli di bottiglia, che ora è diventata autonoma a tutti gli effetti. Ecco la sintesi di quanto mi scrive il titolare del cambiamento introdotto:

Direi che ci sta aiutando molto perché, mai come in questo anno, ho visto cambiamenti di programma continui da parte dei clienti. 

…la settimana scorsa, sapendo che andava in ferie, ha fatto (senza la mia presenza e di sua iniziativa) lo sprint review il venerdì anziché il lunedì e così quando sono rientrato ho trovato già riunione fatta (fantastico davvero!).

Comunque ottimo sistema di programmazione e ottimi risultati, programmazione veloce, semplice, ottimo quadro d’insieme, nessuna perdita di tempo in cose che tanto cambieranno.

Si tratta proprio di un cambio di atteggiamento mentale delle persone, di #mindset. E questo ha i suoi effetti pratici e vincenti per

• le persone dei #team, che sono così molto più motivate
• e anche per il titolare, che può occuparsi maggiormente dei rapporti commerciali con i clienti e dello sviluppo dell’azienda.