Quando Agile diventa un po 'pigro [chiuso]

Non mi piace Scrum. È stata descritta come la metodologia agile meno agile di sempre. Penso che sia la causa di molte inefficienze e molta frizione tra management e sviluppo.

Comprendi che tutte le metodologie agili pubblicate sono punti di partenza per la tua modifica. Elimina i bit che non funzionano per il tuo ambiente, aggiungi bit che ritieni possano aiutarti. Mai e poi mai seguire la metodologia come se fosse una scrittura sacra. Non lo è. Spesso sono solo pratiche che hanno funzionato per qualche team e sono ora pubblicate nel caso in cui ti aiutino. Sfortunatamente un'intera industria è cresciuta facendo agile in questo modo e a loro piace dirvi di seguire le regole - in questo modo è necessario acquistare tempo consulente per scoprire come farlo "giusto". Buono per l'azienda di formazione, male per te.

Quindi hai problemi con il modo scrum che non verranno risolti a meno che tu non abbia a disposizione il responsabile IT e il team aziendale. Devono capire e ottenere il programma per quello che stai facendo per lavorare. Ma sono il programma e quindi sei tu a dover cambiare per accoglierli.

Puoi cambiare mischia per adattarla, ma penso che sia un compito enorme, quindi cambia metodo agile. Uno di quelli che è molto popolare e molto più in linea con i vecchi manager IT si aspettano che il progresso dei lavori sia Kanban . Cambia il tuo team di sviluppo per usarlo, non aver paura di modificarlo, e penso che all'improvviso troverai Agile un grande successo in tutto il team esteso.

The main issue is with our backlog, we have a product owner who is also the IT manager. Virtually all of the items on the backlog have really poorly defined stories, nothing has any priority and no one else in the business seems to be having any input into the backlog.

Questo può essere riassunto come "il Product Owner non sta facendo il suo lavoro". Questo è un problema di gestione, non un problema con la metodologia. Deve essere risolto tramite la gestione.

Sfortunatamente, se il PO è anche il manager, questo sarà difficile, e i metodi per gestirlo non riguardano la programmazione, ma piuttosto la gestione del posto di lavoro.

Il modo in cui scrum dice di gestire questo è di avere retrospettive e regolare il processo. Ma se un membro chiave sta ignorando i risultati di questo, non c'è molto che tu possa fare. Una metodologia non funzionerà se i membri del team non la seguiranno.

As far as I'm concerned the business isn't invested so agile is failing

E c'è il tuo problema. Se l'azienda non è investita, non funzionerà. Le metodologie di sviluppo del software risolvono i problemi del software, non i problemi delle persone.

Ho notato che molte volte un negozio reagisce a un problema identificato nella loro metodologia cambiando la loro metodologia. Questa è spesso la cosa più disfunzionale da fare.

"Mancano le scadenze di sprint". "OK, fai lo sprint più a lungo."

Anche questo sembra funzionare. Ma in realtà nasconde solo il problema.

La metodologia non ti renderà migliore. Mostrerà cosa c'è che non va. Le metodologie non funzionano correttamente.

Hai identificato un problema! È fantastico. Puoi provare che è un problema? Cambiando la metodologia ora dimostrerai che SOOOOO è molto più difficile.

Con un problema dimostrabile ciò che è necessario è la leadership. Identifica ciò che ha causato la cattiva definizione del backlog. Fornire feedback a chi lo ha definito. Coinvolgi gli altri e costruisci un consenso. Salire la catena quando necessario. Se il problema è una persona che non sta eseguendo un cambiamento nella metodologia non è di aiuto. È un reorg.

Piuttosto che cambiare una metodologia, preferisco chiedere se il modo in cui stiamo implementando la metodologia è corretto. Ho visto un sacco di cose chiamate agili per nessun'altra ragione che agile suonava bene.

Non c'è nulla nel backlog che sia praticabile assumersi la responsabilità e mettere qualcosa di lavorabile nel backlog. Puoi persino taggarlo in modo che le persone possano trovare gli oggetti lavorabili. Man mano che le persone iniziano a lavorare su solo elementi realizzabili, il problema si risolve.

Ha davvero senso parlare di cambiare metodologie per risolvere problemi pervasivi che non sono localizzati. Se hai detto che tutti potevano mettere cose nell'arretrato e che l'arretrato era una schifezza, sarebbe tempo di cambiare metodo.

La gestione degli errori fa più e più volte sta prendendo la somma delle stime di sprint per essere la data di consegna. In effetti, ho visto la gestione impostare una data di consegna in pietra prima che il primo sprint sia completato.

Gli strumenti che aiutano nella pianificazione sono un mezzo per raggiungere un fine: non dovrebbero essere uno strumento con cui battere gli sviluppatori. Le stime sono indicatori per il time-lining allo sprint - niente di più.

Se il tuo sprint ha fatlog, dovrebbe essere passato indietro sulla catena di comando. È una follia lamentarsi perché gli sprint non sono completati se passi la maggior parte del tempo a fare analisi sui compiti.

Le attività possono avere la priorità ma il fatto che siano nello sprint dovrebbe essere una priorità sufficiente a meno che non ci siano attività dipendenti.

Anch'io sono stato in una posizione in cui le retrospettive sono state ignorate. Il ragionamento era che i problemi dovevano essere sollevati negli stand up ma in realtà era solo una scusa per il management per spazzare via i problemi sotto il tappeto, poiché la retrospettiva era stata documentata e distribuita, ma le alzate non lo erano. Le campane di allarme dovrebbero suonare!