Avere date di consegna fisse per gli elementi è un modo di lavorare "Agile"?

Continuiamo a sentirci dire che lavoreremo in modo agile su un nuovo progetto da parte del senior management. Hanno allestito stand-up, pianificazione dello sprint, retrospettive ecc. Ecc. Tuttavia, ora hanno escogitato un piano che descrive in dettaglio tutto il lavoro che vogliono che noi consegniamo con le date rispetto a ciascun elemento e che mostri nuovamente le date con ciò che verrà mostrato in ciascuna uno. Questo piano uscirà nel secondo trimestre del 2017.

Per me questo sembra Waterfall nel peggiore dei casi, è stato elaborato un piano senza input da parte del team tecnico in cui alcune storie sul piano sono molto poco chiare e nessuna è stata stimata dal team di sviluppo.

Tuttavia, so che il loro argomento sarà "gli stakeholder senior devono avere delle date e deve esserci un piano, non possiamo semplicemente lavorare da un arretrato". Per me questo sembra che gli stakeholder senior non abbiano acquistato Agile e quindi siamo condannati a non implementarlo a un livello inferiore.

È un giudizio equo o sto reagendo in modo eccessivo a questo piano !?

C'è una differenza tra rispettare la scadenza e soddisfare tutti i requisiti. È come il vecchio adagio "veloce, buono o economico, scegli due".

Quindi qui hai date fisse per la consegna - va bene, significa che hai una scadenza prestabilita in quanto ciò che consegni alla fine del tuo ultimo sprint sarà il prodotto finale. Ti ricordi che devi sempre rilasciare software funzionante alla fine di ogni sprint, non è vero.

Ciò che può accadere è che al software finale mancheranno alcune funzionalità. Bene, questo succede con tutte le metodologie di sviluppo, cascata inclusa. Tutto ciò che accadrà è che ti verrà assegnato il compito di produrre successivamente una versione di patch, o una versione 2. Ciò presuppone ovviamente che la tua consegna finale sia abbastanza buona!

Quindi le date fisse non sono un modo di lavorare non agile. Agile non significa che c'è un budget illimitato per giocare con i tuoi nuovi strumenti di pianificazione. Significa che dovrai concentrarti sulla consegna, non è mai una brutta cosa.

No. Questo è esattamente il genere di cose che le società non software tendono a fare. Ci sono piani, scadenze e budget. E inevitabilmente fallirà, poiché gli umani fanno schifo nel prevedere il futuro.

Esaminiamo i vari punti qui:

Continuiamo a sentirci dire che lavoreremo in modo agile su un nuovo progetto da parte del senior management.

Se tu fossi Agile, allora avresti dei team auto-organizzati, senza che ti venga detto come lavorare dalla direzione.

Tuttavia, ora hanno escogitato un piano che descrive in dettaglio tutto il lavoro che vogliono che consegniamo con le date rispetto a ciascun elemento e che mostri di nuovo le date con ciò che verrà mostrato in ciascuno di essi.

No. Questa è praticamente l'antitesi dello sviluppo iterativo. Accadrà qualcosa (qualcuno si ammala, qualcuno se ne va, alcuni requisiti sono stati dimenticati, i tuoi server muoiono, qualunque cosa) e quindi perdi uno di questi obiettivi. Ora il management può ricalcolare l' intero piano o rompere la frusta sullo sviluppo.

nessuno è stato stimato dal team di sviluppo.

Così come fa la gestione sapere che questo piano è fattibile a tutti ? In Agile, il lavoro è una trattativa. Il business dice: vorremmo questo. Engineering dice: ok, supponendo XYZ, ci vorranno 3 settimane. Non c'è collaborazione con i clienti in ciò che stai descrivendo. Nessun individuo e interazione.

Per me questo sembra che gli stakeholder senior non abbiano acquistato Agile e quindi siamo condannati a non implementarlo a un livello inferiore.

Non sei necessariamente condannato, ma in caso contrario, è solo una coincidenza. Quando tutto il lavoro si presenta perché il management non può vedere il futuro, perderai le tue date (o produrrai un codice scadente o richiederai più risorse del previsto). Sarà quindi colpa tua . La direzione probabilmente ti spingerà a lavorare più ore per fissare la data, o forse gettare le persone al problema.

Nel migliore dei casi , la gestione è in realtà agile ed è abbastanza intelligente da ridurre la portata. Significa che hanno trascorso tutto questo tempo a costruire un grande piano dettagliato che non ha valore.

Se ci si aspetta che specifici set di funzionalità vengano consegnati in date specifiche, allora no, non si tratta di una gestione del progetto agile. Il project management agile è di natura empirica. Le proiezioni non sono fatte sulla base dei desideri dei dirigenti ma piuttosto sull'analisi delle prestazioni precedenti.

La tua descrizione coincide con quella che considero agile da culto delle merci. L'attenzione si concentra su processi e cerimonie specifici e non sui concetti chiave della gestione dei progetti basata sull'evidenza. Potresti avere un po 'di fortuna nel far capire agli uomini d'affari se lo colleghi a Lean o TPS . Il vero problema che devi risolvere qui è far passare il management alla paura dell'ignoto. La risposta giusta ai dirigenti è "non possiamo dirti ora quando le cose saranno fatte, ma una volta che avremo iniziato a fornire valore, possiamo costruire proiezioni basate sulla nostra esperienza". Gli sviluppatori tendono a dire cose come "è fatto quando è fatto" e "Non so quando sarà fatto". I dirigenti non diranno cose del genere ai dirigenti, li farà sembrare dei nincompoop.

Molto probabilmente, il piano fallirà e dovrà essere rivisto. Il rischio maggiore per il team è che ci sarà una grande spinta a rispettare le scadenze e la qualità ne risentirà. Ad un certo punto non sarai sul bersaglio (molto probabilmente, sarà la prima scadenza) e ci sarà una spinta per colpire quella data. Ci si aspetta un lavoro straordinario e ci sarà pressione per tagliare gli angoli (saltare il test unitario, le revisioni del codice, ecc.) Questa è una pendenza scivolosa e una volta che inizi lungo questo percorso, è un po 'una spirale discendente e le cose diventeranno brutte. La produttività peggiorerà man mano che il progetto continua in questo modo.

Se riesci a convincere il team di sviluppo a presentare un fronte unificato, dovresti davvero respingere e mantenere la linea sulla qualità. La mia esperienza è che i project manager tendono a pensare che l'output del software sia lineare. Cioè, ogni periodo X produrrà Y 'precentage completo'. Cioè, se non sei "completo al 50%" a metà del tempo concesso, i klaxon iniziano a squillare. In realtà, se lo stai facendo nel modo giusto, la prima funzione tende a richiedere molto più tempo della 50a funzione (di dimensioni simili.) Se riesci a superare quel periodo iniziale di crisi di pericolo ("che cosa sta succedendo?", "Io non non vedo nulla da fare! ") probabilmente starai bene.

Benvenuti negli affari reali.

Esiste un vecchio stile di attività, che tendo a definire in modo derisorio "sviluppo tradizionale" e poi c'è un nuovo stile, "sviluppo agile". Se provo a considerare questi come ideali opposti, vediamo una divisione semplice nel mezzo: piani e requisiti vanno nella colonna tradizionale, scoperta ed evoluzione vanno nella colonna agile. È pulito, ordinato e sbagliato.

In realtà, gli affari sono una ricerca del mezzo felice tra i due. È facile dimostrare che entrambi gli estremi in realtà cadono piatti sulla sua faccia. Noi che amiamo Agile dimostriamo con entusiasmo tutti i problemi del puro ideale dello sviluppo tradizionale, e ci sono molti che possono mostrare i molti modi in cui Agile puro cade a pezzi. Le aziende agili di successo sono quelle che trovano il loro particolare equilibrio tra i due. Le aziende tradizionali di successo sono quelle che trovano il loro particolare equilibrio tra i due. Non puoi averne uno senza l'altro.

Anche il nostro benedetto processo SCRUM mostra un equilibrio tra i due. Mentre vi è un chiaro tentativo di massimizzare l'agilità, ci sono alcuni compromessi chiave. Ad esempio, il Product Owner ha il potente compito di difendere tutti i clienti. SCRUM non specifica intenzionalmente il funzionamento dell'interazione. Fa intenzionalmente a cuore il fatto che tutti devono essere pagati alla fine della giornata. È compito del Product Owner creare l'illusione che ciò non abbia importanza.

(È interessante notare che l'agile puro funziona alla grande, purché non vieni pagato fino a quando non produci un prodotto e non ottieni l'accesso alle informazioni proprietarie fino a quando non sei investito. Penso che gli unici ingegneri del software siano a loro agio con questo commercio sono gli imprenditori)

Quindi il management ha dettato quali funzionalità saranno presenti e quando dovranno essere presenti. Va bene. Una frase che ho sentito dire è "il cliente sceglie cosa e quando, il produttore sceglie chi e come". Sei stato registrato per il "cosa" e il "quando". Non hanno dichiarato nulla su chi o come, se non per offrirti la possibilità di usare "Agile" come tuo. Non resta che aiutare il management a capire quante persone dovranno assumere per soddisfare le loro esigenze.

In un mondo perfetto, la tua azienda è agile dall'esterno. Interagisce con i suoi clienti in modo agile, permettendo agli sviluppatori di svilupparsi agilmente per loro. Tuttavia, molto spesso l'azienda deve interagire con l'esterno mentre si sviluppa agilmente all'interno. Nel mezzo c'è sempre una serie complessa di compromessi, unica per ogni azienda.

Personalmente, tratto questa situazione come un banco di prova per chiunque pensi di capire lo sviluppo agile. Ad un certo punto in futuro, dovrai sviluppare un prodotto per una scadenza e quella coppia prodotto / scadenza sarà relativamente fissa. Se un prodotto / termine fisso infrange il tuo processo, puoi davvero dire che eri Agile in primo luogo?

Il mio consiglio: non pensare a questa come una cascata. Controlli ancora il "come". Puoi ancora fare tutti gli sprint rapidi e la prototipazione flessibile per cui Agile è così famosa. Devi solo essere consapevole che la gomma incontra la strada e devi consegnare. Questo è il mondo reale, non il mondo ideale. Sarebbe stato meglio per loro chiederti in primo luogo? Sicuro. Potrebbe non essere stata la tua chiamata. Ci possono essere migliaia di ragioni legate al business per farlo a modo tuo che semplicemente non capisci completamente. Sentiti libero di respingerli, ma capisci che potrebbero avere un'ottima ragione per quello che hanno fatto.

Agile non ti impedisce di pianificare traguardi (ad esempio rilasceremo V 1.0 in 3 mesi), ma ciò che va in ogni traguardo non può essere risolto.

Penso che dovresti reagire dipende dalla natura del progetto. Se il progetto prevede di inviare un uomo sulla luna entro il secondo trimestre del 2017, tutti sarebbero d'accordo sul fatto che è destinato a fallire. Se ritieni di poter consegnare un MVP entro la fine del secondo trimestre del 2017, dovresti lavorare su di esso sprint per sprint.

Se il management pensa che il tuo team stia facendo del suo meglio e puoi mostrare i progressi con ogni sprint, dovresti essere in grado di negoziare per più tempo.

OGNI progetto rilevante per l'azienda presenta vincoli:

• Tempo
• risorse
• Un set minimo di funzionalità previsto

Questo non è altro. Sviluppare agili non significa "le persone ci pagano soldi, quindi possiamo sviluppare tutto ciò che vogliamo quando sarà pronto" - avrai sempre un periodo di tempo. Ci sarà sempre una data con alcuni requisiti minimi e se non vengono rispettati il ​​progetto verrà annullato e verrà chiamato un fallimento. A volte possono essere impliciti, quindi il manager sa "Se non ho un'interfaccia utente funzionante con queste funzionalità dopo 4 settimane, questo progetto è destinato a fallire" - o potrebbero esserci azionisti che fissano un obiettivo.

Esistono molti progetti derivanti dalla legislazione. - Se il governo decide che devi implementare la funzione X fino al 2017 per rispettare una nuova legge, avrai una scadenza non negoziabile e una serie di funzionalità che devono essere pronte. L'unica variabile è la quantità di risorse che la direzione può allocare all'attività. - E in questi progetti, dove la scadenza è una decisione esterna, dovranno controllare i tuoi progressi, ascoltare la tua prognosi e dare il personale ai team o esternalizzare parte del lavoro per raggiungere i loro obiettivi.

Tutto ciò non si oppone allo sviluppo agile. Avrai comunque i tuoi sprint, svilupperai le tue funzionalità nel tuo lasso di tempo. Riceverai sempre le priorità delle funzionalità da un cliente e lavorerai per offrire quante più funzionalità possibile fino alla scadenza.

Se la scadenza verrà effettivamente rispettata con le risorse disponibili è un problema di gestione. Puoi dare la tua prognosi e gli aggiornamenti settimanali / giornalieri dello stato e possono decidere se hanno bisogno di più risorse. Altrimenti continuerai a lavorare negli sprint e consegnerai i runnable - lo stesso di qualsiasi progetto.

Come qualcuno ha già sottolineato prima che il manifesto affermi:

Individui e interazioni sul processo

Vorrei suggerire di dare un'occhiata al piano presentato e suggerire modifiche ad esso. Ricorda che il Manifesto afferma che l'arretrato non è mai definitivo, continua a evolversi.

Quindi potresti portare i tuoi suggerimenti al team. Se hai un ragionamento valido e il team è d'accordo, qualsiasi prodotto proprietario degno del suo sale li prenderà in considerazione e eviterà l'arretrato per riflettere l'opinione di tutto il team.

Questo è il punto in cui potrebbe andare in due modi.

1. Il proprietario del prodotto e l'azienda concordano con il tuo ragionamento e possono aumentare le risorse per rispettare la scadenza se è un'opzione OPPURE possono scegliere di abbandonare alcune funzionalità per rispettare la scadenza.

2. Potrebbero ancora voler attenersi alla propria versione contro l'opinione collettiva della squadra.

Se il risultato è n. 2, questo non è Agile.

Se finisci con il n. 1, direi che il team è sulla buona strada, perché Agile non riguarda solo gli sviluppatori "Rispondere al cambiamento", ma anche il fatto che l'azienda sia in grado di rispondere al cambiamento.

Immagina di chiedere a qualcuno di dipingere un muro, una casa e poi un'intera strada per te, quanto tempo daresti a quella persona per farlo?

Qualunque sia la tua risposta, sbaglierai. Questo è tutto.

Non c'è modo che possano avere ragione sulle date se non chiedessero alle persone che hanno bisogno di fare il lavoro cosa pensano.

A proposito, se si (come squadra) accetta queste date, sei nel torto lì.

Dovresti chiedere un po 'di tempo per lavorare su questa pianificazione insieme alle parti interessate, in modo da poter stabilire le priorità a seconda di quanto sia facile e veloce portare a termine le cose.

Ad esempio, forse il lavoro finale richiederà il doppio di quanto pensassero, ma potrebbero usare una beta molto prima del previsto.

Tutto sommato, non puoi lasciare che le persone pensino che sarai in grado di fare X in Y time se non puoi o potresti essere più veloce, questa è la tua responsabilità per chiarire ciò di cui hai bisogno in termini di dettagli e tempo.

Non è aglie pianificazione n.

Ma se fai finta di non conoscere il piano e lavori solo uno sprint. Potrebbe funzionare aglie.

Ci saranno sempre date e budget. Esiste sempre il rischio che vengano persi o superati e quando ciò accade, dovrai sempre ricorrere a un piano B.

Se hai lavorato in modo agile, il piano B è, si spera, l'ultima demo dello sprint