Scrum probabilmente non è appropriato per questa organizzazione.

Dalla Scrum Guide, "Scrum è un framework per lo sviluppo, la distribuzione e il supporto di prodotti complessi". È inoltre progettato per un team di 3-9 membri di un team di sviluppo che lavora al prodotto, un proprietario del prodotto e uno Scrum Master (che può o non può far parte del team di sviluppo) per un totale di 4-11 persone in totale.

Per quanto riguarda lo sviluppo interno, si dice che hanno solo pochi sviluppatori. Se non c'è una squadra abbastanza numerosa da formare uno Scrum Team, non ha senso usare tutto Scrum. Tuttavia, alcune pratiche Scrum potrebbero essere utili per l'organizzazione.

Per lo sviluppo contratto, è possibile che una delle parti esterne utilizzi Scrum. In questo caso, è utile che l'istituto di ricerca conosca le pratiche di Scrum e comprenda i ruoli e il modo in cui funziona. Possono ancora avere bisogno di capire le specifiche di come l'organizzazione di sviluppo esterna usa le pratiche Scrum e altre pratiche, ma può aiutarle a capire come funziona. Ad esempio, capire la necessità di partecipare a Sprint Review o lavorare con l'organizzazione (probabilmente il loro Product Owner) per ordinare il Product Backlog.

18F, un'agenzia di servizi digitali all'interno del governo degli Stati Uniti, ha fatto un sacco di lavoro su come il governo può scrivere contratti per consentire l'uso di metodologie agili in modo coerente con la legge, specificando i risultati generali piuttosto che i requisiti dettagliati per come deve essere fatto il lavoro. Alcune delle loro risorse includono:

• Migliorare i risultati del governo attraverso un formato di contratto agile
• Contratto di acquisto di una coperta flessibile
• Contratto modulare (suddividendo progetti di grandi dimensioni in modulari più piccoli con uno sviluppo agile)
• Il tuo progetto utilizza "agilefall"?

An advantage of agile work methods is that they focus on discovering a solution to a problem after the contract is awarded, that is, during post-award execution, rather than specifying the detailed solution up front as with Part 15. An agile contract tries to specify problems requiring detailed solutions, often as Product Backlog Items that describe high level contract delivery areas.

Understanding this problem, the Office of Management and Budget and Office of Federal Procurement Policy directed agencies to stop using SOWs and shift to using a Performance Work Statement (PWS) for acquiring services. A PWS “should state requirements in general terms of what (result) is to be done, rather than how (method) it is done” Good contracting officers advise agencies that by buying expert services, it implies that you’re not the most knowledgeable in “how” work is done. As the mission owner, you are the expert in “what,” must get accomplished, but conflating the two puts your mission at risk and makes it harder for a contract to provide value.

Fondamentalmente, l'approccio è più simile all'assunzione di un fornitore di servizi che lavori con te per progettare una soluzione, piuttosto che elencare pagine di specifiche dettagliate in anticipo. L'istituzione non assumerebbe un architetto per progettare un nuovo edificio elencando "il progetto deve essere di quattro piani, con una pendenza del tetto di 37º. Il terzo piano deve avere una cucina di 237 piedi quadrati contenente quattro lampade fluorescenti, controllate da una mozione - interruttore della luce sensibile, in un controsoffitto. " Piuttosto, avrebbero un contratto con l'architetto per fornire servizi di progettazione in consultazione con il cliente e fare affidamento sul proprio fornitore, un esperto del settore, per produrre i risultati finali risultanti.

Sebbene i dettagli dipenderanno dall'istituzione e dalle politiche e dalle leggi sugli appalti applicabili, mostra che, in mezzo a tutti i fallimenti dei grandi progetti IT governativi, ci sono gruppi che lavorano per spostare le gare pubbliche per lo sviluppo del software verso più moderni metodologie agili, con sufficiente volontà politica e partner di sviluppo affidabili. Ci vuole un grande cambiamento nel modo in cui tali progetti sono concepiti e gestiti (incluso un sacco di tempo in corso che fornisce feedback agli utenti durante tutto il processo), che l'organizzazione può o non può avere alcun interesse nel perseguire.

Suona tipico. Una volta che l'offerta è stata scritta, le offerte sono state presentate e uno dei contendenti ha ottenuto il contratto ... per quanto riguarda i rappresentanti dell'organizzazione pubblica, il progetto è terminato.

Questo è il motivo per cui molti di questi progetti falliscono. Dopo aver superato il budget.

Il punto che mancano (o almeno non ritengono sia una delle loro preoccupazioni) è che sono stakeholder che dovrebbero partecipare a riunioni e dimostrazioni.

Quindi non c'è alcun conflitto con Agile o Scrum qualunque. È la gente che non riprende i propri ruoli. È il modo in cui funziona il governo che causa questo.

Non è come "vorremmo avere questo sistema e siamo disposti a impegnarci e vedere fino a dove possiamo arrivare".

No. È come se "la nostra democrazia ha deciso che avremo questo sistema, ormai". Il che non lascia spazio a un successo del 100% da un lato e al 100% del fallimento dall'altro. Condannato sin dall'inizio.

È anche un invito al mercato a chiedere tariffe ridicole. Non fare il progetto perché è troppo costoso non è un'opzione, la decisione di farlo è già stata fatta prima che l'offerta fosse scritta.

Giusto abbastanza, anche se gli stakeholder riprendessero i loro ruoli, sarebbero totalmente impotenti. Nessuno di loro avrebbe avuto un bastone credibile da prendere per quelle demo per lo stesso motivo.

No, SCRUM non è incompatibile con le gare pubbliche. Devi dichiarare esplicitamente cosa stai acquistando in una gara pubblica.

"L'acquirente sta cercando di acquistare 10 sprint di 2 settimane di sviluppo, da un team SCRUM con 5 sviluppatori e un master SCRUM certificato (l'acquirente occuperà il ruolo degli stakeholder). Gli sprint si svolgeranno da marzo 2018 a luglio 2018" è un inizio abbastanza ragionevole della gara. Dovrai elencare le competenze del team necessarie, ovviamente, e dare un'idea del progetto su cui lavoreranno, ma è perfettamente accettabile avere una gara d'appalto per assumere una squadra.

Ovviamente, stai rinunciando allo "scope fisso" qui. Questo è tipico di SCRUM, dopo tutto. Con un po 'più di testo nel bando (ma stiamo entrando in territorio legale qui) è possibile consentire una piccola estensione dell'ambito, cioè un piccolo numero di sprint aggiuntivi. Ma se decidi di volere altri 10 sprint dopo i primi 10 sprint, probabilmente dovrai ripetere l'offerta.

È difficile.

Ovviamente non puoi concedere il lavoro con un budget aperto. Quindi devi considerare cosa dovrà essere fatto e quanto sforzo è necessario per fare ciò.

Ora il motivo per cui molti progetti di software falliscono è dovuto al fatto che la risoluzione, il tempo, gli sforzi e la portata in anticipo sono molto soggetti a errori. Ad esempio, una specifica fornita in una gara avrà quasi sempre qualche ambiguità.

Quindi c'è un problema fondamentale non solo con agile, ma con il concetto di appalti aperti per lo sviluppo del software. Le possibilità che qualcuno se ne andasse e creare esattamente quello che volevi, nel tempo che hai specificato, sono basse.

Se consenti una certa flessibilità, puoi migliorarlo.

Sembra che il processo di pubblicazione del bando non sia flessibile. Tuttavia, una volta che il contratto è stato vinta, potresti scoprire che c'è una sala di manovre. Ad esempio, potresti consentire un funzionamento agile, ma dovresti accettare (e ottenere l'autorizzazione legale) che ciò potrebbe influenzare l'ambito.

Ora ritengo che ciò si tradurrebbe in un prodotto migliore in quanto si vedrà cosa sta succedendo presto e si apportano modifiche prima che vengano incorporati nel prodotto. Stretti anelli di feedback e lo sviluppo iterativo possono rendere i prodotti più adatti ai requisiti reali (che possono o meno essere quelli che sono stati messi in gara).

Dipende, ma probabilmente sì.

Sono disposto a scommettere sul denaro che chiunque abbia mai lavorato con un governo in qualsiasi progetto correlato all'IT saprà che, nella pratica, gli "hard limits" descritti nell'offerta non saranno mai soddisfatti. Le cose tendono a superare il budget, vengono ritardate e / o lo scopo è cambiato. Di solito più di quelli. Se i governi sono disposti ad ammettere che questa è la verità e diventano disposti a trattarli come le linee guida che sono, allora la mischia può funzionare davvero bene.

Dall'esperienza personale (sia mia sia della mia rete professionale) so che i requisiti cambiano frequentemente nella maggior parte dei progetti governativi. I comitati responsabili tendono anche ad avere un sacco di feedback quando finalmente vengono coinvolti alla fine di un progetto. Questi sono problemi per cui Scrum è adatto.

Tuttavia, ciò richiederebbe un cambiamento fondamentale nella mentalità da parte dei governi e delle loro agenzie. Nella maggior parte dei paesi, è molto improbabile che questo cambiamento abbia mai luogo. Fino a quel momento, le gare pubbliche continueranno a essere incompatibili con il lavoro con Scrum. (Per quanto mi riguarda, secondo la mia opinione personale le gare pubbliche continueranno ad essere incompatibili con qualsiasi pratiche di sviluppo del software sostenibile, ma questa è un'altra questione per un'altra volta ...)

What would you recommend to this organization?

A questo punto niente.

Ciò che manca qui è la storia di quali problemi il loro processo attuale sta causando loro. Scrum non è qualcosa da raccomandare alla cieca. Ha un punto. Non è una taglia unica.

Chiedete loro quali problemi ha causato il loro attuale processo. Ascolta. Consigliamo solo metodi che risolvano i loro problemi reali. Saranno influenzati dal loro attuale processo. Tinders può sembrare che dettano un processo di sviluppo, ma non lo fanno. Dettano un processo di consegna. Ma questa è una distinzione che questa squadra probabilmente non ha mai dovuto fare prima.

Agile funziona meglio quando i requisiti cambiano di oltre il 3% per tutta la durata del progetto. Altrimenti la cascata è ancora molto efficace. È ancora usato in molti posti oggi. E naturalmente molti sviluppatori di successo non formalizzano mai il loro processo in alcun modo. L'informale funziona bene quando i problemi difficili sono tecnici, non quelli delle persone.

Quindi parla loro del loro attuale processo e dei problemi che ha. Di 'loro che cosa aiutano questi metodi. Ma se non è rotto non aggiustarlo.