Come introdurre Agile in una squadra che utilizza metodi non agili rigidi?

Penso che sia un mito che i team di progetto Agile non documentino le loro applicazioni e questo è il primo punto di resistenza che si ottiene in aziende certificate per avere la migliore documentazione secondo i loro standard.

Lavoro in un'azienda certificata ISO-9001, ma eseguiamo anche Scrums su un gran numero di nostri progetti. Nel nostro caso, il cambiamento è arrivato dai responsabili di Project Delivery (cioè persone piuttosto anziane) ed è per questo che viene adottato - al contrario di un Project Manager o Developer che cerca di spingere in questo cambiamento.

Una pratica utile che seguiamo è Documento sufficiente ma continuo . Questo ovviamente significa che non seguiamo tutti i modelli prescritti per il progetto, ma c'è una comprensione consapevole e un accordo su quali sezioni / documenti sono necessari rispetto a quelli che sono solo inutili spese generali.

Avresti quindi bisogno di socializzare questo punto di vista e ottenere l'approvazione del gruppo Qualità o della divisione degli standard o come si chiama.

Il principio Agile è una documentazione "sufficiente". Puoi provare a spingerlo dal cliente per esprimere al team quanto è sufficiente? Il project manager potrebbe parlare con il cliente e capire quali sono le sue aspettative e esigenze organizzative e quindi entrambi documentano la decisione e soddisfano tali aspettative. Se è abbastanza buono per loro (cioè i clienti paganti), allora può essere quello che segui.

Se pensano che Agile non si adatti a progetti di grandi dimensioni, convincili che può farlo - con la decomposizione e lo sforzo parallelo.

Nell'organizzazione di grandi dimensioni, il controllo e la supervisione per i programmi di grandi dimensioni vengono eseguiti eseguendo un ufficio di monitoraggio del progetto (PMO) che conducono una pianificazione convenzionale per la contabilità / contabilità / gestione delle risorse ecc. quindi richiedono molta documentazione, ma possono monitorare i progressi usando pratiche Agile (il grafico di burn-down di SCRUM per uno). Hanno bisogno di sapere come tecniche come l'integrazione continua li aiutano prima piuttosto che dopo, e quindi è meglio per la produttività di tutti fare in modo che i documenti generali siano fuori mano.

Agile è un insieme di abilità che un team può apprendere che è in gran parte ortogonale alle nostre abilità tecniche tradizionali. Ma se si aggiunge questo alle proprie abilità esistenti, ovviamente si può diventare una squadra più efficace. Gli stand-up giornalieri (vale a dire gli incontri di Scrum) non saranno possibili da un giorno all'altro - ma al momento si terranno regolarmente riunioni di gruppo (ad esempio bisettimanali)? Direi iniziare convertendoli a seguire l'agenda delle domande di Scrum (non troppo subdolo;) e comunicare al team più ampio perché questo approccio può funzionare e non significa documentazione lassa / standard scadenti o qualsiasi altro mito.

Prima separerei Scrum da Kanban.

Con Kanban - ed ecco una buona fonte su come farlo bene - il principio è che rispetti il processo in uscita quando inizi. Kanban non è ciò che sostituisci con il processo esistente, ma cosa applichi ad esso. Mappalo, visualizza e imposta alcune condizioni per un miglioramento graduale.

Scrum è fondamentalmente diverso nel senso che è qualcosa che sostituirà il processo esistente.

Un team utilizzato per i cicli SDLC a cascata di 12 mesi (o più lunghi) sta per passare molto tempo a Scrum. Accorciare gradualmente il ciclo a 6- o 3 mesi rilascia treni con scope più piccoli potrebbe essere un utile passaggio intermedio.

Come ogni cosa nuova che proverai a presentare a un'organizzazione, dovrai affrontare una strong opposizione. Sei pronto per essere criticato ed essere il responsabile se fallisce? Devi essere una persona strong. Questo è il prezzo da pagare quando esponi te stesso.

• Chiediti perché vuoi utilizzare Scrum . Hai bisogno di risolvere un vero problema?
• Assicurati che ti impegni perché nessuno lo farà per te. Sarai il proprietario della cosa. Almeno fino a quando non produce effetti positivi nell'organizzazione
• Allenati . Libri e internet non sono abbastanza. Andare prima a un corso o aumentare notevolmente la possibilità di implementare Scrum in modo errato. Il che probabilmente porterà la tua squadra a risultati peggiori rispetto a prima
• vendilo prima alla squadra . Devi avere il loro pieno supporto, ovviamente
• Non proporre una modifica, proponi un test . E consideralo così. Scrum potrebbe non essere adatto alla tua organizzazione (o al tuo team)
• Trova uno sponsor nella top management

Questo è quasi esattamente quello che è successo nella nostra azienda. Abbiamo seguito metodi rigorosi e non agili. Quando è entrato un nuovo Lead Technical Manager, che ha avuto esperienza con SCRUM , ha pensato che sarebbe stato utile provarlo.

Il modo in cui lo abbiamo fatto è stato quello di prendere un piccolo gruppo di sviluppatori (e analisti) per creare un team SCRUM pilota. Abbiamo seguito la rigorosa metodologia SCRUM per circa 4 mesi, dopo di che la società ha riflettuto su ciò che abbiamo fatto, su come lo abbiamo fatto, analizzato sui dati (sapete, tutte le cose che i BA devono fare).

Quello che hanno trovato è stato che il pilota è stato un grande successo. Così hanno creato un'altra squadra che segue Kanban, e anche loro hanno avuto un grande successo. Penso che si parli che il resto degli sviluppatori formino anche team SCRUM / Kanban.

Penso che il pilota sia stato fondamentale. Fornisce il lato strict del business time per valutare e vedere che funziona prima.

Sono un allenatore Agile e una delle chiavi per cambiare le iniziative è il buy-in a tutti i livelli! Questo include dirigenti, team di sviluppo, manager, ecc. Prima di annunciare uno sforzo di cambiamento grande o piccolo suggerirei di far salire a bordo le persone. Fare questo attraverso una conversazione in terza persona è il modo più semplice per le persone di iniziare a sfornare nuove idee. Cos'è la terza persona? Un blog, video di YouTube, presentazione, ecc. In questo modo, le persone possono iniziare a proporre le proprie idee e con la tua influenza saliranno a bordo con un'iniziativa di cambiamento.

Ecco due video furbi che ho usato per suscitare interesse a tutti i livelli nella catena alimentare.

Kanban: link

Scrum: link