ScrumBut

ScrumBut: Scrum e la resa condizionata?Edoardo Schepis

Dopo aver visto all’opera Scrum per alcuni anni, ho potuto verificare che è un ottimo punto di riferimento nell’approccio agile alla gestione dello sviluppo del software.

Ma allo stesso tempo mi sono convinto che Scrum va pensato come un punto di arrivo nel percorso di cambiamento che si intraprende all’interno di un’azienda IT.

Scrum ha un notevole impatto nei diversi strati della struttura organizzativa e quello che accade tipicamente è che venga applicato accettando molti compromessi.

Non è necessariamente un male, ma deve essere ben chiaro che si tratta di un percorso e che prima o poi questi compromessi devono lasciare il posto alla corretta implementazione dello Scrum.

Lo ScrumBut è la realtà che ti sta intorno ogni giorno all’interno di un’organizzazione orientata all’applicazione dello Scrum. E’ assolutamente normale, ma è anche la sfida che hai di fronte: <We use Scrum, but> <we have these unique circumstances> <so we have had to modify Scrum so it works here>

Ognuno di noi crede di essere unico e lo stesso vale per le aziende, che spesso pretendono di avere già il miglior processo possibile e che Scrum quindi debba scendere a patti.

La presentazione mostra gli ScrumBut’s più comuni, quelli con cui personalmente mi scontro ogni giorno e quali azioni possiamo intraprendere prima di arrenderci all’idea che Scrum non fa per noi.

Con questa sessione intendo inoltre ribadire che Scrum non è semplicemente una serie di pratiche da seguire: è fin troppo facile organizzarsi in teams e fare i meeting previsti dallo Scrum. La vera sfida è il “continuous improvement” che sta alla base della trasformazione di un’azienda in tutte le sue parti e che permette di raggiungere il vero “Scrum as a mirror”.