Spesso i team con cui lavoro stanno piuttosto attenti ad evitare sprechi di tempo, cercare di evitare riunioni inutili, sostituire tool che ci rallentano, scegliere le tecnologie che ci possono rendere più efficienti..
A livello micro, pensa nel lavoro dello sviluppatore quanta parte della giornata viene spesa a fare valore aggiunto (mani sulla tastiera) in confronto al tempo speso in riunioni/discussioni/pause. Forse e' il 50%, se va bene. Poi pensa, del tempo che si suppone a valore aggiunto, con le mani sulla tastiera, quanto tempo viene perso a guardare lo schermo in attesa che l'applicazione riparta o che i test girino, o a riportare l'applicazione nello stato che ti serve per fare una certa prova. Sono tempi a volte dell'ordine del minuto, ripetuti decine e centinaia di volte durante la giornata, che portano via agli sviluppatori una fetta del loro tempo migliore, quello in cui si suppone che facciano valore aggiunto!!!
Che il valore aggiunto è mani sulla tastiera è una supposizione forte, a volte valida, ma dipende dai contesti.
Poi non dico che ottimizzare gli strumenti di sviluppo sia tempo perso, anzi, però in contesti piccoli dove puoi alzare lo sguardo più facilmente ad un livello globale puoi trovare spesso modo di rendere togliere lavoro dal team di sviluppo, creano situazioni "self-service" per gli altri team. Immagina anche banalmente Continuous Delivery al posto che attendere che i sistemisti facciano il deploy, se vuoi rimanere nell'ambito di sviluppo.
Efficienza di flusso. Da quando sono incappato in questo articolo di Hammarberg [http://www.marcusoft.net/2018/03/a-simple-diagram-on-flow-efficiency.html] faccio sempre riflettere le persone, anche visivamente, su quanto del loro lavoro sia composto da attese (nel lavoro della conoscenza si parla di un 85% di attesa...).
Come giustamente sottolinei le fonti di attesa possono essere molteplici e di diverso tipo, quindi raramente c'è una soluzione unica per ridurre i tempi di attesa.
Anzi, di solito la reazione "di pancia" è proprio quella di aggiungere persone, che però migliora solo marginalmente i tempi di lavorazione, lasciando intatti (o allungando) i tempi di attesa (vedi sopra, ottimizzare il 15% quando dovresti erodere il'85% non ha molto senso...).
Sicuramente visualizzazione e categorizzazione delle dipendenze sono passi preliminari e fondamentali: come dico sempre, l'organizzazione la tocchi come ultima cosa (e nessun team in natura è davvero cross-funzionale e autonomo...quindi le dipendenze da qualche parte le hai sempre).
Sulla visualizzazione spesso ho usato dependency spider (https://medium.com/@businessanalysishub/spider-dependency-17b5a63116b0) o dependency matrix: quest'ultima può essere usato sia per dipendenze tra diversi team che tra team e componenti di un prodotto/servizio/piattaforma (parlo sempre di realtà grandi, ovviamente). Lo spider si presta anche a situazioni più semplici.
Sulla dependency matrix ti condivido alcune varianti e anche una idea di "strategia" per la risoluzione delle dipendenze (nel mio esempio categorizzate in dipendenze da risorse - es. ci mancano persone o non abbiamo le persone con le competenze necessarie - oppure è una interdipendenza operativa - es. siamo bloccati se team X o fornitore Y non fa certe cose).[https://www.dropbox.com/s/o3u0uqxnmuhyp3c/Dependency%20Matrix.pdf?dl=0]
I modi per risolvere queste dipendenze variano da "hard" a "soft": il primo step è sempre mapparle e categorizzarle, per poi magari avere una board dedicata alla risoluzione delle dipendenze che viene aggiornata settimanalmente.
Le soluzioni poi possono andare verso l'hard e stabile (cambiamo l'organizzazione) o restare sul soft e temporanea (un comitato di risoluzione dipendenze).
Esternalizzare la risoluzione dei colli di bottiglia con un tool è sicuramente una opzione che definirei "medium-hard": occhio a non trasformare il debito tecnico in debito organizzativo 🙂
Nella mia esperienza, la reazione di pancia e' di iniziare un'altra attivita' mentre che aspetti! E voi mi insegnate che nemmeno questo aiuta, anzi. Come si fa a convincere che spesso e' meglio aspettare invece che iniziare una nuova attivita'? Trucchi, consigli, esperienze?
io non ho soluzioni spaziali, però generalmente mi assicuro che le attività bloccate abbiamo la label "bloccato" e che rimangano in doing.. e se insisti a tenerle lì le persone iniziano ad avvertire il fastidio di avere cose incomplete e bloccate in mezzo ai piedi, agli standup o iteration meeting..
(ah, e spesso kanban usate anche da team che fanno cose diverse dallo sviluppo)
Forse sottovaluti la capacita' di assuefazione... e' come il codice, c'e' chi considera normale lavorare con codice che per me e' insopportabilmente orrendo, ma per loro e' la normalita' e se patiscono fastidio, e' inconsapevole o comunque pensano che non ci sia una maniera migliore
Credo che stiamo parlando dello stesso problema ma da due contesti molto differenti..
Nella mia esperienza di aziende piccole, spesso startup, non mi è capitato di incontrare la problematica che mi racconti, o nel caso era molto leggera ed il fatto di partecipare ai rituali bastava per mettere l'attenzione su certe cose.
Poi ovviamente ogni situazione/ogni team è una cosa diversa.. ma credo tu ne stia affrontando una particolarmente complessa.
A livello micro, pensa nel lavoro dello sviluppatore quanta parte della giornata viene spesa a fare valore aggiunto (mani sulla tastiera) in confronto al tempo speso in riunioni/discussioni/pause. Forse e' il 50%, se va bene. Poi pensa, del tempo che si suppone a valore aggiunto, con le mani sulla tastiera, quanto tempo viene perso a guardare lo schermo in attesa che l'applicazione riparta o che i test girino, o a riportare l'applicazione nello stato che ti serve per fare una certa prova. Sono tempi a volte dell'ordine del minuto, ripetuti decine e centinaia di volte durante la giornata, che portano via agli sviluppatori una fetta del loro tempo migliore, quello in cui si suppone che facciano valore aggiunto!!!
Che il valore aggiunto è mani sulla tastiera è una supposizione forte, a volte valida, ma dipende dai contesti.
Poi non dico che ottimizzare gli strumenti di sviluppo sia tempo perso, anzi, però in contesti piccoli dove puoi alzare lo sguardo più facilmente ad un livello globale puoi trovare spesso modo di rendere togliere lavoro dal team di sviluppo, creano situazioni "self-service" per gli altri team. Immagina anche banalmente Continuous Delivery al posto che attendere che i sistemisti facciano il deploy, se vuoi rimanere nell'ambito di sviluppo.
Pietro, secondo me un esempio da portare alla ribalta potrebbe essere Iubenda.
ah, interessante, non ci avevo pensato a loro... grazie!
Efficienza di flusso. Da quando sono incappato in questo articolo di Hammarberg [http://www.marcusoft.net/2018/03/a-simple-diagram-on-flow-efficiency.html] faccio sempre riflettere le persone, anche visivamente, su quanto del loro lavoro sia composto da attese (nel lavoro della conoscenza si parla di un 85% di attesa...).
Come giustamente sottolinei le fonti di attesa possono essere molteplici e di diverso tipo, quindi raramente c'è una soluzione unica per ridurre i tempi di attesa.
Anzi, di solito la reazione "di pancia" è proprio quella di aggiungere persone, che però migliora solo marginalmente i tempi di lavorazione, lasciando intatti (o allungando) i tempi di attesa (vedi sopra, ottimizzare il 15% quando dovresti erodere il'85% non ha molto senso...).
Sì, l'articolo parla esattamente dello stesso problema.. e propone la classica soluzione del team crossfunzionale, che è ottima in diversi casi..
Per le aziende piccole però credo la soluzione di usare (o fare) tool che rendano le persone più autonome è più efficace spesso.
Oltre a team crossfunzionali e self-service, ti è capitato di usare altre strategie per risolvere le dipendenze tra team?
Sicuramente visualizzazione e categorizzazione delle dipendenze sono passi preliminari e fondamentali: come dico sempre, l'organizzazione la tocchi come ultima cosa (e nessun team in natura è davvero cross-funzionale e autonomo...quindi le dipendenze da qualche parte le hai sempre).
Sulla visualizzazione spesso ho usato dependency spider (https://medium.com/@businessanalysishub/spider-dependency-17b5a63116b0) o dependency matrix: quest'ultima può essere usato sia per dipendenze tra diversi team che tra team e componenti di un prodotto/servizio/piattaforma (parlo sempre di realtà grandi, ovviamente). Lo spider si presta anche a situazioni più semplici.
Sulla dependency matrix ti condivido alcune varianti e anche una idea di "strategia" per la risoluzione delle dipendenze (nel mio esempio categorizzate in dipendenze da risorse - es. ci mancano persone o non abbiamo le persone con le competenze necessarie - oppure è una interdipendenza operativa - es. siamo bloccati se team X o fornitore Y non fa certe cose).[https://www.dropbox.com/s/o3u0uqxnmuhyp3c/Dependency%20Matrix.pdf?dl=0]
I modi per risolvere queste dipendenze variano da "hard" a "soft": il primo step è sempre mapparle e categorizzarle, per poi magari avere una board dedicata alla risoluzione delle dipendenze che viene aggiornata settimanalmente.
Le soluzioni poi possono andare verso l'hard e stabile (cambiamo l'organizzazione) o restare sul soft e temporanea (un comitato di risoluzione dipendenze).
Esternalizzare la risoluzione dei colli di bottiglia con un tool è sicuramente una opzione che definirei "medium-hard": occhio a non trasformare il debito tecnico in debito organizzativo 🙂
Nella mia esperienza, la reazione di pancia e' di iniziare un'altra attivita' mentre che aspetti! E voi mi insegnate che nemmeno questo aiuta, anzi. Come si fa a convincere che spesso e' meglio aspettare invece che iniziare una nuova attivita'? Trucchi, consigli, esperienze?
io non ho soluzioni spaziali, però generalmente mi assicuro che le attività bloccate abbiamo la label "bloccato" e che rimangano in doing.. e se insisti a tenerle lì le persone iniziano ad avvertire il fastidio di avere cose incomplete e bloccate in mezzo ai piedi, agli standup o iteration meeting..
(ah, e spesso kanban usate anche da team che fanno cose diverse dallo sviluppo)
Forse sottovaluti la capacita' di assuefazione... e' come il codice, c'e' chi considera normale lavorare con codice che per me e' insopportabilmente orrendo, ma per loro e' la normalita' e se patiscono fastidio, e' inconsapevole o comunque pensano che non ci sia una maniera migliore
Credo che stiamo parlando dello stesso problema ma da due contesti molto differenti..
Nella mia esperienza di aziende piccole, spesso startup, non mi è capitato di incontrare la problematica che mi racconti, o nel caso era molto leggera ed il fatto di partecipare ai rituali bastava per mettere l'attenzione su certe cose.
Poi ovviamente ogni situazione/ogni team è una cosa diversa.. ma credo tu ne stia affrontando una particolarmente complessa.