Come gestire gli sviluppatori Agile che lavorano con persone aziendali (seriali) tradizionali? [chiuso]

1) Di solito puoi semplicemente rivedere l'ultimo sprint in una riunione, pianificare il prossimo e iniziare. Esaminare in particolare l'accuratezza delle stime delle attività e inserirle in stime per il prossimo sprint. Potresti ritardare il prossimo sprint se hai bisogno di attendere il feedback dei clienti dai risultati del precedente e pensi che il feedback influenzerà le attività per il prossimo sprint.

2) Non sarà più facile, ma il team può ovviamente avere successo. Il tuo commento

The sprint goals are things like "get XX% closer to release"

è un po 'preoccupante in quanto idealmente vuoi includere funzionalità / funzionalità dimostrabili come obiettivi in uno sprint.

3) Dici che ci sono 3-5 progetti completamente diversi. Se non sono correlati, ad esempio per prodotti diversi, non è necessario averli sincronizzati, ma devono essere trattati come sprint indipendenti. Sembra che le tue squadre per ogni sprint siano probabilmente di buone dimensioni.

1) Ci dovrebbe essere un po 'di tempo (forse una settimana circa) tra gli sprint per eseguire la riflessione / l'introspezione / i cambiamenti / ecc.?

No. Una settimana? Devi essere pazzo. 2 ore è il limite.

Or are back-to-back-to-back sprints the norm?

Assolutamente. Altrimenti, stai facendo girare le ruote.

Is there any chance for survival for an agile team with no agile business counter-parts?

Il business non è mai "Agile". Agile è qualcosa che fai. Non loro. Anzi, mai loro. Chiedono solo cose a caso. Lo gestisci.

If not, are there some transitional methodologies or even tips for moving the business towards an iterative if not necessarily agile mindset?

Nessuno. Si decompongono i requisiti in sprint. È la tua disciplina. Non loro.

Should your entire team be on every sprint?

Sì.

We have almost 20 programmers on a single sprint but working on completely different projects (typically teams of 3-5, sometimes larger).

Che cosa? Non è una squadra. Questo è un gruppo di squadre. 4 o forse 5 squadre separate.

Is it normal to have a single sprint or should we be trying to manage multiple independent sprints?

Non ho idea di cosa stai parlando. Tuttavia, dal momento che sembra che 4 o 5 team siano tutti purè insieme, è chiaro che avrai una grande confusione.

Should we be trying to keep the multiple sprints in concurrent lockstep or should their timetables be allowed to overlap and be flexible?

Ogni squadra e gli sprint del team rappresentano il problema della squadra. Nessun altro.

Qualche gente su progetti grandi come questo dovrebbe essere una "Scrum of Scrums". Le squadre stabiliscono i loro obiettivi, costruiscono le loro cose. I rappresentanti di ogni team si riuniscono periodicamente per coordinare le squadre per ottenere rilasci reciprocamente vantaggiosi.

Mi dispiace che tu sia in una organizzazione così disfunzionale.

Se desideri avere qualche possibilità di misurare i progressi, è assolutamente necessario pianificare in termini di traguardi completi al 100%. Se c'è mai spazio per un disaccordo sincero su cosa sia una pietra miliare particolare, la tendenza naturale è che la persona che fa il lavoro prenda l'interpretazione più ottimistica possibile su quanto hanno fatto e la persona che sente quello che dice per sentire che nei modi più ottimistici possibili. Ciò significa che le notizie diventano sempre migliori man mano che si sale sulla catena, portando a una completa disconnessione tra la realtà e ciò che la parte superiore sente. Il link è una visione umoristica e del tutto realistica su questo fenomeno.

Quanto è grave questa disconnessione? Considera questo. Nel progetto medio, il tempo effettivo necessario per il completamento (se mai ci si arriva) fa una media doppia delle stime originali. Ma non importa quanto il progetto sia ritardato, in genere le persone in cima non ricevono i primi suggerimenti che il progetto è dietro fino a circa 2 settimane prima della scadenza, poiché questo è il punto in cui la disconnessione tra aspettative e la realtà non può più essere nascosta.

Quindi gli obiettivi ravvicinati del XX% non sono requisiti effettivi. Letteralmente la tua squadra dovrebbe rifiutarsi di accettare quelli come requisiti reali. È compito tuo educarli che hai bisogno di compiti concreti e attuabili, e nella pianificazione dovranno essere suddivisi in compiti specifici che possono essere stimati in un massimo di poche ore.

In secondo luogo, come altri hanno già detto, devi assolutamente abbattere la tua squadra in unità più piccole, che probabilmente dovranno essere pianificate in modo diverso. La ricerca indica che un singolo team di 20 persone che lavorano su una cosa può ottenere circa un gruppo di 5-8 persone. (Ho trovato questo fatto sorprendente nell'eccellente libro di Steve McConnell Software Estimation .)

In terzo luogo è una bandiera rossa davvero grande che sembra una marcia della morte. Se sembra una marcia della morte, probabilmente è una marcia della morte. Gli sviluppatori di software tendono ad essere al massimo delle prestazioni quando lavorano 35-40 ore alla settimana. (Ho preso quella cifra da Rapid Development di Steve McConnell.) Lavorare più ore può ottenere aumenti temporanei delle prestazioni, al costo di una riduzione a lungo termine delle prestazioni. Un grande progetto è una maratona, devi camminare su se stesso.

Quarto, c'è davvero bisogno di essere un ritmo per uno sprint. Quando ho lavorato in una squadra di scrum, abbiamo trovato molto utile dividere ogni sprint in due sezioni che abbiamo chiamato "long focus" e "short focus". Durante il "focus lungo" abbiamo diretto lo sviluppo del software sui compiti che erano stati concordati per lo sprint. Durante la "breve messa a fuoco" abbiamo fatto tutto il necessario che ci serviva per un sacco di interruzioni e cambi di attività. Così è stato quando abbiamo fatto QA, bug fixing, varie riunioni, stimando i compiti per il prossimo sprint e infine concordato su cosa sarebbe stato o meno nel prossimo sprint. Questo ha funzionato molto bene per noi perché un sacco di sviluppo del software può essere fatto solo quando ci si trova nella "zona", che generalmente non si avvia finché non si esegue un'attività per almeno 15 minuti senza interruzioni.

Se segui un ritmo del genere, otterrai un altro vantaggio in termini di pianificazione diversa tra i team: i tuoi dipendenti del QA possono sempre lavorare su qualsiasi squadra sia attualmente in QA, il che li mantiene con un livello costante di lavoro.

Buona fortuna e sii consapevole che senza il supporto dall'alto potresti non essere in grado di risolvere la disfunzione. Se questo è il caso, la tua migliore opzione realistica potrebbe essere quella di trovare un'organizzazione più sana da far parte piuttosto che cercare di trasformare la tua organizzazione in qualcosa che non diventerà.

1. La mia esperienza è che gli sprint sono generalmente retroattivi con una perdita di tempo per fare retrospettive, dimostrare funzionalità e pianificare il prossimo sprint. Ad esempio, l'ultimo giorno di uno sprint sarebbe spesso considerato un write-off in quanto ci sarebbero 3 riunioni che si sono svolte quel giorno in genere in modo da ottenere uno sprint di 2 settimane pari a 9 giorni lavorativi. La retrospettiva alla fine di uno sprint può portare modifiche da provare nel prossimo sprint che inizia quasi immediatamente in un certo senso.

2. Un'opportunità sì, ma piuttosto piccola, come se si usasse Scrum, dovrebbe esserci un proprietario del prodotto che è stato approvato dalla direzione per dirigere la prioritizzazione dell'urgenza di alcune storie rispetto ad altre. Ci deve essere una certa comprensione di quale responsabilità abbiano, anche se un'altra parte è che il "XX% più vicino al rilascio" è una metrica piuttosto scarsa per la mia mente in quanto tende a non includere bug e altri problemi dell'ultimo minuto che sono quasi impossibili da appropriarsi correttamente stima nella mia esperienza limitata. C'è anche qualcosa da dire per capire quando i cambiamenti delle priorità possono essere conosciuti dal team e utilizzati nella pianificazione di uno sprint. Il management buy-in è fondamentale perché se non capiscono cosa stai facendo potrebbe essere come cercare di effettuare consegne mentre si cammina su un tapis roulant fisso. Mentre le tue gambe si stanno muovendo, non ti stai avvicinando a niente.

3. Non necessariamente, ma a volte può essere il caso. La chiave è sapere quanto ogni sviluppatore è assegnato al progetto e mantenere questo coerente in modo che quando c'è una velocità dai primi pochi sprint iniziali, questo è utile nel predire le velocità future piuttosto che essere inutile come il numero di ore uomo su i progetti rimbalzano troppo per stimare più facilmente quanti punti si possono fare in uno sprint. Ogni progetto dovrebbe avere il proprio set di sprint se il progetto è abbastanza grande da estendersi in settimane di lavoro.

Buona fortuna nell'educare la gestione in termini di ciò che devono fare e in che modo questo può essere il tuo grande ostacolo da superare qui.

Se il tuo progetto utilizza Scrum, dovresti avere uno Scrummaster il cui compito è educare tutte le parti su come esattamente il processo dovrebbe funzionare. Se stai facendo Scrum, sembra che lo scrummaster non stia facendo il suo / il suo lavoro, dal momento che non avere alcun riscatto dal lato commerciale del progetto è un posto di blocco ENORME (e non insolito).

Spiega al programma che le persone lo infrangeranno se dicono che il XX% sarà più vicino al completamento. Digli che finirai i requisiti X, Y e Z in una data come questa. Se vogliono contrarre il programma, chiedi loro cosa vogliono rimuovere, se gli impediscono di dire loro che rimuovono pezzi o aggiungono tempo. Dire di farlo o non farà un po 'di bene. Se spingono, assegna il codice del tuo project manager per completare lo sprint. Ricorda che Agile è uno sforzo di squadra. Se le persone che gestiscono il progetto non lavorano 12 ore al giorno, preferiscono essere lì a prendere pizza e bibite per le persone che sono e qualsiasi bonus per fare le cose in anticipo o in anticipo, meglio andare alle persone che hanno fatto il lavoro. Dillo a mgmt superiore se ne hai anche tu, sono probabilmente quelli che hanno spinto Agile su di te mentre non allenavano le persone che gestiscono il progetto.

Tieni traccia dei tuoi progressi, apporta le regolazioni e scegli i prossimi requisiti da soddisfare. Se il progetto non verrà consegnato fino a quando l'intera operazione non verrà completata, non preoccuparti della priorità delle funzionalità, preoccupati di quali funzioni sono importanti per il tuo lavoro da eseguire in futuro. Devi prenderne possesso. Nemmeno dovrebbe essere una marcia della morte. I progetti Scrum dovrebbero misurare la quantità di lavoro che è possibile completare nella durata di uno sprint NORMALE. Quel 10 (o 9 come indicato sopra) normali 8 giorni lavorativi.

Una cosa che ho sentito alla conferenza Agile alcuni anni fa era che la tua squadra è come una fabbrica e può produrre X quantità di auto (o nel tuo caso) per sprint.

Anche i team di sprint dovrebbero avere da 3 a 5 persone non 20. Ciò potrebbe essere parte del problema. Ogni squadra dovrebbe raccogliere le proprie storie (elementi pubblicitari dei requisiti se lo si desidera) e lavorare a quelle. Dovrebbero scrum separatamente, ma incontrare un grande gruppo su una base per condividere idee.

Quando gestisci questi tipi di team, potrebbe essere meglio per i manager scrum separatamente per determinare quali attività trasversali sono necessarie e mettere in contatto le persone giuste. Uno standup di 20 persone è monotono e noioso per le persone coinvolte.