Modi efficaci per introdurre Agile sul posto di lavoro?

Nella tua esperienza (aneddotica o meno), quali sono alcuni modi efficaci per introdurre Agile in un'organizzazione o società non Agile?

AGGIORNATO: Qualcuno può parlare di casi in cui hai provato a presentare Agile ma sei stato "abbattuto"? Inoltre, hai una comprensione retrospettiva del perché sei stato "abbattuto"?

È DURO MA NON IMPOSSIBILE. A meno che tu non viva in paradiso. Per i passaggi specifici che potresti prendere, ti consiglio vivamente di prendere una copia di Fearless Change

• Per prima cosa ottieni il supporto della direzione . Se non altro, compenserai questo. Se il livello superiore è tutto 'La scadenza è ieri ..', 'Fine settimana di lavoro per i prossimi 3 mesi', 'Perché stai scrivendo dei test quando dovresti essere codifica? .. possiamo testare più tardi. ' Il dodo semplicemente non volerà.
• Verifica se la cultura della tua organizzazione è adatta per l'agile. Questo è qualcosa che mi è sfuggito .. Prendere in prestito una riga del libro .. Il processo sarà più semplice e veloce se la cultura supporta e alimenta nuove idee, concede alle persone il tempo di apprendere e fare cose nuove, è abbastanza paziente da supportare le innovazioni con benefici a lungo termine e non considera la mancata condanna a morte
• The People : Identificare gli innovatori: early adopters: early early: late late: laggards ratio. I primi 3 sono il tuo pubblico di destinazione inizialmente .. dovrebbero essere circa il 30-40% .. che ti dà la massa critica per iniziare. Il problema è che Agile accende i riflettori sugli elefanti nella stanza ... carenze e problemi diventano facilmente visibili .. se vivi in ​​un luogo che ha avuto una "Bozo Explosion" (per citare il termine di Guy Kawasaki) , il cambiamento sarebbe davvero lento e doloroso .. se non del tutto. Abbiamo la tendenza a presumere che se un'idea è buona, verrà accettata. Non vero. Molte ragioni sociologiche alzano la testa.
• Quindi non provare troppe cose contemporaneamente. Vacci piano .. rilassati . Il trucco è usare un approccio di refactoring-legacy-code-like. Trova piccole ferite qua e là e rattoppale con una benda agile. Assicurati che le persone comprendano la pratica e i benefici e che dovrebbero adottarli nel tempo. Non tutto si attaccherà, ma presto diventerà migliore nel complesso. Quanto tempo dipende da un numero di variabili alcune delle quali sono fuori dal tuo controllo.
• È un enorme investimento personale per realizzarlo . Riesamina se sei disposto a prendere questo impegno e ad affrontare gli alti e bassi che comporta. Inoltre potresti dover consegnare il testimone a qualcun altro o un livello superiore. Preparati a rinunciare al cambio di proprietà per un bene superiore. Non cadere nella sindrome di "È il mio bambino".
• Agile è diverso per ogni squadra, ogni organizzazione .. Non tutto ciò che leggi / proponi funzionerà .. lascia che l'accettazione ti guidi verso le cose che funzioneranno per il tuo scenario. Trova altri modi per compensare le pratiche che non hanno messo radici.

Spero che abbia senso ... come avrai intuito, ci sono stato da un po 'di tempo :)

Ascolta il team, la direzione, le parti interessate e ascolta gli indizi. Probabilmente sentono dolore in diverse aree alle quali Agile si rivolge direttamente.

Attenersi ai suggerimenti che possono alleviare direttamente quei dolori. "Non puoi guarire ciò che non senti" - per così dire.

Questo richiede molto tempo, ma costruire la fiducia è della massima importanza. Con i successi passati e la fiducia sia della tua squadra che del tuo manager, ti guarderanno quando arriva il momento di prendere decisioni.

L'ho visto accadere con i miei occhi, dopo anni di frustrazione nel cercare di convincere le persone a cambiare il modo in cui distribuiamo il software. E mentre sto avendo successi ora, non sono quasi completo. Ci sono tonnellate di aree da migliorare, e attualmente sto ottenendo il maggior successo con l'introduzione di piccoli cambiamenti che affrontano direttamente un tipo di dolore che stiamo provando.

Infine direi solo molto empatico. Ho fatto l'errore di respingere la maggior parte delle idee prima di averle davvero pensate perché non ne avevo letto nel "libro agile XYZ". Ascoltare la tua squadra e cercare di attuare alcuni dei loro suggerimenti farà molto.

In bocca al lupo!

Saltando la tecnica, abbiamo scoperto che trovare un gruppo all'interno dell'organizzazione in grado di acquisire metodologie Agile e fornire un "banco di prova" era cruciale. Avevamo molte persone nella nostra azienda che non capivano la diversa terminologia Agile, erano confuse da termini e processi e c'era paura generale.

Il mio gruppo di ricerca era molto interessato a provare a far funzionare Scrum (insieme ad altre metodologie di tipo Agile). Il nostro interesse ci ha permesso di formare un banco di prova all'interno dell'azienda per provare i vari elementi. Prima abbiamo insegnato molto: parlare in corridoio con le persone, presentazioni per dirigenti aziendali, ecc. Non abbiamo spinto molto, abbiamo educato. Quindi abbiamo chiesto il permesso di provarlo con il nostro gruppo.

Ci saranno molte risposte su come mostrare empiricamente come cose come la programmazione di coppie, lo sviluppo guidato da test, Scrum, ecc. Possano tutti risparmiare tempo, ma alla fine sento che la prova deve provenire dalla tua azienda. Trova un gruppo che puoi usare come banco di prova e fagli fare davvero. Nulla alleverà le paure meglio di mostrare che il tuo gruppo che lo fa accadere.

Riempilo in gola, ma senza che se ne accorgano;)

Ho cercato lentamente di implementare principi agili (principalmente mischia) nel mio posto di lavoro negli ultimi 6 mesi circa. Ho introdotto per la prima volta stand up giornalieri, che hanno richiesto un po 'di tempo per abituarsi a tutti, ma sta andando piuttosto bene. Dato che tutti lavoriamo su programmi diversi che fanno tutti parte di un sistema, è un po 'difficile seguire la mischia per definizione. Il mio prossimo passo è iniziare le riunioni di sprint per seguire ciascuna delle nostre versioni. Facciamo già un ciclo lungo un mese, quindi la durata dello sprint non è un problema. Ho anche intenzione di seguire pienamente i principi della mischia durante il nostro prossimo grande progetto. Sono uno dei due sviluppatori del team per il progetto ed è tutto per il miglioramento continuo. La mia speranza è che il management vedrà i benefici di ciò che sto cercando di realizzare.

Penso che la chiave sia prenderla lentamente. Le persone che sono state nella stessa posizione per anni sono generalmente contrarie al cambiamento intrusivo, ma se riesci a intrufolarlo pezzo per pezzo, non dovrebbero accorgersene. Inizia con i piccoli incontri frequenti anche all'inizio. Tenendoli brevi, la direzione non dovrebbe vederlo come uno spreco di tempo.

Sviluppo guidato dai test. Dimostrare come i test unitari possono accelerare il tuo sviluppo. tempo mentre contemporaneamente rendere il codice più stabile è un ottimo primo passo per bere l'agile Kool-Aid.

Migliora te stesso prima. Veramente. L'esempio è il modo forte di parlare di agile. Inoltre, come qualcuno ha già detto, evita le definizioni tecniche e usa solo termini che manager e dirigenti possono capire. Due settimane invece Sprint; Planning invece Sprint Planning o Planning Game; Product Manager anziché Product Owner e così via. Michele Sliger ha fatto una presentazione straordinaria su Agile in Waterfall Enterprise . Davvero un video assolutamente da vedere. Potresti anche essere interessato ad altri video sull'adozione agile .

Dove sto lavorando, apprendo che Scrum è un buon modo per iniziare agili perché il management lo capisce velocemente. È semplice e ha un bel nome. Ultimamente, quando si fanno Retrospettive, è possibile suggerire pratiche XP come miglioramenti e sarà abbastanza facile che le persone accettino almeno di provarle.

Cordiali saluti

Lo abbiamo introdotto nelle nostre attività di "Manutenzione" (bug, modifiche a basso impatto, ecc.) Come uno sprint di 2 settimane. Quindi gli sviluppatori che stavano lavorando a progetti a lungo termine sono rimasti così come sono, ma abbiamo avuto uno sprint di manutenzione rotante. Quindi tutti hanno provato a usare grafici burn-down e stime del poker senza interrompere i grandi progetti.

Quindi, alla fine di ogni grande progetto, abbiamo iniziato il successivo utilizzando agili sprint di 2 settimane. L'intero processo ha richiesto alcuni mesi prima che tutti fossero in volata, ma ciò significava che c'erano meno interruzioni e tutti potevano "facilitare" il processo

All'interno del team di sviluppo, l'introduzione di Agile è molto più qualcosa su cui hai un certo livello di controllo.

Tuttavia, vedo che il problema principale è il requisito che Agile ha di richiedere un feedback costante dal "cliente" o dal suo rappresentante.

Pertanto, è necessario concentrarsi sul lato dell'educazione delle cose al di fuori del proprio team di sviluppo diretto, poiché è probabile che debbano cambiare il modo in cui lavorano in qualche modo (vale a dire molto più contatto con il team di sviluppo).

Il modo migliore che direi è quello di focalizzare gli innumerevoli benefici derivanti dall'avvio di un processo Agile e trasmetterli chiaramente al tuo cliente. Ovviamente se nella vostra azienda è presente un'area vendite / conti, lo stesso vale in questo caso.

Passaggio 1: assicurati che il tuo progetto abbia un arretrato massiccio e assicurati che sia prioritario

Passaggio 2: introdurre le pratiche SCRUM (iterazioni gestibili, standup giornalieri, scrum-master, proprietario del prodotto, grafici di burndown)

Passaggio 3: ogni iterazione presenta i risultati del team con il burndown

quindi ...
implementa TDD / BDD, accoppia la programmazione, rivedi il codice (tutto molto delicatamente), e se hai una squadra abbastanza brava fai mettere tutti in una posizione (una stanza della squadra, se possibile).

Soprattutto, capisci che ci sarà resistenza (SARÀ), quindi sii pronto a gestirlo.

Un'altra cosa da ricordare è che se fai parte di un'organizzazione (grande o piccola) che nel suo insieme non seguirà queste migliori pratiche, potrebbe volerci un po '(se mai) per sentire che stai facendo progressi.

Le persone sono sempre resistenti ai cambiamenti e passare alla mischia è piuttosto grande. La motivazione e la direzione sono fondamentali.

Il primo passo è motivare le persone a dare una possibilità alla mischia. Ho scoperto che Google Tech Talk di Ken Schwaber è stato molto utile nel far riconoscere alle persone i benefici della mischia fornendo una buona introduzione. Inizia con persone che ritieni siano ricettive al cambiamento, siano essi sviluppatori o manager, in modo da poter dare un po 'di slancio. Avere manager dalla tua parte sarà una necessità ad un certo punto, ma il modo in cui lo gestisci dipende dal tuo ambiente.

Dopodiché, tutti devono essere addestrati, sia che si tratti di leggere un libro o di tenere una serie di lezioni. A meno che le persone non sappiano come funziona la mischia, non puoi iniziare a provare a implementare il processo.

Una volta che le persone sono motivate e hanno un'idea di ciò che devono fare, è necessario tenere la prima riunione di pianificazione e impostare le parti necessarie della mischia (scrummaster, riunioni quotidiane, ecc.).

Mi aspetto che il primo incontro di pianificazione non procederà senza intoppi e sarà un'esperienza di apprendimento per tutti. Anche i primi sprint saranno molto rocciosi e probabilmente in ritardo. La parte fondamentale ora è la disciplina e la perseveranza. Non lasciare che le riunioni quotidiane durino troppo a lungo, mantieni attive le riunioni di pianificazione e assicurati che tutti svolgano correttamente i loro ruoli.

Penso che le persone più resistenti siano le persone che hanno lavorato allo sviluppo del software da molto tempo, o persone che pensano che passando alla mischia, stiano ammettendo di aver fatto qualcosa di sbagliato prima. È un ostacolo difficile da superare, ma penso mostrando loro i vantaggi che puoi convincerli lentamente. Ci vuole solo tempo. Nella mia esperienza, i responsabili di prodotto sono davvero resistenti perché li costringe a essere più chiari sulle loro esigenze e su ciò che vogliono. Ma una volta che vedono come il processo agile li avvantaggi e semplifichi la vita, si imbarcano piuttosto velocemente.

In bocca al lupo!

• Dimostrare successo: vedere la risposta di Mark
• Prestare particolare attenzione ai principi / alle tecniche che potrebbero causare il massimo impatto nell'azienda
• Ricorda che si tratta di principi agili e non di un elenco di controllo del processo

Prima di pensare all'introduzione di uno sviluppo agile, esplora qual è la soluzione migliore per la tua organizzazione / progetto. Se ad esempio stai osservando la mischia, considera se lo utilizzeresti rigorosamente o se una forma più ampia di mischia, o anche un altro metodo del tutto potrebbe adattarsi meglio. La mia risposta è quindi sulla mischia come metodo agile.

Scrum è ottimo per i progetti che richiedono innovazione, dove si sa poco e dove è necessaria la sperimentazione. Non è la soluzione migliore per fare cose come la manutenzione di prodotti esistenti o la gestione di lavori di manutenzione periodica. Fortunatamente, la mischia è una struttura libera e puoi usarla nel modo migliore che puoi.

Per i lavori di manutenzione Kanban potrebbe essere migliore per te o potresti provare solo alcuni elementi di mischia per gestire lo sprint e fare cose come standup giornalieri. Lo chiamo "mischia-ma", "sì, facciamo mischia nella nostra compagnia ma ...". Va bene, non sentirti male.

Per introdurre la mischia corretta nella tua organizzazione è necessario il coinvolgimento del proprietario del prodotto e del portatore di interessi. Se sei una piccola azienda, quel ragazzo potrebbe essere una persona, il capo, e in una più grande un product manager e il capo dipartimento / capo. Vorrei suggerire due percorsi per l'introduzione della mischia:

1) è possibile iniziare a utilizzare Scrum in una forma leggermente più flessibile per gestire immediatamente le code di lavoro esistenti. Ma guarda anche Kanban.

2) iniziare a utilizzare la mischia in una forma più rigorosa su alcuni nuovi progetti che richiederanno innovazione, feedback precoci e dove molto è sconosciuto. Puoi suggerire al capo / proprietario del prodotto che la mischia sarebbe l'ideale per questo nuovo progetto.

Ma ricorda! non si tratta solo di codice, il proprietario del prodotto ha una parte cruciale e deve comprendere e adempiere al proprio ruolo. Ciò significa, ad esempio, non scrivere tutte le specifiche in anticipo, piuttosto iniziare con il minimo, iterare rapidamente, ottenere feedback, apprendere e fornire informazioni e così via. Cerca di lavorare con un product manager che vorrebbe introdurre la mischia come te ma dal lato del proprietario del prodotto, e idealmente dovrebbe essere abbastanza duro da respingere le richieste di gestione e proteggere lo sprint.

Ci vorranno sforzi uniti dallo sviluppo e dalla gestione dei prodotti per introdurre la mischia.

In un progetto così nuovo, cerca di far spostare il nuovo team in una stanza separata e usa le note di post-it per visualizzare il lavoro nei vari stati come arretrato, lavori in corso, ecc. Non impantanarti in strumenti elettronici in questa fase , mantieni le cose il più semplice possibile. Non sentirti sciocco a pianificare il poker con le carte quando inizi anche tu, una volta che la tua squadra sarà in grado di accelerare, probabilmente non le userai solo dicendo i numeri.

Nella mia esperienza, è più semplice introdurre prima la mischia in una forma pura, quindi semplificarla per ulteriori code di lavoro di tipo manutenzione. Al contrario, è più difficile.

Il mio commento finale è di stare attenti a pensare che la mischia sia una panacea dello sviluppo, non lo è. Scrum è un framework utile e semplice per l'innovazione di prodotto, ma esplora altri metodi combinandoli quando la tua azienda lo richiede e non sentirti male.

Alcuni anni fa, ero consulente in una società molto grande (quasi 20.000 dipendenti) che gestiva numerosi progetti software di grandi dimensioni. Ero su uno di loro. Molto critico.

Abbiamo affrontato molti problemi e la pressione è stata fortemente influenzata da noi, il team di sviluppo. I problemi erano comuni all'industria del software, ma il management aveva un'esperienza più orientata all'infrastruttura e pochissima esperienza orientata al software. Quindi tutto era focalizzato su di noi. Ho pensato che sarebbe stata una grande idea parlare alla direzione di Scrum.

Mi sono trovata di fronte a una forte riluttanza, quindi ho lasciato perdere l'idea per un po '. Ma i problemi hanno continuato a sommarsi, quindi con lo sponsor del team leader, abbiamo finalmente deciso di fare Scrum comunque, per dodici.

Chiunque, incluso me, ha avuto esperienza con Scrum. Quindi abbiamo scoperto il framework facendo ...

Oggi, Scrum è generalizzato a tutta l'azienda attraverso un programma gestito da un trainer certificato. Non so se la nostra iniziativa sia stata l'innesco. Detto questo, so che è stata una vera rivoluzione in un'azienda piuttosto rigida.

Penso che per introdurre qualcosa in un'impresa del genere, devi rispettare i seguenti principi:

• Deve cambiare è necessario . Se non vi è alcun motivo convincente che la modifica debba essere effettuata, non vi è alcun motivo per cui i team di gestione in atto per assumersi dei rischi.

• Dobbiamo concentrarci sui problemi della gestione e non parlare dei problemi degli sviluppatori, a meno che non facciano parte delle preoccupazioni della direzione. In altre parole, devi trovare una soluzione per loro, non per te. Mettiti nei panni della direzione. Quali sono le loro preoccupazioni?

• Non dovresti proporre di cambiare l'intera organizzazione in una sola volta . Devi proporre un progetto pilota di cui ti assumerai la responsabilità. Ti consiglio di dare obiettivi realistici, come il significativo aumento della visibilità su ciò che sta accadendo nel progetto. È, IMHO, il principale contributo di Scrum alla gestione del software. Permette al buon senso umano di operare e quindi andare avanti.

• Infine, è indispensabile garantire che le persone esperte abbiano il controllo di questa introduzione. Non limitarti a leggere un libro o due. Devi andare all'allenamento e direi che è piuttosto necessario usare un allenatore esperto. Ovviamente, può essere fatto senza, ma sarà doloroso :)

Se segui i principi e vieni con i fatti, funzionerà. Riguardo ai fatti, ne troverai molti nel libro Software in 30 giorni: come i gestori agili battono le probabilità, deliziano i loro clienti e lasciano i concorrenti nella polvere . È l'ultimo libro dei creatori di Scrum, Ken Schwaber e Jeff Sutherland .

In un post sul blog di Ken sul libro puoi leggere:

Jeff Sutherland e io l'abbiamo fatto. Abbiamo scritto un libro insieme, la nostra prima scrittura congiunta dalla prima pubblicazione di Scrum nel 1995. Cosa ci ha spinto? La domanda che ci viene posta frequentemente:

Come vendiamo Scrum al nostro management?

Sono sempre stato perplesso da questa domanda. Perché dovresti vendere più prevedibilità, produttività, qualità, valore, controllo del rischio, clienti soddisfatti, dipendenti coinvolti e meno sprechi a chiunque nel management? Tuttavia, ho parlato con Jeff e abbiamo pensato che dove c'era fumo, ci doveva essere fuoco.

Abbiamo trascorso l'ultima metà del 2011 a scrivere il libro. Qualsiasi manager, dall'alto verso il basso, può facilmente leggere e leggere questo libro.

[...]

Lo vediamo sempre. (informativa completa: sto sviluppando un'applicazione per la gestione di progetti). Il problema è che le metodologie agili introducono una tensione intrinseca nelle organizzazioni gestite tradizionalmente. In genere, i dirigenti superiori vogliono essere in grado di pianificare in anticipo. Vogliono piani di 3 anni; vogliono progetti adeguatamente stimati; vogliono essere in grado di preventivare l'assunzione di nuove persone; vogliono essere in grado di impegnarsi in traguardi significativi quando si tratta di partner / clienti.

Ma poi il dipartimento R&D decide che andrà agile. Non si tratta più di pianificare in anticipo per due mesi prima di scrivere il codice. Gli sprint saranno brevi e oltre gli sprint si ottengono stime a bassa risoluzione degli elementi presenti nel backlog / roadmap. La R&S si rende conto che i requisiti cambiano troppo frequentemente perché la cascata classica sia efficace, ma i responsabili di prodotto vogliono una visione chiara, ponderata e ben preventivata di come sarà il prodotto tra 12 mesi.

Il problema, quindi, è di riconciliare i due. Come ho detto, vediamo tutto ciò accadere continuamente con i nostri clienti. La nostra soluzione è quindi quella di unificare gli strumenti utilizzati sia per gli sprint che per la pianificazione a lungo termine. Bene, ora ecco che arriva la parte della spina spudorata, quindi sentiti libero di prenderla con un granello di sale. Una delle nostre caratteristiche uniche è che utilizziamo un'interfaccia utente zoomabile per la gestione delle attività. Significa che è molto semplice approfondire alcune storie utente / attività ed elaborarle. (puoi vedere come appare qui ). In realtà non esiste alcun concetto di "progetto" nel nostro sistema. Sono tutte attività che contengono altre attività, che si collegano ad altre attività (un frattale, davvero). Questo crea una bella sfocatura tra storie utente, attività, progetti, epopee, ecc.

In pratica, ciò che fanno molti dei nostri utenti che praticano metodologie agili è creare un piano telescopico che unisce la road map (o backlog) a lungo termine con la gestione degli sprint (o iterazioni) a breve termine. I manager riescono ancora a vedere una bella tabella di marcia stimata delle principali funzionalità in attesa di essere aggiunte, e gli sviluppatori semplicemente ingrandiscono più profondamente e si occupano delle attività di lavoro reali. Uno dei vantaggi di questo è che riduce la quantità di "contrattazione" che ha luogo quando i manager rivedono il piano di lavoro. Invece del team di sviluppo che fornisce solo stime molto approssimative (ad esempio "4-6 settimane!"), Hanno la possibilità di ingrandire ciascuna storia utente in questione e suddividerla in blocchi più piccoli. Quando lo fai, all'improvviso c'è meno spazio per contrattare. Passi 10 minuti a scomporre una user story di 5 settimane in blocchi di circa 1 giorno di dimensione, e all'improvviso l'argomento non è "no, puoi farlo più velocemente. no non possiamo. sì, puoi." ma "ecco cosa comporta questo sforzo, incluso tutto il lavoro nascosto che la stima iniziale non ha preso in considerazione. Cosa suggerisci di eliminare? Assicurazione della qualità? Test? Formazione del nuovo ragazzo? Impostazione dell'ambiente di costruzione?".

Questo approccio funziona fintanto che stai utilizzando uno strumento che ti consente di modificare i piani con la stessa rapidità con cui li redigi inizialmente. Qual è la vera ragione per cui la gente in questi giorni detesta la cascata. La maggior parte dei sistemi rende estremamente difficile rifare completamente i piani esistenti e le persone si rifiutano molto razionalmente di perdere tempo in questa attività.

Ok, penso che questo si stia trasformando in un campo di vendite, quindi mi fermo adesso. :)