Un'organizzazione pubblica mi ha chiesto di tenere un seminario informale sul 101 dello sviluppo agile, spiegando termini e concetti di Scrum, Kanban e simili. Lavoro in ambienti agili da circa cinque anni, ma non mi considero un evangelista Scrum.

Dopo il workshop, l'idea è piaciuta. Tuttavia, hanno spiegato che l'approccio probabilmente non si applicherebbe a loro in quanto hanno bisogno di incaricare le società di software esterne di sviluppare software per loro (hanno solo pochi sviluppatori stessi). Questa attività deve essere svolta nell'ambito di una procedura di gara pubblica che descriva il risultato, il prezzo e il calendario. Questo è un requisito legale per richiedere un budget per questa organizzazione (un istituto di ricerca pubblico).

Questi vincoli sembrano in qualche modo contraddittori con i principi fondamentali dello sviluppo agile, no?

Scrum è semplicemente incompatibile in un tale ambiente?

Cosa consiglieresti a questa organizzazione?

Scrum probabilmente non è appropriato per questa organizzazione.

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

Per quanto riguarda lo sviluppo interno, dici che hanno solo pochi sviluppatori. Se non c'è una squadra abbastanza grande da formare una squadra Scrum, allora non ha senso usare tutta Scrum. Tuttavia, alcune pratiche Scrum possono essere utili per l'organizzazione.

Per lo sviluppo su contratto, è possibile che una delle parti esterne utilizzi Scrum. In questo caso, è utile che l'istituto di ricerca sia a conoscenza delle pratiche Scrum e comprenda i ruoli e come funziona. Potrebbero ancora aver bisogno di capire i dettagli di come l'organizzazione di sviluppo esterna utilizza le pratiche Scrum e altre pratiche, ma può aiutarli a capire come funziona. Ad esempio, comprendere la necessità di partecipare a Sprint Review o collaborare 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 lavorato molto 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 funziona deve essere fatto. Alcune delle loro risorse includono:

• Miglioramento dei risultati del governo attraverso un formato di contratto agile
• Accordo di acquisto con coperta agile
• Contratto modulare (suddividere progetti di grandi dimensioni in progetti modulari più piccoli con sviluppo agile)
• Il tuo progetto utilizza "Agilefall"?

Un vantaggio dei metodi di lavoro agili è che si concentrano sulla scoperta di una soluzione a un problema dopo l'aggiudicazione del contratto, cioè durante l'esecuzione post-aggiudicazione, piuttosto che specificare la soluzione dettagliata in anticipo come nella Parte 15. Un contratto agile cerca di specificare i problemi che richiedono soluzioni dettagliate, spesso come articoli arretrati del prodotto che descrivono aree di consegna del contratto di alto livello.

Comprendendo questo problema, l'Ufficio di gestione e di bilancio e l'Ufficio della politica federale per gli appalti hanno ordinato alle agenzie di smettere di usare SOW e di passare a utilizzare un Performance Work Statement (PWS) per acquisire servizi. Un PWS "dovrebbe dichiarare i requisiti in termini generali di ciò che (risultato) deve essere fatto, piuttosto che come (metodo) viene fatto" I buoni agenti contrattuali avvisano le agenzie che acquistando servizi di esperti, implica che non sei il più informato nel "come" il lavoro è fatto. Come proprietario della missione, tu sei l'esperto di "cosa", devi realizzare, ma la fusione dei due mette a rischio la tua missione e rende più difficile per un contratto fornire valore.

Fondamentalmente, l'approccio è più come assumere un fornitore di servizi per lavorare con voi per progettare una soluzione, piuttosto che elencare in anticipo pagine di specifiche dettagliate. 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 un movimento -interruttore sensibile alla luce, in un controsoffitto. " Piuttosto, avrebbero un contratto per l'architetto per fornire servizi di progettazione in consultazione con il cliente e fare affidamento sul loro fornitore, un esperto nel settore, per produrre i risultati finali risultanti.

Mentre i dettagli dipenderanno dall'istituzione e dalle politiche e leggi applicabili in materia di appalti, ciò dimostra che, tra tutti i fallimenti dei grandi progetti IT governativi, ci sono gruppi che lavorano per spostare gli appalti pubblici per lo sviluppo del software verso metodologie agili più moderne, dato 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 per fornire feedback degli utenti durante tutto il processo), che l'organizzazione può o meno avere interesse a perseguire.

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

Ecco perché 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 le parti interessate che dovrebbero partecipare alle riunioni e alle dimostrazioni.

Quindi non vi è alcun conflitto con Agile o Scrum. Sono le persone che non raccolgono i loro ruoli. È il modo in cui funziona il governo a causare questo.

Non è come "vorremmo avere questo sistema e siamo disposti a impegnarci e vedere fino a che punto possiamo portarlo".

No. È come "la nostra democrazia ha deciso che avremo questo sistema, per allora". Ciò non lascia spazio tra il 100% di successo da un lato e il 100% di fallimento dall'altro. Condannato 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 presa prima che la gara d'appalto fosse scritta.

Abbastanza giusto, anche se le parti interessate assumessero i loro ruoli, sarebbero totalmente impotenti. Nessuno di loro avrebbe un bastone credibile da portare a quelle demo per lo stesso motivo.

No, SCRUM non è incompatibile con gli appalti pubblici. Devi dichiarare esplicitamente cosa stai acquistando in una gara pubblica.

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

Naturalmente, ti stai arrendendo allo "scopo fisso" qui. Questo è tipico per SCRUM, dopo tutto. Con un po 'più di testo nel bando di gara (ma stiamo entrando in territorio legale qui) puoi 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 offrire il lavoro con un budget aperto. Quindi devi guardare cosa sarà necessario fare e quanti sforzi sono necessari per farlo.

Ora il motivo per cui molti progetti software falliscono è dovuto al fatto che il fissaggio, il tempo, lo sforzo e l'ambito di applicazione sono molto inclini agli errori. Ad esempio, una specifica fornita in una gara d'appalto avrà quasi sempre delle ambiguità.

Quindi c'è un problema fondamentale non solo con l'agile, ma con il concetto di offerte aperte per lo sviluppo del software. Le possibilità che qualcuno si spenga e crei esattamente ciò che volevi, nel tempo specificato, sono scarse.

Se si consente una certa flessibilità, è possibile migliorare questo.

Sembra che il processo di messa in appalto pubblico non sia flessibile. Tuttavia, una volta che il contratto è stato vinto, è possibile che ci sia spazio per la lotta. Ad esempio, potresti consentire un lavoro agile, ma dovresti accettare (e ottenere l'autorizzazione legale) che ciò potrebbe influire sul campo di applicazione.

Ora credo che ciò comporterebbe un prodotto migliore in quanto vedrai presto cosa sta succedendo e apporterai le modifiche prima che vengano inserite nel prodotto. Stretti circuiti di feedback e sviluppo iterativo possono rendere i prodotti che si adattano meglio ai requisiti effettivi (che possono essere o meno ciò che è stato messo in gara).

Dipende, ma probabilmente sì.

Sono disposto a scommettere soldi che chiunque abbia mai lavorato con qualsiasi governo su qualsiasi progetto relativo all'IT saprà che in pratica i "limiti rigidi" descritti nell'offerta non sono mai tutti soddisfatti. Le cose tendono ad andare oltre il budget, a essere ritardate e / o l'ambito è cambiato. Di solito multipli 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.

Per esperienza personale (sia mia che della mia rete professionale), so che i requisiti cambiano frequentemente nella maggior parte dei progetti governativi. I comitati responsabili tendono anche ad avere molti feedback quando alla fine vengono coinvolti alla fine di un progetto. Questi sono problemi per i quali 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, gli appalti pubblici continueranno ad essere incompatibili con la collaborazione con Scrum. (Del resto, a mio parere, le gare d'appalto pubbliche continueranno ad essere incompatibili con qualsiasi pratica di sviluppo di software sostenibile, ma questa è un'altra questione per un'altra volta ...)

Cosa consiglieresti a questa organizzazione?

A questo punto niente.

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

Chiedi loro quali problemi li ha causati il ​​loro attuale processo. Ascolta. Raccomanda solo metodi che risolvono i loro problemi reali. Saranno influenzati dal loro attuale processo. Gli esca possono sembrare come se dettassero un processo di sviluppo, ma non lo fanno. Stabiliscono un processo di consegna. Ma questa è una distinzione che questa squadra probabilmente non ha mai dovuto fare prima.

Agile funziona al meglio quando i requisiti cambiano di oltre il 3% nel corso della vita del progetto. Altrimenti la cascata è ancora molto efficace. Oggi è ancora usato in molti luoghi. E ovviamente molti sviluppatori di successo non formalizzano mai il loro processo in entrambi i modi. Informale funziona bene quando i problemi difficili sono tecnici, non sulle persone.

Quindi parla con loro del loro processo attuale e dei problemi che ha. Racconta loro di cosa aiutano questi metodi. Ma se non è rotto, non aggiustarlo.