Quali sono i vantaggi di Scrum rispetto a "affrontare le cose come vengono"?

Se le tue squadre stanno producendo un codice di qualità appropriata ad un tasso accettabile dalla direzione, non si ottiene nulla usando la mischia. In un certo senso, la mischia è una metodologia per guidare una squadra a raggiungere questo stato esatto.

Tuttavia, se il tuo codice è di bassa qualità, o se il codice che sviluppi non soddisfa sempre le esigenze dell'utente finale, o se la gestione non è soddisfatta della mancanza di trasparenza nel processo di sviluppo e trova pianificazione nello sviluppo orari difficili, mischia può aiutare.

Scrum intende abbracciare il cambiamento aiutando i team a concentrarsi sugli sforzi che forniscono valore reale al cliente finale in modo prevedibile. Introducendo un breve ciclo di feedback, i team possono essere sicuri di fornire esattamente ciò di cui il cliente ha bisogno. Inoltre, la gestione ha più visibilità su ciò che il team sta facendo ora, su cosa ha intenzione di fare nelle prossime settimane e quando le funzionalità saranno pronte.

E infine, scrum fornisce un quadro per i team per migliorare la scrittura del software attraverso il miglioramento continuo.

Il risultato finale di un team che utilizza scrum è un team in grado di fornire in modo prevedibile un codice di alta qualità che soddisfi le esigenze dell'utente. Se la tua squadra lo sta già facendo, non ha senso cambiare ciò che stai facendo.

Una sorta di vantaggio controintuitivo per la mischia è che ti costringe a dare la priorità al tuo arretrato, essere veramente consapevole della tua capacità effettiva e limitare il tuo lavoro in corso. Quello che abbiamo scoperto quando abbiamo iniziato a fare scrum è stato che pensavamo di essere molto reattivi affrontando le cose mentre venivano, ma in realtà ogni nuova cosa che prendevamo si diffondeva sempre più sottile e ritardava tutto.

In altre parole, invece di finire i 3 compiti con la priorità più alta in 2 settimane, quindi i prossimi 3 compiti con la priorità più alta nelle successive 2 settimane, saremmo d'accordo con tutti e 6 contemporaneamente, ma ci vorrebbe un mese per completare nessuno di loro, perché eravamo più sottili. Concentrare le risorse su un numero inferiore di attività offre un valore più rapido.

Inoltre, non dovresti provare a fare la mischia esattamente come lo stampo del cutter. Puoi fare iterazioni di 1 settimana. È possibile delegare la maggior parte della pianificazione e della stima a una sola persona. Crea i tuoi criteri per quando una storia è pronta per iniziare. Tieni regolarmente le retrospettive e regolale in base alle tue esigenze. Individui e interazioni su processi e strumenti.

Hai alcune buone risposte qui con cui non ho alcuna vera differenza.

Ho inserito la chiave in qualcosa che hai detto sulla tua situazione attuale "agile già al punto di causare il caos". Agile NON è il caos. Ho incontrato molte persone che affermano di essere agili perché sono semplicemente super flessibili e non hanno processi pesanti e pensano di essere efficienti ...

Ho lavorato in aziende imprenditoriali che non avevano un quadro formale e pensavano che fossero agili, ma hai ragione, a volte sono solo caotiche. La risposta di Karl Bielefeldt è assolutamente corretta. Ci sono numerosi vantaggi nell'adottare una struttura agile e le discipline di miglioramento continuo ad essa correlate. Scrum è solo un metodo.

Questo approccio può essere ottimo nelle prime fasi di una fase iniziale. Ma la mancanza di disciplina può impedire la crescita dell'azienda nel tempo.

A proposito, Kanban NON è meno disciplinato di Scrum, anzi, è più vero, se fatto correttamente. Potresti aver bisogno di un coach agile per esaminare i tuoi processi e il tuo business e aiutarti a personalizzare qualcosa che lo mantenga leggero ma ti dia alcuni dei benefici. Forse Scrum sarebbe giusto per te, forse è kanban, o XP, o una miscela. Nessuno può dirti senza prendere un po 'di tempo per conoscere la tua azienda, il tuo prodotto, la tua cultura di sviluppo, ecc.