Qual è stato il singolo punto di errore riscontrato quando la tua azienda ha deciso di sostituire i processi correnti con SCRUM?
Puoi darmi alcuni esempi di cose che sono andate veramente male quando un'azienda ha provato a introdurre SCRUM? Mi piacerebbe sentire i tuoi aneddoti, qualcosa che hai vissuto tu stesso, il grande errore che hai visto arrivare ma che non hai potuto prevenire.
Ho sentito molta preoccupazione per la
Il più grande problema è l'incomprensione. I guasti più comuni sono:
Solo un team sta facendo Scrum, ma il resto dell'azienda (comprese le vendite, la gestione, le risorse umane) pensa ancora alla vecchia maniera. Esempi:
L'interazione continua con il coinvolgimento del cliente e del cliente è molto importante.
Le risorse umane devono capire che le prestazioni del team sono più importanti delle prestazioni degli individui. KPI deve cambiare a quello.
La definizione della caratteristica è un processo continuo. La definizione del progetto si evolverà durante lo sviluppo dal feedback dei clienti. A causa di tale scadenza del progetto, è possibile modificare il budget richiesto o il set di caratteristiche dei risultati (dopo l'approvazione da parte delle parti interessate).
Il cambiamento è parte del processo.
La stima è un processo continuo che non è possibile dire all'inizio del progetto e che verrà eseguito con tutte le funzionalità (molte delle quali sconosciute all'inizio) entro 5 mesi.
Il team ha il potere di prendere decisioni. Il team si impegna per la quantità di funzionalità fornite durante il prossimo sprint. Questo non può essere richiesto o comandato.
Lo sprint è una zona sicura per la squadra. Una volta che il team si impegna in alcune user story definite, l'impegno non può essere modificato al di fuori del team.
Parte della vecchia struttura organizzativa non ha senso quando ci si sposta in Scrum. Scrum definisce tre ruoli: Scrum master, Product owner, team. Ci sono altri ruoli, ma questi tre sono in genere sufficienti per fornire l'applicazione. Il non senso comune è avere Scrum master, Team leader, product owner e uno o più project manager. Project manager e team leader sono ruoli ridondanti in Scrum.
Il ruolo del supervisore Scrum assegnato da Guy non sta facendo lo Scrum master. Scrum master risolve gli impedimenti. Tutto ciò che disturba la squadra è un impedimento che deve essere risolto al più presto. L'errore più comune è assegnare questo ruolo allo sviluppatore senza alcuna precedente esperienza con Scrum. Questo ruolo sostituisce in parte il project manager comune ma Scrum master non ha potere sul team e Scrum master non richiede alcuna funzionalità da implementare. Scrum master protegge la squadra anche contro il proprietario del prodotto con requisiti irrealizzabili.
Modifica:
Sto aggiungendo una nota importante. Quando si utilizza un approccio agile, il punto principale consiste nel fornire la massima quantità di valore aziendale al cliente il più rapidamente possibile. Ma il cliente (rappresentato dal proprietario del prodotto) descrive qual è il valore aziendale. Quindi non è generalmente vero che non si dispone di analisi o documentazione quando si utilizza Scrum. Se il cliente richiede un'analisi o una documentazione e la contrassegnerà come valore aziendale (ad esempio a causa di progetti su larga scala oa lungo termine che dovrebbero essere migliorati nei prossimi anni), la creerai anche tu. L'approccio più basilare include l'analisi e la documentazione nei criteri di accettazione per le storie degli utenti. L'analisi in questo caso è una comunicazione documentata con il proprietario del prodotto in un modo standardizzato.
Il problema più grande che ho notato in oltre 10 anni di xp e scrum, è quando i team che non sono ancora "abbastanza" agili, decidono di "essere flessibili sull'agile" e iniziano a personalizzarlo, eliminando alcune parti, ecc., senza una chiara comprensione di ciò che fa ogni parte e perché è lì.
Ho visto i team avere più successo con scrum quando fanno le cose dal libro in un primo momento, rispetto alle squadre che cambiano ciò che non "ottengono" ancora.
Ecco quando ottieni cose come "prima sprint, faremo tutti i requisiti, secondo sprint tutto il design, ecc. ecc., ultimo sprint tutti i test". Conosciuto anche come cascata. O anche cose semplici come "sediamoci comunque, cosa c'è in questa faccenda in piedi?"
Qualcosa che ha a che fare con Shuhari ( link ).
Il più grande problema è sempre il buy-in. Se una squadra, o le persone chiave non hanno acquistato (gestione del progetto, controllo qualità, sviluppo, ecc.), Il fallimento è quasi garantito.
Un altro problema correlato sta in realtà rendendo tutte le persone coinvolte consapevoli di ciò che è effettivamente la mischia e di ciò che non lo è.
Ho visto ambienti in cui la gestione dei progetti ha effettivamente preso questo come un biglietto per venire direttamente agli sviluppatori con cambiamenti e aspettarsi che venga fatto domani, dal momento che stiamo usando il grande nuovo processo. Chiunque sia stato in questa situazione o in altri tentativi falliti di implementare Scrum e avere un gusto amaro in bocca. Queste persone a volte proveranno a scoreggere anche il progetto.
Un altro problema che ho riscontrato sono le riunioni in piedi. Otterrai sempre il ragazzo che vuole sedersi durante una riunione di stand .... "Ho una brutta schiena" o qualsiasi altra cosa. Sembra sempre essere lo stesso ragazzo che non ha idea di quale sia l'obiettivo dietro la situazione, e non starà zitto sulla politica o su quello che ha fatto quel fine settimana. Le riunioni in piedi, ho trovato, sono la chiave per una comunicazione efficace. È importante non permettere a nessuno di avvelenare queste riunioni.
Cercando di fare tutti l'analisi per il codice che stavamo sviluppando nello stesso sprint, in realtà lo stavamo codificando.
Ci siamo trasferiti in mischia poco fa e, francamente, il management che gestiva ha trattato ogni mischia come un processo a cascata di 2 settimane. C'era una tale adesione alle regole della mischia che è diventata un processo in sé!
Questo è il problema che trovo, tutte le metodologie agili dovrebbero riguardare la flessibilità per lavorare efficacemente nel modo che fa per te. Non è il modo in cui sono proibiti i processi. Per esempio, abbiamo avuto 2 scrum di 2 settimane, e un team ha detto di ritenere che 2 settimane non fossero sufficienti per fare un buon lavoro (non con i tempi di fermo causati dalla fine della demo di scrum e la revisione iniziale dei requisiti) quindi volevano andare a 3 settimana. Shock horror! La direzione rifiutata perché avevano deciso che 2 settimane per scrum era l'ideale e che ora era documentata nelle procedure di qualità.
Scrum è il meno agile dei metodi agili, che è forse il motivo per cui è stato così popolare - è più facile da vendere alla vecchia guardia. dovresti rimuovere cose che non ti piacciono, ma non penso che ciò accada. Il mio consiglio è di andare con uno più flessibile e meno basato su regole e aggiungere invece le regole che ti servono. Preferisco Crystal per questo motivo.
In definitiva, ricorda il manifesto agile semiarrato .
Il problema più grande è che anche il tuo cliente deve accettare il processo SCRUM e diventare agile. La maggior parte dei clienti vuole sentirlo all'inizio del progetto:
Sembra ragionevole, ma è assolutamente incompatibile con l'agile. Devi spiegare al tuo cliente perché è agile per lui invece di waterfall.
Durante la mia prima visita a SCRUM abbiamo riscontrato due grossi problemi:
1) Non avevamo un proprietario del prodotto. Il nostro capo doveva interpretare il ruolo perché nessuno che avrebbe dovuto essere il proprietario del prodotto avrebbe accettato di farlo. Questo tipo di cose si blocca perché non sempre conosceva le risposte.
2) Non eravamo bravi a tenere conto dei componenti esterni. I nostri primi sprint prevedevano il completamento e la messa in funzione di test automatici completi e abbiamo ripetutamente incontrato dei problemi nell'automazione dei simulatori che stavamo utilizzando. In qualche modo non siamo mai riusciti a capire che questo sarebbe successo.
Il problema principale che devo affrontare nel mio progetto è che la raccolta dei requisiti avviene dopo che abbiamo stimato il prossimo sprint. Stimiamo in base ai criteri di accettazione. Durante la raccolta dei requisiti, scopriamo che l'AC finemente sintonizzata è molto più grande, quindi il compito inizialmente stimato in 8 ore è ora di 24 ore! Quindi posso modificare il mio arretrato di sprint e rivedere le stime e ridurre le mie storie? No signore! Richieste agili che non puoi cambiare lo sprint backlog! Questo è quello che dice il mio TL. Quindi non dovrei essere codificato secondo i criteri di accettazione originali per i quali avevo stimato il tempo di 8 ore! Dio! No! Non puoi farlo! Non sarebbe Agile, vero?