Il fixed-scope e il fixed-time sono davvero impossibili da consegnare in agile? O che altro usare?

Tempo, budget e ambito

Ogni progetto, qualunque sia l'approccio ciclo di vita che utilizza, deve far fronte a triplo vincolo di costi, tempi e obiettivi. Nel tuo caso il tempo e l'ambito sono fissi. Non parli dei costi, ma dal momento che hai ereditato questo progetto dal tuo partner, temo che possa esserci un costo fisso (o almeno limitato).

I rischi inesplessi

Questi vincoli possono rendere il progetto difficile e la tua vita infelice. Ma i vincoli da soli non uccidono il progetto. Sono i rischi che uccidono i progetti : rischi che non sono stati presi in considerazione quando budget, programma e scope erano definito, o rischi che si verificano e rendere i vincoli inadatti.

I seguenti rischi portano spesso al fallimento:

• rischio di qualità: se alla fine del progetto si scopre che c'è stato un malinteso fondamentale sui requisiti o sulle aspettative del cliente, il costo e il tempo necessari per correggere tali errori possono portare a costosi fallimenti totali!
• effetto tunnel senza feedback: se entri in un'attività più lunga, potrebbe essere come un tunnel: potresti scoprire alla sua uscita di uscita che sei nel posto sbagliato e che il progetto è stato completamente sottovalutato. Più tempo passa nel tunnel, più alto è il rischio e più infelice sarà il cliente quando gli dirai la situazione spiacevole.
• profezia che si autoavvera: con tempi più lunghi, c'è il rischio che le attività prendano tutto il tempo pianificato inclusi i margini che hai aggiunto nel programma. Ad esempio, le persone potrebbero richiedere del tempo per redigere e redigere un documento di design perfetto. Ma alla fine potrebbe non esserci questo tempo prezioso. Nella gestione tradizionale del progetto, la metodologia a catena critica (non sul percorso!) potrebbe risolvere questo problema. Ma gli obiettivi a breve termine usati nei metodi agili riducono tali effetti in un modo molto più efficiente.

Conclusione

Un approccio agile è a mio avviso l'approccio migliore per anticipare e padroneggiare il più grande progetto rischi . Permette di affrontare tempestivamente l'incertezza, ottenere feedback costanti e progressi tangibili e reagire il più rapidamente possibile in caso di qualsiasi problema.

Così agile non è il problema, è parte della soluzione.

Note aggiuntive (riassunto dei commenti)

Per il tuo progetto al 70% di completamento, credo che tecniche come un backlog preciso e trasparente, frequenti obiettivi a breve termine con un ciclo di iterazione settimanale e brevi standup giornalieri dovrebbero aiutare a mantenere l'attenzione e tornare sulla giusta strada. E la trasparenza sui risultati e il lavoro da fare potrebbero ripristinare la fiducia.

In questa fase del progresso, è difficile aggiungere molte nuove risorse. Potrebbe anche essere controproducente iniziare a imparare un approccio completamente nuovo con strumenti completamente nuovi. Adotta i princìpi fondamentali agile con pragmatismo.

Nota finale: varrebbe la pena di capire cosa succederebbe in caso di consegna tardiva: la società mancherà di alcuni obblighi legali e fallirà? Ci saranno penalità? E lo stesso per quanto riguarda lo scope: tra tutte le tue caratteristiche / user story, ci sono alcuni che sono meno critici che potrebbero nel peggiore dei casi essere consegnati dopo il go-live delle funzioni principali? Tutto ciò potrebbe essere utile per la negoziazione e il controllo dei danni se alla fine fosse richiesto.

Se hai fissato un ambito e una scadenza fissa, il unica cosa che ti rimane da giocare è il costo . Puoi lanciare più persone al problema (che non funziona davvero ), puoi acquistare software in anteprima, o puoi sacrificare la qualità. ... Oppure puoi cambiare le menti delle persone riguardo allo scopo prefissato o alla scadenza fissata.

Questo non è un problema agile, questo è un problema per tutti i progetti. Cambiare le modalità di esecuzione del progetto non modifica i vincoli inerenti.

Sì, un approccio agile potrebbe aiutarti a portare a termine il lavoro ¹ . Al centro, scrum fornisce un modo per un gruppo di persone motivate che lavorano insieme per fornire un prodotto. Scrum fornisce una struttura per spezzare un corpus di lavoro più grande in pezzi più piccoli (epopea, storie, compiti) e quindi lavorare su quei pezzi più piccoli.

Scrum fornisce anche un quadro per il miglioramento costante della squadra, che può anche aiutare a portare a termine il lavoro. Infine, rende visibile il processo, in modo che le parti interessate possano vedere come sta procedendo il progetto.

¹ Un approccio agile ti aiuterà a organizzare e svolgere il lavoro, ma non può garantire che finirai in tempo o budget. Agile è meno focalizzato sui budget e le scadenze e molto altro ancora sulla consegna del prodotto giusto. Detto questo, anche con un ambito fisso e scadenze fisse, come strumento per organizzare la tua squadra per fare il lavoro, può sicuramente aiutare.

Dati i dettagli che hai fornito:

• Corretto l'ambito
• Risolto il limite
• Squadra demotivata
• Project is a mess

Penso che sia agile, ma non mischia. Probabilmente vuoi fare qualcosa di più leggero come Crystal Clear . Questo è brevemente descritto come:

The lead designer and two to seven other developers … in a large room or adjacent rooms, ... using such as whiteboards and flip charts, ... having easy access to expert users, ... distractions kept away, deliver running, tested, usable code to the users … every month or two (quarterly at worst), ... reflecting and adjusting their working conventions periodically.

Le metodologie di mischia sono progettate per essere in grado di proiettare i tempi di consegna in base all'esperienza precedente. Cioè, quando inizi a produrre soluzioni di lavoro reali, usi i dati generati da questo per prevedere il tempo necessario per produrre di più. Continui a farlo e ottieni più dati e li utilizzi per misurare le tendenze.

In base a ciò che stai dicendo, non sembra che la previsione dei risultati sia molto importante per il tuo progetto. L'importante è averlo fatto. Dici che è completo al 70% che in termini Agile significa che il 70% delle funzionalità sono in produzione o in produzione (il primo è più affidabile del secondo). Se la scadenza è molto lontana (un anno o più), potresti voglio iniziare a fare la mischia. Altrimenti fai qualcosa di molto più leggero.

Tutto ciò presuppone che non ci sia spazio per negoziare scopo o consegna. Se puoi, è una storia completamente diversa. Di solito, in queste situazioni, la consegna sta per scivolare e alla fine ciò costringerà a una sorta di discussione. Di solito il cliente preferisce avere qualcosa piuttosto che una causa e più tempo verrà dato.