Mischia per squadre di specialisti

Scrum non è un proiettile d'argento. Non tutti i progetti devono utilizzare Scrum per avere successo. La situazione che stai descrivendo, tuttavia, suona molto bene per Lean / Kanban. Potresti voler controllare.

In pratica, Kanban 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 Scrum board è un'applicazione specifica di una scheda Kanban; È possibile adattarlo per consentire la specializzazione.
• Limita 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'avvio del flusso (design) o alla fine (distribuzione).

Potresti voler controllare alcuni riferimenti su Kanban:

• Un giorno in Kanban Land
• Priming Kanban (Ebook gratuito)

Ti stai concentrando un po 'troppo sui meccanismi della mischia / agile senza guardare a quale cosa agile dovrebbe arrivare. Tu dici che se il ragazzo di matematica stima 2 punti nessuno può dire che ha torto. Questo non è l'obiettivo. L'obiettivo è quello di concordare una serie di obiettivi realizzabili per il prossimo sprint. Come esperto di questo incarico, saprà meglio quanto tempo ci vorrà.

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

L'incontro quotidiano offre ancora benefici. Esistono dipendenze tra i membri del team, anche se sono tutti specialisti. Il ragazzo UI potrebbe essere in attesa sul ragazzo del server per risolvere un bug di notifica. Il ragazzo del server potrebbe essere in attesa sul ragazzo di matematica per capire perché un calcolo è sbagliato. Inoltre, non si tratta solo di come il loro lavoro influisce su di te. Se un membro del team viene costantemente ritardato a causa di "Reason X" ma non ha avuto il tempo di attenuare le occorrenze future di "Motivo X", ciò può essere contestato.

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

• cambia il tuo database
• aggiungi o modifica la GUI o l'interfaccia Web
• combina questo con la logica aziendale corretta (dove, forse, il tuo "matematico" entra)
• assicurati che tutte queste modifiche funzionino bene insieme

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

Scrum è certamente ancora appropriato per la tua situazione, ma così potrebbero altri framework.

Per offrire nuove funzionalità è probabile che tu abbia bisogno di tutte o molte di queste abilità. Affinché il team possa prendere decisioni che si influenzano a vicenda e collaborino, è necessario che comunichino. Più lungo è il tempo tra le riunioni di Scrum, più a lungo un piano negativo può allontanare la squadra. Incontrandosi ogni giorno, il team può affrontare rapidamente queste situazioni e trovare un nuovo piano.

Vorrei affrontare anche alcuni argomenti specifici che porti in primo piano:

Squadre operative trasversali Un team sarebbe considerato interfunzionale se ha tutte le competenze necessarie per fornire un obiettivo di sprint e / o un articolo di backlog del prodotto. Questo non significa che ci sono 2 persone per ogni lavoro.

Dimensionamento È importante ricordare che stiamo dimensionando un problema o un bisogno aziendale, non una soluzione o parte di una soluzione. Ad esempio, Integrare social media / Twitter nel nostro sito di e-commerce è un problema che richiede UX, UI Design, programmazione, database e conoscenza dell'API di Twitter. Una squadra dovrebbe essere dimensionata come un'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, alcuni saranno bassi e nel complesso la previsione calcolata è più accurata della durata stimata.

Pianificazioni di primavera inutili La pianificazione di Sprint è un momento in cui collaborare come Scrum Team (Team di sviluppo + Product Owner + Scrum Master) per determinare cosa dovrebbe essere prodotto e creare un piano su come iniziare. Alcuni team spezzeranno questi Articoli del Product Backlog scelti in attività mentre altri troveranno il proprio modo di progredire, come test che devono superare (si pensi a XP).

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

Metrica velocità squadra inutile Con i team che misurano i problemi e le esigenze del business che tagliano l'architettura / sistema e l'esperienza passata ci dicono quanti di questi sono stati consegnati in un time box consistente (sprint), possiamo ora fornire una previsione per il resto del team l'arretrato.

Ancora una volta, non ci saranno due sprint uguali e tanto più piccolo sarà il set di campioni degli articoli del Product Backlog, tanto minore sarà l'errore nelle stime. Pensalo come il mercato azionario; è sempre salito, ma questo non significa che non abbiamo giù gli anni. All'insieme puoi guadagnare, ma in un dato mese, trimestre, anno indovina male.

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

Se non hai feedback per 5 giorni, ritengo che i tuoi compiti non siano abbastanza dettagliati. Questa è semplicemente la mia opinione, ma si basa sulla mia esperienza come allenatore e membro del team. Le squadre dovrebbero parlare, pianificare e integrare i loro sforzi molto spesso.

Conclusione Scrum ha lo scopo di facilitare l'apprendimento e il bilanciamento di tale apprendimento con la consegna (dove avviene l'apprendimento reale). Sperimenta i tuoi processi e strumenti nel tempo e usa Scrum per ispezionare l'impatto. Prova a passare da Scrum giornalieri a settimanali per vedere se aiuta o danneggia la capacità del team di fornire le giuste funzionalità. Potrebbe funzionare per te.