Di cosa hai bisogno per avere successo con Agile?

Hai bisogno di management, clienti e sviluppatori per comprendere e supportare il modo di pensare Agile e i metodi Agile. Più in dettaglio:

• La direzione deve sentirsi a proprio agio con la verità, al contrario di ciò che tradizionalmente si aspettano di sentire (cioè "sì, il progetto è in pista" per 11 mesi ... poi improvvisamente "oops, dobbiamo posticipare la scadenza entro alcune settimane ... erm, mesi ... erm ... "alla fine). Devono anche sentirsi a proprio agio nel permettere a ciascuna parte di fare (e assumersi la responsabilità per) il proprio lavoro. La cosa più importante è che gli sviluppatori devono prendere decisioni e stime tecniche. Quindi niente controllo stretto e microgestione.
• I clienti devono capire che Agile richiede il loro coinvolgimento profondo e continuo nel processo di sviluppo, non solo "fare l'ordine", quindi raccogliere la consegna alcuni mesi dopo. Devono anche sentirsi a proprio agio a causa della mancanza di una grande specifica sui requisiti fissi e dell'evidente mancanza di impegno da parte del team di sviluppo per fornire ciò per cui erano inizialmente richiesti.
• Gli sviluppatori devono sentirsi a proprio agio nell'assumersi responsabilità, prendere decisioni, comunicare apertamente e lavorare in gruppo. Cioè nessun "codice di proprietà", nessun "solitario cowboys" e nessuna infruttuosa colpa degli altri per problemi che possono essere risolti dal team stesso.

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

Aggiornamento

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

Hai bisogno di:

• Persone che desiderano essere aperte e oneste . La visibilità è tutto perché hai bisogno di fiducia su tutti i tipi di limiti di livello.
• Clienti e manager che veramente vogliono ascoltare la verità.
• Persone che sono disposte e in grado di ridefinire i loro ruoli per soddisfare ciò che è necessario adesso .
• Libertà di cambiare processi che non funzionano adesso .
• Persone che sono disposte ad ammettere gli errori e invertirli .
• La possibilità di creare insieme e testare ambienti a volontà . (Questo è più importante e più costoso di quanto le persone danno credito.)
• Tutte le lavagne con cui puoi riempire i muri.

Sembra così semplice, ma molte di queste sono grandi domande in questo settore.

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

Esempi:

• Il QA insiste che i clienti non possono vedere il software se non ha superato un ciclo di test manuale di un mese
• Gestione impone scadenze non realistiche
• Il cliente si rifiuta di dare la priorità ai requisiti ("loro tutti hanno la priorità più alta!")
• Qualcuno che non è uno stakeholder immediato ma ha un peso politico continua a assegnare compiti lunghi e non collegati a un membro chiave del team e il project manager non può impedirlo.

Posso solo dare il mio consiglio dalla mia personale esperienza.

Un datore di lavoro che avevo totalmente fallito in Agile. Il lavoro è stato svolto su una 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 del tipo" ignora e dimentica ". Implementare una sorta di metodo di ingegneria del software sarebbe stato impossibile in quanto gli sviluppatori erano troppo oberati di lavoro per creare una sorta di software per la gestione dei progetti di tracciamento della storia.

In un altro datore di lavoro, il nostro team ha avuto un membro eroico che ha disperatamente cercato di stabilire alcune best practice Agile: avevamo una scheda Kanban, tracciamento di problemi, abbiamo usato TDD e BDD (mentre non Agile in sé, tendono ad essere presenti in Gruppi agili). Sfortunatamente, mancavano punti come story point, sessioni di stima, pianificazione della capacità, grafici di burn-down, grafici di velocità - il tipo di utili risorse di gestione del progetto Agile che consentono al lavoro di scorrere senza intoppi. Come un classico sintomo di errore di Agile, quando la nostra scheda Kanban si è riempita troppo, abbiamo acquistato una scheda più grande: /

Il posto in cui mi trovo attualmente utilizza i punti storia come un modo di pianificare la capacità con iterazioni di due settimane, TDD, standup quotidiani, retrospettive timebox iterazione iterazione e programmazione di coppie sulla maggior parte delle cose. Questo è il risultato del totale coinvolgimento del management e della formazione del cliente.

Pensa che per far sì che Agile abbia successo in un'azienda, hai bisogno delle seguenti cose:

• Project manager che comprendono Agile e che useranno gli strumenti in modo appropriato.
• Gli sviluppatori che comprendono Agile, che sono aperti e onesti, con la disciplina che richiede Agile
• Buy-in dal cliente. Hanno bisogno di riconoscere i vantaggi di Agile e di essere disposti ad ascoltare i consigli dei loro sviluppatori riguardo a ciò che può essere sviluppato in un dato periodo di tempo.

EDIT: è anche fondamentale assicurarsi di avere una buona conoscenza di -why- 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 in cui le personalità si scontreranno. Forzarli in una squadra Agile o, peggio ancora, in una squadra di programmazione accoppiata, intensificheranno la loro avversione reciproca a un punto di ebollizione. Questo può diventare molto sgradevole, molto rapidamente e portare a cose come atti di sabotaggio degni di un reality show, trasformando le riunioni di mischia in una squadra circolare di biasimo o anche peggio.

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

Il primo è il "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 stia aspettando che la magia accada perché sta seguendo esattamente l'incantesimo. Questa implementazione preliminare di Agile può causare una serie di problemi che porteranno al fallimento del progetto.

L'altro è 'Agile In Name Only' dove vengono usate la terminologia come sprint e scrum ma in realtà sono solo etichette su vecchie pratiche come la micro-gestione, la disonestà che va su e giù per la catena di comando, lunghe riunioni di stato inutili e altre cose del genere. I progetti falliscono come prima, ma ora Agile può essere biasimato per questo piuttosto che una cattiva gestione.

Al di sopra è la mancanza di buy-in da parte del cliente / cliente del progetto. Queste persone avranno le loro priorità dipartimentali e possono essere resistenti al lavoro con un team di sviluppo, a meno che non venga chiarito che è una parte essenziale del loro lavoro da parte del management. Questo può essere aggravato dalla politica dipartimentale o dalle politiche aziendali. Ad esempio, sia le operazioni che il marketing sono stati inseriti in un progetto e la tua squadra finisce per girare le ruote perché le due parti non sono d'accordo su nulla. Un altro esempio è quando la politica aziendale sulla gestione e la fatturazione del tempo causa conflitti. In realtà ho scoperto che i clienti esterni erano più facili da gestire rispetto a quelli interni. A loro è piaciuta l'attenzione che hanno ricevuto dal processo e sapevano che stavano ottenendo il valore dei loro soldi.

L'IMO "Agile" fallisce quando non c'è un buy-in all'ingrosso delle pratiche. Quello che voglio dire è che Agile fa affidamento sul "cliente" (tipicamente un altro dipartimento o manager) che comprende:

1. Non sanno al 100% ciò che vogliono che il software faccia, anche se pensano che lo facciano
2. Non hanno idea di quanto tempo ci vorrà per completare, anche se pensano che lo facciano
3. Saranno detti quanto tempo ci vorrà e dovranno accettarlo o ridurre le funzionalità per rispettare una scadenza
4. Dovranno scegliere le caratteristiche di ogni iterazione e non ottenere l'intera applicazione completa al 100% in un solo colpo.

Tutti questi sono cose molto difficili da gestire per la maggior parte dei manager, e IMO il motivo numero 1 per cui è difficile fare Agile - i manager sono soliti dire "Sarà fatto per x data" e averlo fatto "Magicamente" entro tale data (dopo che gli sviluppatori hanno trascorso 80 ore settimanali) ed è un 180 per rendersi conto che il team di sviluppo sta per dirti che questo progetto sarà fatto in 3 mesi e l'unica scelta che hai è accettarlo o ridurre i requisiti per farlo prima.

In secondo luogo, ci deve essere fiducia nel team di sviluppo. Andando di pari passo con il numero 1 di cui sopra, pochissimi manager sembrano fidarsi dell'opinione di persone assunte come esperti; se uno sviluppatore dice che un progetto richiederà x quantità di tempo, e x è più di quanto la direzione pensa che prenderà, è mai un caso di "Non so come scrivere software, quindi lo sviluppatore probabilmente ha ragione "è molto di più" Quegli sviluppatori buoni a nulla vogliono rinunciare al lavoro, così hanno detto che ci vorranno 3 mesi ".

In terzo luogo, il tuo team di sviluppo deve essere dietro a Agile; ciò significa non tagliare gli angoli e non ignorare il feedback costante e le domande di "È giusto? Quando succede x cosa dovrebbe fare Y?". Anche se non segui la programmazione TDD o Pair, il tuo team di sviluppo deve essere sufficientemente competente per seguire i processi agili (ad esempio sprint, iterazioni). Ciò implica avere un responsabile / responsabile che possa valutare correttamente le attività e capisca che non è necessario rendere prioritarie tutte le funzionalità, è corretto avere un arretrato di lavoro e non dovresti sovraccaricare le persone.