Presentazione dello sviluppo Agile dopo l'avvio del progetto tradizionale

Circa un anno e mezzo fa, sono entrato in un posto di lavoro che ha affermato di fare lo sviluppo Agile. Quello che ho imparato è che questo posto ha adottato diverse pratiche agili (come standup giornalieri, pianificazioni di sprint e recensioni di sprint) ma nessuno dei principi (giusto in tempo / solo una mentalità abbastanza buona, esponendo il fallimento in anticipo, una comunicazione ricca).

Ora mi è stato affidato il compito di rendere il team più agile e mi è stato assicurato di avere un buy-in completo da parte degli sviluppatori e del team aziendale. Come programma pilota, mi hanno dato un progetto che ha appena completato 15 mesi di raccolta dei requisiti, ha un documento di 110 pagine di analisi e progettazione (da considerarsi "scritto nella pietra") e dove non ho accesso alla fine utenti (solo al comitato composto dai gestori degli utenti che non utilizzeranno effettivamente il prodotto).

Ho iniziato in piccolo, dando loro un elenco di risultati attesi per i primi 5 sprint (lasciando indefiniti gli sprint futuri), un elenco di obiettivi per il primo sprint e ho analizzato il documento A&D per ottenere storie utente sufficienti per raggiungere gli obiettivi del primo sprint .

Da allora, hanno chiesto perché non abbiamo tutti i requisiti per tutti gli sprint, perché non ho iniziato a lavorare su cose per il terzo sprint (che considerano più importanti ma si basano sui risultati del primo 2 sprint) e premono per avere ancora più documentazione che il mio intero team IT considera occupato o non correlato a noi (come scrivere il manuale dell'utente in anticipo, documentare tutti i campi di dati da tutti gli sprint in anticipo, e altro ancora lavoro "iniziale").

Questo è stato piuttosto approssimativo per me come nuovo project manager, ma ci sono miglioramenti che ho implementato in modo efficace come scrumban per la gestione delle storie, la programmazione delle coppie e il fatto che l'azienda ci dia test di accettazione dei clienti in anticipo (come parte della documentazione dei requisiti) .

Quindi le mie domande sono:

1. Cosa posso fare per introdurre in modo più efficace il cambiamento in un'azienda resistente?
2. Esistono altre pratiche che posso introdurre dal lato IT per aiutare a mostrare all'azienda i vantaggi di Agile?
3. L'onere della documentazione ci sta strangolando: l'azienda la vede ancora come una strategia di gestione del rischio anziché come un rischio. Cosa possiamo fare per alleviare i loro dubbi e le loro richieste di documentazione (in particolare la quantità di documentazione e la loro necessità per tutto ciò in anticipo)?
4. Siamo in un edificio separato dalla nostra attività, a circa 3 isolati di distanza e si rifiutano di far convivere il loro personale nel progetto b / c che quella persona "non sarà in grado di lavorare sugli altri progetti mentre sono nel nostro costruzione." Si aspettano che andiamo sempre laggiù e raggruppiamo le nostre domande in modo da poterle porre tutte in una volta e non sprecare il tempo di quella persona con "continue interruzioni". Cosa possiamo fare per ottenere una comunicazione più ricca da loro?

Ogni ulteriore consiglio sarebbe apprezzato.

Grazie!

Mi è stato assicurato di avere un buy-in completo da parte degli sviluppatori e del team aziendale [...] e di non avere accesso agli utenti finali [...]

Una cosa da chiarire è la differenza tra l'essere verbalmente assicurati che "si ha il buy-in", da un lato, e dall'altro l'impegno reale da parte di chiunque stia sponsorizzando il proprio lavoro.

Il mio miglior consiglio è di mettere da parte l'etichetta "Agile". Escludere la parola dalla conversazione per quanto possibile. Concentrati invece sulle seguenti cose:

• Quali risultati ti viene chiesto di fornire (in particolare, non il team)
• Quali sono i criteri di successo per la tua missione (di nuovo, i tuoi piuttosto che quelli della squadra)
• Cosa significa che hai a tua disposizione (comprese le persone, l'accesso alle persone, il tempo, le informazioni, il budget di formazione, qualunque cosa)

"Rendere la squadra più agile" non è un obiettivo perseguibile. Non è abbastanza specifico, non è misurabile, non ha condizioni finali. Ciò di cui hai bisogno è qualcosa di specifico: un obiettivo espresso in termini di X percento in meno di difetti, o Y percento delle date di consegna delle tue funzioni effettivamente rispettate, entro la data Z.

Per raggiungere questi obiettivi potrebbe essere necessario introdurre delle modifiche. Ora si applicano alcune regole pratiche. Ogni miglioramento è un cambiamento, ma non ogni cambiamento è un miglioramento. Si dice spesso che le persone resistono al cambiamento, ma in realtà le persone resistono al cambiamento e non sanno se il cambiamento sarà un miglioramento.

Concentrati sulle pratiche che ritieni possano essere vittorie facili, frutti bassi. Concentrati sulle pratiche che stabiliscono un quadro non solo per attuare il cambiamento, ma anche per valutare gli effetti del cambiamento e rassicurare le persone sul fatto che stanno migliorando piuttosto che regredire. I "radiatori delle informazioni" sono buoni, così come le retrospettive.

Alcuni di questi cambiamenti possono essere sia necessari che percepiti come minacciosi, come avere più accesso alle persone che hanno informazioni chiave. Non scendere a compromessi su questi: "buy in" significa un processo di negoziazione in cui hai effettivamente la possibilità di consegnare ciò che ti viene chiesto, non essere condotto come un agnello al massacro politico.

Prova a sistemare le cose in modo che sia difficile spostare la colpa su di te se le cose non vanno bene (e probabilmente molte cose andranno male). Sii consapevole del fatto che ciò può accadere e preparati se ciò accade: conosci la tua strategia di uscita.

Al fine di introdurre una nuova cosa senza problemi, è necessario assicurarsi che le persone non la vedano come una minaccia e permanente .

Molti di noi sono naturalmente collegati per evitare qualsiasi tipo di novità. È biologico Le persone in cerca di novità non ti causeranno mai alcun problema. Devi assicurarti che le persone più ansiose non vedano il tuo suggerimento come una minaccia per il loro attuale conforto.

Il modo ideale per un team di adottare una pratica o un'idea è assicurarsi che l'idea venga da loro, e non da persone esterne come la direzione, o peggio, alcuni consulenti casuali. Per far sì che ciò accada, crea incontri di brainstorming con l'intero team con un solo argomento. L'argomento dovrebbe essere il problema. Nell'incontro, dovrai portare con attenzione le idee e venire con argomenti e fatti.

Non ci piace prendere decisioni su cose permanenti. Siamo già ansiosi per l'effetto di un potenziale cambiamento. Tale comportamento è ben noto nei negozi di animali. L'acquisto di un cane è una decisione molto importante e probabilmente cambierà radicalmente la tua vita. Quando sei al negozio, il venditore ti proporrà spesso di riportarlo a casa e restituirlo se cambi idea. Come prevedibile, ci sono pochissimi ritorni. La proposta ha un solo obiettivo: ridurre l'ansia che impedisce alle persone di prendere decisioni. Suggerisci alla tua squadra di provare a provare per un periodo di tempo fisso dopo quello che ne valuterai l'effetto.

Per quanto riguarda la tua seconda domanda, ti consiglio vivamente di portare una cosa alla volta.

Il tuo problema di documentazione merita il proprio post qui su P.SE e non vedo alcun problema con il fatto che sei in due diversi edifici se entrambi sono disposti a soddisfare regolarmente. Ci sono situazioni in cui una delle parti non vuole assolutamente incontrarsi;)

Agile non è per tutti, sembra che alla tua azienda piaccia solo dire agile perché è la parola d'ordine più alla moda. Prima di tutto, probabilmente sarebbe stata una buona idea spingere per un progetto nuovo di zecca o piccoli progetti di manutenzione per iniziare a rendere il loro processo più simile a vere metodologie agili. Cercare di riprogettare una metodologia usando un progetto già in corso è come cercare di cambiare una gomma nel mezzo di un'autostrada a 8 corsie. Hai bisogno di un modo per dimostrare che la tua attività agile può funzionare, ma hai bisogno di un ambiente in cui abbia una possibilità di lavorare, ma sulla base di ciò che hai detto è improbabile che funzioni bene con la loro cultura consolidata.

A seconda di ciò che desiderano per la documentazione, potresti essere in grado di mostrare loro che questo è generato automaticamente da uno strumento che stai utilizzando, oppure è ridondante e il documento B ha il documento informativo A che è stato richiesto di mostrare. È inoltre necessario modificare i piani per la documentazione, far loro sapere perché le stime stanno cambiando e chiedere loro di ridurre la quantità di documentazione richiesta o di dedicare risorse come un analista aziendale per creare la documentazione.

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

Questo è il tuo problema. Non capiscono. Qualcuno non può chiederti di essere più agile e di non essere disposto a fare un giro. Hanno le aspettative sbagliate. Le cose sono rotte, prima ancora di iniziare. Correggi le aspettative o fallirai. È come se ti chiedessi di guidare 150 MPH e ti do una Chevette in cui farlo.

Costruisci il tempo / le risorse / i costi della documentazione che desiderano e fai loro vedere fino a che punto spinge fuori il programma.

Questo può aiutare a mostrare loro quanto lavoro stanno spingendo nel team di progetto e come questo potrebbe essere ridotto se non lo facessero.