Cosa hai visto andare storto quando hai introdotto SCRUM?

Qual è stato il singolo punto di errore riscontrato quando la tua azienda ha deciso di sostituire i processi attuali con SCRUM?

Potete darmi alcuni esempi di cose che sono andate davvero male quando un'azienda ha cercato di introdurre SCRUM? Mi piacerebbe sentire i tuoi aneddoti, qualcosa che hai vissuto tu stesso, il grande fallimento che hai visto arrivare ma che non hai potuto prevenire.

Sento molta preoccupazione per la mancanza di documentazione sulle decisioni relative ai dettagli di implementazione e sulle dimensioni e sul livello di dettaglio delle storie.

Il problema più grande è l'incomprensione. I guasti comuni sono:

• Solo una squadra sta eseguendo Scrum, ma il resto dell'azienda (inclusi vendite, gestione, risorse umane) pensa ancora alla vecchia maniera. Esempi:

  L'interazione continua con il cliente e il suo coinvolgimento è molto importante.

  Le risorse umane devono capire che le prestazioni del team sono più importanti delle prestazioni delle persone. KPI deve cambiare in quello.

  La definizione della funzione è un processo continuo. La definizione del progetto si evolverà durante lo sviluppo in base al feedback dei clienti. A causa della scadenza del progetto, il budget richiesto o il set di funzionalità dei risultati possono cambiare (dopo l'approvazione da parte degli stakeholder).

  Il cambiamento fa parte del processo.

  La stima è un processo continuo che non si può dire all'inizio del progetto che entro 5 mesi verranno completate tutte le funzionalità (molte delle quali sconosciute all'inizio).

  Il team ha il potere di prendere decisioni. Il team si impegna per la quantità di funzioni fornite durante il prossimo sprint. Questo non può essere richiesto o comandato.

  Sprint è una zona sicura per la squadra. Una volta che il team si impegna in alcune storie utente definite, l'impegno non può essere modificato al di fuori del team.

  Parte della vecchia struttura organizzativa non ha senso quando si passa a Scrum. Scrum definisce tre ruoli: Scrum master, Product owner, team. Esistono altri ruoli, ma questi tre sono in genere sufficienti per la consegna dell'applicazione. Il non senso comune è avere Scrum master, Team leader, product owner e uno o più project manager. Il project manager e il team leader sono ruoli ridondanti in Scrum.

• Guy ha assegnato il ruolo di Scrum master non sta facendo 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 è l'assegnazione di questo ruolo allo sviluppatore senza alcuna esperienza precedente con Scrum. Questo ruolo sostituisce parzialmente il project manager comune, ma Scrum master non ha alcun potere sul team e Scrum master non richiede alcuna funzionalità da implementare. Scrum master protegge il team anche dal proprietario del prodotto con requisiti irrealizzabili.

• Guy assegnato il ruolo di Product Owner non sta facendo Product Owner. Il proprietario del prodotto ha la responsabilità finanziaria del prodotto. È molto specifico e un ruolo chiave per il successo. Il ruolo ha qualcosa in comune con analitica, project manager e product manager. Il proprietario del prodotto raccoglie e mantiene i requisiti (di solito sotto forma di storie utente). La sua responsabilità è fornire informazioni al team e definire la priorità delle storie degli utenti. Dovrebbe essere sul posto con il team perché la cooperazione tra PO e il team è continua.
• Cambiando il nome del processo in Scrum ma lasciando la maggior parte del processo come era alla vecchia maniera. Lo scenario più comune è che cambierai da cascata a Scrum e il cambiamento più significativo è che non fai più analisi e documentazione e dici che Scrum.
• Requisiti / storie utente mancano di definizione di fatto - molto comune. Se non si dispone di una definizione di fatto (criteri di accettazione) non è possibile formulare ipotesi sulla complessità della storia dell'utente durante la pianificazione dello sprint. Se non li hai durante lo sprint, non puoi contrassegnare la user story come completata perché non puoi convalidarla.
• La qualità è considerata facoltativa. La qualità in Scrum è un cittadino di prima classe. Possiamo dire che ogni criterio di accettazione dovrebbe essere coperto da un test end-to-end automatizzato. Una volta che inizi a ridurre la qualità e ad aggiungere funzionalità non testate, perdi il controllo sul prodotto perché le funzionalità considerate completate possono smettere di funzionare in qualsiasi momento a causa della regressione.
• Il risultato dello sprint dovrebbe essere incrementabile shippable (= funzionante e testato) sul prodotto.

Modificare:

Sto aggiungendo una nota importante. Quando si utilizza l'approccio agile, il punto principale è fornire la massima quantità di valore aziendale al cliente il più rapidamente possibile. Ma il cliente (rappresentato dal Product Owner) descrive qual è il valore commerciale. Quindi non è generalmente vero che non si dispone di analisi o documentazione quando si utilizza Scrum. Se il cliente richiede analisi o documentazione e lo contrassegna come valore aziendale (ad esempio a causa di progetti su larga scala o di lungo termine che dovrebbero essere migliorati nei prossimi anni), lo 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 tal 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 si "agitano" ancora, decidono di "essere flessibili sull'agile" e iniziano a personalizzarlo, lasciando cadere alcune parti, ecc., Senza una chiara comprensione di ciò che ogni parte fa e perché è lì.

Ho visto i team avere più successo con Scrum quando all'inizio fanno le cose dal libro, rispetto ai team che cambiano ciò che non "ottengono" ancora.

Questo è quando ottieni cose come "primo 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, che succede con questo business standup?".

Qualcosa a che fare con Shuhari ( http://c2.com/cgi/wiki?ShuHaRi ).

Il problema più grande è sempre il buy-in. Se un team o persone chiave non hanno acquistato (project management, QA, sviluppo, ecc.) Allora il fallimento è quasi assicurato.

Un altro problema correlato è in realtà rendere tutti i soggetti coinvolti consapevoli di ciò che la mischia è reale e cosa non lo è.

Ho visto ambienti in cui il project management ha effettivamente preso questo come un biglietto per venire direttamente agli sviluppatori con modifiche e aspettarsi che venga fatto domani, poiché stiamo usando il nuovo fantastico processo. Chiunque sia stato in questa situazione o in altri tentativi falliti di implementare Scrum e abbia un sapore amaro in bocca. Queste persone a volte cercheranno anche di smantellare il progetto.

Un altro problema che ho visto è alzarsi in piedi riunioni. Otterrai sempre il ragazzo che vuole sedersi durante una riunione di stand .... "Ho una brutta schiena" o qualsiasi altra cosa. Sembra sempre lo stesso ragazzo che non ha idea di quale sia l'obiettivo dietro lo stand-up, e non tacerà sulla politica o su ciò che ha fatto quel fine settimana. Ho scoperto che le riunioni in piedi sono la chiave per una comunicazione efficace. È importante non permettere a nessuno di avvelenare questi incontri.

Cercando di fare tutte le analisi per il codice che stavamo sviluppando nello stesso sprint, lo stavamo effettivamente codificando.

Siamo passati alla mischia poco fa e francamente la direzione che l'ha gestita ha trattato ogni mischia come un processo a cascata di 2 settimane. C'era una tale aderenza 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 in modo efficace nel modo che funziona per te. Non è il modo che è vietato dai processi. Ad esempio, abbiamo avuto scrum di 2 settimane e un team ha affermato di ritenere che 2 settimane non fossero sufficienti per fare un buon lavoro (non con i tempi di inattività causati dalla fine della demo di Scrum e dalla revisione dei requisiti iniziali), quindi volevano andare a 3 settimana. Shock horror! La direzione ha rifiutato perché avevano deciso che 2 settimane per scrum erano l'ideale e che ora era documentato nelle procedure di qualità.

Scrum è il meno agile dei metodi agili, motivo per cui è stato così popolare: è più facile da vendere alla vecchia guardia. dovresti rimuovere cose che non ti piacciono, ma non credo che ciò accada. Il mio consiglio è di scegliere uno più flessibile, meno basato su regole e aggiungere invece le regole di cui hai bisogno. Preferisco Crystal per questo.

In definitiva, basta ricordare il manifesto agile a metà corsa .

Il problema più grande è che anche il tuo cliente deve accettare il processo SCRUM e diventare anche agile. La maggior parte dei clienti desidera ascoltarlo all'inizio del progetto:

• Quanto costerà
• Come sarà
• Quando sarà fatto

Sembra ragionevole, ma è assolutamente incompatibile con l'agile. Devi spiegare al tuo cliente perché è agile per lui invece che a cascata.

Ho avuto due grossi problemi al mio primo tentativo su SCRUM:

1) Non avevamo davvero un proprietario del prodotto. Il nostro capo doveva svolgere il ruolo perché nessuno che avrebbe dovuto essere il proprietario del prodotto avrebbe accettato di farlo. Questo tipo di cricca le cose perché non ha sempre conosciuto le risposte.

2) Siamo stati pessimi nel tenere conto dei componenti esterni. I nostri primi sprint hanno comportato l'attivazione e l'esecuzione di test completamente automatici e abbiamo ripetutamente riscontrato 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 per il prossimo sprint. Stimiamo in base ai criteri di accettazione. Durante la raccolta dei requisiti troviamo che l'AC sintonizzata con precisione è molto più grande, quindi il compito inizialmente stimato per 8 ore ora è davvero 24 ore! Quindi posso cambiare il mio backlog di sprint e rivedere le stime e ridurre le mie storie? No signore! Agile richieste che non è possibile modificare l'arretrato di sprint! Ecco cosa dice il mio TL. Quindi non dovrei anche codificare 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!