Di cosa hai bisogno per avere successo con Agile?

L'adozione agile può fallire in alcune organizzazioni, ho anche lavorato per un'azienda in cui la cascata era l'unico (il vero) modo, ma solo perché hanno provato Agile su un progetto e hanno fallito.

Quando chiesi alle persone che ancora ricordavano che (ero un giovane) ero chiuso a morte, come se stessi ricordando loro un brutto incubo che è realmente accaduto.

Non so perché il progetto sia fallito. Ci sono risorse trovate sul web perché Agile fallisce in alcune aziende, ma la ragione è principalmente economica. Quindi ho pensato di chiedere qui alcuni feedback.

Quali sono i motivi per cui l'adozione Agile fallisce in alcune organizzazioni? Oppure, un altro modo di dirlo ... Cosa serve per avere successo con Agile?

Sono necessari manager, clienti e sviluppatori per comprendere e supportare il modo di pensare Agile e i metodi Agile. Più in dettaglio:

• Il management deve sentirsi a proprio agio nel sentire la verità, al contrario di ciò che tradizionalmente si aspettano di sentire (cioè "sì, il progetto è sulla buona strada" per 11 mesi ... poi improvvisamente "oops, dobbiamo ritardare la scadenza di alcune settimane ... erm, mesi ... erm ... "alla fine). Devono anche essere a proprio agio nel lasciare che ciascuna parte faccia (e si prenda la responsabilità) del proprio lavoro. Soprattutto, che gli sviluppatori devono prendere decisioni e stime tecniche. Quindi nessun controllo stretto e micro-gestione.
• I clienti devono capire che Agile richiede il loro profondo e continuo coinvolgimento nel processo di sviluppo, non solo "effettuando l'ordine", quindi ritirando la consegna alcuni mesi dopo. Devono inoltre essere a proprio agio con la mancanza di una specifica di requisiti fissi e l'apparente mancanza di impegno da parte del team di sviluppo nel fornire ciò per cui erano stati inizialmente richiesti.
• Gli sviluppatori devono avere dimestichezza con l'assunzione di responsabilità, prendere decisioni, comunicare apertamente e lavorare in gruppo. Cioè nessuna "proprietà del codice", nessun "cowboy solitario" e nessuna incolpevole incolpazione degli altri per problemi che possono essere risolti dal team stesso.

Nella mia esperienza, è il primo punto che spesso si cela dietro progetti Agile falliti, ma anche gli altri due possono causare problemi.

Aggiornare

Per "gestione" intendo non solo il project manager diretto, ma anche livelli più alti. Come giustamente osservato da @Michael, alcune parti più o meno esterne (ad esempio QA o un assegnatore di attività esterno) possono anche influenzare il successo / fallimento dei progetti Agile, ma suppongo che ciò sia possibile solo se il loro rispettivo leader lo consente, e / o se le responsabilità e le linee di comando non sono chiare all'interno dell'organizzazione.

Hai bisogno:

• Persone che vogliono essere molto aperte e oneste . La visibilità è tutto perché hai bisogno di fiducia attraverso tutti i tipi di confini di livello.
• Clienti e manager che vogliono davvero sentire la verità.
• Le persone che sono disposte e in grado di ridefinire i loro ruoli per soddisfare ciò che è necessario in questo momento .
• Libertà di cambiare i processi che non funzionano in questo momento .
• Le persone che sono disposte ad ammettere errori e ad annullarli .
• La capacità di mettere insieme costruire e testare ambienti a piacimento . (Questo è più importante e più costoso di quanto le persone gli attribuiscano credito.)
• Tutte le lavagne che puoi riempire con le pareti.

Sembra così semplice, ma molti di questi sono grandi richieste in questo settore.

Un progetto agile fallirà molto spesso quando un giocatore chiave rifiuta di essere agile, o (peggio) quando qualcuno non è sinceramente interessato al successo del progetto o lo sabota apertamente. Quest'ultimo può uccidere qualsiasi progetto (come una serie di altre cose), ma i processi agili offrono alle persone una maggiore flessibilità e ciò include la flessibilità necessaria per svolgere politiche distruttive.

Esempi:

• Il QA insiste sul fatto che i clienti non possono vedere il software a meno che non abbia superato un ciclo di test manuale di un mese
• La direzione impone scadenze non realistiche
• Il cliente rifiuta di dare la priorità ai requisiti ("hanno tutti la massima priorità!")
• Qualcuno che non è un stakeholder immediato ma ha un peso politico continua ad assegnare compiti lunghi e non correlati a un membro chiave del team, e il project manager non può impedirlo.

Posso solo dare il mio consiglio dalla mia esperienza personale.

Un datore di lavoro che avevo completamente fallito in Agile. Il lavoro è stato svolto su base ad hoc, i test erano inesistenti e i requisiti sono stati documentati nelle e-mail e nei verbali delle riunioni. L'unico metodo di sviluppo utilizzato era l'anarchia, o "codifica incendi e dimentica". L'implementazione di un qualche tipo di metodo di ingegneria del software sarebbe stata impossibile in quanto gli sviluppatori erano troppo oberati di lavoro per creare un qualche tipo di software di gestione dei progetti di tracciabilità delle storie.

In un altro datore di lavoro, il nostro team aveva un membro eroico che cercava disperatamente di stabilire alcune best practice Agile: avevamo una scheda Kanban, tracciabilità dei problemi, usavamo TDD e BDD (anche se non Agile in sé, tendono ad essere presenti nei gruppi Agile) . Sfortunatamente, mancavano cose come i punti della storia, le sessioni di stima, la pianificazione della capacità, i grafici di burn-down, i grafici della velocità - il tipo di cose utili per la gestione dei progetti Agile che consentono al lavoro di scorrere senza intoppi. Come un classico sintomo di Agile che va storto, quando la nostra tavola Kanban è diventata troppo piena, abbiamo comprato una tavola più grande: /

Il posto in cui mi trovo attualmente utilizza i punti di trama come un modo di pianificare la capacità con iterazioni di due settimane, TDD, standup giornalieri, retrospettive temporizzate iterazione per iterazione e accoppia la programmazione sulla maggior parte delle cose. Questo è il risultato del buy-in di gestione totale e della formazione del cliente.

Pensa che, affinché Agile abbia successo in un'azienda, sono necessari i seguenti elementi:

• Project manager che comprendono Agile e che useranno gli strumenti in modo appropriato.
• Sviluppatori che comprendono Agile, che sono aperti e onesti, con la disciplina richiesta da Agile
• Buy-in dal client. Devono riconoscere i vantaggi di Agile ed essere disposti ad ascoltare i consigli dei loro sviluppatori in merito a ciò che può essere sviluppato in un determinato arco di tempo.

EDIT: è anche fondamentale assicurarsi di avere una buona comprensione di -perché- cose come stand-up giornalieri e brevi iterazioni sono utili.

Le mie esperienze con il fallimento di Agile non hanno avuto nulla a che fare con l'economia ma con la politica aziendale / dipartimentale / personale.

A livello personale, ci sono semplicemente alcune persone le cui personalità si scontreranno. Costringerli in un team Agile, o peggio ancora in un team di programmazione associato, aumenterà la loro avversione l'uno verso l'altro fino a un punto di ebollizione. Questo può diventare molto sgradevole, molto rapidamente e provocare cose come atti di sabotaggio degni di un reality show, trasformando le riunioni di mischia in una squadra di fuoco circolare o anche peggio.

Oltre a ciò, c'è la gestione dello sviluppo. L'ho visto andare storto in due modi diversi.

Il primo è "cargo cult Agile" in cui il manager insiste nel seguire il manifesto e qualunque classe / libro / sito web leggano esattamente senza capire il motivo per cui e quando usarli e quando improvvisare. È come se il manager Agile stesse aspettando che accadesse la magia perché stanno seguendo esattamente l'incantesimo. Questa implementazione procrustea di Agile può comportare una serie di problemi che porteranno al fallimento del progetto.

L'altro è "Agile In Name Only", in cui vengono utilizzati termini come sprint e scrum, ma sono in realtà solo etichette su vecchie pratiche come la micro-gestione, la disonestà che va su e giù per la catena di comando, lunghi incontri di stato inutili e altre cose del genere . I progetti falliscono come una volta, ma ora Agile può essere incolpato piuttosto che una cattiva gestione.

Oltre a ciò c'è una mancanza di buy-in da parte del cliente / cliente del progetto. Queste persone avranno le loro priorità dipartimentali e possono resistere a lavorare con un team di sviluppo a meno che non sia chiarito che è una parte essenziale del loro lavoro da parte del loro management. Ciò può essere aggravato dalla politica dipartimentale o dalle politiche aziendali. Ad esempio, sia le operazioni che il marketing hanno contribuito a un progetto e il tuo team finisce per girare le ruote poiché le due parti non possono essere d'accordo su nulla. Un altro esempio è quando la politica aziendale sulla gestione dei tempi e la fatturazione causa conflitti. In realtà ho scoperto che i clienti esterni erano più facili da gestire rispetto a quelli interni. Gli piaceva l'attenzione che ricevevano dal processo e sapevano che stavano guadagnando valore per i loro soldi.

"Agile" IMO fallisce quando non c'è un buy-in all'ingrosso delle pratiche. Quello che voglio dire è che Agile si affida al "cliente" (in genere un altro dipartimento o manager) comprendendo che:

1. Non sanno al 100% cosa vogliono fare il software, anche se pensano di farlo
2. Non hanno idea di quanto tempo ci vorrà per completare, anche se pensano di farlo
3. Gli verrà detto quanto tempo ci vorrà e dovrà accettarlo o ridurre le funzionalità per rispettare una scadenza
4. Dovranno scegliere le funzionalità per ogni iterazione e non otterranno l'applicazione completa e completa al 100% in un colpo solo.

Tutte queste sono cose molto difficili da inghiottire per la maggior parte dei manager, e IMO è il primo motivo per cui è difficile fare Agile - i manager sono abituati a dire "Sarà fatto entro x date" e averlo "Magicamente" fatto entro quella data (dopo che gli sviluppatori hanno impiegato 80 ore settimanali) ed è un 180 capire che il team di sviluppo ti dirà che questo progetto sarà realizzato in 3 mesi e l'unica scelta che hai è accettarlo o ridurre i requisiti per ottenere fatto prima.

In secondo luogo, ci deve essere fiducia nel team di sviluppo. Andando di pari passo con il n. 1 sopra, pochissimi manager sembrano in realtà fidarsi dell'opinione delle persone assunte come esperti; se uno sviluppatore dice che un progetto richiederà x quantità di tempo, e x è più di quanto la gestione pensi che ci vorrà, non è mai un caso di "Non so come scrivere software, quindi lo sviluppatore probabilmente ha ragione" è più " Quei programmatori che non vogliono niente vogliono andare a lavoro, quindi hanno detto che ci vorranno 3 mesi ".

In terzo luogo, il team di sviluppo deve essere dietro Agile; ciò significa non tagliare gli angoli e non ignorare il feedback costante e le domande di "È giusto? Quando x accade cosa dovrebbe fare Y?". Anche se non segui TDD o Pair Programming, il tuo team di sviluppo deve essere abbastanza competente per seguire i processi agili (ad esempio sprint, iterazioni). Ciò implica avere un lead / manager in grado di stimare correttamente le attività e capire che non è necessario dare priorità a ogni funzione, è OK avere un arretrato di lavoro e non si deve sovraccaricare le persone.