In questo episodio esploriamo i sette ostacoli più comuni che limitano l’efficacia di Scrum nelle organizzazioni. Questi impedimenti, eredità di una cultura aziendale radicata nell’era industriale, possono significativamente ridurre i benefici che Scrum può portare all’azienda. Scopriremo come identificarli e, soprattutto, come superarli per una vera trasformazione agile.
“Gli ostacoli a Scrum sono spesso radicati nella cultura aziendale tradizionale. La chiave per superarli sta nella consapevolezza e nella volontà di evolversi verso un’organizzazione più agile. Il ruolo dello Scrum Master professionale è fondamentale in questo processo di trasformazione.”
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdere il prossimo episodio del podcast Scrum Italia, parleremo di coaching.
Questo articolo è basato sull’episodio 38 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio speciale celebriamo il 28° compleanno di Scrum, nato il 19 ottobre 1995. Analizziamo il documento originale presentato da Ken Schwaber che ha introdotto Scrum al mondo, esplorando le origini del framework e come i suoi principi fondamentali sono rimasti rilevanti fino ad oggi. Scopriremo come Scrum è nato come risposta alla complessità dello sviluppo software e come ha influenzato l’Agile Manifesto.
🎧 Ascolta l’Episodio
🎯 I Punti Chiave del Documento Originale
La Nascita di un Framework Rivoluzionario
Prima presentazione di Scrum da parte di Ken Schwaber il 19 ottobre 1995
Riconoscimento che lo sviluppo software è un processo imprevedibile e complesso
Critica agli approcci lineari e predittivi dello sviluppo software
Le Metodologie dell’Epoca
Waterfall: approccio lineare e rigido
Metodologia a Spirale: miglioramento iterativo ma ancora troppo strutturato
Approccio Iterativo: più flessibile ma ancora basato su processi definiti
I Principi Fondamentali di Scrum
Accettazione dell’imprevedibilità nel processo di sviluppo
Flessibilità come risposta alla complessità
Importanza del controllo empirico
Focus sulla creazione di valore attraverso l’utilità del sistema
💡 I Benefici Identificati
Vantaggi dello Scrum Originale
Flessibilità nell’adattarsi ai cambiamenti
Libertà creativa per gli sviluppatori
Controllo attraverso meccanismi empirici
Collaborazione migliorata tra tutti gli stakeholder
“Questo documento storico mostra come i principi fondamentali di Scrum fossero già chiari 28 anni fa. La visione di Ken Schwaber di un framework che abbraccia la complessità invece di cercare di controllarla si è dimostrata vincente nel tempo. Oggi questi principi sono più rilevanti che mai nell’affrontare le sfide dello sviluppo software moderno.”
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdere il prossimo episodio dove esploreremo 7 ostacoli a Scrum nel mondo moderno.
Questo articolo è basato sull’episodio 37 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio rispondiamo a due domande fondamentali dei nostri ascoltatori: la prima riguarda i possibili conflitti di interesse nei doppi ruoli in Scrum (Product Owner + Developer, Product Owner + Scrum Master), mentre la seconda esplora come attivare l’innovazione tecnologica in azienda attraverso il framework Scrum.
🎧 Ascolta l’Episodio
🎯 Prima Domanda: I Doppi Ruoli in Scrum
Principi Fondamentali
Le accountability in Scrum possono teoricamente essere ricoperte dalla stessa persona
Un individuo può avere le competenze per svolgere più ruoli
L’approccio deve essere empirico e adattativo
Considerazioni Chiave
Il team deve monitorare attentamente gli effetti del doppio ruolo
Occorre verificare l’impatto su Product Goal e Sprint Goal
È necessario identificare rapidamente eventuali conflitti di interesse
Segnali di Attenzione
Difficoltà nel raggiungimento degli Sprint Goal
Deterioramento della qualità del prodotto
Mancanza di trasparenza
Conflitti di interesse evidenti
🔄 Seconda Domanda: L’Innovazione Tecnologica
Ruolo del Product Owner
Permettere la sperimentazione
Non imporre soluzioni predefinite
Promuovere l’openness e il coraggio di sperimentare
Gestire il rischio limitandolo a uno sprint
Responsabilità dei Developers
Dedicare tempo al brainstorming
Studiare nuove tecnologie
Partecipare a hackathon e momenti di sperimentazione
Proporre soluzioni innovative
Ruolo dello Scrum Master
Assicurare la corretta comprensione e applicazione di Scrum
Facilitare un ambiente che promuove l’innovazione
Supportare il team nell’approccio empirico
💡 Best Practices per l’Innovazione
Definire Sprint Goal ambiziosi
Accettare il rischio di fallimento come opportunità di apprendimento
Mantenere la trasparenza sui contratti e vincoli aziendali
Promuovere una cultura dell’innovazione sostenibile
“L’innovazione in Scrum non è solo una questione di tecnologia, ma di approccio mentale. È fondamentale creare un ambiente dove il team si senta sicuro di sperimentare e dove il fallimento sia visto come un’opportunità di apprendimento. La chiave sta nel bilanciare correttamente le accountability e nel mantenere sempre il focus sulla creazione di valore per gli utenti.”
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perderti il prossimo episodio del podcast Scrum Italia dove festeggeremo i 28 anni di Scrum.
Questo articolo è basato sull’episodio 36 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio affrontiamo una domanda frequente nel mondo Scrum: è possibile in una piccola realtà ricoprire contemporaneamente i ruoli di Developer e Scrum Master? Esploriamo vantaggi, sfide e considerazioni pratiche per gestire questa doppia accountability in modo efficace.
🎧 Ascolta l’Episodio
🎯 La Domanda Principale
La domanda centrale di questo episodio si articola in due parti:
È possibile in una piccola realtà fare da Developer e Scrum Master allo stesso tempo?
Esistono conflitti insormontabili tra queste due responsabilità?
🔄 Punti Chiave della Risposta
Possibilità e Flessibilità in Scrum
Secondo la Scrum Guide, non esistono conflitti insormontabili
Le responsabilità in Scrum non sono ruoli rigidi, Developer e Scrum Master possono essere la stessa persona
Ken Schwaber stesso sostiene la possibilità di iniziare con responsabilità sovrapposte
Sfide e Considerazioni
Potenziali conflitti di interesse tra le due accountability di Developer e Scrum Master
Gestione del tempo tra sviluppo e facilitazione
Difficoltà nell’osservazione obiettiva degli eventi Scrum
Impatto sulla qualità della retrospettiva
Evoluzione Naturale
Importanza dell’approccio empirico
Necessità di riconoscere i limiti della doppia accountability di Developer e Scrum Master
Evoluzione verso ruoli dedicati con la crescita della complessità del prodotto
💡 Best Practices
Mantenere la trasparenza sui conflitti di interesse
Valutare regolarmente l’impatto sulla qualità del lavoro
Considerare la separazione dei ruoli quando necessario
“La chiave non è tanto se sia possibile o meno ricoprire entrambe le responsabilità, ma piuttosto comprendere quando questa sovrapposizione inizia a limitare l’efficacia del team e del framework Scrum. L’approccio empirico ci aiuta a riconoscere questi momenti e ad evolvere di conseguenza.”
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdere il prossimo episodio del podcast, ci sarà un’intervista in cui condivideremo un’esperienza reale di Developer e Scrum Master!
Questo articolo è basato sull’episodio 33 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
Superare il concetto di ritardo con Scrum è possibile! In un mondo in cui le scadenze sono spesso un pilastro cruciale, l’approccio di Scrum può inizialmente suscitare dubbi e scetticismo. La flessibilità apparente delle funzionalità da sviluppare può sembrare controintuitiva, ma è proprio questa caratteristica che rende Scrum un approccio ideale per affrontare problemi complessi in modo empirico. Questo articolo esplora come il concetto di “ritardo” si trasforma in un’opportunità di crescita, quando Scrum è applicato con competenza. Clicca qui, o nell’immagine qui sotto, per ascoltare l’episodio del Podcast Scrum 🇮🇹.
Clicca l’immagine per ascoltare il podcast
Affrontare la complessità empiricamente
L’idea di essere in ritardo presuppone una conoscenza completa e certa delle variabili coinvolte in quello che si sta facendo.
In tutta onestà, nel tuo progetto, puoi immaginare una cosa del genere? Nel contesto aziendale, le variabili sono spesso innumerevoli e i percorsi da seguire sono, molto spesso, incerti. Bisogna farsene una ragione.
L’approccio Scrum sfida questa prospettiva. Accetta l’incertezza come un dato di fatto e si basa su iterazioni brevi e feedback costante per adattarsi alle sfide emergenti. Questo significa che le “scadenze rigide di un’insieme di funzionalità” vengono trasformate in obiettivi, consentendo al team (ed al cliente!) di adattarsi ai cambiamenti e di affrontare la complessità con una mentalità aperta. Le funzionalità diventano variabili, in quantità e granularità (nel senso finezza di sviluppo).
Il Product Owner riveste un ruolo fondamentale nell’orientare il team verso il successo. Invece di considerare le scadenze come funzionalità statiche, il focus si sposta sugli obiettivi del prodotto. Il Product Owner, grazie alla sua conoscenza del contesto business e dei clienti, è capace di fissare Product Goals, stabilendo un legame chiaro tra le attività del team e l’obiettivo attraverso il contenuto del Product Backlog.
Superare il concetto di ritardo con Scrum, significa avere un Product Owner che sia libero di fissare Product Goals chiari e misurabili.
L’Empirismo in azione: Sprint dopo Sprint
Le Basi di Scrum – Cos’è Scrum?
Un aspetto distintivo di Scrum è lo Sprint, in cui il team affronta una parte specifica del lavoro in un periodo di tempo definito. Ogni Sprint è un passo in avanti verso un Product Goal e realizza le funzionalità del Product Backlog coerenti con questo obiettivo.
L’empirismo è alla base di ogni Sprint. Le funzionalità vengono sviluppate in modo iterativo, consentendo al team (e agli Stakeholders) di apprendere e adattarsi man mano che la conoscenza e l’esperienza cresce. Il coinvolgimento del cliente alla fine di ogni Sprint garantisce un feedback tempestivo, orientando ulteriormente il percorso del progetto.
Costruire Fiducia e Valore
L’approccio Scrum, se implementato con maestria, produce risultati che spazzano via l’angoscia del ritardo. Oltre a raggiungere i tradizionali obiettivi di progetto, il processo crea elementi di valore che vanno oltre il mero rispetto delle scadenze:
1. Fiducia: Ogni Sprint dimostra il progresso costante del team, costruendo fiducia sia internamente che verso i clienti o gli stakeholder.
2. Prodotto Funzionante: ogni Sprint porta a un incremento di prodotto funzionante, anche se non corrisponde esattamente alla visione iniziale. Questo approccio guidato dal feedback produce un prodotto di valore reale.
3. Agilità per il futuro: la flessibilità di Scrum consente al team di adattarsi rapidamente ai cambiamenti. Man mano che si apprende e si cresce, il team può perseguire nuove direzioni o eliminare funzionalità superflue.
Superare il concetto di ritardo con Scrum: affrontare le Sfide Comuni
Sebbene Scrum offra un approccio valido, le sfide possono emergere. La mancanza di risorse, la mancanza di interazione con il cliente e altri ostacoli possono minare l’efficacia dell’approccio. In queste situazioni, la collaborazione diventa fondamentale. I membri del team, gli stakeholder e l’azienda devono lavorare insieme per comprendere le priorità reali, mantenendo la qualità e il benessere del team al centro dell’attenzione.
In sintesi, Scrum si dimostra un’arma potente per affrontare il concetto tradizionale di “ritardo”. Il suo approccio empirico, basato su feedback costante, flessibilità e adattabilità, trasforma le sfide in opportunità di crescita e successo. Se applicato con dedizione e competenza, Scrum guida il team verso la fiducia, il valore e una gestione più efficace dei progetti complessi.
Con scrum.org, la nostra missione consiste ad aiutarvi a risolvere problemi complessi, qui sotto trovate alcuni dei corsi che potranno aiutarvi a capire meglio come superare il concetto di ritardo con Scrum!
In questo episodio esploriamo come superare il concetto di ritardo con scrum per trasformarlo in un’opportunità di crescita quando Scrum viene applicato con competenza. Scopriremo come l’approccio empirico di Scrum permette di superare la visione tradizionale delle scadenze rigide, favorendo una gestione più efficace dei prodotti complessi.
🎧 Ascolta l’Episodio
🎯 Concetti Chiave
Il superamento del concetto di ritardo in Scrum, come evidenziato nell’articolo del blog, si basa su diversi elementi fondamentali:
Strategie per la costruzione della fiducia nel team
🎓 Note del Trainer
“Il vero vantaggio competitivo delle aziende oggi e dei team in generale sarà la capacità di superare le difficoltà attraverso una collaborazione efficace. Superare il concetto di ritardo con Scrum significa una maggiore maturità agile del team.”
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Nel prossimo episodio del podcast Scrum Italia vedremo come prendere decisioni efficaci all’interno dello Scrum Team.
Questo articolo è basato sull’episodio 30 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio esploriamo una delle sfide più comuni nelle organizzazioni che adottano Scrum: cosa succede quando il Product Owner non ha vera ownership sul prodotto? Insieme al nostro ospite Michael Forni, Agile Coach con esperienza nel settore finanziario, analizziamo le cause, le conseguenze e le possibili soluzioni a questa situazione.
Pattern di comunicazione efficace in ambienti aziendali
🎓 Note dell’Ospite
“Il successo non è terminare il progetto. Il successo è dare valore al cliente finale in modo incrementale. Il Product Owner deve avere la libertà e il supporto necessari per prendere decisioni basate su evidenze, non su opinioni o pressioni organizzative.”
Michael Forni
🔜 Prossimo Episodio
Non perdere il prossimo episodio del podcast Scrum Italia, dove parleremo di come superare il concetto di ritardo con Scrum.
Questo articolo è basato sull’episodio 29 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio esploriamo il fenomeno della “reazione autoimmune aziendale” verso Scrum, analizzando come le organizzazioni tradizionali spesso reagiscono all’introduzione di Scrum come se fosse una minaccia, invece di riconoscerlo come un elemento benefico per lo sviluppo di prodotti complessi.
🎧 Ascolta l’Episodio
🎯 Cos’è la Reazione Autoimmune Aziendale?
La reazione autoimmune aziendale si verifica quando il “sistema immunitario aziendale” – costituito dalla cultura, dai sistemi e dall’organizzazione tradizionale – percepisce Scrum come una minaccia e lo “attacca”, cercando di neutralizzarlo o modificarlo profondamente.
🔄 Caratteristiche Principali
Sistema Immunitario Aziendale
Cultura orientata alla produzione di massa
Organizzazione ottimizzata per l’efficienza
Comportamenti di command & control
Sanzione dell’errore
Responsabilità frammentate
Silos organizzativi
Sintomi della Reazione Autoimmune
Adattamento forzato di Scrum ai processi aziendali
Resistenza all’autogestione dei team
Imposizione di pressione e scadenze rigide
Eccesso di reporting e controllo
Modifiche strutturali a Scrum (es. doppio Product Owner)
💡 Come Curare la Reazione Autoimmune
Approcci Terapeutici
Stabilire la psychological safety attraverso il team manifesto
“Il problema nelle aziende non è Scrum o qualsiasi altro approccio di lavoro. Il problema è la reazione aziendale alla novità, perché rappresenta un cambiamento che viene percepito come un pericolo. Una malattia autoimmune si può curare, ma richiede tempo, pazienza e il giusto approccio terapeutico.”
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdete il prossimo episodio del podcast Scrum Italia, parleremo di Product Ownership!
Questo articolo è basato sull’episodio 28 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
Scrum e la reazione autoimmune aziendale è una riflessione sulla mia esperienza dell’applicazione di Scrum professionale in azienda. Rivela i meccanismi socio-aziendali, ai quali ho assistito, che impediscono di trarre massimo beneficio dallo sviluppo empirico di un prodotto.
Clicca l’immagine per ascoltare il podcast
Ovviamente non sono un esperto in campo medico, mi scuso in anticipo se certi paralleli o nozioni sono incorrette da questo punto di vista.
Il parallelo fra Scrum Professionale (considerata come “sostanza sana” quando si pensa allo sviluppo di prodotti complessi) e gli anticorpi aziendali (che dovrebbero riconoscere Scrum come “amico”, ma non lo fanno, scatenando una reazione anomala di distruzione autoimmune) mi è venuto da tempo e penso possa essere una buona metafora per rappresentare le sfide che ci aspettano in azienda.
Qual’è un ambiente di lavoro considerato come “sano” in un contesto di complessità?
Un ambiente di lavoro “sano” consiste in pochi principi, ma importanti:
Anticorpo
Servant Leadership: dei dirigenti e manager che sono al servizio delle persone che lavorano, per aiutarle ad abbattere gli ostacoli che impediscono di creare prodotti complessi (burocrazia, procedure, silos, gerarchie, etc.)
Psychological Safety: trovarsi in un ambiente di lavoro che permette di imparare velocemente, eventualmente celebrando gli errori che fanno parte del processo di apprendimento
Responsabilità chiare: un capitano, il Product Owner, delle competenze per dirigere la nave e esplorare soluzioni (i Developers), una persona che conosce bene le regole del gioco (lo Scrum Master)
Focus alla risoluzione di problemi o opportunità: capire bene per chi si lavora e come si può soddisfare
Ownership condivisa: grazie ad obiettivi chiari
Video un pò datato, ma ancora valido. Scusate il suono orribile.
Il sistema immunitario aziendale
Un’azienda tradizionale è stata concepita secondo un modello di produzione industriale, trarre massimo profitto dalla produzione di massa. È il sistema immunitario aziendale. Di conseguenza, è normale osservare:
Command & Control: il management dice ai lavoratori cosa (e, a volte, come) devono fare il lavoro
Sanzione dell’errore: se non si mantiene la parola data, o qualcosa va storto, saltano teste
Responsabilità sparsa: su diverse persone, con due risultati possibili (decisioni lente, oppure immobilismo)
Carriera: le persone gerarchicamente di alto livello hanno uno stipendio migliore, concorrenza interna, politica
Focus su funzionalità: senza pensare o chiedere agli utenti il loro feedback
Silos: ossia funzioni ottimizzate per produrre un certo tipo di output come, per esempio, marketing, informatica, sales, etc.
Burocrazia: processi e procedure per assicurarsi che ogni tipo di input crea un preciso output in qualsiasi situazione
Scrum e la reazione autoimmune aziendale
Quando Scrum Professionale arriva in azienda, si osserva la reazione autoimmune aziendale, che lo riconosce come una minaccia e lo attacca, in maniera più o meno evidente.
Fabio Panzavolta
Nella mia esperienza ho potuto osservare le reazioni autoimmuni seguenti, in ordine casuale e non esaustivo:
L’adattamento di Scrum all’azienda: ossia modificarlo profondamente per farlo entrare nei processi aziendali, mantenere le gerarchie ed i controlli esistenti. Qualche esempio:
Nominiamo due Product Owner, uno business e uno tecnico. Invece di una sola persona, con la conseguenza di creare disordine e difficoltà a prendere decisioni.
Selezioniamo gli eventi Scrum che ci fanno più comodo. Limitando la capacità a lavorare in modo empirico e, di fatto, mantenendo il lavoro a cascata (waterfall)
Imponiamo una quantità di lavoro ai Developers, gli obiettivi sono inutili. Annullando l’autogestione, l’ownership e la responsabilità
Facciamo a meno dello Scrum Master, non serve a niente. Alimentando il massacro di Scrum, in quanto non c’è più nessuno che può aiutare a combattere gli anticorpi.
L’autogestione da noi non funziona: continuiamo a scrivere specifiche, assicurandoci che siano seguite alla lettera e nei tempi stabiliti. E poi serve comunque qualcuno che gestisca il team, altrimenti il lavoro non va avanti
La pressione è necessaria per far lavorare le persone: quindi imponiamo date di fine all’inizio del progetto, su scope fisso e chiediamo il commitment a tutto il team. Sacrificando la qualità e l’innovazione
Il reporting è fondamentale: dobbiamo sapere come vanno le cose per poter prendere decisioni. Il team non è in grado di farlo. Controllare le persone è più facile rispetto al controllo degli obiettivi e delle performance del prodotto.
Ci sono tante altre reazioni autoimmuni, quali osservi nel tuo lavoro? Scrivilo nei commenti!
Quali sono le cure alla reazione autoimmune?
Se hai riconosciuto almeno una reazione autoimmune fra quelle elencate, non tutto è perduto, esistono delle cure 😊. Più o meno invasive.
L’ideale consiste a cominciare a lavorare con Scrum per scatenare le reazioni autoimmuni, osservarle e renderle trasparenti. In poche parole bisogna avere il coraggio di non seguire la corrente.
Fabio Panzavolta
Un piccolo team, di qualche persona, che lavora secondo i principi di Scrum, rivelerà molte cose che non funzionano in azienda.
Una volta rivelati i disfunzionamenti aziendali, l’obiettivo è quello di curare la reazione autoimmune, non cambiare Scrum.
Bisogna fare tutto ciò che è necessario per far riconoscere Scrum come “sostanza sana” e far progredire la sua comprensione/applicazione, per l’interesse dell’azienda e degli utilizzatori dei prodotti.
La brutta notizia è che la soluzione miracolo non esiste, bisogna sperimentare approcci diversi, a seconda del contesto, per capire cosa funziona meglio.
La buona notizia è che, dal momento che si vedono progressi nel sistema azienda, anche minimi, allora vuol dire che le cose evolvono. Ci vuole pazienza e perseveranza ed anche un buon grado di accettazione che la reazione autoimmune potrebbe vincere.
Vediamo qualche cura possibile da sperimentare.
Ristabilire la Psychological Safety – Team Manifesto
Per prima cosa lavorare nel contesto dello Scrum Team, che deve assolutamente capire che certi comportamenti e decisioni sono necessari quando si crea un prodotto complesso. Quindi la nozione di quello che è “giusto o sbagliato” cambia. Questa può essere una vera sfida per quei team composti in parte da dipendenti e in parte da contractors.
Questo è un lavoro che si fa mettendo al centro i Valori Scrum (coraggio, rispetto, apertura, focus, commitment), assolutamente fondamentali per comportarsi in modo consono ad un contesto complesso.
Scrum e la reazione autoimmune aziendale – Clicca l’immagine per accedere al contenuto
Il Team Manifesto è necessario per rendere trasparente la nozione di coraggio (ad esempio) per ogni membro del team, riconoscere e mettersi d’accordo su cosa vuol dire avere coraggio per il team ed impegnarsi a comportarsi di conseguenza.
Questo aiuta a capire che il comportamento del team, di fronte a certe situazioni, sarà uniforme e contribuisce ad aumentare la sicurezza psicologica.
Ovviamente il Team Manifesto è qualcosa che evolverà nel tempo, un ottimo strumento per accogliere un nuovo arrivato, per esempio.
Comprensione di Scrum
Comprendere perché Scrum è uno strumento adatto alla risoluzione di problemi complessi è assolutamente necessario.
Applicare Scrum secondo le regole permetterà di rivelare ciò che disfunziona in azienda (attivare gli anticorpi aziendali per riconoscerli) e che è necessario correggere, col tempo, per rimanere o diventare competitivi in un contesto di complessità.
Un’esempio di come ho aiutato un’azienda ad adottare Scrum si trova qui a destra (in inglese).
Come riconoscere la guarigione dalla reazione autoimmune
La guarigione prenderà tempo, a seconda della cultura aziendale. Aziende che esistono da decine d’anni, con strutture gerarchiche piramidali forti avranno più difficoltà ad evolvere. A volte evolvono fino ad un certo punto, per poi tornare improvvisamente ai vecchi metodi di lavoro. Altre volte evolvono solo in certi dipartimenti, non a livello globale.
I segnali che considero come positivi e che permettono di riconoscere un certo successo sono:
Meno burocrazia: si semplifica il lavoro, concentrandosi e mantenendo unicamente i processi utili alla creazione di valore
Personale più felice: meno assenze per malattia, ambiente più sereno e quindi più produttivo
Clienti più felici: i clienti acquistano fiducia, si sentono ascoltati e credono in noi per risolvere i loro problemi
Qualità del prodotto in crescita: meno interruzioni dalla produzione, quindi più focus per creare nuove cose
Rapidità nell’arrivare sul mercato: capacità del team a mettere in produzione più rapidamente e regolarmente
Capacità di reazione alle difficoltà: il team è capace di trovare soluzioni a qualsiasi cambiamento, da solo, dimostrando la capacità di adattamento richiesta in un contesto di complessità
Quali altri segnali positivi hai notato nella tua azienda? Condividili nei commenti!
Conclusioni
Il problema nelle aziende non è Scrum, o qualsiasi altro approccio di lavoro, il problema è la reazione aziendale alla novità. Perché rappresenta un pericolo, scatenando la reazione autoimmune.
Una malattia autoimmune si può curare, a volte ci si deve convivere, altre volte ci vogliono interventi chirurgici pesanti. Mi scuso se qualche lettore è passato attraverso queste prove difficili, è una metafora forse fuori luogo, ma che trovo talmente azzeccata in un contesto di adozione di Scrum in azienda.
Il problema in azienda è la mancanza di leadership, di visione. Le persone che sono semplici esecutori di “ordini”, la mancanza di fiducia (orizzontale e verticale), l’incapacità a dire di no, una strategia mirata solo alla creazione di fatturato o soddisfazione degli azionari.
Questi sono i problemi, non Scrum o qualsiasi altro approccio di lavoro.
La leadership mediocre, porta a risultati mediocri e a reazioni autoimmuni che alimentano la mediocrità.
In conclusione mi piace ricordare il perché si ha bisogno di Scrum. Il futuro (ormai il presente) è costituito da prodotti customizzabili, riutilizzabili, ecologici, utili, specifici.
L’utente è ormai il prodotto, bisogna capirlo per soddisfarlo, non creare qualcosa e poi pensare che una campagna marketing o un buon venditore riuscirà a venderlo.
Gli anticorpi aziendali fanno di tutto per continuare a creare prodotti che non hanno qualità, arrivano tardi sul mercato, non corrispondono a qualcosa che gli utenti desiderano, creano un sacco di spreco, di infelicità.
La nostra missione, da Collective Genius e Scrum.org, è quella di aiutarvi a far riconoscere Scrum come elemento “sano” del vostro sistema azienda e farvi diventare il leader di mercato del vostro mestiere!
ℹ️ Implementazione di Scrum in piccola azienda 📅 Data: 27/06/2023 ⏱️ Durata: 39 minuti
📑 Sommario
In questo episodio, intervistiamo Stefano Berretta, uno sviluppatore con oltre 20 anni di esperienza che ha guidato l’adozione di Scrum in una piccola software house. Scopriamo come il framework Scrum può essere implementato in realtà più piccole, i benefici ottenuti e le sfide ancora da affrontare.
🎧 Ascolta l’Episodio
🎯 Punti Chiave dell’Intervista
Background e Contesto
20+ anni di esperienza nello sviluppo software
Lavoro in una software house di 10-15 dipendenti
Sviluppo di soluzioni per aziende manifatturiere
Motivazioni per l’Adozione di Scrum
Progetti problematici e stress del team
Necessità di migliorare la qualità del software
Ricerca di un approccio più umano e collaborativo
🔄 Principali Cambiamenti Implementati
Passaggio dal lavoro individuale al lavoro in team
Introduzione di pratiche di test e quality assurance
Maggiore collaborazione e condivisione delle responsabilità
Materiale sulla gestione del cambiamento organizzativo
Risorse sulla qualità del software
🎓 Note del Trainer
“L’esperienza di Stefano dimostra come Scrum possa essere implementato con successo anche in realtà più piccole, ponendo l’accento sull’importanza delle persone e del miglioramento continuo. Il cambiamento richiede pazienza, dedizione e una visione chiara dei benefici che si vogliono ottenere.”
Per fornire le migliori esperienze, utilizziamo tecnologie come i cookie per memorizzare e/o accedere alle informazioni del dispositivo. Il consenso a queste tecnologie ci permetterà di elaborare dati come il comportamento di navigazione o ID unici su questo sito. Non acconsentire o ritirare il consenso può influire negativamente su alcune caratteristiche e funzioni.
Funzionale
Sempre attivo
L'archiviazione tecnica o l'accesso sono strettamente necessari al fine legittimo di consentire l'uso di un servizio specifico esplicitamente richiesto dall'abbonato o dall'utente, o al solo scopo di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica.
Preferenze
L'archiviazione tecnica o l'accesso sono necessari per lo scopo legittimo di memorizzare le preferenze che non sono richieste dall'abbonato o dall'utente.
Statistiche
L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici.L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici anonimi. Senza un mandato di comparizione, una conformità volontaria da parte del vostro Fornitore di Servizi Internet, o ulteriori registrazioni da parte di terzi, le informazioni memorizzate o recuperate per questo scopo da sole non possono di solito essere utilizzate per l'identificazione.
Marketing
L'archiviazione tecnica o l'accesso sono necessari per creare profili di utenti per inviare pubblicità, o per tracciare l'utente su un sito web o su diversi siti web per scopi di marketing simili.