Le scadenze sono agili?

Le scadenze sono una realtà. La maggior parte delle volte devi avere qualcosa entro una certa data. È inevitabile. Senza scadenze, anche i progetti agili possono soccombere alla legge di Parkinson :

Work expands so as to fill the time available for its completion.

In altre parole, se il tuo progetto può andare avanti all'infinito, lo sarà.

In relazione alle scadenze, Agile prova a fare alcune cose:

• Assicurati che tutti possano vedere sempre quanto lavoro verrà svolto entro la scadenza
• Assicurati che le funzioni più importanti siano state completate per prime
• Assicurati che le funzionalità completate siano utilizzabili, nel senso che non dipendono da caratteristiche che non sono ancora state completate
• Garantire che lo sviluppo continui a un ritmo sostenibile

In questo modo, quando arriva l'inevitabile giorno, non hai una pila inutile di codice, ma un prodotto funzionante e testato con, si spera, solo le cose meno importanti non finite. E nessuno è sorpreso dal prodotto finito.

Quindi sì. "Agile" e "scadenze" possono essere perfettamente compatibili.

Le scadenze sono un dato di fatto. Ci sono cose che hanno una data molto ferma.

We need the software by Comdex

o

The games must be on store shelves by Black Friday

e simili. Non si può rimandare il Comdex o il Black Friday - il resto del mondo non funziona in questo modo.

L'obiettivo che Agile ha è che le cose che non soddisfano la scadenza falliscono più velocemente (e questa è una buona cosa), o l'ambito può essere riesaminato prima in modo che le risorse possano essere focalizzate sulla corretta ROI in modo più tempestivo.

La scadenza è una data difficile che viene stabilita con fermezza. Agile è uno strumento che consente di realizzare in anticipo nel ciclo che il software impiegherà il doppio del tempo per svilupparsi come originariamente sperato. È importante che i project manager siano in grado di realizzare questi problemi prima che possano essere aggiunte più risorse, modificare l'ambito di applicazione, adeguare la scadenza (nella situazione in cui è una scadenza piuttosto che solida) o il progetto annullata.

La trasparenza che Agile cerca è quella di mostrare i problemi e progredire in precedenza nel ciclo. Il classico fallimento della consegna a cascata è il caso in cui hai passato mesi a porte chiuse e consegnato il prodotto una settimana prima della scadenza e ti viene detto che stai sbagliando tutto e hai perso mesi (e ora hai completamente superato la scadenza) . L'altro classico fallimento della cascata è scoprire una settimana prima della scadenza che hai ancora mesi per andare. Agile cerca di rendere noti questi problemi all'inizio del processo.

L'altra parte che Agile cerca di fare nel contesto di una scadenza è che anche se solo una parte delle funzionalità concordate sono complete (per qualsiasi motivo), la versione corrente del software è utile e distribuibile.

Ok, we missed having everything we want for the tax software to be deployed on April 15th, but we've got 75% and what we do have works and has been working since we started last November. We've known we are not going to be able to deploy the full feature set since mid December and refocused our efforts on the 80% of the customer base.

Alcune scadenze devono essere rispettate. Obblighi contrattuali, convenzioni, requisiti normativi. Alcuni sono imposti dai manager che vogliono essere in grado di mettere lo sviluppo del software nello stesso grafico della produzione sul loro foglio di calcolo. Qualunque sia la causa, la maggior parte delle persone non può allontanarsi da loro.

Se lavori in un team funzionante, la comunicazione tra gli sviluppatori e il management / stakeholder significa che le persone che hanno bisogno di prendere una decisione sono ben informate per decidere se perdere la scadenza o continuare con lo sviluppo è più importante.

Anche se fornisci storie di utenti completate una volta alla settimana o due volte al mese, probabilmente avrai ancora scadenze. Quando ne viene fuori, assicurati che i tuoi stakeholder sappiano cosa pensi che si adattano entro la scadenza e stabilisci le aspettative.

Se crei costantemente il miglior software possibile con i requisiti che hai attualmente in ogni fase, una scadenza alla fine di ogni sprint dovrebbe teoricamente non essere un problema. In pratica, questo non è normalmente il caso, ma poi nemmeno le scadenze appaiono dal nulla. Le scadenze più importanti che mi siano mai state comunicate mi sono state comunicate molto tempo prima, era l'aspettativa della qualità e delle caratteristiche che rappresentavano il problema.

Scadenze arbitrarie che non hanno conseguenze se mancate non sono molto agili, ma ci sono situazioni in cui, per ragioni al di fuori del controllo del team di sviluppo, le scadenze devono essere fissate e mantenute. Fortunatamente, se le scadenze sono ragionevoli, ci sono molti modi per invertire l'equazione e gestire le scadenze in modo agile.

Le scadenze non sono sempre sbagliate. Come tutti abbiamo appreso da Obi-Wan:

"Only the Sith deal in absolutes"

È giusto dire che nella maggior parte dei casi le scadenze sono sciocche, inutili e certamente non agili, ma sarebbe sciocco dire che è sempre così. Il caso architypal è un software necessario per un uso sensibile al tempo, come il software di monitoraggio delle elezioni. Se il software non è pronto in tempo per l'elezione, non sarebbe sensato né pratico rimandare l'elezione, e non sembra essere molto orientato al cliente solo per dire "Scusa, sembra che abbiamo impiegato troppo tempo. So che questo software per il quale ci stai pagando è completamente inutile, ma le scadenze non sono agili, quindi come puoi davvero resisterci per non averle incontrate? "

Non è molto agile dire ai tuoi clienti di spingerlo per volere qualcosa che tenga conto del tempo, e alla fine della giornata qualcuno dovrà costruire queste cose. Quindi, come possiamo ancora rendere felici i clienti e offrire soluzioni apparentemente ragionevoli alle cose che sono sensibili al fattore tempo? Bene, se lo sviluppo di un software richiede una quantità di tempo incerta e la scadenza non è variabile, qualcos'altro dovrà essere solo variabile per gestire quell'incertezza ...

Se la data di consegna viene mantenuta costante, qualche altro aspetto diventa una variabile. Come tutti sappiamo, nei progetti software può esserci un'ampia incertezza. Qualcosa deve essere reso variabile in risposta a questa incertezza se si vuole avere successo nel progetto, e solitamente questa è la data di consegna. Sembra abbastanza naturale, comunque. Ma questa non è la tua unica opzione. Se sei bloccato a impegnarti in una dura scadenza, il modo per gestirlo è quello di rendere variabili le tue caratteristiche. Dare priorità a un elenco di funzionalità, comunicare chiaramente che non vi è incertezza nella quantità di funzioni che possono essere consegnate entro tale data. Collaborare con il cliente per dare la priorità a queste funzionalità in modo che le più importanti abbiano una maggiore probabilità di essere spedite. Quindi, è normale come al solito, solo quando la scadenza si avvicina a te spedisci tutto ciò che è pronto per essere spedito. In questo modello, la spedizione di più funzionalità è analoga alla spedizione in una data precedente e la spedizione di meno funzionalità è l'analogo della spedizione in un secondo momento.

Se qualcuno vuole fissare una scadenza allora va bene e la scadenza può essere corretta, ma ciò che devono capire è che se la scadenza è fissa, l'ambito deve rimanere flessibile.

tl; dr

In un mondo ideale non avremmo scadenze e semplicemente consegneremo le cose quando saranno pronte. La realtà è che le persone che pagano per le cose di solito vogliono sapere quando hanno finito. Le metodologie agili riconoscono questo, ma riconoscono anche che non tutto può essere bloccato.

Ciò garantisce di mantenere la qualità della consegna al livello giusto per il prodotto. Se fissi una scadenza e un ambito (e un budget), le cose si precipitano e ti ritrovi nel vecchio mondo delle cascate con un pazzo momento di crisi alla fine del progetto. Aumentare il budget di solito non è la risposta, perché l'aggiunta di altri sviluppatori e tester non risolve un problema più velocemente. È una visualizzazione ben nota (e sono d'accordo con l'esperienza), che più persone aggiungi (ciascuna con le loro stesse debolezze) più tempo ci vuole.

Ora, in genere (a meno che non comprendano davvero i metodi Agile) alla persona che paga il software non piace sentirsi dire, possiamo rispettare la tua scadenza ma non possiamo fare tutto quello che vuoi. Questo può essere gestito dando la priorità alle funzionalità che compongono il software. La tua discussione sulla prioritizzazione potrebbe essere simile a:

Dev Team (D): "Please can you prioritise the features you want delivered, with most important first?"

Customer (C): "Everything is priority 1 - I want them all done by the end of next month."

D: "That may be possible, but that may not be possible if requirements change or we discover issues we didn't expect while going through development."

C: "Well what if I give you more money?"

D: "sigh...even with more resource it's going to take them one month to really get going; so if you're not sure how to prioritise the features just tell us which ones you want done first."

C: "Ok I want the big button but make it really big, and then ...etc"

Ora puoi iniziare a lavorare sulle funzionalità in ordine di priorità. Aiuta anche a guardare avanti con la tua squadra a quegli articoli più in basso nell'ordine di priorità e fare alcune stime iniziali, sapendo che potresti cambiarle quando arrivi allo sviluppo quando hai più informazioni. Questo può essere usato per ridefinire o creare la roadmap se non ne hai ancora uno. Questo quindi costituisce la base del piano di rilascio. La roadmap può essere discussa con il cliente riconoscendo che l'ambito può cambiare ma si ha un ordine di cose da consegnare.

Uno dei grandi vantaggi di Agile è che riconosce che le cose cambiano man mano che si procede allo sviluppo e si regola come fanno. Contrariamente agli approcci più tradizionali, questo principio, insieme ai consueti deliverable di sprint e alla comunicazione continua con il cliente, significa che sei naturalmente obbligato a essere più trasparente sul progresso, che è una buona cosa.

A volte al cliente non piace che non otterranno ciò che vogliono entro una certa data, ma capiranno perché e ciò che otterranno sarà di buona qualità. E 6 mesi dopo la consegna delle funzionalità, il cliente non si preoccuperà o ricorderà che hai consegnato entro una certa data, ricorderanno la qualità del prodotto che stanno ancora utilizzando.

Le scadenze sono tradizionalmente basate sul ciclo di vita aziendale. Il software fiscale deve essere installato entro il 15 aprile. Le segnalazioni per il prossimo anno fiscale potrebbero essere necessarie entro luglio.

Il manifesto Agile afferma:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

Le scadenze sono un contratto. Sono un piano. Non rispondono alla velocità della tua squadra. Non cambiano se perdi i tuoi tre migliori sviluppatori.

Le scadenze non sono agili, ma Agile può darci feedback sulle scadenze. Agile, facci sapere se la nostra velocità non ci permetterà di stabilire una scadenza senza che una feature venga tagliata. Inoltre, facci sapere se abbiamo bisogno di assumere una scadenza. E in alcuni casi, facci sapere che una scadenza è impossibile, quando non ci sono caratteristiche da tagliare.

La cosa migliore che un team Agile può fare è lasciare che la loro velocità e il backlog con priorità guidino le scadenze. Ciò fornirà date di consegna stimate. Se quelli cadono fuori dalla scadenza, allora è il momento di parlare seriamente con il cliente e determinare se la scadenza è persino fattibile.

Direi che la consegna di ogni sprint non è negoziabile. Valuta il lavoro, metti le dimensioni delle carte su di esso e carichi abbastanza per mantenere la tua squadra occupata fino allo sprint (e lo sprint dovrebbe essere piccolo - qualsiasi cosa da una settimana a un mese). "Termini di consegna" dovrebbero essere basati sulla tendenza storica del lavoro completato rispetto al lavoro previsto. Agile aggiunge / non rimuove nulla dalla vecchia idea di limitazione "costo / tempo / ambito", semplicemente utilizza l'ambito come metodo preferito di gestione dello slippage sulla base del fatto che una migliore definizione delle priorità rispetto all'ambito è generalmente preferibile a spendere più tempo o denaro.

Alcune persone sembrano confondere agile per "wild west". Agile non significa che tutto vada. Agile significa che smettiamo di mentire a noi stessi su quanto può essere stimato da una persona ragionevole. Fondamentalmente possiamo stimare lo sviluppo del software per circa 2 - 4 settimane nel futuro. Oltre a ciò, sono tutti i vari gradi di tralci e supposizioni. Peggio ancora, il costo di fornire stime per cose più lontane nel futuro si avvicina al costo del solo lavoro. Per qualsiasi ragione, i Project Manager non sono stati storicamente disposti ad ammettere queste verità assolute ai clienti. Agile aggiusta semplicemente quel modo di pensare affermando che esiste un limite al modo in cui possiamo prevedere il futuro nell'ingegneria del software e passa in modo sottile alla "stima basata sull'evidenza" per le previsioni a lungo termine. Dando la consegna certa morta in piccoli blocchi e la consegna basata su prove per cose a lungo termine, otteniamo qualcosa di simile al meglio dei due mondi: possiamo essere veritieri su ciò che siamo in grado di stimare e possiamo fornire stime ragionevoli della consegna futura a lungo termine in base a ciò che abbiamo fornito fino ad ora.

TL; DR

Are deadlines [a]gile?...[D]eadlines are viewed to go hand in hand with [a]gile development.

È probabile che molte risposte si concentrino sugli aspetti ingegneristici della domanda. Invece, affronterò questo da una prospettiva di gestione del progetto.

Una scadenza implica una grande pianificazione iniziale che non è in linea con principi agili. Invece, i modelli di sviluppo iterativi si basano su tempi, cadenza e cicli di rilascio che includono pianificazione just-in-time, ma non sulla "pianificazione generale" generalmente associata al progetto tradizionale. termini di gestione.

È ancora possibile pianificare la release con metodologie agili, ma i piani sono generalmente basati su una stima del numero di iterazioni richieste per raggiungere un obiettivo piuttosto che su obiettivi di gestione stabiliti da fiat. Ciò non vuol dire che le date di spedizione non possano essere impostate, o che gli obiettivi non possano essere raggiunti, ma il modo che sono definiti e soddisfatti è molto diverso rispetto alle tradizionali metodologie di gestione dei progetti.

Pensa alle caselle di tempo, non alle scadenze

However, every project I have ever been on has insisted on setting a deadline. Given that Agile attempts to focus on adaptive planning, flexibility and change; are deadlines Agile?

Questo è un comune fraintendimento dei principi agili. Strutture agili come Scrum e Kanban non sono focalizzate sulle scadenze, ma piuttosto sul time-boxing e una cadenza di consegna sostenibile.

In Scrum, ad esempio, lo Sprint non è una "scadenza". Si tratta di una finestra temporale che viene riempita con la quantità di lavoro che le stime del team si adatteranno entro il time-box senza sovraccaricarlo, e viene quindi "completata" o "non completata" quando scade il time-box. Una volta andato, il time-box è sparito per sempre; qualsiasi lavoro che non viene svolto deve essere riprogrammato e ri-stimato all'interno di un nuovo time box time altrettanto effimero basato sui bisogni attuali (piuttosto che storici) del progetto.

L'importanza del time-box è che crea sia una cadenza prevedibile per le parti interessate per esaminare i progressi, sia un ritmo sostenibile per il team in cui fornire incrementi di valore potenzialmente trasferibili . Il lavoro è incrementale e segue la cadenza; il concetto di una scadenza grande e anticipata non è quindi in linea con i principi agili.

Pianificazione della pubblicazione in base a intervalli di tempo

Forse l'area in cui le persone hanno maggiori difficoltà a mappare i processi agili ai framework tradizionali è nella pianificazione delle release. La pianificazione dei rilasci spesso implica deliverable con scope fissi o fissi. In framework agili, la pianificazione dei rilasci avviene di solito attraverso un processo di stima dove scope è definito esplicitamente come variabile mutabile, mentre le date di rilascio sono stimate in iterazioni.

Ad esempio, un progetto può essere impegnato a rilasciare v1.0 di un progetto alla fine di 20 iterazioni; l'ambito di ciò che viene rilasciato può cambiare nel corso della vita del progetto (dato che l'ambito, le caratteristiche e le priorità possono cambiare all'inizio di ogni Sprint), ma le date obiettivo per ogni release sono fissate nel piano del progetto. Il team si impegna a fornire un incremento potenzialmente spedibile a ogni Sprint e la definizione di Done include controlli di qualità come l'integrazione continua per garantire che il progetto si trovi in uno stato rilasciabile alla fine di ogni Sprint.

Occasionalmente, vedrai progetti agili in cui l'ambito è fisso, ma poiché lo scope è la variabile mutabile nei progetti agili, la data di rilascio può cambiare nel tempo in quanto l'ambito di ciascuna iterazione si adatta, si modifica o si adatta alle esigenze in evoluzione del progetto. Certamente non consiglio l'approccio a scope fisse ai team agili, in particolare i team inesperti, ma ci sono momenti in cui è l'approccio giusto.

Vedi anche

• Come eseguire la pianificazione della versione agile

Pensa alle scadenze come impegno. Il fatto che il progetto sia agile non significa che non dovresti impegnarti a fornire determinate funzionalità per una determinata data.

Ciò che l'agilità porta è ciò che accade nel mezzo. Invece di avere un rigido documento di specifica dei requisiti del software che definisce che dovresti fornire una caratteristica A composta di sotto-caratteristiche B, C, D ed E per una determinata data, ti impegni a consegnare la caratteristica A per una determinata data, dato che al nella fase iniziale, né tu né il tuo cliente siete a conoscenza dell'aspetto della funzione, oppure avreste le sotto-funzioni B, C, D ed E o forse B e C, o una dozzina di altre sottofunzioni.

Immagina un'azienda che in passato ha consegnato merci solo a piccole imprese e ha appena firmato un contratto con una grande azienda. Questa grande azienda utilizza EDIFACT e sembra che l'attuale software di contabilità utilizzato dalla tua azienda non gestisca EDIFACT. Ti viene richiesto di creare un plug-in che lo faccia, dato che contrattualmente, la tua azienda dovrebbe essere pronta per il 15 aprile ^th .

L'agilità significherebbe che i passaggi intermedi saranno consegnati progressivamente e si baseranno su un feedback regolare. Fondamentalmente, mostrerai i tuoi progressi ai contabili, e loro ti diranno cosa ne pensano, quali sono i possibili problemi, ecc. Ciò significa anche che forse, in origine, i ragionieri avevano una grande idea che, pensavano, potevano migliorare sostanzialmente l'esperienza dell'utente. Tre settimane più tardi, è emerso che non solo non migliorava così tanto, ma si tradurrebbe anche in un mese di ulteriore sviluppo. Grazie a Agile, puoi quindi reindirizzare i tuoi sforzi da questa funzione a qualcos'altro, assicurandoti di consegnare in tempo.

Dovresti anche capire il punto di vista del cliente:

• Spesso le aziende hanno bisogno di una data di consegna specifica. Ad esempio, non puoi offrire il servizio di streaming online dei giochi olimpici dopo la fine dei giochi olimpici. Dal punto di vista del business, questo è semplicemente un fallimento, con enormi conseguenze negative.

• Senza un impegno, è una tentazione per uno sviluppatore o un subappaltatore essere perfezionista o rendere la priorità del progetto bassa. Sebbene la regolarità degli sprint aiuti, non previene completamente questo rischio.

  Non mi piacciono le scadenze per questo, soprattutto dal momento che le scadenze si verificano molto facilmente, ma capisco ancora perché molte aziende lo facciano. Non è sempre facile vedere che il progetto è in ritardo rispetto al programma osservando solo gli sprint: una scadenza mancante, in questo contesto, potrebbe essere un chiaro promemoria del fatto che qualcosa va fuori controllo e dovrebbe essere affrontato, proprio ora.

Programmazione eXtreme indica la pianificazione del rilascio:

The base philosophy of release planning is that a project may be quantified by four variables: scope, resources, time, and quality.

Che sembra giusto. Dichiara anche che

No one can control all 4 variables. When you change one you inadvertently cause another to change in response. Note that lowering quality to any less than excellent has unforeseen impact on the other 3 variables

E come già notato da br3w5 , l'aumento delle risorse è una soluzione limitata. Probabilmente potresti aggiungere un paio di persone che erano già parte del team se fossero state inviate su qualcos'altro. Ma non puoi semplicemente aumentare le dimensioni del team velocemente e indefinitamente, almeno non senza una riorganizzazione delle squadre che richiede molte volte.

Quindi, con una qualità irriducibile e risorse fisse: una scadenza è un vincolo temporale, significa che è necessario adattare l'ambito. E usare l'agilità ti dà il mezzo per rispettare la scadenza con l'obiettivo più produttivo possibile. Tuttavia, di solito è possibile garantire che parte dell'ambito verrà eseguita in tempo. Questa è la parte in cui puoi stimare con fiducia il suo tempo per essere limitato al di sotto della scadenza. In genere qualcosa che è molto vicino a quello che hai fatto più volte e ha poco conosciuto.

Lo scopo dei metodi di sviluppo del software, una volta compreso correttamente, è di renderci più produttivi concentrando i nostri pensieri e fornendo un linguaggio comune per situazioni tipiche. Riguarda l'ispirazione e l'abilitazione, non il controllo della mente e il senso di colpa.

Seguire un metodo di sviluppo del software senza compromessi letteralmente corrisponde a quello che viene chiamato radicalismo o fondamentalismo in altri contesti. La forma pura di questa aberrazione è raramente vista in pratica perché in genere porta a un rapido fallimento nel mercato. Ma ovviamente quando gli sviluppatori competono nel difficile compito di implementare un metodo specifico, il superamento del mark è un evento naturale.

Il problema è esacerbato dal fatto che i missionari e gli evangelisti si rivolgono principalmente a coloro che hanno ancora bisogno di convincere per usare il metodo; e anche se predicano la moderazione, la natura umana assicura che riceve meno attenzione.

Le scadenze non sono agili, sono:

1) Cascata, e 2) Sbagliato.

Il software e le scadenze non funzionano bene insieme e non hanno mai avuto. In molti modi, i metodi Agile sono una reazione all'enorme problema delle scadenze o dei software mancati, quando è diventato chiaro che la scadenza non poteva essere rispettata (così come i problemi di budget).

Agile tenta di iniettare la realtà nella situazione dicendo "Sai che la scadenza o le caratteristiche stanno per scivolare e / o cambiare, lo sappiamo, quindi scendiamo con il piede giusto e non fingiamo nemmeno".

La chiave è che la scadenza diventa semplicemente una data di rilascio per la prima versione del software. Potrebbe essere ancora scritto nella pietra - diciamo, il software è per uso accademico e DEVE essere utilizzabile dall'inizio del termine - ma ciò che consegnerai non lo è. Hai un prodotto minimo vitale che tutti sono molto sicuri possono essere consegnati da allora, e hai un carico di "vorrebbe avere". Invece di far alzare le mani quando si scopre che l'intera lista non verrà consegnata entro la "scadenza", assicurati di far uscire l'MVP e molti dei "vorrebbero avere" come possibile e quindi valutare il costo / beneficio del resto a quel punto.

Chiunque abbia giocato a giochi per computer per un certo periodo di tempo sa esattamente come funziona! Se la prima versione raggiunge gli standard beta molti giocatori sono contenti, così bassi sono le aspettative di cosa significhi "duri e reali scadenze" nella vita reale.

Quindi le scadenze non sono agili, sono dei passaporti dei tempi in cui la gente pensava che il software potesse essere trattato come l'ingegneria dell'hardware e dell'acciaio. Abbiamo imparato che questo non è né possibile né desiderabile, dal momento che getta via il maggior vantaggio che il software ha sull'hardware: è morbido.

Agile cerca di sfruttare questa morbidezza consentendo agli obiettivi di svilupparsi e cambiare nel corso del progetto in un modo che un progetto di bridge non potrebbe mai avere.

Rispondi "probabilmente no"

Il Project_management_triangle indica che costo, tempo e ambito (e anche qualità) dipendono l'uno dall'altro. ("prendi due e prendi il terzo")

Uno scrum sprint sceglie il tempo fisso (cioè 7 giorni = lunghezza dello sprint) e il costo (ovvero il budget per 7 membri del team) e stima l'ambito (il numero di storie da fare in sprint)

Se la direzione o il reparto vendite cercano di definire tutti e tre (costo, tempo e ambito), allora non è agile nel senso della mischia perché la squadra non può non prometti di raggiungere l'obiettivo (senza violare la qualità = definizione-di-fare)

La gestione professionale cerca di definire costi e tempi e riduce l'ambito, se necessario, se c'è una data fissa da rispettare.

Non si può rispondere a questa domanda in modo semplice e diretto?

Nessuna scadenza non è agile.

Il punto è costruire quello che puoi in un apprendimento della moda iterativo e adattarti man mano che lo fai.

Una scadenza è "devi consegnare x per y" che fallisce su entrambi i fronti in quanto prometti un deliverable fisso in una scala temporale predeterminata (dove agile dice che non siamo sicuri di cosa stiamo provando a consegnare, e l'apprendimento da agile ci insegna che anche se sappiamo che è molto difficile avere certezza sui tempi - o è un problema risolto e non dovremmo farlo comunque).

Avendo stabilito che la risposta alla domanda è "No, le scadenze non sono agili" - allora siamo in grado di avere una conversazione interessante che affronta la questione di "come affrontiamo le scadenze in un contesto agile" e c'è un ci sono molte riflessioni positive nelle altre risposte.

A mio parere, una risposta ragionevole a quest'ultima è che offriremo incrementi di valore presto e spesso e vedremo dove saremo a tempo debito - ma non esiste una taglia adatta a tutti.

Il grado di agilità richiesto nel lavoro di una persona è inversamente proporzionale alla sua posizione nell'organigramma.

"Agile" è buono, per quello che è. Una sorta di "agile" significa "mentalità aperta unita a competenze sufficienti". Sono i grugniti in fondo che devono essere i più agili.

Se, a livello dirigenziale, il capo dai capelli a punta era abbastanza agile da capire che spingere una scadenza indietro di una settimana renderà un prodotto migliore, o renderà il codice più pulito, più privo di bug e più sfruttabile in modo che la compagnia (o la divisione) risparmia due settimane in futuro, quella è una scadenza agile.

Ma come l'interesse personale illuminato, in realtà non esiste.