Quando Agile va storto [chiuso]

Sto scrivendo un corso Agile per alcuni dei nuovi ragazzi a cui stiamo partecipando di recente e voglio aggiungere una storia di avvertimento in modo che capiscano che Agile non è pensata per tutti i progetti.

Il mio problema è che, a causa della natura dei progetti in cui lavoro con Agile finora ha funzionato abbastanza bene, non posso onestamente indicare cosa può andare storto e perché quando lo usi nel tipo sbagliato di progetto.

Quali sono le cose da cercare quando un progetto Agile va storto?

Il più grande fallimento con i team "Agili" è il risultato di ciò che viene chiamato Cargo Culting . In sostanza, i team vogliono gli effetti di team agili di successo in modo da imitare le azioni visibili

• Standup giornalieri (che durano circa un'ora)
• Rompere il lavoro in sprint
• User story (che di solito sono poco più di una frase ma è prevista una stima)

Questi sono i tre che vedrai costantemente "applicati" in questi ambienti, ma con pochissimo impegno a essere realmente agili. In effetti sentirai dire al management che "stiamo agendo". (Scappa a quelle due parole è un brutto segno.)

Sentirai anche molto parlare del debito tecnico, ma la loro definizione di debito tecnico è "fallo in modo rapido e sporco e forse potremo fare in modo di migliorarlo in seguito". (Traduzione: faremo sembrare che ci occupiamo della manutenibilità, ma in realtà manterremo la stessa mentalità del locale caldaie perché è quello che ha funzionato per noi in passato).

Altre frasi chiave: "So che queste storie non sono completamente definite ma stiamo agendo in modo da poterle sistemare mentre andiamo".

"Stiamo facendo uno sviluppo agile, quindi dovresti essere in grado di soddisfare ciò di cui ho bisogno durante lo sprint mentre lo identifico."

"Non siamo in grado di bloccare le nostre storie impegnate all'inizio dello sprint perché i bisogni continuano a cambiare a metà sprint".

L'indicatore chiave sul successo di un progetto Agile è se il responsabile del progetto (scrum master o qualunque ruolo) abbia avuto esperienza o formazione formale sulla conduzione di un progetto agile. Troppo spesso ho visto le persone leggere di Agile in un libro o frequentare un corso di due giorni per diventare un maestro della mischia e pensare di avere le braciole per implementarlo con successo. Mi dispiace non sta succedendo capitano.

Le persone che non capivano cosa fosse (era?) Agile e lo applicavano a:

• clienti che non sono disponibili per un commento fino alla scadenza
  ... e che minacciano azioni legali in seguito;

• manager che tengono gli sviluppatori lontani dal client , (probabilmente perché sono leggermente sottopagati e potrebbero saltare le navi, andare a lavorare per detto cliente) e giocare a un " telefono rotto " in un tentativo disperato (spesso di successo, però) guardare occupato e utile,

  Vedi anche: gestione dei funghi , noto anche come "tenuto oscuro, nutrito con letame" e boss dai capelli a punta . :)

• squadre troppo grandi per andare ovunque;

• le aziende che stanno conservando il loro libro paga progettisti di architettura di sistema un tempo rinomati che stanno disperatamente distogliendo l'attenzione dal fatto che hanno completamente perso di vista il vero mestiere di programmazione, sovrastampando famiglie di sagrada UML magnifiche, non pratiche, difficili da realizzare .

Agile non è adatto per contratti a tempo determinato o a prezzo fisso. Una volta che ti sei registrato per una tale bestia, devi consegnare. Agile è bravissima a continuare lo sviluppo per sempre, poiché i clienti cambiano idea e "chiariscono" le loro esigenze. Questo non ti aiuta il giorno in cui il denaro si esaurisce, ma deve ancora finire il lavoro.

Agile è molto buono per la fase post-progetto quando si eseguono aggiornamenti incrementali e correzioni di bug.

L'altro aspetto in cui Agile fallisce non è colpa di Agile, è colpa di persone che insistono su tutte le cose vecchie come la documentazione completa del progetto, i progetti iniziali e le cattive linee di comunicazione. (Il manifesto agile a metà corsa ).

Ecco alcune domande che potrebbero essere utili per cercare una risposta in termini di ricerca di un esempio in cui un tentativo di Agile può andare male:

• Agile è il nuovo microgestione?
• Il processo Agile: come e cosa dovrebbe essere documentato?
• Giusto mix di pianificazione e programmazione su un nuovo progetto

Hai mai sentito parlare di "pseudo Agile"? Ecco un paio di post di blog a riguardo:

• Da Pseudo-Agile a Waterfall - Il percorso di una piccola e nuova società di software
• Pseudo Agile!

C'è qualcosa da dire per le aziende che possono prendere le loro opinioni su ciò che è Agile e trasformarlo in qualcos'altro.

Ho lavorato in un team Agile di grande successo, nonché in alcuni che hanno tentato Agile, ma non sono riuscito a farlo funzionare.

Quello di successo aveva i seguenti elementi:

• Requisiti veramente "agili". C'erano storie di utenti e ne abbiamo codificato.
• Proprietario del prodotto disponibile. Se una user story da cui stavo codificando era incompleta, potrei facilmente andare dal proprietario del prodotto, chiedergli cosa dovrebbe essere lì, aggiungerlo e completare il codice.
• Impegno nel processo e consapevolezza che si trattava di una curva di apprendimento.
• Squadra focalizzata.
• Manager che conoscevano e capivano il modo agile di fare le cose che si erano impegnati a farlo funzionare.

Il team di successo ha fatto Agile e lo ha fatto davvero bene. Penserei che se non si dispone di nessuno di questi punti sopra, si potrebbe fallire abbastanza facilmente. La prima e la seconda cosa vanno di pari passo, e se non ce l'hai, Agile non funzionerà.

La squadra in cui facevo parte che non faceva bene ad Agile aveva anche alcuni elementi:

• Mancanza di impegno da parte della direzione. Il management non credeva nella filosofia ed era esitante a impegnarsi di conseguenza.
• Requisiti documentati in luoghi diversi dalle storie degli utenti. Vedi sopra sull'impegno della direzione. Inoltre, avevamo analisti di requisiti altamente pagati e strumenti di requisiti molto costosi di cui qualcuno aveva bisogno per giustificare l'uso.

Aggiungerò alle grandi risposte già pubblicate che, per la mia esperienza, Agile e in particolare Scrum funzionerà solo se la direzione E il team sono disposti a dare molta visibilità a ciò che sta succedendo.

Ciò significa che nelle aziende pubbliche (ad esempio i governi), sarà molto difficile farlo funzionare correttamente.

Non lo so per esperienza personale, ma ipoteticamente, ci sono molte circostanze in cui l'agile non è l'opzione migliore.

• Progetti il ​​cui prodotto è critico per la vita o la proprietà - Ad esempio, non si desidera utilizzare l'agile per sviluppare il software che esegue il pacemaker. Perché? Perché hai tolleranza quasi zero per gli errori. Considera un classico esempio di errore di programmazione in medicina per quanto riguarda Therac 25 . Certo, non è stato costruito con agilità, ma il punto è questo: lo sviluppo della vita o della proprietà critica non è un luogo in cui dire "lo ripuliremo al prossimo sprint" o "non abbiamo bisogno di grandi cose, solo bene abbastanza."

• Progetti con troppi sviluppatori junior: Agile prevede una certa autonomia all'interno del gruppo partecipante. Se non c'è abbastanza esperienza nella squadra, quell'autonomia può lavorare contro di te.

• Progetti che richiedono un livello più elevato di controllo o pianificazione rispetto a quanto offerto tradizionalmente con Agile.

Suppongo che qualcun altro salterà dentro e ci darà una mano con esempi migliori, o declasserà questo pezzetto di trippa che ho scritto ;-).

Ricorda solo che quando l'unico strumento che hai è un martello, ogni problema sembra un chiodo. Non tutti i progetti sono unghie.

Agile secondo me è tutto incentrato sulla cultura della squadra che si sta esercitando. Se la cultura fa schifo, i membri del team non vanno d'accordo e le persone non collaborano per rispettare gli impegni di sprint, la cultura o il team sono carenti.

Non direi necessariamente che Waterfall funzionerà necessariamente in un ambiente simile, non è una situazione in bianco e nero, molto poco è veramente in bianco e nero.

Una buona squadra Agile è in comune. Hanno uno spirito tribale di comunità in cui tutti i membri stanno lavorando per raggiungere gli stessi obiettivi. La squadra ha successo o fallisce insieme. Lavorano insieme per risolvere i problemi. Un membro del team interromperà ciò che sta facendo con i suoi compiti per aiutare un membro del team in difficoltà. Tutto è affondare o nuotare.

Quando questo non è il caso, diventa subito chiaro cosa non va. Se i membri del team sono seduti, scrivono sui loro laptop o mandano messaggi o si mettono in pausa durante lo standup quotidiano, allora non hai una buona squadra Agile. Se i project manager stanno applicando tutte le procedure, le definizioni e le terminologie di Scrum, ma tutti stanno solo mantenendo la cadenza e pagando il servizio labiale, allora questa è solo una palese farsa di ciò che è veramente Agile, e questo in molti modi porta a disfunzione del team, inefficienza , scadenze mancate e progetti falliti.

Fallire Agile è per molti versi peggiore di un team di Waterfall di moderato successo e probabilmente ha percentuali di successo del progetto più basse.