Come possiamo rendere agile il divertimento per gli sviluppatori che amano possedere personalmente, in modo indipendente, blocchi di grandi dimensioni dall'inizio alla fine

Siamo all'incirca a metà del nostro passaggio dalla cascata all'agile usando la mischia; siamo passati da grandi team nei silos di tecnologia / disciplina a team interfunzionali più piccoli.

Come previsto, il passaggio ad agile non è adatto a tutti. Ci sono una manciata di sviluppatori che hanno difficoltà a adattarsi ad agili. Voglio davvero tenerli impegnati e sfidati, e alla fine mi piace venire al lavoro ogni giorno. Sono persone intelligenti, felici, motivate che rispetto sia a livello personale che professionale.

Il problema di base è questo: alcuni sviluppatori sono principalmente motivati ​​dalla gioia di prendere un lavoro difficile, pensare attraverso un progetto, pensare attraverso potenziali problemi, quindi risolvere il problema pezzo per pezzo, con una minima interazione con gli altri, per un periodo prolungato periodo di tempo. Generalmente completano il lavoro ad un alto livello di qualità e in modo tempestivo; il loro lavoro è mantenibile e si adatta all'architettura generale. Passando a un team interfunzionale che apprezza l'interazione e la responsabilità condivisa per il lavoro e la consegna della funzionalità di lavoro a intervalli più brevi, i team si evolvono in modo tale che l'intero team risolva il difficile problema. Molte persone trovano che questo sia un cambiamento positivo; qualcuno che ama affrontare un problema e possederlo indipendentemente dall'inizio alla fine perde l'opportunità di lavorare così.

Questo non è un problema con le persone aperte al cambiamento. Certamente abbiamo visto alcune persone a cui non piace il cambiamento, ma nei casi di cui mi preoccupo, le persone sono brave performer, sinceramente aperte al cambiamento, fanno uno sforzo, vedono come sta il resto della squadra cambiando e vogliono adattarsi. Non si tratta di qualcuno che è difficile o ostruzionista o che vuole accaparrarsi il lavoro più succoso. Semplicemente non trovano gioia nel lavoro come una volta.

Sono sicuro che non possiamo essere l'unico posto in cui non ci siamo imbattuti in questo. Come si sono avvicinati gli altri a questo? Se sei uno sviluppatore motivato dal possesso personale di un grosso pezzo di lavoro da un capo all'altro e ti sei adattato a un diverso modo di lavorare, che cosa ha fatto per te?

Dirò che ci sono pochissimi negozi di software che hanno la fortuna di avere la rara distinzione in cui Agile non ha davvero senso come metodologia. Se l'intero team è composto da sviluppatori software davvero eccezionali con una profonda comprensione degli aspetti del business e della longevità con l'azienda e tra di loro, e se i requisiti aziendali e le esigenze del cliente sono in genere sempre simili e raramente soggetti a cambiamenti nel mezzo di un Rilascio quindi hai la fortuna di lavorare in un ambiente così raro in cui Agile probabilmente può effettivamente FARE MALE.

È progettato per essere l'approccio più efficace tra caotico e in continua evoluzione delle esigenze aziendali e delle esigenze dei clienti, in evoluzione o modifica delle risorse del progetto e scadenze rigide o mutevoli. Un tale ambiente comporta un certo destino per lo sviluppo tipico delle cascate in quanto è vulnerabile ai cambiamenti del team a metà progetto, vulnerabile alle esigenze mutevoli ed estremamente vulnerabile a una data che cambia.

Mi sento per i tuoi preziosi membri del team che non trovano più gioia nel loro lavoro. Possono benissimo essere persone di eccezionale talento che si impegnano nel loro lavoro, ma alla fine un certo numero di fattori al di fuori del loro miglior controllo può ancora uccidere il progetto. Il modo migliore per avvicinarsi allo sviluppo delle funzionalità è perdere loro l'atteggiamento e l'espressione individuali e pensare in termini di approccio di squadra.

Se scopri che questo non funzionerà per loro, puoi trovare un uso speciale per loro. Se sono eccezionalmente talentuosi ed esperti, vedi se sarebbero interessati a un ruolo architettonico, definendo progetti, approcci di alto livello, sperimentando nuove tecnologie e sviluppando le migliori pratiche. Chiedi a queste persone di controllare e rivedere la documentazione di progettazione.

Se questo non è ancora adatto a loro, allora forse farli lavorare separatamente su refactoring tecnici estremamente complessi su un ramo separato, prototipi enormemente coinvolti e prove di concetti, o altri lavori pionieristici che a volte devono essere fatti ma non si adattano bene al ambito di un singolo progetto o release.

Semplicemente non trovano gioia nel lavoro come una volta.

Corretta.

È un grande sintomo che stai sbagliando.

Agile non dovrebbe imporre un nuovo cattivo ordine alle persone.

Agile dovrebbe consentire al team di auto-organizzarsi in modo da renderlo più efficace.

Auto-organizzazione significa che la gestione non impone regole strane. Non impone programmi scadenti e non impone interazioni inutili.

Alcuni sviluppatori sono principalmente motivati ​​dalla gioia di prendere un pezzo di lavoro difficile, pensare attraverso un progetto, pensare attraverso potenziali problemi, quindi risolvere il problema pezzo per pezzo, con una minima interazione con gli altri, per un lungo periodo di tempo

Perché non possono continuare a farlo?

Perché cambiarli?

Si prega di leggere il Manifesto Agile alcune volte.

Il Manifesto Agile dice

Individui e interazioni su processi e strumenti

Non dice forzare le persone a lavorare in un modo scomodo e improduttivo.

Se stai forzando le persone a "interazioni" di valore troppo basso, allora sei andato troppo lontano.

Software funzionante su documentazione completa.

Lo stanno facendo? Quindi lasciali soli.

Collaborazione con i clienti sulla negoziazione del contratto.

Lo stai già facendo? Quindi non cambiare.

Rispondere al cambiamento seguendo un piano.

Dove queste persone sono già in grado di rispondere ai cambiamenti? In tal caso, erano già Agili. Non avevano bisogno di cambiare.

la mia azienda ha tentato (e ancora tentando dopo anni di tentativi) di fare la stessa transizione e finora, personalmente, non ho riscontrato molto successo. Durante questa transizione, ho fatto molte letture sullo sviluppo agile e su diversi modi / aspetti / preoccupazioni / tecniche e una cosa con cui sono fortemente d'accordo è che lo sviluppo agile puro è più adatto quando l'intero team è composto da persone senior e di alta qualità (o almeno tutte le persone dello stesso livello).

L'ultima versione facevo parte di un team "agile" che aveva troppi sviluppatori IMHO con livelli di abilità in tutto il luogo e abbiamo cercato di coinvolgere tutti nello stesso progetto. È stato un disastro. Abbiamo parlato e discusso più del lavoro e alla fine quello che il team ha prodotto è stato un lavoro medio (leggi Peopleware o Mythical Man Month sul prendere la media). Dimentica i modelli di progettazione, dimentica il basso accoppiamento o la suddivisione del codice in classi e metodi di piccole dimensioni. Dimentica di cercare di rendere qualcosa di interessante perché a) che non poteva essere spiegato e compreso da tutti i membri del team (almeno non in modo tempestivo) eb) dato che eravamo agili, qualunque cosa avessi iniziato questa iterazione, qualcun altro senza assolutamente capire continuerebbe nella prossima iterazione. Personalmente,

Odiavo assolutamente il fatto di non poter fare nulla con i modelli C ++ o di scrivere alcune librerie di framework di basso livello (ma un po 'complesse) che avrebbero reso le nostre vite molto più facili. Come si può fare qualcosa del genere quando nessun altro membro del team è nemmeno in grado di leggere i file di intestazione STL ma dovremmo tutti lavorare su una cosa alla volta. L'intero progetto ha finito per essere una funzione forzata per funzionalità, perché questo è ciò che l'agile sembra enfatizzare.

Allo stesso tempo, ci sono poche (pochissime) persone nella mia azienda con cui mi piacerebbe assolutamente lavorare fianco a fianco e condividere tutto il mio codice.

Ma ora devi affrontare una scelta. A) Prendi tutti i tuoi bravi sviluppatori senior che producono codice di alta qualità e inseriscili nel loro team e metti il ​​resto in un team separato. O B) cercare di bilanciare le squadre e metterne di buone con altre meno buone. In (A) il problema è che una delle tue squadre sarà molto poco performante e non acquisirà buone abilità / abitudini dai bravi ragazzi. In (B) i tuoi bravi ragazzi (in puro ambiente agile) si sentiranno frustrati e inizieranno a lavorare sui loro curriculum. Il mio è aggiornato.

Allora cosa devi fare?

Non so se questa è la soluzione giusta. Chiedimi di nuovo tra circa un anno. Ma cosa succede se invece di "pura agilità" formassi una squadra, ma identifichi chiaramente quale persona (e) ha più influenza (design, recensioni di codice ...) e assicuri che quella persona capisca questo e sia ricompensata per responsabilità extra. Mentre i membri del team iniziano a lavorare insieme, identifica quelli che stanno acquisendo buone abitudini / pratiche ed elevale allo stesso livello delle tue brave persone. Spero che quando le persone passano una versione o due a lavorare insieme, impareranno cosa pensano l'altra persona e come funzionano, così saranno più compatibili per lavorare nello stesso codice allo stesso tempo. Ma fino a quando ciò non accadrà, se si buttano le persone in un progetto, non sarà altro che frustrazione (di nuovo, solo la mia opinione).

Alcuni dei miei pensieri si basano su come ho iniziato a lavorare professionalmente nel software. Quando ero una cooperativa, ho lavorato con un ragazzo che era il mio mentore. Mi ha insegnato di tutto, dall'etica del codice al buon design, alla lettura di migliaia e migliaia di righe di codice che non hai scritto. All'inizio non eravamo affatto vicini allo stesso livello e sarebbe ridicolo se fossimo inseriti in un team agile e avessimo detto che potevamo lavorare su ogni altro codice. Ma nel tempo (pochi anni), abbiamo iniziato a pensare in modo molto simile. Ho potuto capire il suo codice con una semplice occhiata e mi ha detto più volte che non aveva assolutamente problemi (e ne era sorpreso) navigando nel mio codice che non aveva mai visto prima. Ci sono voluti anni, non qualcosa che è successo durante la notte. Dopo aver vissuto un disastro dopo l'altro in un ambiente agile negli ultimi anni,

Questa non è davvero una risposta, ma riassume la mia esperienza / osservazioni. Voglio vedere cosa direbbero gli altri a riguardo.

Che cos'è Agile?

È:

• un insieme di regole che devi seguire per raggiungere ciò che intendevano i regolatori?

• un approccio di ipotesi ottimale per ottenere risultati nell'ambito dei propri punti di forza, requisiti e limiti?

Se pensi che Agile sia la prima, e segui sempre ognuna delle regole Scrum e ti preoccupi costantemente se lo stai facendo bene o no, forse questo link ti illuminerà un po '.

Se pensi più al secondo, allora congratulazioni: ottieni "Agile". Qualsiasi metodologia Agile può essere solo un suggerimento su come procedere. Se qualsiasi aspetto del metodo agile scelto non ti sembra giusto, allora hai il dovere di smettere di usarlo, modificarlo o essere agilea proposito. L'importante è che tu raggiunga qualcosa, che non sei frenato da vincoli artificiali - non solo quelli che tutti conosciamo e amiamo dai nostri vecchi giorni a cascata in cui il Primo Ministro ti darebbe fastidio per i diagrammi completamente documentati che nessuno avrebbe mai leggi solo perché "questo è ciò che il processo dice di fare", ma anche dai vincoli di ciò che stai usando. Se una mischia quotidiana sembra un vincolo, allora non battere ciglio! Avere ciecamente perché le regole lo dicono non è più agile dei vecchi modi.

Ora, se hai dei ragazzi che riescono a fare le cose rinchiusi in una stanza con solo un litro di cola e un portello per la pizza, allora utilizza questo fatto. Dai loro una parte del sistema che è per lo più autonomo e bloccali. Quando hanno finito, dovresti convincerli a integrare quel lavoro (o convincere qualcun altro a farlo se lo preferiscono) con il resto del sistema.

Alistair Cockburn lo ha descritto nei suoi metodi. Se hai "praticanti di livello 3", un metodo agile perfettamente valido è il seguente:

“Metti 4-6 persone in una stanza con postazioni di lavoro e lavagne e accesso agli utenti. Invitali a consegnare agli utenti software in esecuzione e testati ogni uno o due mesi, altrimenti lasciali soli. "

Dato che hai un mix di persone, devi trovare un modo per farle lavorare insieme in modo costruttivo, e questo significa che un approccio a misura unica probabilmente non sarà molto efficiente. Quindi è necessario dividere i compiti, garantendo nel contempo che l'obiettivo comune sia enfatizzato. Va bene inviare quei ragazzi al codice, ma devono essere consapevoli di come le loro cose saranno parte integrante del resto del lavoro del team e che non riuscire a farlo è un fallimento di tutto ciò che stanno producendo . Una volta capito che (cioè non possono semplicemente fare quello che vogliono e consegnare qualcosa di inservibile), il tuo lavoro è finito.

Diciamo che l'agile non è per tutti e l'agile non è per ogni progetto. Allo stesso tempo, l'agile è un termine molto ampio e Scrum è solo una delle implementazioni di un processo agile - posso in qualche modo dire l'implementazione con probabilmente il maggior numero di vincoli che tenta di impostare un processo standardizzato con passaggi ben noti.

Un'altra area a cui pensare è qual è lo scopo di Agile? È agile il modo in cui funzionano gli sviluppatori? Forse - alcune metodologie vanno davvero in quella direzione. Ma l'agile stesso copre aree al di fuori dello sviluppo. Agile si occupa principalmente di guidare l'intero processo, il modo in cui funziona un'interazione, il modo in cui consegna il prodotto funzionante con le funzionalità più importanti in tempo e il modo in cui controlli le risorse, come vedi dove ti trovi nel progetto, eccetera.

Ci sono metodologie che non provano a cambiare nulla dal tuo processo di sviluppo - Scrum non è quello. Tutte le metodologie agili enfatizzano il miglioramento continuo. Rileverai alcuni passaggi inefficienti del tuo processo e proverai a migliorarlo / a cambiarlo - questo è il modo agile. Controlla un'altra metodologia agile popolare: Kanban.

Tu / la tua azienda avete deciso di utilizzare Scrum e questo può portare al fatto che ad alcune persone non piacerà e se ne andrà. Dovresti occuparti di ciascuno dei tuoi sviluppatori separatamente. Dovresti parlarne con ognuno di essi e dovresti cercare di trovare alcuni interessi che consentano loro di godere di nuovo del lavoro.

Possono avere un ruolo di mentori, possono insegnare agli altri, mostrare loro come rifattorizzare il codice per migliorare l'architettura quando lavorano in modo iterativo. Possono formare insieme alcuni progetti di architettura globale attraverso progetti. Possono anche lavorare su prove di concetti, partecipare a RFI (richiesta di informazioni) quando i clienti fanno domande per pensare alla fattibilità dei requisiti. Possono lavorare in coppia con sviluppatori meno qualificati e svolgere insieme compiti complessi, ecc. Il loro valore principale dovrebbe essere quello di usare le loro abilità e permettere ad altri di imparare da loro.

La mischia e l'agile a livello globale in qualche modo tengono giù gli individui e danno la priorità ai team: i team forniscono l'applicazione, non gli individui. Questa idea si basa sul fatto che non avrai mai una squadra in cui tutti hanno lo stesso set di abilità ed esperienza.

Se la transizione a Scrum avrà esito positivo, dovrebbero vedere che il processo complessivo è migliorato, i tempi di consegna sono stati ridotti, la qualità è migliorata e i clienti sono più soddisfatti. Possono ancora credere che le stesse applicazioni sviluppate siano molto peggio di quanto potrebbero essere, ma questo è il punto: il cliente non vuole il miglior codice mai scritto. I clienti desiderano il codice di lavoro minimo / più economico / più veloce che soddisfi le loro esigenze. Se la forza bruta è sufficiente per quello, allora sia. Questo è qualcosa che può causare problemi agli sviluppatori altamente qualificati, ma non è un fallimento agile, è il luogo in cui le esigenze aziendali e il perfezionismo si contrappongono.

Beneficerà l'intero team se prendi alcuni dei problemi principali e li passi a un grande sviluppatore. Tutti possono essere aggiornati in seguito e imparare qualcosa nel processo. Basta non creare un'intera applicazione in questo modo.

Non annacquare il codice al minimo comune denominatore. Fai in modo che l'inesperto raggiunga gli sviluppatori migliori.

Ci sono state molte discussioni su ciò che è o non è "agile" e molti sentimenti, esperienze e dubbi personali sul processo agile condiviso qui, ma non ho visto una vera risposta alla domanda. La domanda originale era come mantenere motivati ​​i tuoi migliori sviluppatori quando vedono il loro codice che hanno scritto a livello di pura forma d'arte e in cui hanno investito il loro sudore e sangue, violato da qualcun altro e "corrotto". Si noti che, agile o no, questo accadrà ad un certo punto, è solo più visibile ora perché stanno ancora lavorando sul codice contemporaneamente ad altri, invece di avere il tipico handoff da supportare, a quel punto semplicemente non vedevano quei cambiamenti essere fatti.

Quello che vedrei come la chiave qui è di espandere la responsabilità di questi sviluppatori e aiutarli a cambiare la loro attenzione sul quadro generale. Forse questo significa un nuovo titolo, come Software Architect, Team Lead o Senior Software Engineer. Quindi mostra loro che questa è un'opportunità per avere un impatto maggiore, non solo su un singolo progetto alla volta, ma su più progetti. Il senso di proprietà può essere ancora lì, ma il loro obiettivo non dovrebbe più essere la realizzazione di un unico grande progetto, ma sull'aiutare a stabilire lo standard per TUTTIprogetti. Aiutali a esprimere il loro forte desiderio di costruire qualcosa di eccezionale, ma sposta l'attenzione sulla costruzione di pratiche di ingegneria del software della tua azienda e sugli altri sviluppatori. Invece di fare il cretino al pensiero dei loro colleghi che fanno a pezzi il loro codice, questa può essere un'opportunità per loro di passare al livello successivo e guidare i loro compagni di squadra e portarli al loro livello.

Cercherò di illustrare alcuni aspetti che non sono stati affrontati da altre risposte e che, IMO, sono importanti.

Il problema di base è questo: alcuni sviluppatori sono principalmente motivati ​​dalla gioia di fare un lavoro difficile, pensare attraverso un progetto, pensare attraverso potenziali problemi, quindi risolvere il problema pezzo per pezzo, con una minima interazione con gli altri, per un periodo prolungato periodo di tempo. Generalmente completano il lavoro ad un alto livello di qualità e in modo tempestivo; il loro lavoro è mantenibile e si adatta all'architettura generale.

Questo tipo di sviluppatori può avere difficoltà ad adattarsi a un ambiente agile e il loro atteggiamento è spesso respinto come "riluttanza a cambiare", probabilmente correlata all'ego o all'antica.

Ciò che viene spesso ignorato è che per risolvere problemi complessi è necessario gestire molte informazioni e che ciò potrebbe richiedere molte analisi, pensiero, tentativi, delineare una soluzione, gettarla via, provarne un'altra. Un problema così complesso può richiedere da alcune ore a poche settimane di lavoro mirato fino a quando non avrai una soluzione completa.

Un approccio è che uno sviluppatore prende la specifica del problema, va nella sua stanza e torna due / tre settimane dopo con una soluzione. In qualsiasi momento (quando necessario), lo sviluppatore può avviare alcune interazioni con altri membri del team o con le parti interessate (ponendo domande su questioni specifiche), ma la maggior parte del lavoro viene svolto dallo sviluppatore a cui è assegnata l'attività.

Cosa succede in uno scenario agile? Il team suddivide il problema in piccoli pezzi (user story) dopo una rapida analisi (toelettatura). La speranza è che le storie degli utenti siano indipendenti le une dalle altre, ma spesso non è così: per spezzare un problema complesso in blocchi veramente indipendenti avresti bisogno di una conoscenza che normalmente ottieni solo dopo aver lavorato su di esso per diversi giorni. In altre parole, se sei in grado di spezzare un problema complesso in piccole parti indipendenti, significa che lo hai già sostanzialmente risolto e che ti resta solo il lavoro di diligenza. Per un problema che richiede, diciamo, tre settimane di lavoro, questo sarà probabilmente il caso durante la seconda settimana, non dopo un paio d'ore di toelettatura effettuata all'inizio dello sprint.

Quindi, dopo aver pianificato uno sprint, il team lavora su diversi blocchi di un problema che probabilmente hanno dipendenze tra loro. Ciò genera molte spese generali di comunicazione nel tentativo di integrare diverse soluzioni che potrebbero essere ugualmente buone ma che sono, beh, diverse l'una dall'altra. Fondamentalmente, il lavoro di prova ed errore è distribuito su tutti i membri del team coinvolti, con un ulteriore sovraccarico di comunicazione (che aumenta in modo quadratico). Penso che alcuni di questi problemi siano illustrati molto bene in questo articolo di Paul Graham, in particolare il punto 7.

Naturalmente, la condivisione del lavoro tra i membri del team riduce il rischio legato alla chiusura del progetto da parte di un membro del team. D'altra parte, la conoscenza del codice può essere comunicata in altri modi, ad esempio utilizzando revisioni del codice o dando presentazioni tecniche ai colleghi. A questo proposito, non credo che ci sia un proiettile d'argento valido per tutte le situazioni: la proprietà del codice condiviso e la programmazione delle coppie non sono l'unica opzione.

Inoltre, "la consegna della funzionalità di lavoro a intervalli più brevi" provoca un'interruzione del flusso di lavoro. Questo può essere OK se il pezzo di funzionalità è "aggiungi un pulsante Annulla nella pagina di accesso" che può essere completato entro la fine di uno sprint, ma quando lavori su un'attività complessa non vuoi tali interruzioni: è come cercando di guidare un'auto 100 km più veloce che puoi e fermandoti ogni 5 minuti per controllare fino a che punto sei arrivato. Questo ti rallenterà.

Certo, avere frequenti checkpoint ha lo scopo di rendere un progetto più prevedibile, ma in alcuni casi l'interruzione può essere molto frustrante: si può a malapena guadagnare velocità che è già tempo di fermarsi e presentare qualcosa.

Quindi, non penso che l'atteggiamento descritto nella domanda sia legato solo all'ego o alla resistenza al cambiamento. Può anche essere che alcuni sviluppatori considerino più efficace l'approccio alla risoluzione dei problemi sopra descritto perché consente loro di comprendere meglio i problemi che stanno risolvendo e il codice che stanno scrivendo. Forzare tali sviluppatori a lavorare in modo diverso può comportare una riduzione della loro produttività.

Inoltre, non credo che il fatto che alcuni membri del team lavorino da soli su problemi specifici e difficili sia contro valori agili. Dopo tutto, i team dovrebbero auto-organizzarsi e utilizzare il processo che hanno trovato essere il più efficace nel corso degli anni.

Solo i miei 2 centesimi.

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

Sembra che siano "Lone Rangers". Nella Scrum canonica, queste persone non riescono ad adattarsi al Team (mancano il bit di "interazione").

Se non sono "Lone Rangers", allora c'è speranza. Se stai eseguendo correttamente Scrum, devono far parte del design della funzione su cui lavoreranno (durante la pianificazione dello Sprint). Questa è l'unica volta in cui hanno bisogno di interagire con gli altri. Puoi persino "assegnare" tutte le storie relative a quella caratteristica.

Durante lo Sprint, saranno solo "infastiditi" dallo Scrum quotidiano ... fino a quando non potrai dimostrarli (con azioni, non con parole) che saranno solo 15 minuti del loro tempo, e solo per garantire che tutto stia funzionando senza intoppi. Stai vicino alle tre domande e la maggior parte delle persone smetterà di conformarsi.

Nel nostro team, abbiamo un gruppo speciale solo per i miglioramenti delle prestazioni. Non li vediamo molto, solo all'inizio dello sprint per parlare delle modifiche da apportare e alla fine nella retrospettiva. Hanno il loro "leader della mischia" che riferisce al team di Scrum of Scrum. Posso dirti che si stanno divertendo.

Se Joe (il tuo sviluppatore Hero) è un po 'flessibile, allora non vedo un problema:

Come detto sopra, lascia che il team si auto-organizzi: se alcuni problemi vengono affrontati meglio lasciando che Joe lo mastichi da solo, allora ti aspetteresti che un team auto-organizzante di mentalità aperta raggiunga questa conclusione da solo.

Le uniche sfide che rimangono nei pochi vincoli che Scrum impone:

1. Fornire funzionalità a intervalli regolari: se lasci che Joe mastichi un problema per mesi, senza nulla da mostrare fino alla fine, allora Joe non è davvero agile: sta prendendo in ostaggio il proprietario del prodotto e non gli concede l'opportunità di ri-spec quella parte del prodotto. Con questa pratica c'è anche il rischio che sia in ritardo e nessuno se ne accorga. (Ma secondo la tua descrizione non è così probabile). Rimedio: sarebbe troppo chiedere a Joe, sedersi insieme all'OP, spezzare la storia dell'utente e concordare risultati intermedi, preferibilmente (ma non necessariamente) con il valore dell'utente?

2. Onorare le priorità stabilite dal proprietario del prodotto: se parti di codice sono di proprietà di esperti, si rischia una situazione in cui l'evoluzione del prodotto è determinata dalla disponibilità di ciascun esperto, piuttosto che dalle priorità commerciali: il resto del team potrebbe lavorare su funzionalità meno importanti, mentre le 3 funzionalità principali sono in stallo perché "solo Joe può farlo". Questo è male. In quel momento, il team dovrebbe (temporaneamente) cambiare abitudine e dividere il lavoro di Joe su più membri del team.

In breve: se Joe, l'eroe-sviluppatore, concorda con l'OP come mostrerà i progressi ogni sprint, allora la squadra può assegnargli alcune storie e lasciarlo in pace. Ma se l'OP ha troppo lavoro per Joe e non abbastanza per la squadra (o viceversa), Joe e la squadra devono adattarsi, non l'OP.

Le regole per un team agile dovrebbero essere personalizzate per adattarsi al team - questa può essere una personalizzazione davvero personale; Ad esempio, ho lavorato in una squadra in cui la regola era:

Tutto il codice deve essere scritto da una coppia, tranne David può scrivere solo il codice.

David era uno sviluppatore / architetto senior, che lavorava principalmente su strumenti che altri avrebbero usato nel proprio codice. Possedeva moltissimo il codice che aveva scritto. È stato mantenibile e testato, e tutti i membri del team sapevano che probabilmente era il miglior programmatore e che il team sarebbe stato servito meglio facendogli costruire alcuni elementi della struttura e presentarli come completi alla squadra.

Non ho una risposta per gli introversi delle varietà da giardino, ma per gli introversi eccezionali, il team prenderà felicemente regole diverse per ottenere il beneficio.