Scrum trasforma gli sviluppatori attivi in ​​sviluppatori passivi?

Sono uno sviluppatore web che lavora in un team di tre sviluppatori e un designer. Sono ormai circa cinque mesi che implementiamo la metodologia di sviluppo del software agile di mischia. Ma ho la strana sensazione che volevo solo condividere in questo sito.

Un fattore importante nella vita umana è il processo decisionale. Tuttavia, c'è una grande differenza nelle decisioni che prendi. Alcune decisioni sono solo il risultato di una forza interna o esterna, mentre altre decisioni sono completamente basate sul tuo libero arbitrio e alcune decisioni sono semplicemente qualcosa nel mezzo. Più libertà hai nel prendere decisioni, più autonomo diventerebbe il tuo lavoro. Questa sembra essere una regola. Perché tendiamo a modellare noi stessi le nostre vite.

C'è una grande differenza tra te che decidi cosa fare o che ti viene detto cosa fare .

Prima della mischia, mi sentivo più libero di prendere le decisioni relative allo sviluppo, all'analisi, alla definizione delle priorità di implementazione, ecc. Avevo più la sensazione di decidere cosa sto facendo .

Tuttavia, a causa della metodologia della mischia, ora molte decisioni vengono semplicemente dal proprietario del prodotto. Dà priorità ai PBI , analizza come dovrebbe funzionare il software, anche a volte come devono essere implementate l'interfaccia utente e le funzionalità. So che questo fa parte della metodologia della mischia e so anche che ciò potrebbe comportare migliori vendite di prodotti in futuro. Tuttavia, ora sento che mi viene sempre detto di fare qualcosa, invece di decidere di fare qualcosa . Questa sindrome ora mi ha reso più passivo verso il lavoro.

1. Tendo a cercare meno per trovare una soluzione, un approccio o una tecnica migliori
2. Non mi sveglio la mattina aspettandomi di arrivare a un lavoro piacevole. Piuttosto, mi sento costretto a lavorare per vivere
3. Ho più fame di lavorare sui miei progetti di hobby dopo il lavoro
4. Non spingerò più il team a raggiungere i livelli tecnologici più elevati
5. Adesso passo più tempo a cena o all'ora del tè e ho meno entusiasmo per tornare al lavoro
6. Ora sono disposto a fare in modo che il lavoro finisca prima, in modo da poter tornare a casa

Il grosso problema è che vedo e diagnostico questo comportamento anche nei miei colleghi. È il risultato della mischia? Scrum fa davvero sentire al team di sviluppo che non ha alcun ruolo nella formazione del software complessivo, rendendo così passivo il progetto? Come posso superare questo sentimento?

Tuttavia, ora sento che mi viene sempre detto di fare qualcosa, invece di decidere di fare qualcosa.

Questo è un serio indicatore che qualcosa è andato fuori dai binari. Un progetto agile non dovrebbe sentirsi così. Quella retorica "persone troppo processate" dovrebbe includere "non forziamo la nostra gente a fare cose che fanno schifo". Ecco alcune idee:

Stai facendo "mischia ma"? Cioè, in parte mischia, in parte qualcos'altro. (Vale a dire: "Stiamo facendo la mischia, ma tutte le nostre storie devono provenire dal nostro PMO, non da un product owner.") Un sacco di stronzate pazze si chiama Scrum in questi giorni.

Personalmente, non sei coinvolto nel processo in cui dovresti essere? Ho conosciuto un certo numero di persone arrabbiate per il contenuto delle storie e si scopre che sono coinvolte solo quando la storia è nel backlog dello sprint. Parla con il proprietario del prodotto all'inizio dello sviluppo della storia e ottieni il tuo feedback. (In quanto OP, hanno l'ultima parola, ma ciò non significa che debbano farlo da soli.)

In Scrum, il team dovrebbe essere il proprietario del processo e si prevede che il processo cambierà nel tempo per soddisfare le esigenze del team. Mostra le tue preoccupazioni alla retrospettiva. Se riesci a trovare una modifica del processo da suggerire, questo tende a rendere più facile la vendita per alcune squadre.

Il tuo problema non è Scrum (e come Jarrod Roberson ha menzionato nei commenti, non è Scrum quello che stai descrivendo) - è il microgestione del Product Owner e la tua (e della tua squadra) mancanza di assertività .

"Tuttavia, a causa della metodologia di Scrum, ora molte decisioni vengono semplicemente dal proprietario del prodotto. Dà priorità ai PBI, analizza come dovrebbe funzionare il software, anche a volte come dovrebbero essere implementate l'interfaccia utente e le funzionalità. So che questo fa parte della metodologia di Scrum."

Ti sbagli. Solo da una breve occhiata alla pagina di Wikipedia per Scrum si può vedere che: "il Team, un gruppo interfunzionale che esegue le analisi, la progettazione, l'implementazione, i test, ecc." Vedere? Il Product Owner ti dice cosa fare, ma spetta al Team decidere come farlo.

Sei la persona responsabile dell'implementazione, quindi dovresti decidere come implementare l'applicazione. Ascolta l'opinione del Product Owner, ma la decisione finale spetta a te (o al Team).

BTW microgestione non gira sviluppatori attivi nella sviluppatori passivi.

Quello che stai descrivendo NON è SCRUM

Il proprietario del tuo prodotto ha superato i suoi limiti se ti sta dicendo come fare il tuo lavoro tecnicamente, non è affatto quello che riguarda SCRUM.

SCRUM consiste nel liberare gli sviluppatori per concentrarsi sui problemi di sviluppo e responsabilizzarli a determinare il tempo impiegato e le modalità per risolverli .

SCRUM riguarda la collaborazione, ecco a cosa servono gli incontri di pianificazione Sprint, per promuovere la collaborazione tra tutti gli stakeholder; proprietario del prodotto, sviluppatori e test.

Sì, il proprietario del prodotto dovrebbe dare la priorità alle funzionalità, ciò che deve essere consegnato prima in base alle esigenze dei clienti, ma gli sviluppatori dovrebbero fare l'ingegneria e la progettazione, non il proprietario del prodotto.

Non sono d'accordo sul fatto che gli sviluppatori debbano progettare GUI e flussi di lavoro a meno che non siano specificamente incaricati e addestrati a lavorare con i clienti e ne facciano funzionare direttamente la funzionalità. La programmazione della GUI realizzata nel vuoto raramente soddisfa le esigenze dei clienti.

SCRUM consiste nel mettere su un processo leggero che può essere prevedibile e ripetibile rispetto al manifesto agile.

Mi rende triste ascoltare storie secondo cui cose molto buone vengono pervertite in questo modo.

Immagino prima di Scrum, tutti hanno fatto quello che volevano: yippee ki-yay mf'er . I tuoi utenti sono i tuoi benefattori e guidano la storia e pagano le bollette. Il proprietario del prodotto si assicura che la storia venga completata. In qualche modo, il tuo gruppo è giunto alla conclusione che il Product Owner dovrebbe dirti come programmare.

Vuoi scrivere codice o creare piccole app pulite che ritieni interessanti? "Voglio fare prima la funzione A e non la B, quindi posso mantenere la mia libertà di scelta." Trova un benefattore diverso e non una nuova metodologia di sviluppo.

Sei coinvolto nel titolo del proprietario del progetto o qualcosa del genere. Se hai un motivo valido per non essere d'accordo con la storia, dì qualcosa, fai la tua discussione. Potresti non vincere sempre. È loro compito tornare agli utenti e far loro sapere che esiste un problema valido con la loro richiesta. Ammettiamolo, se la storia ti chiede di rilasciare un database in modo casuale durante il giorno, senza un backup, nessuna perdita di dati o tempi di inattività, hai un problema e un dovere di chiarire la storia.

Sembra che le tue avventure in Agile siano state corrotte da Scrum. Trovo che, tra tutte le metodologie agili, Scrum sia la meno agile. È più simile a cascate in miniatura e gestione del progetto aggiuntiva. Questo, ovviamente, lo rende il più apprezzato dai dirigenti che sentono che stanno riprendendo il controllo da quei fastidiosi sviluppatori, ma ovviamente vedi la realtà della situazione.

Agile non si tratta di seguire un percorso prescritto, è progettato per renderti più produttivo e motivato. La gente non elabora dice il manifesto (parafrasato), e questo è perso nel sistema che stai usando.

Quindi cambiarlo. Provalo con la direzione e afferma che si tratta di un passo indietro, che la tua produttività è inferiore rispetto a prima e che non sei soddisfatto del modo in cui funziona. Mostra il Manifesto Agile (e il suo gemello malvagio ) e dimostra che non solo hai imparato le lezioni da questo esperimento, ma vuoi far evolvere i pezzi positivi da esso in un sistema migliore (uno come quello che avevi un tempo, che sembra funzionare bene per te).

Penso che semplicemente voi ragazzi siete abituati ad avere più proprietà - e tutti quelli che penso preferiscono, la sua natura umana.

Sfortunatamente penso che molto software sia inferiore a quello che potrebbe essere, perché spesso le parti sono scritte per lo sviluppatore e non per il client. Il tuo nuovo approccio dovrebbe ridurlo, ma a scapito del sentimento di proprietà.

Non ho idea di come suggerirti di rendere le cose migliori o più divertenti, ma è un'ottima domanda e un'ottima intuizione.

Stai ottenendo le storie degli utenti sotto forma di "Come - ruolo--, voglio --goal / desiderio-- in modo che - benefici--"? Sembra che il tuo Product Owner voglia fare il lavoro di progettazione e potrebbe non essere la persona migliore per farlo. L'uso del modello di storie utente può aiutare a garantire che il Product Owner sia fedele all'interesse commerciale e che gli sviluppatori software stiano realizzando lo sviluppo del software.

In Scrum c'è molto spazio per gli sviluppatori per contribuire e dare consigli su nuove funzionalità, interfaccia utente, usabilità ... Scrum richiede collaborazione e conversazione tra uomini d'affari e sviluppatori e ciò lo consente. Tuttavia, alla fine, il proprietario del prodotto avrà sempre l'ultima parola perché è lui il responsabile della massimizzazione del valore commerciale degli incrementi del software prodotti dopo lo sprint (in altre parole, il ROI).

Dal manifesto agile:

La nostra massima priorità è soddisfare il cliente attraverso la consegna anticipata e continua di software prezioso.

Tuttavia, il proprietario del prodotto che spiega come implementare l'interfaccia utente e le funzionalità non è accettabile. In questo caso si dovrebbe avere l'ultima parola in quanto v'è responsabile per la qualità interna del software si produce.

Forse lavori in un'azienda creata da sviluppatori in cui i programmatori avevano la libertà di implementare qualsiasi funzione desiderassero. Tuttavia, la maggior parte delle metodologie Agili fa una chiara separazione tra le persone del dominio aziendale e il team responsabile della produzione di software (sviluppatori, tester ...) che è la divisione di lavoro più comune nella maggior parte dei luoghi. Se i miei presupposti sono giusti, posso capire la sensazione che hai di non essere più in grado di "avere un'influenza sul quadro generale" ma con la crescita dell'azienda credo che sarebbe stato comunque il caso, Scrum o no.

Per quanto riguarda l'analisi, la progettazione e altre attività di meta-sviluppo menzionate (che di nuovo non dovrebbero essere svolte dal proprietario del prodotto), i team Agile dovrebbero essere interfunzionali e privi di silos. Nessuno dovrebbe possedere tutte le conoscenze relative a una specifica attività di sviluppo, quindi forse c'è un'opportunità per te di diversificare lì rispetto al "codice di scimmia".

Al contrario, ho scoperto che fare in modo che un proprietario del prodotto prenda decisioni sulla funzionalità mi consente di dedicare più tempo alla produzione del codice di qualità. Inoltre, se ci sono dubbi validi, posso sempre mettere in discussione le decisioni dei proprietari dei prodotti e questo di solito porta a discussioni fruttuose.

Qui pratichiamo Scrum. Abbiamo una riunione di pianificazione quindicinale in cui nutriamo le attuali priorità aziendali, i successi e i fallimenti dello sprint precedente e decidiamo, come squadra , cosa vogliamo affrontare per lo sprint successivo.

Uno dei modi in cui lo facciamo è ordinare l'arretrato su una scheda in base alla complessità in verticale e alla priorità aziendale in senso orizzontale. Successivamente, il Product Owner ha avuto il suo contributo, quindi spetta al team scegliere cosa vogliamo fare. Ovviamente, scegliere un compito a bassa priorità e ad alta complessità è disapprovato, ma lo stiamo decidendo come una squadra. Rende più lunghe le sessioni di pianificazione, ma ne vale la pena e una parte fondamentale del processo Agile.

E a volte abbiamo una micro-gestione, ma questo è un problema diverso.

Il vero problema che stai descrivendo è una patologia comune quando i team adottano una metodologia: spengono il cervello. Questo è vero sia con un sistema agile di nuova scuola che con sistemi pesanti della vecchia scuola.

D: La metodologia prescrive x, ma x non funziona bene. Cosa dovremmo fare?

A: Affina la tua implementazione di x. Forse smetti di farlo del tutto. La metodologia non è il tuo capo!

In questo caso specifico, sembra che il proprietario del prodotto stia facendo troppo. Ti senti a tuo agio a parlargli? Ti sentiresti a tuo agio con quella conversazione se non "facessi la mischia"? Se il proprietario del prodotto non è sensibile al feedback costruttivo, non è un problema di metodologia, è un problema con il proprietario del prodotto.

Non sono davvero in sintonia con l'intera faccenda della mischia perché sono stato più cascata per un po '.

Ad essere onesti, questo sembra più un problema di gestione del personale che un problema di tecnica di gestione del progetto. Come in è più basato sulle persone che sulla tecnica.

Il ruolo dei leader in un team auto-organizzante sarebbe un post sul blog su qualcosa che sembra mancare nel tuo post. Dov'è il team che decide quale lavoro viene svolto in uno sprint? Dov'è la squadra che ha la proprietà nel processo e nel lavoro? Hai qualcuno che conosce Scrum abbastanza da farlo Scrum e non una versione perversa di esso?

Ho avuto la stessa esperienza con Scrum e mi piace definirla la "tirannia della storia".

Dalla mia esperienza, gli sviluppatori più dal punto di vista creativo / design / frontend sembrano soffrirne di più rispetto alle persone coinvolte nel lavoro di backend.

L'unica via d'uscita che ho trovato finora è stata quella di abbandonare Scrum - spesso non possibile e / o appropriato perché dopo tutto ha i suoi vantaggi - o introdurre qualcosa come il 20% di tempo di Google per offrire agli sviluppatori uno sbocco creativo oltre al "tu" sei libero di scegliere come implementare la pagina di accesso ", perché in realtà non lo sei poiché l'implementazione è limitata dal codice e dall'architettura di sistema esistenti, vale a dire se non si considera la libertà di scegliere tra" a for e a while loop "a la libertà.

C'è una grande differenza tra te che decidi cosa fare o che ti viene detto cosa fare .

Nella mia esperienza, c'è solo un tempo piuttosto lungo modo da sentirsi dire cosa fare per decidere cosa fare.

Alla fine di questo modo di solito scopre che ci sono stati istruiti non perché li come l'energia e non perché li hanno niente di meglio da fare. Al contrario, alla fine di questo modo - quando si guadagnano sufficiente fiducia nella nostra squadra - sembrano essere sollevato e felicemente ci ha passare il maggior controllo siamo in grado di gestire (e se la loro fiducia è veramente duro, hanno anche cercare di passare più di quello)

Oh, e nella mia esperienza questo non ha praticamente nulla a che fare con Scrum / agile. Accaduto con mischia, iterativo, cascata, qualunque cosa. Sembra che la questione della fiducia sia il processo agnostico

Nel nostro team, il product owner ci dice cosa fare e decidiamo come lo facciamo. È davvero importante avere questa separazione o finirai nella situazione che hai descritto.

Secondo la mia esperienza, Scrum è di osservarti profondamente ciò che fai. È solo seduto sulla tua spalla e guarda cosa fai. Anche se ha il suo vantaggio, odio la metodologia della mischia. Si aspetta il conteggio, non la qualità. La qualità viene compromessa dalla metodologia di Scrum.