Quando si parla di Agile in un’azienda software, si pensa quasi automaticamente agli sviluppatori: Sprint, backlog, Kanban e retrospettive sono strumenti che siamo abituati ad associare alla progettazione e allo sviluppo di un software.
In Antos, però, l’Agile non si ferma all’area tecnica (dove viene applicato da anni).
Anche team con attività molto diverse tra loro, come Marketing, Amministrazione e Help Desk, utilizzano tecniche agili per organizzare il proprio lavoro, definire le priorità, pianificare e migliorare continuamente il modo in cui lavorano.
La cosa interessante è che non esiste un modello identico per tutti.
Gli strumenti sono comuni, ma ogni team li ha adattati alle proprie attività e alle proprie esigenze.
Vediamo allora cosa significa, concretamente, lavorare Agile in Antos anche dove non si scrive una riga di codice.
Tutto parte dal backlog
Marketing, Amministrazione e Help Desk hanno lavori, obiettivi e quotidianità molto diversi. Ma c’è un punto di partenza comune: ogni team ha il proprio backlog (l’elenco delle attività da pianificare).
È qui che vengono raccolte, sotto forma di stories, le attività che il team dovrà svolgere.
Per il Marketing una story può riguardare una campagna adv o l’organizzazione di un evento.
Per l’Amministrazione, un’attività di controllo di gestione, di gestione dei clienti per incassi o dei fornitori per pagamenti.
Per l’Help Desk, una nuova installazione o la realizzazione di un articolo per la Knowledge Base.
Tutte queste stories vengono gestite in YouTrack, lo strumento che utilizziamo per pianificare le Sprint e rendere visibile il lavoro dei team.
📌 Il backlog, però, non è una lista di cose da fare da svuotare il più velocemente possibile.
È il punto da cui il team parte per scegliere le attività su cui concentrarsi e stabilire insieme le priorità.
Dal backlog alla Sprint: decidere su cosa concentrarsi
Avere molte attività da fare non significa poterle – o doverle – affrontare tutte contemporaneamente e di corsa per arrivare a dire “ho fatto tutto”.
Per questo il lavoro viene organizzato in Sprint che, da noi, durano due settimane.
Durante la pianificazione, il team seleziona dal proprio backlog le stories su cui lavorerà nella Sprint successiva. Le stories selezionate entrano così nella Sprint e vengono organizzate nella Kanban del team.
Ed è proprio guardando le Kanban dei diversi team che si vede quanto uno stesso metodo possa adattarsi a lavori molto differenti. Ogni team ha infatti le proprie categorie di stories.
🔵 Nel Marketing, per esempio, le attività sono organizzate in categorie come eventi, HubSpot, sito web, campagne adv, magnet, articoli, inbound marketing, formazione e pre-sales.
🔵 In Amministrazione troviamo invece fatturazione attiva e passiva, ordini clienti e fornitori, pianificazione finanziaria, rapportini di consulenza, provvigioni, incentivi, gestione contabile, incassi e pagamenti, banche, controllo di gestione e presenze.
🔵 Nell’Help Desk la Kanban riflette ancora un’altra quotidianità: gestione ticket, nuove installazioni, articoli per la Knowledge Base, test, formazione e Video Academy.
📌 Tre team, tre lavori completamente diversi.
Lo stesso principio: rendere il lavoro visibile, scegliere le priorità e sapere su cosa ci stiamo concentrando.
Ed è forse proprio qui che si capisce meglio cosa significa per noi lavorare Agile: non applicare una procedura uguale a tutti, ma utilizzare un metodo comune adattandolo alla realtà di ciascun team.
La Sprint è pianificata e ci aiuta a mantenere il focus
Una Sprint dura 14 giorni e definisce le attività su cui il team ha deciso di concentrarsi. Questo, però, non significa che non ci siano imprevisti. Gli imprevisti fanno parte della quotidianità di qualsiasi team.
Una nuova richiesta, un’attività urgente, una priorità che emerge all’improvviso: succede nel Marketing, in Amministrazione e, naturalmente, nell’Help Desk.
Ma lavorare Agile non significa cambiare continuamente programma per inseguire ogni nuova richiesta. Anzi, per noi uno dei vantaggi della Sprint è proprio quello di proteggere la pianificazione.
Una volta definite le attività, ogni team ha davanti a sé un percorso chiaro per i successivi 14 giorni e cerca, per quanto possibile, di rispettarlo.
Quando arriva una nuova richiesta, quindi, non entra automaticamente nella Sprint in corso.
Se può aspettare, viene inserita nel backlog e valutata in fase di pianificazione, eventualmente come priorità della Sprint successiva.
Se invece può essere gestita senza compromettere quanto già pianificato, il team può decidere di inserirla. E naturalmente ci sono situazioni in cui una nuova esigenza è davvero urgente e non può aspettare: in quel caso la pianificazione viene rivista.
La differenza rispetto a un lavoro organizzato semplicemente “a richiesta” è proprio questa: non interrompere ciò che stiamo facendo ogni volta che arriva qualcosa di nuovo, ma valutare consapevolmente quando è davvero necessario cambiare priorità.
Le vere urgenze esistono e possono modificare la Sprint, ma non tutto ciò che arriva dopo diventa automaticamente urgente.
Alla fine della Sprint arrivano review e retrospettiva
Ogni Sprint si chiude con la review: guardiamo le attività pianificate, quelle completate e quelle che, eventualmente, non siamo riusciti a portare a termine.
Poi arriva la retrospettiva. Ed è qui che, dalle attività, spostiamo l’attenzione sul modo in cui abbiamo lavorato.
Ogni membro del team assegna un voto da 1 a 5 a cinque aspetti della Sprint:
Soddisfazione · Teamwork · Qualità · Velocità · Goal
Non valutiamo quindi soltanto quanto siamo riusciti a fare. Ci chiediamo anche come abbiamo lavorato insieme, quanto siamo soddisfatti del risultato, con quale qualità e velocità abbiamo lavorato e quanto siamo riusciti a raggiungere gli obiettivi che ci eravamo dati.
Quando emergono valutazioni da 1 a 3, ci fermiamo a capire cosa non ha funzionato e soprattutto cosa possiamo fare concretamente per migliorare nella Sprint successiva.
Da qui nascono le iniziative del team: cose nuove da iniziare a fare, pratiche che stanno funzionando e che vogliamo continuare, oppure modalità di lavoro che decidiamo di eliminare.
📌 La retrospettiva, quindi, non serve semplicemente a dire cosa è andato bene o male.
Serve a valutare anche azioni concrete per migliorare la Sprint successiva.
In fondo, è proprio questa la logica Agile: provare, osservare, confrontarsi e migliorare.
Dalla retrospettiva al cambiamento: tre esempi concreti
Le iniziative che emergono durante le retrospettive non rimangono sulla carta. Possono diventare piccoli o grandi cambiamenti nel modo in cui lavoriamo.
Nel Marketing, ad esempio, durante le retrospettive è emersa la difficoltà di mantenere focalizzate alcune riunioni che coinvolgevano anche altri team: poteva capitare che il confronto si spostasse su attività aggiuntive o che non si arrivasse mai a una vera chiusura. Da qui la decisione di introdurre un’agenda con gli obiettivi della riunione e individuare un responsabile con il compito di guidare il confronto e mantenerlo focalizzato su quegli obiettivi.
In Amministrazione, per fare un altro esempio, durante una retrospettiva il team si è reso conto che alcuni processi richiedevano troppo tempo. Da questa osservazione sono nate analisi e proposte di miglioramento che hanno portato anche ad automatizzare alcune operazioni all’interno del software gestionale. Il risultato? Meno tempo dedicato ad attività ripetitive e processi più veloci.
Nell’Help Desk, invece, in una delle ultime retrospettive il team ha individuato un’altra opportunità: non disperdere le informazioni e le soluzioni raccolte durante le installazioni e gli aggiornamenti dei software. È nata così l’iniziativa di trasformarle, quando possibile, in articoli della Knowledge Base, creando nel tempo una documentazione sempre più ricca e utile sia per il team sia per i clienti.
Sono tre esempi molto diversi, ma partono dallo stesso principio: valutare come stiamo lavorando, proporre cosa può essere migliorato e trasformare il confronto in un’azione concreta (o una nuova modalità di lavoro).
Lavorare Agile significa anche avere voce sul proprio lavoro
In Antos Backlog, Sprint, Kanban e retrospettive non sono solo modi per organizzare attività e priorità.
Significano lavorare con obiettivi chiari, confrontarsi con il proprio team e avere la possibilità di proporre nuovi modi di fare le cose.
Perché chi vive ogni giorno un processo – ad esempio una campagna marketing, un processo amministrativo o una richiesta di assistenza – è spesso anche la persona più adatta a capire come migliorarlo.
È questo il miglioramento continuo che cerchiamo di portare avanti: osservare, confrontarci, provare e rendere il nostro modo di lavorare sempre più efficace.
Ti piacerebbe lavorare in un team in cui puoi contribuire non solo alle attività, ma anche al modo in cui vengono organizzate e migliorate?
👉dai un’occhiata alle posizioni aperte e inviaci la tua candidatura. Ti aspettiamo!