Quando Agile va storto [chiuso]

Il più grande fallimento con i team "Agile" è 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

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

Questi sono i tre che vedrai in modo coerente "applicati" in questi ambienti, ma un impegno molto piccolo per essere effettivamente agili. In effetti sentirai dire che stiamo facendo "agile". (Scappare con quelle due parole è un brutto segno.)

Sentirai anche molto sul debito tecnico, ma la loro definizione di debito tecnico è "fallo in fretta e sporco e forse faremo in modo di migliorarlo in seguito". (Traduzione: faremo sembrare che siamo interessati alla manutenibilità, ma in realtà manterremo la stessa mentalità del locale caldaia 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 che possiamo correggerle man mano."

"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é le esigenze continuano a cambiare mid-sprint."

L'indicatore chiave sul successo di un progetto Agile è se il capo del progetto (scrum master o qualsiasi ruolo) ha avuto esperienza o formazione formale sulla conduzione di un progetto agile. Troppo spesso ho visto persone leggere di Agile in un libro o fare un corso di due giorni per diventare un maestro di scrum e pensare di avere le costolette per implementarlo con successo. Mi spiace che non stia succedendo capitano.

Le persone che non capivano cos'è agile (era?) e lo applicano a:

• clienti che non sono disponibili per i commenti fino alla scadenza
  ... e azione legale contro la minaccia in seguito;

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

  Vedi anche: gestione dei funghi , aka "mantenuto oscuro, alimentato con letame " e capi dai capelli a punta . :)

• team troppo grandi per andare ovunque;

• le aziende che stanno mantenendo il loro stipendio una volta rinomati progettisti di architetture di sistemi che stanno disperatamente distogliendo l'attenzione dal fatto che hanno completamente perso di vista l'attuale codifica, con overdesigning magnifico, poco pratico, sagrada familias

Agile non è adatto per contratti a prezzo fisso o a prezzo fisso. Una volta che ti sei registrato per una bestia del genere, devi consegnare. Agile è molto bravo a continuare lo sviluppo per sempre, poiché i clienti cambiano idea e "chiariscono" le loro esigenze. Questo non ti aiuta nel giorno in cui i soldi finiscono, ma devono ancora finire il lavoro.

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

L'altro aspetto in cui Agile fallisce non è una colpa di Agile, è una colpa delle persone che insistono su tutte le vecchie cose come la documentazione completa sul progetto, i progetti iniziali e le scarse linee di comunicazione. (Il manifesto agile semistrutturato ).

Ecco alcune domande che possono essere utili per cercare una risposta in termini di trovare 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 su questo blog:

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

C'è qualcosa da dire per le aziende che possono prendere la loro visione di ciò che è Agile e macinarlo in qualcos'altro.

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

Il successo aveva i seguenti elementi:

• Requisiti davvero "agili". C'erano storie di utenti e ce ne siamo codificati.
• Proprietario del prodotto disponibile. Se una storia utente di cui stavo codificando era incompleta, potrei facilmente andare dal proprietario del prodotto, chiedergli cosa dovrebbe essere lì, aggiungerlo e completare il codice.
• Impegno per il processo e consapevolezza che si trattava di una curva di apprendimento.
• Team mirato.
• I manager che conoscevano e capivano il modo agile di fare cose che si impegnavano a farlo funzionare.

Il team di successo ha fatto Agile, e lo ha fatto davvero bene. Penserei che se non hai nessuno di quei punti sopra, potresti fallire abbastanza facilmente. La prima e la seconda cosa vanno di pari passo, e se non lo hai, allora Agile non funzionerà.

Il team di cui ero parte che non ha fatto bene Agile aveva anche alcuni elementi:

• Mancanza di impegno da parte della direzione. La direzione non credeva nella filosofia ed esitava a impegnarsi di conseguenza.
• Requisiti documentati in luoghi diversi dalle User story. Vedi sopra sull'impegno della direzione. Inoltre, disponevamo di analisti di requisiti altamente retribuiti e di costosi strumenti di requisiti costosi che qualcuno aveva bisogno di giustificare l'uso di

Aggiungerò alle ottime risposte già pubblicate che, per la mia esperienza, agile e specificamente Scrum funzionerà solo se la squadra di gestione e il team sono disposti a dare molta visibilità a ciò che sta accadendo.

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

Agile secondo me è tutto sulla cultura della squadra che sta praticando. Se la cultura fa schifo, i membri del team non vanno d'accordo e le persone non collaborano per soddisfare gli impegni di sprint, quindi la cultura o la squadra è carente.

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

Una buona squadra Agile è comunale. Hanno uno spirito tribale di comunità in cui tutti i membri lavorano per gli stessi obiettivi. Il team 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 della squadra in difficoltà. Tutto è affondare o nuotare.

Quando questo non è il caso, diventa subito evidente ciò che è sbagliato. Se i membri del team sono seduti, scrivendo sul proprio computer portatile o mandando SMS, o facendo una suddivisione in zone durante lo stand up giornaliero, non si dispone di una buona squadra Agile. Se i project manager applicano tutte le procedure, le definizioni e le terminologie Scrum, ma tutti mantengono la cadenza e il servizio a parole, questa è solo una palese farsa di ciò che è veramente Agile, e questo in molti modi porta a disfunzioni della squadra, inefficienza , mancate scadenze e progetti falliti.

Failing Agile è in molti modi peggio di un team Waterfall di discreto successo e probabilmente ha tassi di successo del progetto più bassi.

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

• Progetti il cui prodotto è cruciale per la vita o la proprietà: ad esempio, non si desidera utilizzare agile per sviluppare il software che gestisce il pacemaker. Perché? Perché hai tolleranza quasi zero per gli errori. Considera un classico esempio di errore di programmazione all'interno della medicina relativamente a Therac 25 . Certo, non è stato costruito con agilità, ma il punto è questo: lo sviluppo di vita o proprietà critiche non è il caso di dire "lo ripuliremo al prossimo sprint" o "non abbiamo bisogno di grandi, solo buone abbastanza ".

• Progetti con troppi sviluppatori junior - Agile si aspetta una certa autonomia all'interno del gruppo partecipante. Se non c'è abbastanza esperienza nel team, allora quell'autonomia può funzionare contro di te.

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

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

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