Mischia per team di specialisti

Scrum è la soluzione migliore per i team con membri generalisti, ovvero team in cui almeno 2 persone possono svolgere gli stessi compiti. La mia principale preoccupazione è trovare buone soluzioni per adattare la mischia (cosa mantenere, cosa rimuovere, cosa migliorare) per i team composti da specialisti?

Supponiamo di avere un team di 5 sviluppatori (non reale, solo per esempio):

1. Un matematico con forti capacità in C;
2. Uno sviluppatore di DB;
3. Uno sviluppatore Web;
4. Uno sviluppatore UX / GUI;
5. Un architetto del software;

Qui, tutti sono specialisti e nessuno può sostituire qualcun altro (non mi interessa il rischio di costruire una squadra del genere, voglio concentrarmi sulla mischia). Quindi, in un contesto di mischia, ecco i miei pensieri:

1. Pianificazioni di primavera inutili: infatti, quando il matematico afferma che un compito specifico vale 2 punti, nessuno può votare contro di lui;
2. Metrica della velocità della squadra inutile: poiché tutti possono assegnare un numero qualsiasi di punti ai propri compiti, la velocità di calcolo non ha senso;
3. Sostituisci le riunioni di mischia giornaliere con riunioni di mischia settimanali (più lunghe): poiché ogni membro del team sta lavorando ai propri compiti, le riunioni di mischia giornaliere dovrebbero essere davvero importanti per mantenere uno "spirito di squadra". Tuttavia, le riunioni quotidiane della mischia dovrebbero durare circa 15 minuti. Questo chiaramente non è sufficiente per capire cosa fanno e faranno gli altri. Inoltre, il matematico risponderà il più delle volte alle stesse cose: "Sto ancora facendo % & Lo (+? $$ + &)" ... Le riunioni settimanali darebbero più tempo. Per mantenere lo stesso tempo tra gli incontri di scrum "iniziali" e gli incontri di scrum "settimanali", ogni incontro di scrum settimanale dovrebbe durare (5 giorni a settimana, con sprint di 4 settimane, con incontri di sprint della durata di 4 ore e incontri giornalieri della durata di 15 minuti): (4 * 60 + 20 * 15) / 4 =>

O la mischia è ancora utilizzabile? Forse un'altra tecnica agile dovrebbe essere usata?

Scrum non è un proiettile d'argento. Non tutti i progetti devono utilizzare Scrum per avere successo. La situazione che stai descrivendo, tuttavia, sembra un'ottima soluzione per Lean / Kanban. Potresti voler dare un'occhiata.

Kanban sostanzialmente ti chiede di fare solo alcune cose, nessuna delle quali è in contrasto con il tipo di squadra che stai descrivendo:

• Visualizza il flusso di valore, ovvero la scheda Kanban. La scheda Scrum è un'applicazione specifica di una scheda Kanban; È possibile adattarlo per consentire la specializzazione.
• Limitare il Work In Progress (WIP), in modo che la quantità di lavoro assegnata al team sia sufficiente per mantenere il flusso di lavoro costante, ovvero nessun "blocco" all'inizio del flusso (progettazione) o alla fine (distribuzione) .

Potresti voler dare un'occhiata ad alcuni riferimenti su Kanban:

• Un giorno nella terra di Kanban
• Priming Kanban (eBook gratuito)

Ti stai concentrando un po 'troppo sulla meccanica della mischia / agile senza guardare a ciò che si suppone che agile fornisca. Dici che se il ragazzo di matematica stima 2 punti nessuno può dire che ha torto. Questo non è l'obiettivo. L'obiettivo è concordare una serie di obiettivi raggiungibili per lo sprint in arrivo. Come esperto in tale compito saprà meglio quanto tempo ci vorrà.

"E se mentisse o si sbagliasse?" tu dici. Nella mia esperienza, le persone sottovalutano di più perché temono di essere fucilate per avere un'ipotesi precisa. Altri sotto stima aggiungono quindi un margine di sicurezza che bilancia tutto e la persona pigra dispari sopravvaluterà in modo da non dover correre. Dei tre il primo verrà rilevato sul tracciamento della velocità, il secondo mentre suona male, funziona e il terzo è qualcosa che devi affrontare al di fuori della mischia.

L'incontro quotidiano offre ancora vantaggi. Esistono dipendenze tra i membri del team anche se sono specialisti. Il ragazzo dell'interfaccia utente potrebbe essere in attesa sul ragazzo del server per correggere un bug di notifica. Il ragazzo del server potrebbe essere in attesa del ragazzo di matematica per capire perché un calcolo è sbagliato. Inoltre non si tratta solo di come il loro lavoro ti influenza. Se un membro del team viene costantemente ritardato a causa di "Reason X" ma non ha impiegato del tempo per mitigare le occorrenze future di "Reason X", ciò può essere sfidato.

Se hai uno specialista con qualifiche come quelle che hai descritto, la tua supposizione che ognuno stia lavorando sul proprio compito, con raramente necessità di comunicare con gli altri, è IMHO sbagliato. In effetti, per realizzare una nuova funzionalità (una "user story"), spesso dovrai farlo

• cambia il tuo database
• aggiungere o modificare la GUI o l'interfaccia Web
• combinalo con la logica aziendale corretta (dove, forse, entri il tuo "matematico")
• assicurati che tutti questi cambiamenti funzionino bene insieme

Quindi suppongo che dovranno comunicare molto di più come in un team di generalisti, in cui tutti potrebbero lavorare su una diversa storia dell'applicazione / utente, apportando da solo tutte le modifiche necessarie a tutti i livelli dell'applicazione. Pertanto, tutte le attività del team di Scrum che hai elencato sopra hanno molto senso per una squadra del genere.

Scrum è sicuramente ancora appropriato per la tua situazione, ma potrebbe esserlo anche per altri framework.

Per offrire nuove funzionalità è probabile che tu abbia bisogno di tutte o molte di queste competenze. Affinché il team possa prendere decisioni che si influenzano a vicenda e lavorano insieme dovranno comunicare. Più lungo è il tempo tra le riunioni Scrum, più lungo è un piano negativo che può deviare la squadra. Incontrandosi quotidianamente, il team può affrontare rapidamente queste situazioni e elaborare un nuovo piano.

Vorrei affrontare anche alcuni argomenti specifici che sollevi:

Squadre interfunzionali Una squadra sarebbe considerata interfunzionale se avesse tutte le competenze necessarie per raggiungere un obiettivo di sprint e / o un articolo di arretrato del prodotto. Ciò non significa che ci siano 2 persone per ogni lavoro.

Dimensionamento È importante ricordare che stiamo dimensionando un problema o un'esigenza aziendale, non una soluzione o parte di una soluzione. Ad esempio, l'integrazione dei social media / Twitter nel nostro sito di e-commerce è un problema che richiede UX, progettazione dell'interfaccia utente, programmazione, database e conoscenza dell'API di Twitter. Una squadra dovrebbe dimensionare quella come unità, dal momento che, come squadra, fornirà questa funzionalità. Questa dimensione non sarà accurata al 100%, ma scopriamo che, nel complesso, le previsioni basate sul dimensionamento relativo sono più accurate. Ciò significa che alcuni saranno alti, altri saranno bassi e nel loro insieme la previsione calcolata è più accurata della durata stimata.

Pianificazioni di primavera inutili La pianificazione di Sprint è il momento di collaborare come Scrum Team (Team di sviluppo + Product Owner + Scrum Master) per determinare cosa dovrebbe essere prodotto e elaborare un piano per iniziare. Alcuni team suddivideranno questi elementi del Product Backlog scelti in attività mentre altri troveranno la propria strada per progredire, come i test che devono superare (pensa a XP).

Questa è una collaborazione a due vie. Assegnare alla squadra un set di PBI e dire "go" è il ruolo di un dittatore. Il team sta negoziando con il Product Owner per massimizzare il tempo nello sprint.

Metrica della velocità del team inutile Con i team che dimensionano i problemi e le esigenze del business che tagliano l'architettura / sistema e l'esperienza passata che ci dice quanti di questi team sono stati consegnati in un intervallo di tempo coerente (sprint), ora possiamo fornire una previsione del team per il resto del backlog.

Ancora una volta, non ci sono due sprint uguali e più piccolo è il set di campioni di articoli di Product Backlog che usi, meno sarà ripartito l'errore nelle stime. Pensalo come il mercato azionario; è sempre salito, ma ciò non significa che non abbiamo anni passati. Nel complesso puoi guadagnare, ma in un dato mese, trimestre, anno indovinerai male.

Sostituisci le riunioni di scrum giornaliere con riunioni di scrum settimanali (più lunghe) Il Daily Scrum è lì per fornire al team un ciclo di feedback 24 ore e l'opportunità di pianificare le prossime 24 ore. Niente di più, niente di meno. Le "tre domande" hanno lo scopo di facilitare tale sforzo.

Se non ricevi feedback per 5 giorni, credo che i tuoi compiti non siano abbastanza precisi. Questa è semplicemente la mia opinione, ma si basa sulla mia esperienza come allenatore e membro del team. I team dovrebbero parlare, pianificare e integrare i propri sforzi molto più spesso.

Conclusione Scrum ha lo scopo di facilitare l'apprendimento e l'equilibrio tra l'apprendimento e la consegna (dove avviene l'apprendimento reale). Sperimenta i tuoi processi e strumenti nel tempo e usa Scrum per controllare l'impatto. Prova a passare da Scrum giornalieri a settimanali e vedi se aiuta o danneggia la capacità dei team di offrire la giusta funzionalità. Potrebbe funzionare per te.