Come ha trovato il suo equilibrio il team tecnico folk?

Oggi vi parlerò di come affrontiamo lo sviluppo agile di software in folk.

Se non avete familiarità con lo sviluppo agile di software, esistono alcune ottime risorse sul web. Noi di folk abbiamo deciso di costruire la nostra roadmap tenendo a mente due obiettivi: ritmo e concentrazione.

Per i responsabili tecnici che guidano team composti da 20-50 persone, folk si è dimostrato la soluzione ideale per gestire in modo ottimale sia i flussi di lavoro di sviluppo che le relazioni con i clienti.

👉🏼 Prova folk per organizzare i promemoria relativi ai progetti e agli stakeholder in un unico posto.

A tal fine, abbiamo definito due diversi modi per gestire i nostri progetti:  

• A: Iterazione di 3 settimane che porta al rilascio di una funzionalità importante.
• Tutti gli altri progetti rientrano in un flusso di miglioramento continuo.

La nostra intenzione

A settembre il nostro team tecnico è quadruplicato (siamo passati da 2 a 8 persone). Siamo ancora un piccolo team, ma ci siamo subito resi conto che dovevamo migliorare il nostro sistema di gestione dei progetti. Finora gestivamo il backlog delle attività utilizzando l'approccio Kanban. Era una soluzione semplice e all'inizio funzionava bene. Dopotutto, non è così difficile tenere traccia di 3 o 4 problemi alla volta. Ma con 8 persone ora nel team (e altre in arrivo), questo processo non funzionava più per noi. Questa esperienza rispecchia ciò che molti responsabili tecnici devono affrontare quando il loro team passa da 20 a 50 persone: ecco perché folk diventa essenziale per mantenere la visibilità e il coordinamento in team di sviluppo più grandi.

Quando abbiamo iniziato a pensare a come volevamo che fosse il processo, ecco cosa è venuto fuori:

• Volevamo rilasciare almeno un grande progetto ogni 3 settimane. Dato che stiamo ancora sviluppando il prodotto, è importante continuare a sviluppare e creare funzionalità fondamentali. Abbiamo deciso di puntare su 3 settimane perché 2 settimane ci sembravano troppo poche e 4 settimane troppo lunghe.
• Avevamo bisogno di dedicare un po' di tempo ai miglioramenti continui. Il prodotto che abbiamo realizzato finora è ottimo e ne siamo orgogliosi, ma poiché stiamo creando qualcosa di completamente nuovo (un CRM senza codice), è necessario perfezionarlo costantemente.
• Abbiamo deciso che i progetti non dovevano essere infiniti. Avevamo bisogno di una scadenza definita.

Non è stato facile conciliare questi obiettivi:

• I miglioramenti sono basati sull'ambito. Quando si desidera migliorare qualcosa, solitamente si vuole farlo tutto in una volta. Inoltre, si tende a scoprire altri problemi lungo il percorso. Di conseguenza, è più difficile rispettare le scadenze.
• I progetti sono basati sul tempo. Ma se ci si impegna su date precise, è più difficile rimanere al passo con i miglioramenti basati sull'ambito.

Alla fine, abbiamo deciso che nulla era più importante del ritmo e della concentrazione per raggiungere i nostri obiettivi.

Il ritmo serve a mantenere tutti motivati, assicurando che i progetti non vadano alla deriva. L'obiettivo principale è garantire che rimaniamo efficienti e in grado di mantenere il ritmo. Abbiamo quindi dovuto elaborare il nostro approccio agile allo sviluppo software. Per i responsabili tecnici delle startup che supervisionano team di 20-50 sviluppatori, folk offre il perfetto equilibrio tra monitoraggio dei progetti e gestione degli stakeholder, supportando questo tipo di approccio allo sviluppo disciplinato e incentrato sul ritmo.

👉🏼 Prova folk per gestire i promemoria basati sui contatti con il tuo team e mantenere il ritmo di 3 settimane.

Agilità, sì certo, ma...

Nella maggior parte delle mie esperienze precedenti, gli approcci utilizzati erano Kanban o SCRUM. Si trattava comunque di un miglioramento rispetto ai metodi di lavoro precedenti, ma questi approcci presentavano alcuni punti deboli: Kanban non prevede alcun vincolo temporale, mentre SCRUM sì.

Ho sempre trovato SCRUM fonte di delusione e stress, per due motivi principali:

Classificare i compiti in base alle dimensioni: utilizzare una scala astratta per misurare i compiti porta a una stima errata nel 90% dei casi. La buona notizia è che, poiché si tratta di una scala astratta, è sempre possibile aggirare il sistema e cavarsela. Ad esempio: "Abbiamo detto 5 punti per quello? Impossibile. Credo che intendessimo 13. Rivediamo lo sprint di conseguenza".

Pianificazione: pianificare non è altro che cercare di inserire una certa quantità di punti astratti in un periodo di tempo prestabilito. È qualcosa di molto difficile da prevedere. Dubito di aver mai vissuto uno sprint che sia terminato quando previsto. Gli sprint finiscono sempre prima o, nel 98% dei casi, troppo tardi. Entrambe le opzioni sono negative perché indicano che lo sprint non è stato pianificato correttamente.

Utilizzando il triangolo di ferro, volevamo avere un sistema che avesse sia vincoli di tempo che di portata. Ovviamente, consideriamo le risorse come fisse perché non assumiamo nuovi sviluppatori ogni giorno.

Domande frequenti

Qual è la differenza tra Scrum e Kanban?

Scrum utilizza sprint di durata fissa con ruoli e cerimonie; l'ambito viene pianificato per ogni sprint. Kanban è basato sul flusso con limiti WIP, senza timebox predefiniti. Scegli Scrum per consegne con scadenze precise; Kanban per un flusso continuo e una rapida definizione delle priorità.

Quanto dovrebbe durare un'iterazione agile?

La maggior parte dei team utilizza 1-4 settimane. Scegli una durata adeguata alle dimensioni della funzionalità, alla frequenza delle revisioni e alla capacità del team. Tre settimane spesso consentono di bilanciare l'ambito e il feedback, riducendo al contempo il cambio di contesto. Mantieni la coerenza per creare un ritmo di consegna affidabile.

Come possono i team combinare progetti con scadenze prestabilite e miglioramento continuo?

Flussi separati: fornire una funzionalità principale e definita nel tempo per ogni ciclo, dedicando risorse alle piccole correzioni e al perfezionamento dell'esperienza utente. Utilizzare un controllo rigoroso dell'ambito sul flusso delle funzionalità e una selezione accurata del backlog sul flusso dei miglioramenti per rispettare la pianificazione.

In che modo un CRM può aiutare a gestire lo sviluppo agile?

Un CRM centralizza contatti, stakeholder e feedback da utenti e clienti. Sincronizza le informazioni con il backlog, segmenta le versioni beta e monitora la diffusione. Strumenti come folk collegano il contesto del cliente alla consegna, migliorando la definizione delle priorità.