Agile è il nuovo microgestione?

76

Questa domanda mi è venuta in mente da un po 'di tempo, quindi volevo chiedere a coloro che stanno seguendo pratiche di agile / scrum nei loro ambienti di sviluppo.

La mia azienda ha finalmente intrapreso l'integrazione di pratiche agili e ha iniziato con un team di 4 sviluppatori in un gruppo agile su una base di prova. Sono passati 4 mesi con 3 iterazioni e continuano a farlo senza essere completamente agili per il resto di noi. Ciò è dovuto al fatto che la fiducia della direzione per soddisfare i requisiti di business con un bel po 'di richiesta di tipo ad hoc dall'alto.

Recentemente, ho parlato con gli sviluppatori che fanno parte di questa iniziativa; mi dicono che non è divertente. Non sono autorizzati a parlare con altri sviluppatori tramite il loro master Scrum e non sono autorizzati a prendere alcuna telefonata nell'area di lavoro (che può andare bene fino a un certo punto). Per esempio, se voglio parlare con il mio amico per i calci che è nella squadra agile, non sono autorizzato senza l'approvazione del master Scrum; chi è seduto proprio accanto alla squadra agile.

L'idea di tutto questo o dell'agile è quella di fornire un vuoto completo per gli sviluppatori agili da eventuali interruzioni e di averli messi in buone 6+ ore produttive. Bene, ragazzi, io non sono un guru agile, ma quello che ho letto su Yahoo è un documento rollout agile e simile per altre organizzazioni, mi dà la sensazione che agile non sia economico. Richiede risorse e budget per instillare agili nei team e correggere il problema non appena arrivano per rimetterli in carreggiata.

Per cominciare, richiede formazione per sviluppatori e coaching per manager ed ecc, ecc ... L'attuale master Scrum era un manager che impiegò un paio di giorni di agile corso di formazione pagato dalla dirigenza che ora sta conducendo questo agile team. Ho anche sentito nell'incontro che un manifesto agile non impone che l'agilità non sia impostata in termini di pietre e sia personalizzata in modo diverso per ogni azienda. Bene, tutto sembra buono e motivo.

In conclusione, ho sempre pensato che l'agile avrebbe dovuto portare armonia nei team di sviluppo che si traducono in felici sviluppatori. Tuttavia, ho una sensazione molto opposta quando parlo con gli sviluppatori del team agile. Sono scontenti che non possano parlare altro che lavorare, stare seduti tranquillamente tutto il giorno solo lavorando, e sentono che è solo un altro modo per il management di farli lavorare di più.

Dimmi, per favore, se questo è uno degli esempi di buone pratiche utilizzate allo scopo di un vantaggio egoistico per più dollari? O forse, siamo solo noi sviluppatori come me e questo gruppo agile sente che non gli piace lavorare in un ambiente in cui respirano solo lavoro perché sono al lavoro.

È una società nel settore sanitario che ha uffici negli Stati Uniti. Sicuramente si sente come un agile stile cowboy che mi fa davvero non volere andare per niente agile, specialmente alla mia attuale compagnia.

Tutto ciò ha a che fare con la gestione che è completamente a buon mercato. Tagliare caffè costosi per una versione più economica, dare risalto al risparmio ed essere produttivi rimanendo il più snello possibile.

La mia sensazione è che qualcuno nella gestione dietro la porta abbia buttato fuori questa idea, che agile ti fa produrre di più in modo che possiamo mostrare ai nostri capi che produciamo di più con lo stesso organico. Oppure, forse, ci permetterà di ridurre l'organico, se è il caso.

Stanno facendo il loro incontro quotidiano di 5 minuti. Ma non è permesso parlare o parlare con qualcuno al di fuori della propria squadra. Tutta l'attenzione è concentrata sul lavoro.

    
posta 5 revs, 4 users 68%Smith James 16.08.2018 - 21:23
fonte

14 risposte

87

Stai descrivendo la dittatura manageriale, non agile. Agile riguarda lo sviluppo incrementale in un campo in cui i requisiti cambiano, non quello di dettare alle persone il modo in cui svolgono individualmente il proprio lavoro.

    
risposta data 15.03.2011 - 18:08
fonte
46

They are not allowed to talk to other developers by their Scrum master and are not allowed to take any phone calls in the work area

Questo non fa parte delle pratiche Agile e un problema separato.

Una grande motivazione delle metodologie Agile è una maggiore comunicazione tra gli sviluppatori. La limitazione della comunicazione sviluppatore < - > dello sviluppatore è un problema separato dalle pratiche Agile. Non sto dicendo che questo non sta accadendo - ovviamente lo è, ed è stato etichettato come parte del lancio "agile" nella tua organizzazione, ma questo è davvero un problema separato da agile (e un po 'contrario allo spirito di sviluppo agile, IMO).

    
risposta data 15.03.2011 - 18:04
fonte
31

Sembra un'implementazione piuttosto perversa di agile. Agile, semmai, dovrebbe ridurre la microgestione, non aumentarla. Il team si impegna e parte del processo è che la direzione si fida che il team lo realizzerà. Il daily scrum è un modo per gli sviluppatori di comunicare tra loro e un modo per informare ciò che hanno fatto, non come hanno trascorso il loro tempo (che è un errore che ho visto in alcuni punti). Anche il processo di stima dovrebbe rimuovere il tempo esplicito dalle stime, dal momento che dovresti stimare la relativa complessità, non quanto a lungo una storia prenderà (un altro errore comune). Controllare il tempo trascorso dagli sviluppatori è il segno distintivo del microgestione e rimuovere il tempo dal processo è uno dei principi fondamentali dell'agile.

    
risposta data 15.04.2015 - 17:05
fonte
23

Questo non è agile.

In primo luogo, Scrum non è agile . Scrum, francamente, è una cazzata. Sono cresciuto in una casa di Extreme Programming (letteralmente - ho avuto Kent Beck seduto sul divano di mio padre e mi parla di test), e posso dirvi che Scrum non lo è. Scrum è uno strumento di gestione del progetto, un ritmo definito per un progetto di sviluppo. Ma non ha nulla da dire sullo sviluppo stesso, e molto poco da dire su requisiti, pianificazione e relazione con il cliente. XP ha molto da dire su tutto ciò; qualsiasi altra metodologia che voglia chiamarsi agile deve avere qualcosa da aggiungere alla conversazione. I sostenitori di Scrum lo hanno descritto non come un processo, ma come un involucro per un processo. Un uomo saggio una volta ha sottolineato che un involucro è ciò che rimuovi e scarti per ottenere le cose buone.

Ok, mischia la miseria!

In secondo luogo, un principio fondante di XP, che credo sia fondamentale per qualsiasi processo agile, è che è centrato sullo sviluppatore . È un modo per dare agli sviluppatori il potere di fare il lavoro che sanno di dover fare e viene così spesso impedito. Una squadra agile può essere strutturata come una democrazia o un'autocrazia, ma i leader sono sviluppatori. Ci sono ruoli per i project manager e così via - ruoli vitali - ma non è una leadership del team. Avere un manager - mi dispiace, 'scrum master' - stare seduti a comandare la gente è un segnale sicuro che la squadra non sta facendo agilità.

Mi sento come se ci dovesse essere un terzo. Non c'è.

    
risposta data 16.03.2011 - 00:24
fonte
23

L'ambiente che descrivi suona come varietà da giardino cazzate pseudo-agili .

Sono stato coinvolto con Agile prima che fosse Agile. Circa 2000 stavo bruciando i codici, ho sentito parlare di Extreme Programming, l'ho provato e mi è piaciuto. Mi ha dato come sviluppatore un contesto in cui produrre software solido era la cosa più importante e mi dava gli strumenti per ridurre al minimo un sacco di cazzate che mi stavano facendo impazzire. L'ho adorato.

Il problema oggi, che Spiego in dettaglio altrove , è che la maggior parte delle persone che "adottano Agile" in questi giorni non sono interessate a migliorare nulla se le mette a disagio. Quindi per loro, "Agile" è solo una nuova leva per battere gli sviluppatori allo stesso modo. Al contrario, diciamo, un modo per aumentare radicalmente la produttività rimuovendo tutte le cazzate che rallentano lo sviluppo.

Proprio ora. Sto iniziando una società, e userò un sacco di XP, oltre a un sacco di altri trucchi che ho appoggiato nel mondo Agile. Ma proprio a causa di storie come la tua, mi ritraggo ogni volta che ho sentito parlare di una adozione Agile in questi giorni.

Quindi, per rispondere direttamente alla tua domanda: Agile non dovrebbe essere la nuova microgestione. Dovrebbe riguardare l'empowerment delle persone che fanno il vero lavoro per ottenere merda. Ma nel tuo caso, Agile suona come l'ultima bugia che ti stanno dicendo mentre si concedono i loro stessi cattivi istinti. Per il quale sono veramente dispiaciuto.

    
risposta data 16.03.2011 - 00:39
fonte
16

Scrum è il figlio bastardo di Agile. È lo stile più cascata di tutte le metodologie agili, ed è per questo che è il più popolare tra i gestori.

Tutti i metodi agili stanno producendo codice funzionante senza intralci. Leggi di nuovo. E ancora.

Tutto ciò che si frappone a quell'obiettivo, indipendentemente dalle "regole agili", è sbagliato. Se le regole si intromettono, cambia le regole f * * ! Questo è il modo agile, è ciò che lo rende pertinente ed efficace.

Il miglior esempio di questo è dato da Alistair Cockburn (uno degli autori del manifesto agile):

“Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone.”

Se questo funziona per la qualità dei ragazzi che hai, allora è tutto ciò di cui hai bisogno. Non hai bisogno di un maestro di mischia o di una metodologia "agile". Se ti trovi seduto in una mischia quotidiana, allora f * * * fallo. Farti alzare in piedi è solo una patetica rinuncia alla tua capacità di pensare per conto tuo.

C'è una risposta al tipo di agile che stai facendo. È questo. Stampalo e fissalo da qualche parte quando non c'è nessuno in giro e fagli scoprire da soli.

    
risposta data 11.06.2011 - 02:01
fonte
11

The current Scrum master was a manager who took a couple days agile training class paid by the management is now leading this agile team.

Questo è il tuo problema. I manager vogliono un po 'di Agile, non sanno veramente di cosa si tratta e lo impongono ai team. Questo è più o meno cosa fare quando vuoi ridurre in modo significativo la produttività dei tuoi sviluppatori;)

La nuova proposta di processo dovrebbe provenire dagli sviluppatori. O almeno essere recensito e amp; approvato da loro se è un'idea di gestione.

In ogni caso, se gli sviluppatori lo rifiutano, non implementarlo ! O sarà il disastro che descrivi.

    
risposta data 15.03.2011 - 18:23
fonte
9

"Agile" e ogni altra "metodologia di gestione" sono spesso abusate per forzare la microgestione sulle persone. OTOH a volte viene anche abusato per difendere la scarsa manodopera.

"Siamo Agili" è la scusa più frequente che sento per mancanza di pianificazione, mancanza di riflessione sul design, caratteristiche, qualità, cicli di rilascio. Questo di solito dagli sviluppatori e dalla gestione inferiore. È follemente anche la scusa più frequente che sento da middle manager, architetti, venditori, ecc. Per la microgestione, le scadenze e i featurelists sempre mutevoli, costringendo il massiverter alle persone (le sempre mutevoli scadenze e featurelists assicurano ovviamente), ecc. Ecc. .

I due naturalmente sono spesso in contraddizione diretta e possono accadere sullo stesso progetto.

    
risposta data 16.03.2011 - 12:55
fonte
7

Per rispondere alla tua domanda originale, Agile è la nuova gestione micro, direi di no.

Per prima cosa, leggi questo (manifesto Agile) e noterai che non parlare ai tuoi co-sviluppatori non è elencato.

In realtà "Individui e Interazioni" è esattamente l'opposto di non parlare con i tuoi co-sviluppatori.

    
risposta data 15.03.2011 - 20:07
fonte
2

Agile dovrebbe essere la nuova autogestione. Se l'agile viene praticato correttamente, molte decisioni vengono prese da un cliente e uno sviluppatore che lavorano su una story story con ambito appropriato che viene aggiunta al backlog come attività sono identificati.

La mischia quotidiana riguarda la comunicazione, non la gestione. Ci saranno alcune discussioni sulla priorità e il bilanciamento del carico, ma la persona gestita nella mischia è, si spera, la scrum master. Come sviluppatore, presento, dico cosa ho fatto, cosa ho intenzione di fare e quale aiuto mi serve. Quindi il mischia dovrebbe entrare in azione e rimuovere gli ostacoli ai miei progressi.

I team Agile non devono sentirsi come se il lavoro quotidiano fosse gestito gerarchicamente. Se le decisioni vengono prese da lontano da qualcuno in cima a un'organizzazione gerarchica, è tempo di decentralizzare il processo decisionale! Per alcune persone e alcune organizzazioni, questo potrebbe essere un ponte troppo lontano. Se quanto segue non è vero per la tua organizzazione:

Vivi il Agile Manifesto

"We are uncovering better ways of developing software by doing it and helping others do it."

Evita "Incontra il nuovo capo, come il vecchio capo". Originare Agile all'interno del team il più possibile. A volte questo accade scegliendo una coalizione di volontà di partecipare a un progetto di prova con Agile. Se riesci a formare il tuo team Agile da volontari o membri invitati che hanno un track record per un buon lavoro di squadra, possono risolverlo. Utilizzare un piccolo team su un progetto breve, magari per un cliente interno o altamente accessibile.

Abbraccia il cambiamento. Forse puoi fare un po 'di allenamento, ma forse il tuo budget è limitato e il denaro non è lì. Altre opportunità possono fornire anche miglioramenti. Fai un po 'di lettura, chiedi ai membri del team di imparare cosa possono fare con Agile e insegnarti a vicenda. Potresti riuscire a trovare personale nuovo o esistente qualificato per modellare e guidare nell'adozione di Agile.

    
risposta data 20.12.2012 - 05:40
fonte
1

Le squadre agili sono come le squadre di calcio che lavorano per raggiungere un obiettivo comune. Ho fatto parte di team agili per alcuni anni e la chiave è una comunicazione efficace ed efficiente tra tutti i portatori di interesse. I manager / scrum master sono semplici facilitatori della squadra e la gestione / micro gestione tradizionale ucciderà lo spirito della squadra.

Nelle squadre in cui ho lavorato, siamo incoraggiati a giocare a squadre dopo l'orario di lavoro per migliorare il cameratismo all'interno dei membri. Ho raccolto questi pensieri qui .

    
risposta data 11.06.2011 - 08:58
fonte
0

Per rispondere alla tua domanda: No. Agile non è una forma di microgestione. Ma come qualsiasi strumento, le persone possono usarlo in modo errato. Agile è meraviglioso se implementato correttamente e quando le persone sono coerenti con esso.

I miei pensieri sull'argomento "Devs not talking to nobody but the scrum master":

Ho lavorato in un posto in cui era una regola prima. TUTTAVIA, la regola era più legata al chiedere alle persone di completare i compiti. Per esempio, non posso salire a caso a un tester di sviluppo e chiedere loro di fare qualche test per me nelle prossime ore. Ho bisogno di parlare con il master di mischia in modo che possano discutere con il membro del team di come quel lavoro si adatta allo sprint se si tratta di un'emergenza (o se deve essere spinto all'arretrato per uno sprint futuro).

In questo caso, ho compreso il concetto di "sviluppatori che non parlano tra loro" perché si sono veramente tradotti in operazioni di incanalamento attraverso un checkpoint in modo che uno sviluppatore particolare non sia sovraccarico o occupato in compiti di emergenza che non possono portare a termine il lavoro pianificato.

Altrimenti, gli sviluppatori DEVONO parlare tra loro. Sempre. Ti aiuta a superare i problemi più rapidamente, a diventare più vicino come una squadra e a fornire più velocemente.

Solo per offrire un'altra prospettiva: Sono anche stato in un ambiente in cui la gente pensava che gli sviluppatori "parlavano troppo". Dopo un sit-down, abbiamo scoperto che in realtà "gli sviluppatori non sono abbastanza indipendenti da fare il proprio lavoro. Perché tutto è così frammentato, gli sviluppatori devono andare da altre tre persone per completare un piccolo compito."

Quindi, quando i manager hanno deciso di passare all'agile, si aspettavano che questo aiutasse a portare le informazioni ai posti giusti e a fermare gran parte della frammentazione all'interno dell'organizzazione. Alcune persone erano deluse dal fatto che dopo l'implementazione di Agile, gli sviluppatori stessero ancora correndo avanti e indietro l'uno con l'altro. Ma quello che non capivano è che stava accadendo sempre meno. Ci è voluto del tempo però. Quindi, forse se questo è ciò che sta accadendo nella tua organizzazione, potrebbe essere che le persone si aspettavano che fosse agile risolvere le cose durante la notte. Questo non è il modo in cui funziona.

    
risposta data 16.08.2018 - 22:43
fonte
-1

L'autore originale Smith Janes potrebbe aver dato esperienza. Ma questi sono i problemi tipici che ho riscontrato nel progetto Agile.

  1. La maggior parte delle organizzazioni, gli sviluppatori dovrebbero lavorare in più progetti, in Agile / scrum .. Gli sprint non sono mai considerati questo fatto. il tuo Scrum Master presuppone che tu debba finire le tue storie alla fine dello sprint. Il tuo Scrum master potrebbe essere dedicato a un solo progetto, ma non agli sviluppatori .. QUESTA E 'LA DISTRAZIONE - non è necessario semplicemente prendere una telefonata o permettere una telefonata.
  2. Ho visto progetti Agile in cui è stato programmato Sprint, storie incluse in Sprint, senza essere rannicchiati..a metà o metà degli sprint ... gli sviluppatori che trovano dipendenze non risolte, i requisiti o la storia non sono completati narrati ... .. Questo è uno degli abusi nei progetti più agili.
  3. Test: TTD .. sì, è molto buono .. ma ho visto la maggior parte dei progetti Agile affidarsi totalmente al TTD ... nessun ambito o tempo consentito per test funzionali o umani .. Un altro abuso ... Un sacco di Scrum Masters inoltre non conosce o capisce l'importanza dei test funzionali. Il tuo codice potrebbe funzionare in modo perfetto, se non serve alle esigenze aziendali. Non serve a niente. Questo succede quando gli affari non partecipano molto bene .. o la partecipazione è lì ... ma non riflette le decisioni aziendali .. Alla fine, gli sviluppatori sono incolpati, non hai fornito la funzionalità ... o finirà con il cambio dell'ultimo minuto ... ore extra lunghe perché il tuo master Scrum non vuole prendere la colpa per la storia non completata.

Abuso qui ... o scarsa partecipazione del business o del partecipante non pienamente informato o persona in affari che si ritira nel bel mezzo dello sprint.

  1. Non tutti i progetti sono adatti per Agile ... La maggior parte dei manager o dei maestri di mischia non lo sanno. Progetti di manutenzione .. Un difetto inizialmente ipotizzato può essere fatto in 8 ore, accettato nello sprint. Dopo aver trascorso 4 ore, ho scoperto che questo è Java / un altro prodotto ... (Recentemente ho affrontato il difetto di negoziazione relativo a Quartz Scheduler ... all'interno del nostro progetto) e questo difetto potrebbe portare all'aggiornamento del prodotto / pacchetto..deal burocrazia, approvazione, finanziamento, nuova versione o aggiornamento dovrebbero essere approvati dall'Ingegneria interna ecc., 5. Retrospection: solo una manciata di progetti Agile fa questo passo .. Se non lo hai fatto ... Gestione, Scrum Master non si è mai preso nessuna responsabilità delle storie fallite ..
  2. Accoppiamenti ... Molti sviluppatori considerano l'abbinamento come luogo per abusare dei colleghi di lavoro .. criticano altri progetti, pratiche di codifica ... considerano il lavoro di gruppo., imparano gli uni dagli altri ... Un altro modo di abusare di Agile / Scrum.

Agile è sicuramente una buona metodologia .. A meno che la tua organizzazione non segua completamente o non sia allenata .... È Abusata .... effetti collaterali 60+ ore di lavoro / settimana, gioco di colpa, morale basso.

    
risposta data 10.03.2013 - 21:31
fonte
-3

Agile è la microgestione sotto mentite spoglie. Non c'è spazio per l'iniziativa o la creatività in Agile, ha rimosso il divertimento dalla programmazione per consentire ai manager incompetenti di mantenere il controllo anche senza avere un indizio dal punto di vista tecnico.

    
risposta data 02.05.2013 - 00:41
fonte

Leggi altre domande sui tag