Come presentare Agile a un team che utilizza metodi rigidi non Agile?

Considera un'azienda certificata con orgoglio per una metodologia non Agile, che la utilizza come punto di vendita ai propri clienti per dimostrare la propria responsabilità.

Come si fa a introdurre progressivamente Kanban o Scrum senza rompere l'intero sistema e continuare a renderli sicuri che possa essere altrettanto responsabile / verificabile ?

So che questo è probabilmente correlato a " Come introdurresti una metodologia agile come Scrum ", ma qui mi chiedo come aggirare / aggirare il fatto che la società imponga un certo modo di gestire l'SDLC con la falsa pretesa che sia l'unico modo per avere una pista di controllo.

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 nelle aziende certificate per avere la migliore documentazione secondo i loro standard.

Lavoro in un'azienda certificata ISO-9001, ma ANCHE facciamo Scrum su un gran numero di nostri progetti. Nel nostro caso, il cambiamento è arrivato dai responsabili della consegna del progetto (vale a dire persone piuttosto senior) ed è per questo che viene adottato - al contrario di un project manager o sviluppatore che cerca di spingere in questo cambiamento.

Una pratica utile che seguiamo è abbastanza documento ma continuamente . 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.

Dovresti quindi socializzare questo punto di vista e ottenere l'approvazione del gruppo Qualità o della divisione Standard o come si chiama.

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

Se pensano che Agile non si adegui a grandi progetti, convincili che può farlo - per decomposizione e sforzo parallelo.

In una grande organizzazione, il controllo e la supervisione di programmi di grandi dimensioni sono realizzati eseguendo un Project Monitoring Offices (PMO) che conducono una pianificazione convenzionale per la gestione dei costi / contabilità / gestione delle risorse ecc., Quindi richiedono molta documentazione, ma possono monitorare i progressi usando le pratiche Agile (la tabella di burn-down 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 evitare documenti generali.

Agile è un insieme di competenze che una squadra può apprendere e che è in gran parte ortogonale alle nostre abilità tecniche tradizionali. Ma se aggiungi questo alle loro abilità esistenti, ovviamente puoi diventare un team più efficace. Standup giornalieri (ad es. Riunioni Scrum) non saranno possibili dall'oggi al domani - ma avresti incontri di squadra regolari (diciamo bisettimanali) al momento? Direi iniziare convertendo quelli nel seguire l'agenda della domanda Scrum (non troppo subdolamente;) e comunicare al team più ampio perché questo approccio può funzionare e non significa documentazione lenta / standard scadenti o qualunque altro mito.

Prima avrei separato Scrum da Kanban.

Con Kanban - ed ecco una buona fonte su come farlo nel modo giusto - il principio è che rispetti il ​​processo di uscita quando inizi. Kanban non è ciò con cui si sostituisce il processo esistente, ma ciò a cui si applica. Mappare, visualizzare e impostare determinate condizioni per un graduale miglioramento.

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

Un team che è abituato a cicli SDLC a cascata di 12 mesi (o più) avrà difficoltà a passare a Scrum. Un accorciamento graduale del ciclo a treni a rilascio di 6 o 3 mesi con portata ridotta potrebbe essere un utile passo intermedio.

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

• Chiediti perché vuoi usare Scrum . Devi risolvere un vero problema?
• Assicurati che TU ti impegni , perché nessuno lo farà per te. Sarai il proprietario della cosa. Almeno fino a quando non avrà effetti positivi sull'organizzazione
• Allenati . Libri e Internet non sono sufficienti. Vai prima a un corso o aumenterai notevolmente la tua possibilità di implementare Scrum in modo errato. Il che probabilmente porterà la tua squadra a risultati peggiori di prima
• Vendilo prima alla squadra . Devi avere il loro pieno supporto, ovviamente
• Non proporre un cambiamento, proporre un test . E consideralo così. Scrum potrebbe non essere adatto alla tua organizzazione (o al tuo team)
• Trova uno sponsor nel top management

Questo è quasi esattamente quello che è successo nella nostra azienda. Abbiamo seguito metodi rigorosi e non agili. Quando si unì un nuovo responsabile tecnico responsabile, che aveva una certa esperienza con SCRUM , pensò che sarebbe stato bello provarlo.

Il modo in cui lo abbiamo fatto è stato quello di prendere un piccolo gruppo di sviluppatori (e analisti) per creare un team pilota di SCRUM. 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 (sai, tutto ciò che i BA devono fare).

Quello che hanno scoperto è che il pilota è stato un grande successo. Così hanno formato un'altra squadra che segue Kanban e anche loro hanno avuto un grande successo. Penso che si parli che anche gli altri sviluppatori formino team SCRUM / Kanban.

Penso che il pilota sia stato fondamentale. Dà il lato rigoroso del tempo di business per valutare e vedere che funziona per primo.

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

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

Kanban: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI