In Agile SCRUM, come gestisci la distribuzione uniforme del lavoro in uno sprint tra "esperti"?

Where I work, we have a lot of silos of knowledge.

Non buono.

The concern is that it doesn't make sense to have the GUI guy work on Networking stuff, when there is already someone that can (in terms of efficiency) get something done better because they are already familiar with it.

Tranne naturalmente che ciò porta a questo tipo di scenario o al sempre presente "Cosa succede se Bob viene investito da un autobus?" problema.

How would I overcome this issue?

Per prima cosa, la gestione superiore non vede le tue stime. Non riescono a vedere gli incarichi a livello di persona. Non dovrebbero mai sapere che hai scelto 21 su 5. Dovrebbero vedere che alla fine dello sprint, la squadra ha fatto cose interessanti.

Oltre a questo, dovresti addestrare i tuoi dipendenti in modo che invece di 5 e 21 stime hai 5 e ... 15. Dopodiché, spetta al tuo project manager e / o team lead assicurarsi che le tue funzionalità hanno la priorità per distanziare il lavoro. Non allineare 90 ore di lavoro di rendering come massima priorità se sai che l'esperto del renderer ha 60 ore nel prossimo sprint. A volte capita che succeda, ma gestire i flussi e le fluttuazioni naturali di lavoro contro le persone è un'esigenza comune, anche con l'attenzione di agile sul fare le cose quando sono necessarie.

In una certa misura, non c'è niente che puoi fare se i tuoi team sono specializzati. E se stai chiedendo dal punto di vista di un manager, non c'è niente che dovrebbe fare, sia. Questo è un problema che il team stesso deve risolvere.

Un punto da ricordare è che scrum cerca di ottimizzare il team , non l'individuo. Va perfettamente bene (da una prospettiva di mischia) per un individuo essere inattivo. L'obiettivo è che la squadra nel suo complesso sia produttiva, e se ciò significa che il ragazzo UI è inattivo parte del tempo per fare in modo che la squadra sia produttiva, così sia.

Man mano che la tua squadra matura, il team stesso imparerà come ottimizzare se stesso per evitare che i membri del team non abbiano nulla da fare. Ad esempio, i membri del team possono imparare a scrivere test, o possono creare documentazione, o affrontare il debito tecnico, o il supporto interno, oppure possono essere in conversazioni con il proprietario del prodotto sui prossimi requisiti.

Come consulente, anche i miei team hanno membri con specializzazioni. Dobbiamo raggiungere l'alta qualità il più rapidamente possibile per soddisfare al meglio le esigenze dei nostri clienti e i margini di profitto della nostra organizzazione. È del tutto valido avere membri del team specializzati per prestazioni ottimali.

TUTTAVIA: ciò non significa che non dovrebbe verificarsi l'allenamento incrociato.

Abbiamo specialisti di sviluppatori front-end, ma quando sono impegnati i nostri progetti non possono fermarsi. Se sembra che uno sviluppatore .NET abbia un po 'di tempo in più in uno sprint, non rimane inattivo. Prendono qualcosa con cui hanno meno familiarità e usano l'esperto come qualcuno a cui possono porre domande. Dal momento che lo specialista sta già lavorando su altre cose (altrimenti la storia non sarebbe disponibile per afferrare) non stai "sprecando" velocità, ma piuttosto aumentando le capacità e le capacità complessive della squadra in quella specialità (supponendo che il tempo per le domande non negare l'aumento della produttività). Questo è un ottimo modo per utilizzare i membri del team 'inattivo' per aiutare la velocità complessiva del team e aumentare le capacità interfunzionali del team.

Un'altra opzione è quella di utilizzare gli sviluppatori inattivi per associare il programma, scrivere test di unità per gli altri, scrivere qualsiasi documentazione necessaria, aiutare il proprietario del prodotto con qualsiasi attività che potrebbe essere necessaria. Ricorda sempre che QUALSIASI lavoro che deve essere svolto dal team può sempre utilizzare un set di mani extra per farlo accadere più velocemente!

A seconda del livello di specializzazione potresti prendere in considerazione un qualche tipo di implementazione della programmazione della coppia. Se qualcuno è sottoutilizzato durante uno sprint, non preoccuparti della velocità, e falli abbinare a qualcuno che viene utilizzato in un'area di competenza che non hanno familiarità con. L'ovvio beneficio di questo è che i membri del tuo team costruiranno abilità in una più ampia varietà di aree verso la fine di chiunque sia capace di fare qualsiasi cosa .

I silos sono cattivi per una serie di motivi. Il fattore bus era già menzionato. Quando hai una specializzazione ristretta, paghi anche il prezzo della consegna e l'integrazione.

Mi piace l'idea di "non fare nulla" per te come manager - questo è il consiglio saggio, tuttavia, ci sono ancora cose a cui devi prestare attenzione.

1. Priorità . Questo sembra quasi sempre fuoriuscire dalla scena quando la domanda arriva ai processi (come la pianificazione, la stima, ecc.) - i processi sono lì per aiutarti a fornire valore per il business, non per il loro stesso interesse. Chiedi a te stesso, o meglio al tuo team, in che modo la cosa più importante sul tuo backlog può essere eseguita nel modo più rapido ? Lo scopriranno. Non assegnare lavoro per riempire i cicli di inattività. Invece di fare in modo che la persona inattiva lavori su qualcosa di piccolo ma non importante, falli passare del tempo a migliorare il modo in cui forniscono un valore importante. C'è sempre lavoro per automatizzare / templatizzare / etc.

2. Proprietà del team . Se in realtà hai una squadra (non solo assunti consulenti temporanei dispersi), lavora per migliorare il sentimento di padronanza della squadra al suo interno. È fantastico quando tutti nel team sono interessati ai lavori in corso. È brutto quando uno è sbadigliare durante lo stand-up mentre ascolta l'aggiornamento di altri che non ha alcun interesse / comprensione. Cerca di far lavorare il team su sezioni verticali , in modo che costruiscano un'esperienza end-to-end alla volta - quindi, saranno più acquistati in tutte le tempo, e incoraggerà l'UI ad aiutare con il back-end e viceversa. Come già suggerito, XP è ottimo per aumentare la proprietà del team e migliorare la condivisione delle conoscenze.

3. storie più piccole . 21 è A LOT per una stima. Puoi fare fette verticali più piccole? Questa è un'abilità che il tuo team deve sviluppare ed è difficile da fare all'inizio. Quello che sostengo è di giocare a poker con le dita (1,2,3,5) se si è fuori le dita per il valore di stima - questo è un segnale che la storia è troppo grande per essere stimata . Una volta acquisita padronanza nell'abilità di creazione della storia, tenderai naturalmente verso NoEstimates movimento. Il semplice conteggio delle storie funzionerà al meglio per la tua velocità. Leggi questo per gli svantaggi però;)