In questo articolo ti voglio parlare della mia esperienza personale nei riguardi delle metodologie agili. Se sei interessato a saperne di più su Agile e Lean ti consiglio questo articolo: Metodologie Agili e Lean: come migliorare la tua azienda!

La mia giornata tipo

Quando sono andato a lavorare per Lean IT Consulting non capivo abbastanza quanto veniva fatto in termini di gestione. Il tutto mi sembrava immensamente strano e nuovo. Oggi posso dire che mi fa strano vedere aziende che non agiscono allo stesso modo ed aver visto parecchi altri colleghi di aziende o nuovi clienti rimanere increduli e dubbiosi sul modo di operare che ho seguito costantemente per 2 anni come dipendente.

Normalmente il modo di operare era il seguente: ogni mattina dalle 9.00 alle 9.30 si fa standup. Quindi tutti in piedi, in cerchio, ci si racconta quello che abbiamo fatto il giorno prima e cosa andremo a fare. Normalmente non viene utilizzato come strumento di controllo, strumenti come Jira e le Kanban board rendono già l’idea delle attività di ogni dipendente.

Il punto focale è: fai notare se c’è qualcosa di nuovo da condividere con i colleghi per migliorare il team e fai notare se hai problemi con qualcosa e se bisogna cambiare alcune stime.

Timidezza

All’inizio ero molto timido al riguardo. Un po’ non capivo bene il senso, un po’ mi sentivo controllato, un po’ mi creava vergogna dire “trovo difficoltà a fare questo o quello”. Con il passare del tempo mi sono abituato ed anzi vorrei che fosse così in tutte le aziende.

Gli errori che commettevamo erano quelli di parlare ore durante lo standup delle novità così di come risolvere problemi. Lo scopo dello standup però non è questo. Si enunciano i problemi e le novità e poi si organizza:

• O un meeting aziendale quando c’è più tempo
• O si comunica direttamente alla persona che ci può aiutare se ha un po’ di tempo per discutere di un problema e fare pair programming

Il Lunedì

Una delle cose più distruttive della mia vita erano i planning, eppure adesso credo che siano una condizione necessaria per far convivere un team e per far credere a tutti nella mission aziendale. A differenza di aziende dove qualcuno decide 100 attività da smistare, nel planning ci si siede tutti insieme ad un tavolo per discutere di cosa si deve fare e per inserire le attività in una kanban board.

Anche in questo caso era massacrante all’inizio perché i planning finivano tardi la sera ed iniziavano alle 9.00 di mattina. Con il tempo tutti i team ci passano. Le persone si vergognano meno di dare le stime e si impara a discutere di ogni attività senza entrare troppo nel particolare. Nel frattempo i dipendenti interagiscono, danno le stime, sentono quello che stanno producendo come se fosse un loro figlio!

Alla fine di ciascun planning la nostra kanban board era pronta.

Il Venerdì

Al venerdì normalmente l’obiettivo era finire di programmare alle 17:00 così da poter fare la retrospective. Durante la retrospective parlavamo di diversi argomenti:

• Cosa è andato bene questa settimana
• Dove ci siamo migliorati
• Cosa bisogna migliorare
• Come abbiamo gestito gli imprevisti
• Come rendere il planning più realistico e migliorare con le stime
• ecc.

Anche in questo caso all’inizio la timidezza era tanta, ma l’ottica giusta per affrontare questi meeting sta nel non aver paura di esprimersi e farlo sempre per l’interesse del team. Spesso si ha paura di dire che qualcosa sia andato male per paura di colpevolizzare qualcuno o di sminuire un lavoro. Nella realtà dei fatti, con l’educazione, bisogna saper accettare critiche e fare critiche, ma sempre portando idee e cercando di essere propositivi. Il punto non è litigare, ma aiutare il team a lavorare più sereno.

La retrospective ha un momento adatto per essere fatta: la chiusura dello sprint.

Scrum

Planning, retrospective e standup sono state le 3 chiavi fondamentali per seguire uno scrum che ci rendeva incredibilmente produttivi. Azienda piccolina, ma multinazionali come clienti!

Da ogni planning usciva uno sprint. Abbiamo fatto diverse prove tra cui sprint da 2 settimane e sprint da 1 settimana. Normalmente con lo sprint da 2 settimane si lavora bene. Una volta definite le user stories in fase di planning si preparavano anche le attività con le stime andando a raccogliere attività dal backlog o ad aggiungere attività al backlog. Dopo di che la nostra lavagna era costituita dalle seguenti colonne:

1. TO DO
2. In Progress
3. Done
4. In Test
5. Tested
6. Ready For Production

L’obiettivo era arrivare a fine settimana con tutte le attività in fase Done, dopo di che nella settimana con il rilascio tra le attività in TO DO c’era quella relativa ai tests. I Tests venivano fatti solitamente da chi non aveva lavorato sull’attività da testare e l’obiettivo era di portare più attività possibili in Ready For Production.

Il Dialogo

Il dialogo nel team è difficile da trovare in molte aziende, ma il tutto sta in chi sei e come ti poni. Il dialogo deve rimanere qualcosa di naturale e questo aiuta il team ad essere sempre al corrente di qualsiasi cosa accade. Tutti sono interessati allo stesso modo di ogni attività e vogliono che venga conclusa.

Appena viene trovato un bug, durante la fase di test, viene comunicato allo sviluppatore dell’attività. Oppure a seconda dell’importanza si discute tutti insieme sul da farsi. In questo caso un’attività può entrare nello sprint anche se inserita a sprint iniziato.

Con il tempo ci si abitua a mettere tra le attività quella relativa alla risoluzione bug. Un’azienda che ha un anno di vita riesce benissimo a calcolare in media quanto tempo si perde in test, assistenza e risoluzione bug ed ad un certo punto si riesce anche ad allocare dello spazio già in fase di planning.

Parlarsi ogni mattina, risolvere i problemi e fare pair programming aiutano chi è più timido o meno capace ad aver più coraggio, a sapersi far aiutare, ed a capire come svolgere il suo compito.

Pair Programming

E’ un termine relativo alla programmazione, ma sono convinto che sia attuabile per ogni tipo di azienda. Il pair programming serve per far sì che due persone programmino insieme. E’ ovvio che non si parla di usare 2 tastiere e scrivere sullo stesso file. Ma vuol dire stare qualche ora con un collega e scrivere un po’ di codice a testa.

I benefici sono molteplici:

• Non conosco il codice, vedo come si muove il mio collega, imparo e poi tocca a me scrivere con lui a fianco
• Conosco bene il codice ed insegno le logiche ed i pattern usati al mio collega
• Conosciamo bene il codice, ma la soluzione da implementare al momento ci sembra ostica ad entrambi, mettiamoci a scrivere insieme, ragioniamo insieme e capiamo insieme se siamo sulla strada giusta

Fare questo tipo di attività ti serve per conoscere strumenti che tu non utilizzi, ma che ti potrebbero essere utili (ho imparato una marea di shortcut in questo modo 🙂 ).

Il pair programming è utile anche per il dialogo. Forse è stata una delle cose che più mi ha aiutato a stringere rapporti con i colleghi quando avevo appena iniziato questo percorso.

Non aver paura

Dico a te, capo team, manager o qualsiasi cosa sei!

Sento spesso, in altre aziende, che tutto questo sembra un’immensa perdita di tempo. E io, che sto quì a parlartene, mica ci guadagno qualcosa 😀 . In termini di unione del team e di visione ci guadagnerai sicuramente. All’inizio perderai anche un po’ di tempo, più del necessario, ma tutti nel team conosceranno il software che stanno producendo e la gente non penserà più solo al suo orticello.

Con calma vedrai che i dipendenti saranno più entusiasti ed allo stesso tempo diminuirai la durata del planning. In cambio avrai molta organizzazione ed un processo di sviluppo rapido che consente una grande diminuzione degli sprechi.

Cambiare in corso d’opera, poter vedere ogni settimana come procedere e cambiare le priorità alle attività in maniera condivisa con il team creano risparmio di tempo (una marea di tempo) e maggiore visione complessiva della mission.

Conclusione

Spero di essere stato d’aiuto raccontando la mia esperienza. Non avevamo raggiunto la perfezione sicuramente, ma eravamo avanti anni luce rispetto ad una marea di aziende.

Per saperne di più ti consiglio uno dei libri che ho definito un must have in questo articolo ed è presente in italiano: Partire leggeri. Il metodo Lean Startup: innovazione senza sprechi per nuovi business di successo.

Se vuoi condividere la tua opinione o ai domande lasciami un commento 🙂

Se ti è piaciuto l’articolo seguimi su Facebook e Twitter oppure rimani sempre aggiornato con la newsletter (da 1 a 4 mail al mese!)