Blog

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 🇮🇹.

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).

Superare il concetto di ritardo con Scrum. Dal contenuto fisso all’obiettivo da raggiungere

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

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!

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.

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:

• 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)
• Capacità a fissare obiettivi chiari e misurabili: per fare focus e scelte coscienti e motivate
• Competenze: per fare quello che si deve fare
• Focus alla risoluzione di problemi o opportunità: capire bene per chi si lavora e come si può soddisfare
• Ownership condivisa: grazie ad obiettivi chiari

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.

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.

Le regole del gioco sono descritte nello Scrum Guide, disponibile anche nel nostro podcast Scrum Italia.

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!

Per approfondire

• Scrum Guide (qui in versione audio)
• Valori Scrum
• Scrum requires Psychological Safety (in inglese)

Le formazioni che aiutano a far riconoscere Scrum come un elemento sano all’azienda!