Un anno di Kanban (Parte 3)

Mi piace l’odore del Napalm la mattina…

 

Smaltiti i bagordi natalizi (sì, siamo bravini ma lenti), torniamo a noi. Dove eravamo rimasti? Ah sì, parlavamo di fallimenti!

Progetti consegnati in ritardo, obiettivi mancati, budget sforati, team demotivati, mail di avvocati, scuse, migliaia di scuse, montagne di scuse.

“Ti prego, ti prego, non mi uccidere. Ti prego baby, lo sai che ti amo. Non avrei mai voluto lasciarti, non è stata colpa mia. Davvero, sono sincero. Quel giorno finì la benzina. Si bucò un pneumatico. Non avevo i soldi per il taxi! Il mio smoking non era arrivato in tempo dalla tintoria! Era venuto a trovarmi da lontano un amico che non vedevo da anni! Qualcuno mi rubò la macchina! Ci fu un terremoto! Una tremenda inondazione! Un’invasione di cavallette!…”

 

Generalmente al nobile e profondo animo dei commerciali è affidato il delicato e gravoso compito di comunicare al cliente le drammatiche derive assunte dalla commessa. Il capo progetto, una bella mattina, senza lasciar trasparire emozione alcuna, entra nel tuo ufficio. Da quell’anaffettivo grave che è (perché è dimostrato, gli IT non provano sentimenti) ti consegna questa bella novella: “Devi chiamare il cliente, fa parte del tuo lavoro, non t’invidio”. Devi dirgli nell’ordine che:

 

Il dialogo prosegue con commenti che scendono sul personale. Chiaramente quello del cliente:

 

Il capo progetto, senza nessuna comprensione, ti lascia solo.  La stanza lascia spazio a silenzio e sconforto, rimangono solo le tue paure e quella telefonata da fare. Queste dinamiche ormai sono un ricordo del passato, quando si stimavano i progetti dalla genesi sino alla presunta fine, ci si accapigliava per una riga di codice con il cliente, si lavorava a corpo (non al corpo…a corpo).

Domani si va tutti all’Agile Day!

Ma domani sarà sabato! Replicavi con tono fantozziano.

Fa niente, l’azienda viene prima di tutto

Al netto dell’ironia più bassa che si possa spendere all’indirizzo di una metodologia che nei propositi dovrebbe salvarti la vita e di nome fa AGILE  – agile de che…. – ci troviamo un giorno tutti coinvolti in questa gita lavorativa sabatina.

Ecco il resoconto:

 

Al termine di otto estenuanti ore di erudimento, lasciamo l’Alma Mater di Ancona con la percezione, lontana, di poter un giorno firmare un contratto senza aver la chiara e netta sensazione di star compiendo un’enorme e irrimediabile minchiata.

La mia personalissima definizione di Agile trova la più fedele rappresentazione in:

“inizio presto, finisco presto e di solito non pulisco il water…”. 

 

Come a dire:

“S’inizia a lavorare subito, generalmente si finisce in fretta, se siamo stati bravi non facciamo troppi danni cui dobbiamo riparare”.

L’uso del termine agile per riferirsi a metodi di sviluppo software fu introdotto dal Manifesto Agile pubblicato nel 2001.

I principi sottostanti al Manifesto Agile (come dire…non avrai altro Agile all’infuori di me…), sono diventati il nostro vangelo, nostro padre e nostra madre.

Scorriamo e commentiamo (con occhi e lingua biforcuta da account), come in una lenta omelia, i sacri principi del Manifesto agile…

 

Subito e Continuo: Musica per le orecchie un commerciale… Liberi dal giogo delle giornate uomo, a obiettivo unico viene issata la soddisfazione del cliente, il quale non è più costretto ad aspettare giorni, mesi, anni per dare un’occhiata a qualcosa che non comprende neanche minimamente, ma può iniziare da subito a mettere qualcosa sotto i denti (odio le metafore, qui ci stava): un mock up, un’interfaccia grafica, l’installazione di un CMS, ecc.;

Il progetto, infatti, è realizzato per unità incrementali dette iterazioni. Il tempo di sviluppo di ciascuna iterazione è generalmente rarefatto (in media due settimane), fisso e rigorosamente rispettato. Ogni iterazione rappresenta un incremento delle funzionalità del sistema. La lavorazione della prossima iterazione, ha inizio solamente ad approvazione incassata della precedente.

 

I cambiamenti come un vantaggio: estasi pura! Nella vita precedente il cambiamento in corso d’opera era visto come il male assoluto, Lord Broke di Sandokan, la lebbra, la fine. Infiniti e snervanti triangoli capo progetto – account – cliente, calati obtorto collo, nel patetico e a tratti ridicolo, reciproco gioco delle parti. Il progetto, tirato per la giacchetta, non procedeva, lo faceva ma come monco, sfociava in un compromesso squallido e inefficace. Ora – da Agili – è visto con favore…

 

Consegnamo, è già questo è (come dicono i giovani) tanta roba. Lo facciamo di frequente, arrivando a preferire i periodi brevi. Vabbè…ciaone (sempre i giovani).

 

In questo passaggio, quelli del Manifesto l’hanno messa giù un po’ dura. Sovraintendere un’intesa pressoché quotidiana, tra cliente e sviluppatori, nella migliore delle ipotesi porterebbe alla demenza anche il più centrato dei venditori. Vero è però, che è richiesto un frequente e costante confronto tra le parti, per consentire al progetto di rimanere intimamente fedele alle esigenze del committente, evitando pericolose e disfunzionali derive.

 

Le società di servizi come la nostra, affidano le loro sorti agli uomini, non hanno molto altro. Team che lavorano per obiettivi, che hanno autodeterminato i modus di sviluppo. È l’unica strada per ottenere risultati efficaci. Tutto ciò che viene imposto dall’alto sarà avvertito come un’imposizione e sarà svolto in modalità “compitino” e la responsabilità sarà sempre di qualcun altro.

 

Lo sviluppo delle iterazioni, gli atomici dell’Agile, prevede una modalità di lavoro in team e disincentivano l’utilizzo di strumenti tecnologici per comunicare con essere umani che risiedono a 25 cm lineari dalla tua postazione;

 

Se funziona è buono, se non funziona è male. Molto bianco e nero, poco grigio. Ci si misura su un univoco e difficilmente controvertibile metro di valutazione, il lavoro svolto, preordinato di comune accordo con il committente.

 

Secondo il noto adagio “poco e bene”. Stiamo fuggendo da progetti con proiezioni incerte e difficile da sostenere. Le iterazioni condivise con il cliente, devono essere ben definite nei tempi e nei modi, così da non ricadere in pericolose e nefaste derive di lavorazione non sostenibili. Risultato? L’irritante “mi serviva ieri” è quasi estinto.

 

Lavoriamo in un ambiente protetto. Fuori dalla porta dovremmo aver lasciato snervanti discussioni sui tempi, i modi, i costi, elevando a massimo obiettivo la riuscita tecnica e tecnologica del progetto.

 

Montagne di giornate uomo che finiscono non si sa bene dove, rimpalli sulle imputazioni: commerciali, supporto al cliente scatenano cruente guerre intestine, evitare gli sprechi. Stringendo: in Agile si fa, non si parla. E se si scrive, si scrive codice. Non si lavora sul lavoro.

 

Onori e oneri. Lavorare per obiettivi, assunzione di responsabilità, autogestione del team, come a dire “tanto a sbagliare siamo capaci da soli…”.

 

S’impara da se stessi, innescando un circolo virtuoso che non ha mai fine e che genererà una sorta di selezione Darwiniana nelle organizzazioni. Questa metodologia spinge i componenti del team a collaborare e prendere decisioni veloci ed efficaci. Il team vivrà di vita propria, in una dimensione che travalica il singolo:

“Se lanci la maglia, sei fuori”. Mourinho docet.

 

Chiudiamo con i conti della serva. Con questa metodologia, trova impiego anche la formula del “lavoro, guadagno, spendo e pretendo”.

Il cliente al termine di ogni iterazione ha l’opportunità di:

Meglio di così…

Ti piace il nostro metodo di lavoro? Hai bisogno di sviluppare un progetto AgileContattaci!