Come posso gestire un team di scrum controproducente?

Backstory:
ho lavorato come parte di questo team negli ultimi tre anni e in questo periodo abbiamo avuto tre diversi Scrum Master che hanno gestito tutto in modo diverso.

A causa di questo cambiamento in Scrum Masters e del loro modo di gestire lo spettacolo, il mio team ha lasciato intorpidito l'idea di Scrum perché i principi non sono stati applicati in modo coerente e uno degli Scrum Masters era una persona che non crede nell'agile sviluppo e appena tenuto eventi e manufatti come un principiante per rispettare le decisioni dell'azienda.

Ora i membri del mio team sono infastiditi e annoiati quando facciamo eventi Scrum e una persona in particolare è molto verbale al riguardo.

Presente:
due mesi fa la compagnia mi ha nominato Scrum Master del mio team a causa della mia dedizione al lavoro agile e dei suoi principi.

Sto soffrendo molto sotto la pressione atmosferica dei membri del mio team riluttanti a fare Scrum.

Come accennato, sono infastiditi dall'intero processo, il che mi rende molto difficile perché non sono impegnati nelle conversazioni necessarie per rendere efficaci Planning, Retrospective e Daily Scrum.

Per loro, Pianificare è solo una perdita di tempo, perché ci limitiamo a passare il trabocco nel nuovo Sprint e non completiamo comunque il lavoro, quindi perché preoccuparsi.

Durante la Retrospettiva posso solo sentire che vogliono dire "Smetti di fare Scrum". Una persona lo fa, ma le altre sono silenziose e devo occuparmene ogni volta.

Scrum quotidiano è di nuovo solo una perdita di tempo perché nessuno di loro si preoccupa di parlare e pianificare la giornata. Dicono semplicemente "Ho lavorato sull'attività X ieri e ci lavorerò ancora oggi". E la maggior parte delle volte scherzano solo finché non mi sento più severo.

Sono stato molto grande quando si tratta di come hanno trascorso il loro tempo durante questi eventi. Ma sto morendo dentro perché ho una passione per questo e a loro non importa più.

Oggi la persona che è sempre contro di me mi ha detto di smettere di dire "Hanno detto che è quello che si sono impegnati per questo Sprint" perché, nelle sue parole, "Non completiamo mai uno Sprint. Ci limitiamo a muoverci in compiti e accettarne di nuovi nel prossimo Sprint per riempire una quota. Facciamo KanBan in realtà. Quindi smettila di dirlo. "

Capisco perché lo dice, ma non sembra rendersi conto che è così perché a lui e agli altri membri del team non importa. Funzionano e basta invece di affrontare gli impedimenti. Si lamentano degli impedimenti, ma non fanno nulla al riguardo. E quando provo ad aiutare, lo scrollano di dosso.

A loro importava, ma negli ultimi due anni la loro disponibilità è diminuita più o meno fino in fondo.

Come posso far loro vedere che scherzare e perdere tempo durante questi incontri costa all'azienda un sacco di soldi?

Potresti aver sentito molte statistiche su progetti software falliti e sei giunto alla conclusione che il fallimento non è di natura tecnica. I problemi tecnologici possono essere risolti tramite centinaia di soluzioni tecniche, ma risolvere i problemi nell'atmosfera sul posto di lavoro utilizzando Scrum non funzionerà.

Il mio suggerimento qui è di smettere completamente di considerare questo come un problema tecnico. Non si tratta di Scrum, non di standup giornalieri, sprint, retrospettive o qualsiasi altra cosa del genere. Devi entrare in contatto con il tuo team e trovare un modo di lavorare efficace che soddisfi sia loro che i tuoi superiori.

Se pensano che i quotidiani siano una cattiva idea, non dovresti dire loro di fare dei quotidiani e di provare a punzecchiare il tuo ragionamento. Pensa tu stesso cosa ti offrono i quotidiani. Verifica con il tuo team se valgono anche questi vantaggi. Scopri perché non condividono la tua comprensione, come nel comprendere il loro punto di vista, non nel convincerli di nulla. Quindi controlla se i quotidiani aiutano effettivamente la tua squadra o se puoi ottenere di più con qualche altro meccanismo. La cosa divertente dei maestri Scrum è che sono servitori della loro squadra - potresti benissimo servirli meglio abolendo Scrum del tutto.

In breve, smetti di concentrarti su Scrum e torna invece alle basi dell'agilità. Potresti voler iniziare fin dall'inizio con il manifesto agile : valorizzare gli individui e le interazioni su processi e strumenti.

Nella mia esperienza, i team che sono disillusi devono iniziare con retrospettive efficaci. Ecco perché secondo me le retrospettive sono l'unica parte obbligatoria di un processo agile. Tutto il resto è soggetto a modifiche attraverso le retrospettive.

In retrospettive efficaci, non ti lamenti solo dei tuoi problemi, scegli almeno uno di questi problemi e identifichi possibili soluzioni ad esso, quindi prova quella soluzione nella prossima iterazione. Alla prossima retrospettiva, parlerai di come quella soluzione ha funzionato o non ha funzionato e, se necessario, apporta ulteriori modifiche o scegli un altro problema su cui lavorare.

Quando i membri del team vedranno di avere il potere di effettuare cambiamenti effettivi nel loro processo, diventeranno più disposti a impegnarsi.

Il processo retrospettivo è il motivo per cui se si visitano tutti i team di un'azienda che agisce bene, lo fanno tutti in modo leggermente diverso. Abbiamo alcuni team che fanno Kanban, altri che fanno XP, altri che fanno stand-up solo lunedì mercoledì venerdì.

Se alla tua squadra non piace il modo in cui gestisci i postumi di una sbornia, fai un brainstorming su approcci diversi. Ho conquistato sviluppatori molto riluttanti ascoltando costantemente retrospettive e cercando soluzioni.

Ok, allora cominciamo di grosso - gran parte del problema è con te - senti, ma non ascolti. Il tuo team ti sta dicendo chiaramente quali sono i problemi. Devi affrontarli invece di incolpare la tua squadra.

Pianificazione

Per loro, Pianificare è solo una perdita di tempo, perché ci limitiamo a passare il trabocco nel nuovo Sprint e non completiamo comunque il lavoro, quindi perché preoccuparsi.

Esattamente. Se non riesci costantemente ad assegnare una quantità corretta di tempo alle attività e sono costantemente sottovalutate, ha effetti molto negativi:

• Gli sviluppatori si sentono costantemente sotto pressione.
• "Non riesco a fare nulla in tempo".
• Poiché il processo non funziona, lo considerano giustamente come una perdita di tempo.

Soluzione : correggi le tue stime utilizzando la combinazione di:

• Story Story (come combinazione di tempo e rischio).
• Non consentire attività in uno sprint> 55 SP
• Stime comparative
• Pianificazione basata sulle prove

Come base per questo, è assolutamente necessario tenere traccia del tempo effettivamente impiegato per completare le attività precedenti, tra cui test, scrittura di documentazione, test di scrittura, formazione per l'utente finale, sforzi di integrazione, implementazione. eccetera.

Una volta che hai un tempo totale per una determinata attività, puoi basare il tempo previsto su quelle attività precedenti.

Chiedi a ogni membro se il compito assegnatogli risulta più complicato o più semplice rispetto alla selezione di compiti precedenti, regola il numero di compiti assegnati in base a quello.

Se non hai mai usato SP prima, il mio consiglio è di iniziare con 1h di vero lavoro onesto a dio = 5SP come linea guida. Tieni presente che nel normale ambiente di sviluppo ne otterrai forse 6 al giorno, quindi 30SP / giorno max . Mai e poi mai consentire un compito che richiede più di 2 giorni per salire a bordo. Idealmente, secondo la mia esperienza, dovresti avere 2 compiti al giorno.

Se non pianifichi correttamente, il resto delle tue attività Scrum sembrerà una perdita di tempo (inclusa la pianificazione).

Retrospettiva

Durante la Retrospettiva posso solo sentire che vogliono dire "Smetti di fare Scrum". Una persona lo fa, ma le altre sono silenziose e devo occuparmene ogni volta.

Mi ricorda Daily beatings will continue until morale improves!e due dei lavori passati. Se non rimuovi gli impedimenti, allora hanno ragione che è una perdita di tempo.

Ancora una volta, ascolta ciò che la gente sta effettivamente dicendo. Se i reclami sollevati durante la retrospettiva non vengono affrontati, perché preoccuparsi di farli?

Così:

• Prendi in considerazione le tecniche di Six Thinking Hats per migliorare la comunicazione.
• Riduci il tempo impiegato per Retrospective, massimo 30 minuti.
• Garantire che i reclami sollevati durante la Retrospettiva siano risolti prima di quello successivo.

SCRUM giornalieri

Scrum quotidiano è di nuovo solo una perdita di tempo perché nessuno di loro si preoccupa di parlare e pianificare la giornata. Dicono semplicemente "Ho lavorato sull'attività X ieri e ci lavorerò ancora oggi". E la maggior parte delle volte scherzano solo finché non mi sento più severo.

Sembra che tu abbia due problemi qui: le riunioni SCRUM sono troppo lunghe e la tua pianificazione e la creazione di attività fanno schifo.

Entrambi possono far sembrare che una riunione di mischia sia una perdita di tempo.

Per la lunghezza SCRUM:

• Prova al massimo 15 minuti.
• Prova tutti in piedi.
• Formula fissa:
  • Cosa hai fatto ieri.
  • Cosa stai pianificando oggi.
  • Ciò che i membri del tuo team (non tu!) Dovrebbero sapere sull'attività, come li influenzerà.
• Non preoccuparti degli impedimenti se non hai intenzione di affrontarli.

Questa è una seconda prova che la tua pianificazione compromette la tua situazione - se non hai nulla di specifico da segnalare, ciò significa che di solito il compito è troppo grande e tutto ciò che potresti dire era: ci stavo lavorando.

• Suddividere le attività nei punti elenco.
• Assicurati che le attività siano abbastanza piccole da richiedere meno di un giorno. Idealmente, IMO, l'attività dovrebbe durare ~ 3h ed essere equivalente a circa 13 SP, quindi puoi fare 2 al giorno nella maggior parte delle condizioni.

Trattare con la squadra

Oggi la persona che è sempre contro di me mi ha detto di smettere di dire "Hanno detto che è quello che si sono impegnati per questo Sprint" perché, nelle sue parole, "Non completiamo mai uno Sprint. Ci limitiamo a muoverci in compiti e accettarne di nuovi nel prossimo Sprint per riempire una quota. Facciamo KanBan in realtà. Quindi smettila di dirlo. "

Ha ragione. Tui hai torto. Stai eseguendo SCRUM bastardizzato e / o variazione su Kanban. Non è affatto colpa loro.

Capisco perché lo dice, ma non sembra rendersi conto che è così perché a lui e agli altri membri del team non importa.

Non credo che tu capisca affatto. Potrebbero preoccuparsi meno di prima, ma incolparli non solo non migliorerà nulla, ma potrebbe anche peggiorare la situazione. Se fosse il fondo, potrebbero effettivamente iniziare a scavare.

Funzionano e basta invece di affrontare gli impedimenti.

E qui ho pensato che fare il lavoro fosse il loro lavoro. Mi chiedo chi avrebbe dovuto affrontare gli impedimenti .... oh giusto. Uno Scrum Master. È il tuo lavoro Ti dicono cosa c'è che non va. Lo aggiusti. Non il contrario.

Questo è probabilmente il motivo per cui hai così tanti problemi nella Retrospettiva.

Come posso far loro vedere che scherzare e fare jogging durante queste riunioni costa all'azienda un sacco di soldi?

Ferma gli incontri inutili e loro scherzeranno invece sul raffreddatore d'acqua. Vedi anche il paragrafo sui pestaggi che migliorano il morale. Se usano l'umorismo come meccanismo di difesa, hai qualche problema serio signore!

Entra in uno scherzo - come nel lavoro con la tua squadra, non contro di essa. (A chi importa il denaro della compagnia? Ora sei un azionista?)

Riassumere

La tua cattiva pianificazione sta facendo fallire altre parti di SCRUM e tutti coloro che partecipano miseramente. Vedono che nulla cambia, nulla viene affrontato e le loro lamentele non vengono ascoltate.

Migliora la tua pianificazione e migliorerai il flusso e il morale.

Fai il tuo lavoro rimuovendo gli impedimenti e il tuo team progredirà più velocemente. Chiedere loro che cosa si sente si dovrebbe fare per aiutarli.

Ancora più importante: ascolta la tua gente. Ti hanno già detto (e io) qual è il problema.

In bocca al lupo!

Uno dei principali principi agili è tornare indietro e correggere tutto ciò che è sbagliato. Ciò non include solo il refactoring del codice e correzioni di bug, ma corregge anche il processo di sviluppo.

Quindi, perché non organizzare un incontro con il tuo team e vedere come puoi migliorare il processo di sviluppo? Se ciò significa, nessuna mischia o riunioni standup, allora sia.

Inoltre stai infrangendo uno dei principi del manifesto agile : "Individui e interazioni su processi e strumenti".

D'altra parte, se il tuo team ritiene che lo sviluppo iterativo sia negativo, forse stai sbagliando. Non importa se non finisci tutto ciò che hai pianificato per una iterazione: puoi sempre spostare le cose alla prossima iterazione. Questo è anche il motivo per cui contrassegni le cose come "deve contenere", "bello avere", ecc. Fintanto che fornisci nuove funzionalità, lo stai facendo bene.

Solo un piccolo sgarbo: nella mia compagnia precedente e attuale abbiamo fatto e facciamo ancora riunioni stand-up. Dalla mia esperienza, sono una grande perdita di tempo, dal momento che ogni volta si trasformano in riunioni di report sullo stato di oltre 30 minuti e per me forniscono poche o nessuna informazione. Le persone parlano dei loro problemi, che onestamente non mi interessa.
Nella mia precedente azienda, erano intelligenti, hanno riconosciuto questo problema con gli standup e li hanno fermati subito dopo che le persone hanno iniziato a lamentarsi.

Se ti piace vedere un ottimo video sulla mischia, vedi " Robert C. Martin - La terra che Scrum ha dimenticato ".

Come priorità, guarderei ai compiti che continuano a essere trasferiti. Non raggiungere gli obiettivi è estremamente demoralizzante. Ti impegni troppo? Ci sono fatlog che dovrebbero essere scomposti? Ci sono colli di bottiglia al di fuori del tuo controllo? Hai una chiara definizione di "fatto"? I requisiti sono chiari? Le ore per sviluppatore sono ragionevoli?

Quindi, abbandonare tutto ciò che non funziona. Il processo senza valore è solo un ladro di tempo. Gli standup possono richiedere molto tempo se non sono focalizzati e non forniscono valore al team. Le ore potrebbero essere trascorse meglio altrove. Forse potresti anche dividere la squadra se è troppo grande.

Cerca di capire cosa sta demotivando la squadra. Avere retrospettive e, soprattutto, agire sull'output. È altrettanto importante celebrare i successi e guardare anche ai fallimenti.

Infine, potresti voler valutare gli approcci dei maestri della mischia che hanno preceduto chi potrebbe aver danneggiato il marchio per così dire. Ho lavorato sotto un esperto di scrum tossico prima che ogni problema sollevato si aggiungesse al tuo carico di lavoro, che tu lo sapessi o no. Risultato finale: i problemi sono stati ignorati e tutti hanno lavorato sulla propria piccola area con pochissimo lavoro di squadra.

Chiedere al tuo team di chiudere efficacemente lo sprint (come almeno l'80% delle storie) Sprint su Sprint è secondo me la cosa più importante che puoi fare. Se la tua squadra è costantemente assente, questa è una chiara indicazione che è necessario modificare le stime.

Il team dovrebbe essere ricettivo a questo, anche se può essere molto difficile convincere gli sviluppatori a essere più realistici sulle stime: ho lavorato su un team che non ha chiuso uno sprint per un anno (chiudendo costantemente meno del 50% dello sprint) , sempre sottovalutato e in ogni pianificazione / retrospettiva ero una sola voce a dire che le tue stime fanno schifo, sei scioccamente troppo sicuro di te, smetti di fare scuse per ciò che ti ha impedito di fare la stima e invece aggiusta la stima per riflettere la realtà ( forse più diplomaticamente di così, ma quello era il sentimento di base) - Quando sei in quella posizione, sarei pienamente d'accordo con il curmudgeon della tua squadra che dice che il processo è una perdita di tempo perché stai effettivamente facendo KonBon, indipendentemente da come lo chiami tu. Ad un certo punto, la sua opinione viene convalidata dalle circostanze. E'

Ad un certo punto devi ripristinare le cose, devi far sì che la squadra compensi drasticamente le loro stime solo per mettere in moto il sistema. Una volta che una squadra inizia a chiudere le storie in modo coerente, dovrebbero rendersi conto che il processo Agile è principalmente buonsenso e non riuscire a materializzarlo in qualche modo è dannoso per la produttività. Ma fintanto che l '"impegno" e gli "obiettivi di sprint" non vengono presi sul serio, cosa che accade quando non vengono raggiunti in modo coerente, allora il tutto è una finzione e diventa un drenaggio per la produttività delle squadre.

Far sì che le persone acquistino con uno sprint significativamente diverso (in termini di stime, pianificazione, ect dell'impegno) è difficile, in quel team alla fine l'ho realizzato grazie a due fattori. Uno stava solo raccogliendo i dati da JIRA e dicendo "non ci sono scuse per questo, i numeri sono lontani, sono sempre in una direzione, dobbiamo correggerli, non voglio scuse nel retro, voglio i numeri da sommare "- e l'altro era la pressione dall'alto nella gestione che alla fine ho spiegato loro come ..." Il punto di questo processo è di rendere prevedibile la nostra cronologia di sviluppo. Se completiamo una quantità costante di lavoro ogni Sprint va bene, indipendentemente da quello, la nostra tavola deve riflettere accuratamente ciò che facciamo. Il management è più consapevole del nostro successo rispetto all'impegno che non al nostro output effettivo, per il tuo bene, allinea la proiezione all'output in modo che sembri che stai facendo il tuo lavoro piuttosto che spendere metà di ogni sprint facendo nulla. Più le persone rimosse vengono da questo momento, più ti vedono fallire, le scuse che fai nel retro non sono nemmeno qualcosa di loro competenza, ti vedono solo fallire. "

Alla fine il nostro team ha ottenuto la trazione e le cose hanno iniziato a diventare molto più fluide, basse ed ecco, abbiamo anche iniziato ad avere un output più alto una volta che il processo ha effettivamente iniziato a funzionare. Quindi tl; dr - fai tutto il necessario per iniziare a chiudere gli sprint con un successo relativamente alto. Se non lo fai, il curmudgeon nella tua squadra continuerà a far convalidare la sua resistenza a Scrum dai risultati e alla fine avrà ragione che il tuo processo è in realtà solo una finzione e una perdita di tempo per tutti.

Come Scrum Master ti alleni e guida la squadra per diventare più produttiva. Il framework Scrum è un potente strumento per arrivarci, ma il framework Scrum non deve mai diventare l'obiettivo da solo - altrimenti stai facendo Cargo Cult .

Sembra che tu stia facendo Cargo Cult da 3 anni e la gente abbia capito che è una orribile metodologia di gestione del progetto. La buona notizia è che hai persone intelligenti , hanno capito bene. Sfortunatamente, alcune persone nella tua azienda lo chiamano Scrum, ma ancora una volta hai persone intelligenti , ti hanno persino detto che ciò che il team sta facendo non si chiama Scrum.

La pianificazione è solo una perdita di tempo, perché ci limitiamo a passare il trabocco nel nuovo Sprint e non completiamo comunque il lavoro, quindi perché preoccuparsi.

Esattamente. Perché preoccuparsi? Devi trovare una risposta, o meglio devi cambiare la pianificazione e lo sprint stesso, quindi c'è un punto nella pianificazione. O quello, o smetti di perdere tempo con una pianificazione Sprint inutile. Potresti chiedere alla compagnia di inviarti un corso di Scrum Master, perché gestire una Sprint Planning eccezionale non è banale.

Durante la Retrospettiva [...] gli altri tacciono e devo occuparmene ogni volta.

Se hai a che fare con lo stesso problema in ogni retrospettiva, un popolo non si prende nemmeno la briga (più?) Di parlare durante la retrospettiva, è solo una perdita di tempo. A meno che tu o il tuo team non possiate in qualche modo affrontare i problemi sollevati nella Retrospettiva, l'incontro è solo un demoralizzante del team. Le questioni sollevate nella Retrospettiva devono essere affrontate e ci dovrebbero essere progressi dalla Retrospettiva successiva.

Scrum quotidiano è di nuovo solo una perdita di tempo perché nessuno di loro si preoccupa di parlare e pianificare la giornata. Dicono semplicemente "Ho lavorato sull'attività X ieri e ci lavorerò ancora oggi".

In effetti, perché preoccuparsi di perdere tempo a tutti se lavorano sugli stessi compiti più giorni? Sono assolutamente corretti, il fatto che il Daily Standup sia davvero inutile. Lo Standup facilita una stretta collaborazione su molte attività che possono essere completate ciascuna in mezza giornata o meno. Se le tue attività non possono essere suddivise in questo modo (a causa della pianificazione Sprint interrotta o perché le attività in realtà non si adattano bene con Scrum), non ha molto senso tenere la riunione di 5 minuti di Standup giornaliero (è non più di 5 minuti, giusto?).

"Non completiamo mai uno Sprint. Ci limitiamo a muoverci in compiti e ne assumiamo di nuovi nel prossimo Sprint per riempire una quota. Facciamo KanBan in realtà. Quindi smettila di dirlo."

Capisco perché lo dice, ma non sembra rendersi conto che è così perché a lui e agli altri membri del team non importa.

No, non capisci assolutamente perché lo dice . Hai trovato la causa principale dell'impedimento - che devi risolvere - sbagliato. A loro non importa perché le pratiche di gestione del progetto del team fanno schifo. Preoccuparsi di fare Cargo Cult e fare Cargo Cult in modo più duro non gli impedisce di essere Cargo Cult, una delle peggiori metodologie di gestione del progetto esistenti (a vostra difesa: anche la più utilizzata).

Cosa puoi fare al riguardo?

1. Ascolta le loro preoccupazioni. Ancora una volta, sei benedetto dal fatto che hai persone intelligenti .

2. Aiutali a risolvere gli impedimenti.

E questo è tutto, davvero. Dovrai sperimentare come modificare Sprint Planning, Daily Scrum e Retrospectives per renderli preziosi per il team - anche se volessi lasciare l'etichetta Scrum, hai comunque questi 3 incontri con frequenza e scopo simili in ogni altro metodologia di gestione del progetto là fuori. Per quanto riguarda il modo in cui sperimenterai (frequenza, contenuto, chi ospita la riunione, orario, durata, ecc.), È sorprendentemente facile: chiedi al team. Non forzare le tue idee su di esse, semmai dovresti lasciarle forzare le loro idee su di te (supponendo che possano essere d'accordo su alcune).

Se hai paura di perdere il controllo, imposta prima alcuni limiti, ad esempio:

• Le etichette delle riunioni rimangono le stesse.
• Le riunioni si svolgono ancora e la frequenza delle riunioni non può variare di oltre un fattore 2.
• Attualmente stai sperimentando, quindi ogni modifica dura solo 2 sprint, dopodiché ritorni al vecchio schema (meglio dare il tempo in settimane per evitare ambiguità quando vogliono raddoppiare la durata dello sprint).

Penso che tutti stiano citando la stessa riga del Manifesto Agile . Farò lo stesso: "Individui e interazioni su processi e strumenti".

Se tu come master SCRUM vuoi usare SCRUM per fare il lavoro, devi affrontarli come un individuo che interagisce con un altro. Inizia a fare brainstorming su come migliorare il processo. Forse puoi convincerli ad apprezzare SCRUM. Forse possono convincerti a utilizzare un processo diverso. Scopriamolo!

Sembra che il team riconosca già che il sistema attuale non sta facendo il lavoro. Puoi incoraggiarli a credere che possa fare il lavoro? Citi alcuni esempi. Se stai riempiendo eccessivamente lo Sprint in modo che coli sempre ... fermati. È il tuo team SCRUM. Aiutali a smettere di impegnarsi troppo. Respingi la gestione per ottenere un po 'di respiro. Usa SCRUM per quello che serve. Usalo per presentare i dati al management che stanno spingendo abbastanza forte da perdere il valore del loro processo. Se il management vuole SCRUM come processo, fagli aiutare a costruire lo spazio e l'energia necessari per risolverlo. Come master SCRUM, il tuo compito è risolvere i problemi in modo che il team possa essere produttivo.

Un altro approccio utile può essere quello di generare un nuovo processo all'interno del vecchio. Continuate a far funzionare SCRUM nello stesso modo inutile, ma isolate una piccola parte del programma e dite "in questa parte del nostro programma, scopriremo come utilizzare correttamente gli strumenti". Non esagerare lì. Usa le tue metriche. Concentrati su tutti i tuoi incontri lì. Solo la parte rimanente del tuo progetto "SCRUM" come scudo per mantenere felice la gestione mentre tu e il tuo team "[scoprite] modi migliori di sviluppare software facendolo e aiutando gli altri a farlo." Nel tempo, vorrai mettere sempre più delle tue preziose attività in questo secchio e il vecchio secchio morirà lentamente. Presto avrai un vivace ambiente di sviluppo software e nessuno è più saggio.

O mescolali e abbinali. Ho lavorato su un programma che era anti-scrum. I clienti volevano poter aggiungere nuove attività in qualsiasi momento durante il processo e farci agire immediatamente. (Questa era in realtà una richiesta sana: il loro lavoro era altamente volatile e spesso avevano bisogno di un supporto rapido ... è quello per cui siamo stati pagati). Ovviamente, abbiamo dovuto capire come gestire i loro problemi "perché non viene fatto X quando l'hai promesso nello sprint". La nostra soluzione era in realtà quella di costruire un processo in due fasi. Compiti a lungo termine sono stati inseriti in SCRUM per una corretta definizione delle priorità. I compiti a breve termine sono stati messi in un processo homebrewed che si è concentrato sulla stretta interazione tra cliente e sviluppatore. Resta inteso che i clienti sono invitati a spingerci con noi utilizzando questo processo a breve termine, ma che hanno capito che ciò ha spinto lo Sprint " la timeline, ed era loro proibito aggiungere richieste senza ascoltare e affrontare contemporaneamente i problemi di pianificazione che avevano causato. Risultato? Ha funzionato. La maggior parte dei compiti sono stati inseriti nel processo SCRUM, come dovrebbero essere, e le emergenze hanno interagito perfettamente con loro. L'atteggiamento era "Se vuoi essere un cliente, mettiti in fila per una storia SCRUM. Se vuoi essere un partner, sentiti libero di scendere e lavorare con noi a livello quotidiano e far funzionare questo prodotto !"

Lo dico perché lo so davvero. Si riscontra un problema nel vertice aziendale con overcheduling, incapacità di stabilire le priorità e volontà di aggiungere altri elementi ma non far tornare indietro le date di rilascio.

Dicevo che non esiste una metodologia che possa funzionare in questo modo, ma ora che ho visto Kanban lo dico, ma solo perché Kanban non deve preoccuparsene. Continua a funzionare in caso di sovraccarico. Non porterà risultati più velocemente, ma non è possibile eseguire il backup nelle code di alcun individuo e quindi il problema di gestione ricade sulla gestione. I rapporti di feedback mostrano un sovraccarico, che è corretto.

A causa di questo cambiamento in Scrum Masters e il loro modo di gestire lo spettacolo

Oh bene, questo potrebbe essere il tuo problema. Un maestro Scrum non è lì per gestire uno spettacolo, non è un capo progetto. È lì per assicurarsi che tutte le parti interessate stiano comunicando e che l'operazione sia trasparente.

Mi chiedo da dove provenga la squadra. Potevano essere più o meno autonomi prima che Scrum (incluso l'inevitabile maestro Scrum) venisse lasciato cadere su di loro? Perché è stato introdotto Scrum in primo luogo? Cosa avrebbe dovuto risolvere?

Scrum dovrebbe fornire una guida e il tuo team sta chiarendo che non lo percepiscono come utile in alcun modo. A loro non importa la guida, la considerano una perdita di tempo inappropriata. Apparentemente almeno un decisore pensa di dover essere guidato comunque. Chi? Perché? Hanno un punto?

Questo è un problema non limitato al software.

In qualsiasi ambiente di lavoro, ci saranno persone diverse con personalità e abilità diverse. Anche se Scrum fosse un metodo perfetto, ci sarebbero comunque persone contrarie a causa delle loro personalità e abilità.

Gli sviluppatori gestiscono compiti difficili in modo razionale. Per essere in grado di farlo, ogni sviluppatore avrà il suo modo di gestire tali cose che possono rivelarsi come avversione a cose come Scrum. Se tutti gli sviluppatori sono stati addestrati da zero esattamente nello stesso modo, potrebbe essere molto più semplice utilizzare un modello, ma in caso contrario è necessario un adattamento sul lato sviluppatore o sul lato gestionale.

Inoltre, ai pensatori indipendenti (sviluppatori e altri specialisti) spesso non piace sentirsi dire come fare le cose perché quello è il loro lavoro ed è facile che si verifichino scontri nell'opinione pubblica. Scrum può sembrare un rituale inutile per un pensatore logico che di solito analizza e agisce di conseguenza per ogni problema in questione.

Quanto segue sembra suggerire dove si trova il problema ma non quale sia. C'è sicuramente di più. Posso solo supporre (per esperienza) che gli sviluppatori hanno provato, ma è stato impedito. L'ho visto molte volte in cui gli sviluppatori vogliono risolvere qualcosa ma qualcosa di sistematico (gestione, politica aziendale, ecc.) Lo rende quasi impossibile, quindi si arrendono. A loro non importa davvero o non si preoccupano solo di fare qualcosa che credono non aiuterà (forse per esperienza).

Capisco perché lo dice, ma non sembra rendersi conto che è così perché a lui e agli altri membri del team non importa. Funzionano e basta invece di affrontare gli impedimenti. Si lamentano degli impedimenti, ma non fanno nulla al riguardo. E quando provo ad aiutare, lo scrollano di dosso.

A loro importava, ma negli ultimi due anni la loro disponibilità è diminuita più o meno fino in fondo.

Come posso far loro vedere che scherzare e fare jogging durante queste riunioni costa all'azienda un sacco di soldi?

Se qualcosa viene forzato su altre persone, spetta alle persone forzare il metodo per convincerli dei benefici. Anche se non credo davvero nel forzare le persone a fare le cose, suggerisco come in qualsiasi situazione, ascoltare tutti e sviluppare un metodo che funzioni per l'ambiente attuale.

Scrum non è privo di punti deboli. Naturalmente posso parlare da solo, ma penso che gli sviluppatori lo odino per una buona ragione . È la mia onesta opinione che non debba essere tentato .

Per capire perché, leggi ciò che ogni scrum master dovrebbe sapere sulla mischia . Non è scritto da me, eppure tutto ciò che è rappresentativo della mia esperienza, che posso riassumere solo come puro terrore .

Nel mio caso, ho sofferto soprattutto al punto 5. Fondamentalmente, la mischia mi ha trattato come un bambino e un perdente. Ora, sono un co-sviluppatore intraprendente che aiuta i miei colleghi ... non mi meraviglio di cosa preferirei!

Ora ho un nuovo capo (non scrum), che cammina e parla con le persone, e ne sono così grato ! Parte del motivo per cui questo funziona è che abbiamo anche una chat room (usiamo la maggior parte) per la comunicazione tra sviluppatori. Se qualcuno ha un programma, lo portiamo lì. Le riunioni sono solo per discussioni ad hoc con gli sviluppatori, non per imporre scadenze quotidiane artificiali su se stessi.

Hai ottenuto molte risposte eccellenti. Ecco alcuni altri punti che potrebbero essere utili:

Cambiare metodologia è difficile

È una grande sfida in uno spazio di lavoro, perché stai lavorando sotto l'inerzia di "questo è il modo in cui facciamo le cose" e contro la pressione delle scadenze e delle esigenze aziendali.

Hai ragione nel concludere che il tuo team deve dedicare più tempo alla pianificazione, non di meno ; che la pianificazione è qualcosa in cui il tuo tempo attualmente non è eccezionale e deve migliorare. Il problema è che non ci si arriva semplicemente dettando nuove regole. Le nuove regole sono un nuovo onere prima che diventino di grande aiuto. E se non forniscono immediatamente un grande valore , otterrai elusione piuttosto che cooperazione.

Consiglio vivamente Roy Osherove su questo argomento. Ha un breve riassunto di come pianificare ed effettuare il cambiamento nella tua azienda , e approfondisce l'argomento in modo molto più approfondito in questo video .

L'osservazione di base di Osherove è che tutte le seguenti sfide devono essere soddisfatte:

Motivazione personale: perché qualcuno dovrebbe preoccuparsi di comportarsi in un modo specifico?
Abilità personale: possono letteralmente farlo?
Motivazione sociale: esiste una spinta di pressione tra pari per questo comportamento?
Abilità sociale: le persone intorno a me supportano il mio comportamento e mi aiutano quando ne ho bisogno?
Motivazione strutturale: ci sono premi \ punizioni per il comportamento buono \ cattivo?
Abilità strutturale: l'ambiente fisico supporta questo comportamento?

È necessario imparare a interrompere le attività

Il tuo team ritiene che "Ho lavorato sull'attività X ieri e ci lavoreremo ancora oggi", e sembrano avere ragione, nel senso che i compiti continuano a essere respinti una settimana.

Ciò che è veramente utile qui è imparare come suddividere le attività in piccoli componenti. Quello che stai cercando è la risposta alla domanda "OK, stai lavorando sull'attività X, ma su cosa stai lavorando nello specifico X oggi ?"

Alcune risposte potrebbero essere:

• Sto imparando questa classe di codice legacy.
• Sto risolvendo un bug, i cui sintomi sono (SINTOMI).
  • Se questo è un bug in corso che richiede un po 'di tempo: "Oggi quello che sto per provare è ... (PIANO)"
• Devo cambiare questa interfaccia.
• Sto scrivendo dei test.
• Sto integrando il codice non testato.

... E così via e così via. Essere in grado di osservare cosa si può effettivamente fare in un giorno o in una settimana è uno dei grandi vantaggi di Agile. Ciò significa che in realtà è necessario esaminare la risoluzione dei singoli giorni, non un compito monolitico X che sarà pronto ogni volta che è pronto.

Fatto vs. Consegnato

Un problema comune (con Agile e la pianificazione del posto di lavoro in generale) è che le scadenze tendono a venire dalla direzione, non dagli sviluppatori. Tale scadenza potrebbe essere separata dall'effettivo lavoro da svolgere - e in particolare, è probabile che le cose vengano consegnate il più rapidamente possibile.

Il problema è che "consegnato al più presto" è un processo molto caotico. Incoraggia il taglio degli angoli; codifica "veloce e sporco"; ignorando le linee guida; non ripulire dopo te stesso. Incoraggia una mentalità di "provalo, vedi se funziona. Se sì, consegna. Se no, prova qualcos'altro" - e, così espresso, puoi vedere perché nessuno può prevedere quanto tempo impiegherà qualcosa.

Mentre se si sta lavorando con metodo, se siete rigorosi di pianificazione e testing e così via, allora hai impostato una serie di pannelli e reti di sicurezza. Potrebbe volerci più tempo - stai dedicando molto tempo a cose che non promuovono la consegna immediata e potresti non essere ancora molto bravo in questo tipo di flusso di lavoro - ma sarà molto meno volatile.

Quindi una cosa da porsi è: sono gli sviluppatori a fissare gli obiettivi dello sprint, in base ai bisogni e alle necessità che vedono realmente? O la direzione sta fissando le scadenze, lasciando gli sviluppatori a cercare di inserire i loro impegni in una pianificazione simile allo sprint?

Se agli sviluppatori non viene concesso il tempo di pianificare le cose o di lavorare secondo un piano affidabile, non c'è da meravigliarsi che non possano fare stime utili. :)

Questa potrebbe essere un'opinione impopolare, ma potresti non essere in grado di fare nulla al riguardo.

Posso immaginare che nel corso degli anni dell'esistenza della squadra e del flusso di leader, persone veramente insoddisfatte della squadra, siano andate via. Ciò che hai sono resti di persone che potrebbero lamentarsi, ma non sono interessate a impegnarsi effettivamente per migliorare la situazione. Vogliono solo passare le loro 8 ore di codice di hacking, non interrotto da nessuno e tornare a casa alla fine della giornata. Quello che hai qui sembra essere un serio problema di motivazione. E non è compito di Scrum Master risolvere questo problema. È un problema di chiunque stia pagando quelle persone.

Se questo è davvero il caso, l'unica vera opzione è sbarazzarsi della squadra attuale e ricominciare da zero. Forse lascia una o due persone che pensi siano le migliori della squadra e spara o sposta il resto in squadre diverse. Dovresti almeno discutere questa possibilità con i tuoi superiori.