Scrum trasforma gli sviluppatori attivi in sviluppatori passivi?

However, I now feel like I'm always getting told to do something, instead of deciding to do something.

Questo è un indicatore serio che qualcosa è andato fuori dai binari. Un progetto agile non dovrebbe sentirsi così. La retorica di "persone che si sovrappongono" dovrebbe includere "non costringiamo i nostri a fare cose che fanno schifo". Ecco alcune idee:

Stai facendo "scrum ma"? Cioè, in parte mischia, in parte un'altra cosa. (es .: "Stiamo facendo scrum, ma tutte le nostre storie devono venire dal nostro PMO, non dal proprietario di un prodotto.") Un sacco di schifezze folli si chiama Scrum in questi giorni.

Sei, personalmente, non coinvolto nel processo in cui dovresti essere? Ho conosciuto un certo numero di persone che sono sconvolte dal contenuto delle storie, e si scopre che vengono coinvolte solo una volta che la storia è nel backlog di sprint. Parla con il proprietario del prodotto all'inizio dello sviluppo della storia e ottieni il tuo feedback. (Come il PO, hanno l'ultima parola, ma ciò non significa che debbano farlo da soli.)

In Scrum, il team dovrebbe possedere il processo e si prevede che il processo cambierà nel tempo per soddisfare le esigenze della squadra. Raccogli le tue preoccupazioni alla retrospettiva. Se riesci a proporre un tweak di processo da suggerire, tende a rendere più facile la vendita per alcuni team.

Il tuo problema non è Scrum (e come Jarrod Roberson ha menzionato nei commenti, non è Scrum quello che stai descrivendo) - è il micromanagement del proprietario del prodotto e la tua (strong) mancanza di assertività .

"Tuttavia, a causa della metodologia di mischia, ora molte decisioni provengono semplicemente dal proprietario del prodotto: dà la priorità ai PBI, analizza come dovrebbe funzionare il software, anche a volte come dovrebbero essere implementate l'interfaccia utente e la funzionalità. di metodologia scrum. "

Ti stai sbagliando. Solo da una breve occhiata alla pagina di Wikipedia per Scrum si può vedere che: "la Squadra, un gruppo interfunzionale che esegue analisi, progettazione, implementazione, test, ecc. " Vedi? Il proprietario del prodotto ti dice cosa fare, ma spetta al team decidere come come farlo.

Sei la persona responsabile dell'implementazione, quindi dovresti decidere come sarà implementata l'applicazione. Ascolta l'opinione del proprietario del prodotto, ma la decisione finale spetta a te (o al team).

Il microgestione di BTW rende gli sviluppatori attivi in sviluppatori passivi.

Quello che stai descrivendo NON è SCRUM

Il proprietario del tuo prodotto sta scavalcando i suoi limiti se ti sta dicendo come fare tecnicamente il tuo lavoro, non è affatto ciò di cui SCRUM è a conoscenza.

SCRUM significa liberare gli sviluppatori per concentrarsi sui problemi di sviluppo e responsabilizzarli assumersi la responsabilità di determinare quanto tempo le cose prendono e come farle.

SCRUM riguarda la collaborazione, ovvero le riunioni di pianificazione Sprint, per promuovere la collaborazione tra tutti i soggetti interessati; proprietario del prodotto, sviluppatori e test.

Sì, il product owner dovrebbe dare la priorità alle funzionalità, ciò che deve essere consegnato prima in base alle esigenze del cliente, ma gli sviluppatori dovrebbero fare l'ingegneria e il design, 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 specificatamente istruiti e addestrati a lavorare con i clienti e ad eliminare la funzionalità direttamente con i clienti. Le GUI del programmatore realizzate nel vuoto raramente soddisfano le esigenze dei clienti.

SCRUM significa mettere un processo leggero che può essere prevedibile e ripetibile sul manifesto agile.

Mi rattrista sentire storie che cose molto buone vengono pervertite in questo modo.

Sto indovinando 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 fatta. In qualche modo, il tuo gruppo è giunto alla conclusione che il Product Owner dovrebbe dirti come programmare.

Vuoi scrivere codice o creare piccole app che ritieni perfette? "Voglio fare il primo A e non 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 una ragione valida per non essere d'accordo con la storia, di 'qualcosa, fai la tua discussione. Potresti non vincere sempre. È loro compito restituire agli utenti e far loro sapere che c'è un problema valido con la loro richiesta. Ammettiamolo, se la storia ti chiede di lasciare un database casualmente per tutto il giorno, senza un backup, nessuna perdita di dati o tempi morti, hai un problema e il dovere di impostare la storia direttamente.

Sembra che le tue avventure in Agile siano state corrotte da Scrum. Trovo che, tra tutte le metodologie agili, Scrum sia il meno agile. È più simile a cascate in miniatura e gestione di progetti aggiuntivi. Questo, ovviamente, lo rende il più gradito dal management che sente che stanno prendendo il controllo da quei fastidiosi sviluppatori, ma ovviamente vedi la realtà della situazione.

Agile non sta seguendo un percorso prestabilito, è progettato per renderti più produttivo e motivato. Le persone non elaborano dice il manifesto (parafrasato) e questo è perso nel sistema che stai utilizzando.

Quindi cambialo. Rivolgiti alla direzione e dì che è un passo indietro, che la tua produttività è inferiore a quella di una volta e non sei soddisfatto del modo in cui si sta allenando. Mostra il Agile Manifesto (e il suo malvagio gemello ) e dimostra che non hai solo imparato le lezioni da questo esperimento, ma vuoi evolvere i buoni bit da esso in un sistema migliore (uno come te, che sembra funzionare bene per te).

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

Purtroppo penso che molti software siano meno di quanto potrebbero essere, perché spesso le parti sono scritte per lo sviluppatore e non per il client. Il tuo nuovo approccio dovrebbe ridurlo, ma a spese del tuo sentimento di proprietà.

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

Stai ricevendo storie di utenti sotto forma di "Come un --role--, voglio --goal / desire-- in modo che --benefit--"? Sembra che il tuo Product Owner voglia fare il lavoro di progettazione, e lui / lei potrebbe non essere la persona migliore per farlo. L'utilizzo del modello della trama utente può aiutare a garantire che il proprietario del prodotto sia conforme all'interesse commerciale, e lo sviluppo del software viene svolto dagli sviluppatori del software.

In Scrum c'è molto spazio per gli sviluppatori per contribuire e dare il loro consiglio su nuove funzionalità, interfaccia utente, usabilità ... La collaborazione e la conversazione tra uomini d'affari e sviluppatori è richiesta in Scrum 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 sprint dopo lo sprint (in altre parole, il ROI).

Dal Manifesto Agile:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Il proprietario del prodotto che ti spiega come l'interfaccia utente e la funzionalità devono essere implementate non è tuttavia accettabile. In tal caso tu dovresti avere l'ultima parola da quando tu sei responsabile della qualità interna del software che produci.

Forse lavori in un'azienda creata da sviluppatori in cui i programmatori hanno la libertà di implementare qualsiasi funzione volessero. Tuttavia, la maggior parte delle metodologie Agile crea 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 suppongo che sarebbe stato comunque il caso, Scrum o no.

Riguardo all'analisi, alla progettazione e ad altre attività di meta-sviluppo menzionate (che di nuovo non dovrebbero essere fatte dal Product Owner), i team Agile dovrebbero essere interfunzionali e silo-free. Nessuno è in grado di possedere tutta la conoscenza di una specifica attività di sviluppo, quindi forse c'è un'opportunità per te di diversificare lì rispetto al solo "code monkeying".

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

Pratichiamo Scrum qui. Abbiamo una riunione di pianificazione quindicinale in cui nutriamo le attuali priorità di business, i successi e i fallimenti dello sprint precedente e decidiamo, come una squadra , che cosa vogliamo affrontare per il prossimo sprint.

Uno dei modi in cui lo facciamo è ordinare il backlog su una scheda in base alla complessità verticale e alla priorità aziendale in senso orizzontale. Dopo di ciò, il Product Owner ha avuto il suo input, quindi spetta al team scegliere quello che vogliamo fare. Ovviamente, scegliere un'attività a bassa priorità di elevata complessità è disapprovato, ma stiamo decidendo questo come una squadra. Rende le sessioni di pianificazione più lunghe, ma ne vale la pena e costituisce una parte fondamentale del processo Agile.

A volte abbiamo microgestione, ma questo è un problema diverso.

Il vero problema che stai descrivendo è una patologia comune quando i team adottano una metodologia: si spengono il cervello. Questo è vero con un sistema agile di nuova scuola come lo era con i sistemi dei pesi massimi della vecchia scuola.

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

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

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

Non sono molto in sintonia con tutta la mischia come se fossi stato più cascata per un po '.

Ma per essere onesti, questo suona più come un problema di personale di gestione che un problema di tecnica di gestione del progetto. Come in è più basato sulla gente che basato sulla tecnica.

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

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

Dalla mia esperienza, gli sviluppatori più sul lato creativo / design / frontend sembrano soffrire di più rispetto a quelli coinvolti nel lavoro di back-end.

L'unica via d'uscita che ho trovato finora è stata la fuga di Scrum - spesso non possibile e / o appropriata perché in fin dei conti ha i suoi vantaggi - o introdurre qualcosa come il 20% di Google per dare agli sviluppatori uno sbocco creativo a parte "sei libero di scegliere come implementare la pagina di accesso ", perché in realtà non sei come la tua implementazione è vincolato dal codice esistente e dall'architettura di sistema, ovvero a meno che non si consideri la libertà di scegliere tra "un ciclo for for while" una libertà.

There is a big difference between you deciding what to do, or being told what to do.

Nella mia esperienza, c'è un modo piuttosto lungo di in cui viene detto cosa fare a decidere cosa fare.

Alla fine di questo modo di solito risulta che siamo stati istruiti non perché loro come potere e non perché loro non abbiano niente di meglio da fare. Al contrario, alla fine di questo modo - quando loro acquisiscono sufficiente fiducia nel nostro team - sembrano essere sollevati e ci passano felicemente il controllo che possiamo gestire (e se la loro fiducia è davvero fermo, cercano persino di passare più di quello)

Oh e nella mia esperienza questo non ha praticamente nulla a che fare con Scrum / agile. È successo con mischia, iterativo, cascata, qualunque cosa. Sembra che la questione di fiducia sia indipendente dal processo

Nel nostro team, il proprietario del prodotto ci dice cosa fare e decidiamo in che modo lo facciamo. È davvero importante avere questa separazione o finirai nella situazione che hai descritto.

Secondo la mia esperienza, Scrum ti sta osservando profondamente per quello che fai. È solo sulla tua spalla e guarda cosa fai. Anche se ha il suo vantaggio, odio la metodologia scrum. Si aspetta il conteggio, non la qualità. La qualità viene compromessa con la metodologia di scrum.