Qualcun altro ritiene che Scrum non sia agile?

41

Sono un grande fan dello sviluppo agile e alcuni anni fa ho usato XP su un progetto di grande successo. Mi è piaciuto tutto, l'approccio iterativo allo sviluppo, la scrittura di codice attorno a un test, l'accoppiamento della programmazione, la presenza di un cliente sul posto per eseguire le cose. Era un ambiente di lavoro altamente produttivo e non mi sentivo mai sotto pressione.

Tuttavia, negli ultimi posti in cui ho lavorato, ho usato / usato Scrum. So che è il bambino poster per lo sviluppo agile in questi giorni, ma non sono convinto al 100% che sia agile. Di seguito sono riportati i due motivi principali per cui non mi sento agile.

I project manager lo adorano

I project manager, che per loro stessa natura sono ossessionati dalle tempistiche, sembrano tutti amare Scrum. Nella mia esperienza, sembrano utilizzare lo Sprint Backlog come mezzo per tenere traccia dei requisiti di tempo e tenere traccia di quanto tempo è stato dedicato a una determinata attività. Invece di usare una lavagna usano tutti un foglio Excel, che ogni sviluppatore è tenuto a compilare, religiosamente.

Secondo me, questo è troppo documentazione / monitoraggio del tempo per un processo agile. Perché dovrei perdere tempo a stimare quanto tempo impiegherà un'attività quando posso semplicemente continuare con l'attività stessa. O allo stesso modo perché dovrei perdere tempo a documentare il tempo impiegato da un'attività quando posso passare all'attività successiva a portata di mano.

Incontri standup

Le riunioni stand-up nel posto precedente in cui ho lavorato sono state un incubo. Ogni giorno dovevamo spiegare cosa avevamo fatto ieri e cosa avremmo fatto quel giorno. Se andassimo oltre il nostro "preventivo" del tempo per un compito, il project manager darebbe un calcio puzzolente e farebbe riferimento allo Sprint Backlog come un mezzo per dimostrare l'incompetenza per non aderire alla linea temporale.

Ora capisco la necessità di comunicare, ma sicuramente il tono delle riunioni quotidiane dovrebbe essere spensierato e focalizzato sulla condivisione delle conoscenze. Non penso che dovrebbe trasformarsi in una sciarada in cui dovresti fare i compiti. Sicuramente anche il punto di buco dell'agile è che le linee temporali cambiano, non dovrebbero essere impostate sulla pietra.

Conclusione

L'idea di agile è migliorare il software semplificando la vita degli sviluppatori. Pertanto, a mio avviso, qualsiasi processo agile utilizzato da un team dovrebbe essere guidato dallo sviluppatore. Non credo che avere un project manager che usi un processo che ha definito "agile" per tenere traccia di un progetto abbia qualcosa a che fare con lo sviluppo agile.

Qualcuno pensa?

agile scrum

— winarama
fonte

6

Nella mischia, i team dovrebbero essere autogestiti. L'obiettivo del project manager è infine quello di eliminare il loro ruolo in modo che il team organizzerà e parteciperà alle riunioni quotidiane da solo. Il ruolo di project manager dovrebbe idealmente essere eliminato per partecipare alle riunioni retrospettive e di pianificazione e gestire tutto il lavoro organizzativo.

— superM del

7

Sì. Persino uno dei "padri" dell'agile non è d'accordo sul fatto che Scrum sia davvero agile: youtube.com/watch?v=hG4LH6P8Syk

— Euforico

18

Quindi quello che stai dicendo è che non stai facendo Scrum, e ne sei consapevole, ma poi sei sorpreso che Notscrum sia anche Notagile?

— pdr

2

Non ho mai trascorso più tempo nelle riunioni a parlare di processo di ogni singolo team "agile" in cui sono stato. Ma mi piace ancora molto meglio dell'alternativa.

— Rob

11

Nella mia esperienza, Scrum è essenzialmente un tentativo di far sembrare Waterfall agile dividendola in unità più piccole. In effetti, gli sprint dovrebbero essere più realisticamente chiamati "cascate".

— Berislav Lopac,

25

Ci sono alcuni elementi in Scrum che sono più inclini alla perversione, ma ad essere sinceri, quello che stai descrivendo è il risultato del tentativo di convincere un'organizzazione ad adottare Scrum senza istruire tutte le parti interessate su cosa si tratta, come funziona e perché funziona. Per ottenere risultati è necessario un buy-in nell'intera azienda.

Qualsiasi trasformazione agile sta per esporre tutto ciò che sta succedendo nella tua organizzazione, inclusi, ma non solo, micromanager, persone potenti con i loro programmi, sviluppatori insufficientemente addestrati, silos di comunicazione, ecc. Se non c'è volontà collettiva per affrontare questi problemi e semplicemente "fai stand-up" e semplicemente "lavori in sprint", l'implementazione di Scrum sta andando a vuoto.

Non posso sottolinearlo abbastanza: se vuoi fare Scrum, hai bisogno di allenatori competenti che possano mostrarti il percorso. Non è sufficiente leggere Essential Scrum e poi vedere solo dove ti porta ...

— Stefan Billiet
fonte

16

In che modo gli standup giornalieri sono diversi dalla microgestione?

— Giorgio,

10

Gli stand-up sono per il team di organizzare il loro tempo in modo che non si intralcino l'un l'altro. È assolutamente inappropriato parlare di stime, tempo trascorso su attività passate ecc. - In effetti un project manager (al contrario del master della mischia) probabilmente non dovrebbe partecipare affatto.

— Julia Hayward,

10

@Georgio: dipende da cosa intendi per microgestione. L'obiettivo di uno standup quotidiano in SCRUM è di tenere tutti informati su ciò che fanno tutti gli altri, non di fornire un'opportunità a un project manager di castigare le persone per non aver rispettato le stime. In effetti, non esiste un project manager in SCRUM, il monitoraggio e l'adeguamento delle stime è il lavoro del team e se non vengono soddisfatte la domanda da porsi è "cosa l'ha causato e come possiamo evitarlo o consentirlo in futuro? ", non" di chi è la colpa e quanto possiamo fargli sentire male? "

— Michael Borgwardt,

3

@ErikReppen com'è praticamente con qualsiasi cosa, hai un piccolo gruppo di persone che escogita un miglioramento degno di valore e poi ottieni un gruppo molto più grande che vuole monetizzarlo e generalmente lo pervertisce completamente :-p Credo in Scrum, ma mi distacco completamente dalla Scrum Alliance e dalla sua attività di certificazione.

— Stefan Billiet,

8

@jessehouwing: Sì, ma imporre incontri a una squadra matura è come andare da qualcuno che sa camminare perfettamente e dire loro: guarda, hai un problema, non puoi camminare, ti insegnerò a camminare correttamente. Queste persone ti guarderanno e si chiederanno: Ehi, cosa vuole questo ragazzo da me? Certo che posso camminare. Quindi, imporre incontri quotidiani su un team maturo e auto-organizzato disturba solo il loro flusso di lavoro: è solo uno spreco. Tale decisione può essere spiegata da un management incompetente o dalla volontà di osservare / controllare il funzionamento del team.

— Giorgio,

20

Sì. Persino uno dei "padri" dell'agile non è d'accordo sul fatto che Scrum sia davvero agile: youtube.com/watch?v=hG4LH6P8Syk - Euforico

Penso che questo link da uno dei commenti sopra dice davvero tutto. Vale la pena dare un'occhiata, lo zio Bob fa una breve storia su Scrum e sostanzialmente dice che Scrum non è un processo di sviluppo Agile perché Scrum si è evoluto nel tempo per diventare un processo di gestione . Le ragioni dietro questo sembrano essere perché erano i project manager, e non gli sviluppatori, a seguire i corsi Scrum.

— winarama
fonte

2

Questo (quello che hai scritto, non quello che ha detto lo zio Bob) è un non sequitur. Solo perché qualcosa è un processo di gestione non lo rende intrinsecamente non Agile.

— Dave Hillier,

9

Puoi avere gatti marroni e cani marroni, ma un gatto marrone non può mai essere un cane marrone. Non è perché non è marrone, è perché non è un cane. Allo stesso modo un processo di gestione Agile non può essere un processo di sviluppo software Agile, non perché non è agile ma perché non è un processo di sviluppo software, che è ciò di cui stiamo parlando.

— Winarama,

1

Quindi potresti voler aggiornare la tua domanda, intitolata "Qualcun altro ritiene che Scrum non sia agile?"

— Dave Hillier,

Grazie per aver condiviso il video. L'ho trovato davvero illuminante.

— MickJ,

Bene, i manager come l'agile lo usano persino in modo improprio. Quindi possono incolpare gli sviluppatori. Quindi usare agile qualunque cosa sia falsa o no è una questione di correttezza politica.

— Amore

13

Quello che stai descrivendo è ciò che noi, Scrum trainer professionisti, vediamo molto nelle organizzazioni che hanno "implementato la mischia". Spesso "fanno anche XP nel team di sviluppo", il che significa che ci sono alcuni test unitari in esecuzione su un server di build da qualche parte. Questa non è mischia .

Sì, i project manager possono utilizzare un backlog di prodotto, in particolare uno che è stato digitalizzato, per abusare delle metriche raccolte da tali sistemi. Ma il team di sviluppo e lo Scrum Master non dovrebbero permetterlo. Cosa ci fa comunque un Project Manager? Non dovrebbe essere un Product Owner ?!

Proprio come XP può essere fatto male, e alcuni processi più rigorosi possono sembrare molto fluidi (con integrazione continua, implementazione, ma ancora molto guidata dai piani), Scrum è solo un framework. Ci vogliono persone buone che capiscano i valori e il processo per eseguirlo bene. Ci vuole apprendimento continuo un miglioramento per arrivarci.

— jessehouwing
fonte

12

Probabilmente te lo aspettavi, ma solo perché alcune (molte?) Persone abusano di Scrum in modo non agile non significa che Scrum non sia Agile.

Project Manager : non esiste un ruolo simile in un team Scrum. Scrum Master non è responsabile del budget o del rispetto delle scadenze. È responsabile per aiutare la squadra e rimuovere tutti gli ostacoli sulla strada verso l'obiettivo a cui si sono impegnati. Da quello che descrivi, sembra che il tuo PM abbia dirottato Scrum per prendersi le prerogative che normalmente vanno al team e al Product Owner, perpetuando le precedenti abitudini di comando e controllo.

Rilevamento del tempo : Scrum consiglia di tenere traccia del tempo rimanente e di sommarlo per determinare lo stato dello sprint, non il tempo trascorso dai singoli membri del team. Questo potrebbe sembrare un dettaglio, ma fa la differenza tra una cultura orientata alla colpa e un approccio orientato agli obiettivi.

Dalla guida Scrum :

Monitoraggio dei progressi dello Sprint

In qualsiasi momento nel tempo di uno Sprint, il lavoro totale rimanente nel Backlog Sprint può essere sommato. Il team di sviluppo tiene traccia di questo lavoro totale rimanendo almeno per ogni Scrum quotidiano per proiettare la probabilità di raggiungere l'obiettivo Sprint . Tracciando il lavoro rimanente durante lo Sprint, il team di sviluppo può gestirne i progressi.

— guillaume31
fonte

È inevitabile diventare una cultura orientata alla colpa anche se Scrum è in teoria al 100% politicamente corretto.

— Amore

2

scrum è una metodologia di gestione del progetto

agile è una metodologia di sviluppo software (-ish)

scrum + agile funziona molto bene

mischia senza agilità ... non così tanto

— Steven A. Lowe
fonte

3

È interessante notare che Scrum era una metodologia di sviluppo software, ma nel tempo si è evoluta in una metodologia di gestione del progetto.

— Winarama,

2

Penso che sia inevitabile. Gli sviluppatori semplicemente non hanno tanto senso di proprietà nel processo (non lo vogliono). In una recensione di sprint di recente, ho messo in discussione lo scopo del team: scrivere software o far apparire bene il grafico di burndown. Ho fatto il mio punto, ma poi tutti i PM nella stanza hanno dovuto fare di tutto per sottolineare l'importanza di bla bla bla. lol!

— Rob

2

@ T-Pane: ancora più interessante che Scrum sia stato originariamente proposto come metodologia di sviluppo di nuovi prodotti - hbr.org/1986/01/the-new-new-product-development-game/ar/1

— Steven A. Lowe

2

@ StevenA.Lowe Ah Scrum, è in un viaggio alla scoperta di sé.

— Winarama,

1

So che è vecchio ma questa risposta è completamente falsa. Scrum è un framework in cui i modelli si adattano. Agile è un insieme di valori e principi.

— Venture2099