Introduzione allo sviluppo Agile dopo l'inizio del progetto tradizionale

I've been assured that I have complete buy-in from the devs and the business team [...] I have no access to the end users [...]

Una cosa abbastanza chiara è la differenza tra l'essere verbalmente assicurato che tu hai "buy-in", da una parte, e dall'altra parte l'impegno effettivo da chi sponsorizza il tuo lavoro.

Il mio miglior consiglio è di mettere da parte l'etichetta "Agile" del tutto. Metti al bando la parola dalla conversazione nella misura del possibile. Invece, concentrati sulle seguenti cose:

• Quali risultati ti viene chiesto di consegnare (in particolare, non il team)
• Quali sono i criteri di successo per la tua missione (di nuovo, i tuoi anziché quelli del team)
• Che significa hai a tua disposizione (incluso persone, accesso alle persone, tempo, informazioni, budget per la formazione, qualsiasi cosa)

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

Per raggiungere questi obiettivi potrebbe essere necessario introdurre modifiche. Ora si applicano alcune regole empiriche. 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 alla modifica e non sanno se il cambiamento sarà un miglioramento.

Concentrati sulle pratiche che ritieni siano facili da vincere, frutti a bassa attaccatura. Concentrati sulle pratiche che stabiliscono un quadro non solo per implementare il cambiamento, ma per valutare gli effetti del cambiamento e rassicurare le persone che stanno ottenendo miglioramenti piuttosto che regressione. "I radiatori di informazione" sono buoni, così come le retrospettive.

Alcuni di questi cambiamenti potrebbero essere necessari e percepiti come minacciosi, come avere più accesso a persone che hanno informazioni importanti. Non scendere a compromessi su questi: "compra" significa un processo di negoziazione in cui hai effettivamente la possibilità di consegnare ciò che ti viene richiesto, senza essere condotto come un agnello al massacro politico.

Cerca di impostare le cose in modo che sia difficile trasferire la colpa a te se le cose non vanno bene (e molto probabilmente andrà male). Siate consapevoli che ciò potrebbe accadere e preparatevi se ciò accada: conoscete la vostra strategia di uscita.

Per presentare una nuova cosa senza intoppi, devi assicurarti 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 che in genere cercano la novità non ti causeranno alcun problema. Devi assicurarti che le persone più ansiose non vedano il tuo suggerimento come una minaccia per il loro comfort attuale.

Il modo ideale per una squadra di adottare una pratica o un'idea è assicurarsi che l'idea provenga da loro, e non da persone esterne come la gestione o, peggio, alcuni consulenti casuali. Per fare in modo che ciò accada, crea incontri di brainstorming con tutto il 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à preoccupati dall'effetto di un potenziale cambiamento. Questo comportamento è ben noto ai 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 propone spesso di portarlo a casa e restituirlo se cambi idea. Come puoi aspettarti, ci sono pochissimi ritorni. La proposta ha un solo obiettivo: ridurre l'ansia che impedisce alle persone di prendere decisioni. Suggerisci alla tua squadra pratica che provi per un periodo di tempo fisso dopo quello che valuterà il suo effetto.

Riguardo alla tua seconda domanda, ti consiglio vivamente di portare una cosa alla volta.

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

Agile non è per tutti, sembra che alla tua attività piaccia dire "agile" perché è la parola d'ordine più calda. 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 ridisegnare una metodologia utilizzando un progetto già in corso è come provare a cambiare un pneumatico 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 la possibilità di lavorare, ma basandoti su ciò che hai detto, è improbabile che funzioni con la loro cultura consolidata.

A seconda di ciò che desiderano per la documentazione, potresti essere in grado di mostrare che questo è generato automaticamente da uno strumento che stai usando, o è ridondante e il documento B ha il documento informativo che A è stato richiesto di mostrare. È inoltre necessario adeguare i piani per la documentazione, far loro sapere il motivo della modifica delle stime e chiedere loro di ridurre la quantità di documentazione richiesta o 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. Loro non capiscono. Qualcuno non può chiederti di essere più agile e non essere disposto ad andare avanti per la corsa. Hanno aspettative sbagliate. Le cose sono rotte, in anticipo, prima ancora di iniziare. Correggi le aspettative o fallirai. È come se ti chiedessi di guidare 150 MPH e ti do una Chevette per farlo.

Costruisci il tempo / le risorse / i costi della documentazione che vogliono e lascia che vedano fino a che punto spinge il programma.

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