L’organizzazione agile è una strutturazione ottimale per aziende basate più sulla tecnologia dell’informazione e sulla rete, che non sulle catene di montaggio, le gerarchie a molti livelli, la compartimentazione a silos. 

Un’azienda agile è snella, ha pochi livelli gerarchici, tutti comunicano, cooperano, condividono informazioni, obiettivi, responsabilità e meriti, i capi non sono controllori di procedure e detentori di potere, ma sono i facilitatori, i serventi dei gruppi di lavoro, che durante i cicli produttivi non vanno disturbati. 

Quello che conta è l’output che esce da ogni ciclo produttivo, un output concreto, funzionante, utilizzabile. Anche quando si tratta di qualcosa di immateriale, come l’esito di una riunione, dalla riunione deve uscire un report, un promemoria, una relazione, un pezzo di progetto. Il concetto di base è proprio la completezza e funzionalità dell’output: se è l’indirizzo di una persona, deve essere completo, se manca il numero civico non è utilizzabile. Il responsabile di quell’indirizzo può procurarselo come vuole, ciò che conta è avere l’indirizzo completo e verificato entro il termine stabilito. Quindi non è importante il processo o la procedura, ma il risultato, ciò che ne esce alla fine.

Il manager che si basa sul comando e controllo vigila sui processi, a volte li stravolge con richieste “urgenti”, ma non dà l’importanza dovuta a ciò che viene fuori alla fine. Il “servant manager” agile mette a proprio agio i suoi collaboratori, concorda con loro le cose da fare, le caratteristiche, i termini di consegna, ma poi li lascia fare senza interferire, fino a quando consegnano il prototipo da testare o da sottoporre al cliente. Se il cliente chiede modifiche e aggiustamenti dopo aver provato l’output, queste diventano i compiti del prossimo ciclo produttivo. In tal modo non si fa una progettazione rigida a monte, ma si organizza una serie di cicli produttivi che arrivano ad un prodotto completo – ma mai definitivo, perché sempre pronto ad essere aggiornato e modificato con i feedback provenienti dall’uso – in modo flessibile, organico, naturale.

Ed è proprio agli organismi viventi che l’organizzazione agile assomiglia, non alla macchina delle strutture industriali del primo novecento. Organismi che vivono in ambienti complessi adattandovisi in modo ecologico, sistemico. In un organismo vivente come un corpo umano non è il cervello che controlla ciò che deve fare il fegato o il cuore: essi svolgono i loro compiti in modo autonomo, e lanciano segnali solo quando c’è qualcosa che non va. Solo allora il cervello interviene consultando un medico o somministrando una medicina, con lo scopo di farli funzionare bene, non di imporre il suo potere e la sua autorità.

Questo è l’unico modo per gestire l’imprevedibilità e la turbolenza che caratterizzano l’orlo del caos, la zona di frontiera in cui non c’è più l’ordine delle vecchie abitudini, ma non si è ancora nell’ingestibilità totale del caos.

A differenza degli open space e dei capannoni con le lunghe catene di montaggio, la produzione agile avviene in una stanza chiusa dove lavora insieme tutto il team incaricato. All’inizio di ogni ciclo si fa una riunione con tutti gli stakeholder, dal responsabile del team, all’intermediario fra produzione e cliente, ad altri portatori di interessi come collaboratori esterni o distributori. Nella riunione si stabiliscono le caratteristiche dell’output, della cosa concreta che deve venir fuori da quel ciclo di lavorazione, e la scadenza temporale in cui il ciclo deve concludersi. Una volta iniziato il ciclo, il team di sviluppo funziona come una scatola nera: visto da fuori non si sa che cosa stia facendo, se stia lavorando o no. Nessuno può disturbarlo, neanche le massime autorità dell’organizzazione, per non compromettere la serenità e l’efficienza del lavoro.

L’output deve essere qualcosa di funzionante, di utilizzabile. Se è un insieme di dati, questi devono essere tutti verificati e attendibili. Se è un pezzo di software, deve produrre i risultati per cui è stato scritto. Se è una pagina web, devono funzionare tutti i link e le icone dei menu e delle barre di navigazione.

La metodologia agile è stata adottata inizialmente per progetti informatici, per poi estendersi a tutta l’organizzazione. Il progetto agile si adatta a processi che prevedono output incerti, come programmi gestionali software o siti web che non hanno mai un aspetto definitivo immutabile, ma cambiano in corso d’opera in base a collaudi, aggiornamenti, debug, e addirittura escono sul mercato in versioni che verranno aggiornate nel tempo in base ai feedback di beta-tester ed utilizzatori finali, o ad ulteriori progressi tecnologici che offrono soluzioni nuove più efficaci.

Il progetto agile di software si basa su quattro principi:

1. Gli individui e le interazioni più che i processi e gli strumenti.
2. Il software funzionante più che la documentazione esaustiva.
3. La collaborazione col cliente più che la negoziazione dei contratti.
4. Rispondere al cambiamento più che seguire un piano.

La filosofia agile è ancora poco usata nelle organizzazioni, specialmente in quelle grandi, burocratiche, poco tecnologiche. Le resistenze dipendono soprattutto dalla scarsa capacità di delega di leader iper-controllanti e autoritari, all’eccessivo attaccamento a programmazioni a cascata, o all’opposto al vivere alla giornata in balia della cosa più urgente da fare, alla pretesa di applicare metodi agili a progetti ad output certo come la costruzione di un palazzo, che si prestano di più ad essere gestiti con metodi tradizionali.