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.
In questo episodio esploriamo le prime azioni fondamentali che uno Scrum Master dovrebbe intraprendere quando inizia a lavorare con un nuovo team in una nuova azienda. Scopriremo l’importanza dell’osservazione, della costruzione della fiducia e dell’approccio empirico al miglioramento continuo.
🎧 Ascolta l’Episodio
🎯 Le Tre Fasi Iniziali dello Scrum Master
Questi sono suggerimenti che puoi sperimentare, non sono in un ordine preciso e nemmeno esaustivi. Ricorda che ogni ambiente di lavoro offre un contesto diverso ed unico, da qui l’importanza dell’approccio empirico.
1. Osservazione Attiva
Dedica le prime settimane all’osservazione del team
Utilizza un quaderno condiviso per annotazioni trasparenti
Mantenere un approccio trasparente nelle osservazioni
Rispettare i tempi di adattamento del team
Bilanciare interventi diretti e supporto indiretto
Costruire gradualmente la credibilità professionale
🔄 Evoluzione del Ruolo
Focus iniziale sul team e le sue dinamiche
Progressiva espansione verso le sfide organizzative
Adattamento continuo dell’approccio in base al contesto
Bilanciamento tra coaching diretto e facilitazione
🎓 Note del Trainer
“Come Scrum Master, il primo approccio con un nuovo team è fondamentale. Non esiste una formula magica, ma l’osservazione attenta, la costruzione della fiducia e un approccio empirico al miglioramento sono elementi chiave per stabilire una base solida per il successo futuro.”
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdere il prossimo episodio del podcast Scrum Italia dove vedremo se è possibile essere contemporaneamente Developer e Scrum Master.
Questo articolo è basato sull’episodio 32 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!
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!
In questo episodio intervistiamo Alessandro Bignami, un professionista con oltre 25 anni di esperienza nel mondo del software development, di cui gli ultimi 7 dedicati all’Agile e Scrum. Esploriamo come il mindset agile sia una caratteristica naturale che paradossalmente dimentichiamo con il tempo, e come riscoprirlo possa portare a risultati sorprendenti nei progetti software.
🎧 Ascolta l’Episodio
🎯 Punti Chiave dell’Intervista
Background di Alessandro
25+ anni nel software development
7 anni di esperienza in Agile e Scrum
Transizione da developer a Scrum Master nel 2018
Certificazioni Scrum e continuo apprendimento sul campo
L’Agilità come Comportamento Naturale
Il mindset agile è insito nel nostro modo di apprendere fin dalla nascita
Impariamo naturalmente per incrementi (esempio: linguaggio)
Paradossalmente, nelle organizzazioni tendiamo a complicare i processi
Caso di Studio: Successo con Scrum
Progetto con proof of concept iniziale
Team piccolo con approccio Scrum adattato
Collaborazione costante con il cliente
Sprint di 2 settimane con feedback continuo
Risultato: prodotto di successo in 10 mesi
💡 Lezioni Apprese
Importanza della volontà di mettersi in gioco
Necessità di adattare il framework al contesto
Valore della trasparenza e della collaborazione
Focus sui principi più che sulle pratiche
⚠️ Sfide nell’Adozione Agile
Resistenza al cambiamento nelle dirigenze
Crisi identitaria dei manager tradizionali
Necessità di un approccio graduale al cambiamento
Importanza di iniziare con progetti pilota mirati
📚 Consigli per Chi Inizia
Partire con una formazione di base solida, guarda i corsi disponibili!
Concentrarsi sul significato dietro le pratiche
Accettare la “sindrome dell’impostore” come normale
Non perdere il prossimo episodio del podcast Scrum Italia, un’altra intervista sulla tematica del miglioramento continuo.
Questo articolo è basato sull’episodio 26 del podcast Scrum Italia con Alessandro Bignami e Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
Project Manager e Scrum Master sono due mestieri diversi. Se sei un project manager, senti parlare sempre di più di Scrum e vorresti capire cosa c’è di così diverso fra questi due ruoli? Perché dovresti scegliere fra l’uno o l’altro e non si può fare un pò dei due?
In questo articolo provo a condividere le risposte a queste domande, con i principi e le ragioni che differenziano Scrum Professionale dal Project Management.
L’obiettivo non è quello di convincere che Scrum è la soluzione miracolo a tutto, al contrario. La mia esperienza come project manager mi porta ad apprezzare tutto quello che ho imparato durante gli anni spesi a gestire progetti in modo tradizionale.
Aggiornamento del 6 luglio 2023 – aggiunta del video dell’evento in diretta relativo a questa tematica.
Premessa
Ho avuto tre esperienze principali di lavoro:
Sviluppatore software per sistemi industriali complessi (essenzialmente C, C++ e SQL) dal 2001 al 2006 (6 anni)
Team leader, project e program manager nel settore bancario, trasporto e logistica, finanza dal 2007 al 2014 (8 anni)
Scrum Master e Professional Scrum Trainer dal 2015 ad oggi (9 anni)
Conosco bene cosa pensa (e cosa vive) uno sviluppatore, un project manager o uno Scrum Master. In particolare, per averli vissuti personalmente, conosco le sfide che un project manager deve affrontare se vuole diventare un buon Scrum Master.
Esploriamole insieme!
Project Manager e Scrum Master
Sono due mestieri diversi. È importante capirlo, perché il focus e le responsabilità di questi due ruoli sono diametralmente opposti.
Il Project Management funziona bene in contesti complicati o semplici (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)
Project Manager: ha per missione di tenere sotto controllo costi, time e scope del progetto. Garantisce all’azienda che gli investimenti strategici sono correttamente gestiti. Spesso è un esperto tecnico o funzionale e dice ai colleghi cosa fare, assegna i task e controlla che siano eseguiti secondo i piani. Ne parlo in questo articolo.
Un project manager lavora per soddisfare il management interno, ovvero controllare che il lavoro sia eseguito secondo i piani.
Fabio Panzavolta
Scrum funziona bene in contesti complessi (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)
Scrum Master: ha per missione di assicurarsi che Scrum è correttamente capito ed utilizzato. Contrariamente al project manager, i risultati del team “non gli interessano”. Se i membri dello Scrum Team hanno capito cosa vuol dire creare prodotti complessi in modo empirico, i risultati arriveranno.
Lo Scrum Master è un servant leader, aiuta a rimuovere gli ostacoli che impediscono il raggiungimento degli obiettivi del team (ne parlo in questo articolo).
Uno Scrum Master (con tutto lo Scrum Team) lavora per soddisfare gli utilizzatori del prodotto il più rapidamente possibile.
Fabio Panzavolta
Project Manager e Scrum Master, focus interno o esterno all’azienda?
La ragione di esistere di un project manager è quella di limitare i rischi aziendali garantendo il controllo degli investimenti.
Questo funziona principalmente per progetti altamente prevedibili, per i quali non sono previsti cambiamenti sostanziali durante lo sviluppo.
Quando lavoravo come project manager i primi cambiamenti al piano del progetto arrivavano molto rapidamente. Questo portava inevitabilmente a ginnastiche improbabili per non stravolgere il piano.
Project Manager – Focus interno
Per un Project Manager il focus è interno all’azienda, si passa più tempo a negoziare un paio d’ore di lavoro a destra e sinistra con gli sviluppatori che a sviluppare effettivamente il prodotto.
Questo focus interno porta a perdere di vista il perché si fa un progetto concentrandosi principalmente su budget, time e scope.
Ho personalmente conosciuto sviluppatori software che lavoravano da due anni su un progetto e non avevano mai visto il prodotto finito… immaginate la motivazione e l’impegno che potevano mettere al lavoro.
Scrum Master – Focus esterno
Uno Scrum Master, aiuta lo Scrum Team e gli stakeholders a fare un focus sui problemi da risolvere agli utilizzatori, ad ottimizzare il lavoro non fatto per concentrarsi solo su ciò che è veramente importante: il valore creato per gli utilizzatori del prodotto.
Questo non vuol dire che i limiti aziendali sono ignorati, perché il Product Owner fa attenzione a massimizzare il valore del prodotto. Quindi, per esempio, il budget a disposizione è speso in maniera opportunistica e non pianificata su un anno o due, ma con cicli di un mese al massimo.
Massimizzare il valore del prodotto vuol dire, fra l’altro, che la strategia del Product Owner implica la creazione di un prodotto che si auto-finanzierà il prima possibile.
Project Manager e Scrum Master, Scope fisso o variabile!
Altro cambiamento fondamentale, uno Scrum Master aiuta ad acquisire un modo di lavorare orientato sugli obiettivi, i requirements ci interessano, ma fino ad un certo punto.
Il project manager raccoglie tutti i requisiti, che molto spesso fanno parte del contratto. Per ottimizzare (sigh, sob 😊) si cerca di elencare tutte le funzionalità, con il cliente, nelle prime fasi del progetto. In modo tale da non doversi più vedere per un annetto o due (ri-sigh, ri-sob).
Ovviamente questo modo di lavorare funziona, come dicevo prima, se ciò che state facendo non ha incertezze sostanziali.
Purtroppo (in particolare per l’informatica), molto spesso il cliente non sa nemmeno cosa vuole. Oppure (che è anche peggio) è assolutamente convinto di sapere cosa vorrebbe avere (poi si scopre che gli utenti e i loro problemi quotidiani non li conosce veramente).
Quindi il povero project manager (esperienza vissuta) fa dei piani nel momento in cui il team, il cliente e lui stesso hanno meno esperienza e meno informazione possibile… conoscete i risultati… altrimenti non sareste arrivati fino qui a leggere 😊.
Questo problema è risolto in Scrum, perché invece di lavorare a scope fisso, si lavora con obiettivi fissi, concedendo una certa “liquidità” nelle funzionalità da implementare grazie all’ordinamento del Product Backlog.
Lo Scrum Master insegnerà a tutti (anche al cliente) come fondare il lavoro su obiettivi, generare risultati concreti per gli utilizzatori e farà in modo che le esigenze emergano con l’esperienza, grazie al feedback degli utilizzatori ed alla collaborazione regolare con il cliente.
In un mondo complesso ed incerto, quando non si sa veramente cosa si vuole, un prodotto non si pianifica, emerge dall’esperienza.
Fabio Panzavolta
Scegliere di fissare un obiettivo ed avere funzionalità variabili avrà come conseguenza una migliore qualità, più implicazione da parte di tutti, più innovazione nella ricerca di soluzioni e più rilasci in produzione.
Project Manager e Scrum Master, dalle esigenze agli obiettivi
Parlavo di contratto prima… quante volte, da project manager, mi sono trovato a dover discutere con il cliente per giorni, settimane per cambiare una virgola in una particolare esigenza… con il risultato che dopo la discussione ci volevano altre settimane per avere il GO per implementare il cambiamento (che nel frattempo, a volte, era già stato fatto).
Purtroppo, in certi casi, ci siamo anche trovati ad implementare delle cose che sapevamo sbagliate, o incoerenti, per non dover subire il processo descritto sopra.
Il focus sulle esigenze è un focus malato in un contesto complesso e mutevole.
Fabio Panzavolta
Il giusto focus è negli obiettivi… in Scrum ce ne sono due:
Product Goal: definito dal Product Owner, è un obiettivo a medio termine, un passo in più verso la visione del prodotto
Sprint Goal: definito dallo Scrum Team, è un obiettivo a corto termine (un mese massimo), un passo in più verso il Product Goal
In un contratto si possono fissare i Product Goal, facendo attenzione a non renderli troppo stringenti, bensì sufficientemente vaghi per dare una direzione e lasciare libertà nel decidere cosa e come sperimentare nuove soluzioni.
Segui questo link se vuoi saperne di più sui contratti agili.
Riuscire a fare un focus sul goal (Scrum Professionale) e non sui requirements (Project Management), vuol dire concentrarsi sul perché si vuole fare qualcosa, non sul come. Le discussioni sul cosa e come raggiungere l’obiettivo saranno legate al perché si vogliono fare, con un focus maggiore, più o meno funzionalità a seconda del contesto e degli esperimenti che si faranno collaborando.
Conclusioni
Project Manager e Scrum Master sono due mestieri diversi, con focus diverso. Non si può pensare di accettare un ruolo di Scrum Master senza aver capito Scrum Professionale o le responsabilità di uno Scrum Master (ne parlo in un episodio del podcast Scrum 🇮🇹).
La difficoltà non è Scrum, bensì il cambiamento nel modo di pensare, agire e prendere decisioni.
Uno Scrum Master si accontenta di rivelare ciò che non funziona secondo Scrum, non dà soluzioni o dice agli altri cosa fare. Piuttosto, aiuta le persone a trovare e sperimentare le soluzioni grazie alle idee che emergono discutendo.
Se sei un Project Manager e desideri cominciare o continuare il tuo percorso di professionalizzazione, puoi cominciare da autodidatta.
Personalmente ho letto tanto, questi sono i libri, ho praticato in condizioni differenti (prima in contesti al di fuori del lavoro, poi al lavoro) e non smetto mai di pensare che sto ancora imparando.
Un’altra fonte inesauribile di conoscenza è ovviamente il sito scrum.org, ma anche i blog di Ken Schwaber e Gunther Verheyen, i miei due punti di riferimento.
Se vuoi imparare o migliorare la tua conoscenza di Scrum Professionale, facendoti accompagnare, puoi anche scegliere di partecipare ad una delle nostre formazioni.
In questo episodio ascolteremo l’audiobook completo della Guida Scrum, il documento scritto da Ken Schwaber e Jeff Sutherland che definisce il framework Scrum. Scopriremo la teoria, i valori, gli eventi e gli artefatti che compongono Scrum, direttamente dalla fonte ufficiale tradotta in italiano.
La Guida Scrum è il punto di riferimento per comprendere il framework. Ascoltarla in formato audio permette di assimilarne i concetti fondamentali in modo diverso rispetto alla lettura, offrendo nuove prospettive e una comprensione più profonda.
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdere il prossimo episodio dove parleremo della differenza fra Agile e Scrum.
Questo articolo è basato sull’episodio 20 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.
Il servant manager è una delle chiavi per stimolare l’innovazione in azienda. In questo articolo concentro le risorse che ti permetteranno di esplorare questo argomento.
Discutendo con dirigenti di società di qualsiasi dimensione, i problemi ricorrenti che espongono sono: qualità scarsa dei nostri prodotti, lentezza nel mettere in produzione nuovi prodotti, difficoltà a trattenere o attirare talenti, clienti insoddisfatti. Questi sono i sintomi di un’azienda che adotta una leadership che funzionava mezzo secolo fa. Quando si parla di innovazione spesso il focus è fatto su nuove tecnologie, ma la vera prima innovazione consiste ad adottare una leadership che sia adatta all’epoca in cui viviamo, costituita da incertezze e cambiamenti rapidi.
Un vero problema quando si devono risolvere problemi complessi.
2 – Le conseguenze
Osservabili facilmente in qualsiasi azienda, in maniera più o meno evidente:
Personale infelice
Competitività aziendale in diminuzione
Burn-out
Turnover
ecc.
Il controllo eccessivo delle persone, la burocrazia ed i processi che si usano per limitare i rischi, scatenano i sintomi osservati sopra. Purtroppo la soluzione usata in molte aziende, quando le cose vanno male, consiste nell’incrementare burocrazia e processi. Questo nel tentativo di correggere la situazione.
Purtroppo si ottiene l’effetto contrario.
3 – Capire il contesto
Questa mancanza di impegno al lavoro può essere spiegata dal fatto che il management non si è ancora perfettamente adattato alla gestione di problemi complessi.
Per prima cosa, quindi, è necessario farsi le domande giuste, cioè capire se il contesto nel quale operiamo è ancora del tipo “industriale”, con processi di sviluppo lineari e predittivi. In questo caso procedure e processi per controllare il risultato del lavoro sono la buona soluzione.
Ma se il contesto è di tipo complesso, allora il management come l’abbiamo imparato all’università (ed il modo di pensare) non sono più adatti in quanto in questo tipo di situazioni il pensiero e la risoluzione dei problemi non sono più lineari e prevedibili. In questo caso, è necessario ridurre (eliminare il più possibile) burocrazia e procedure, liberare le persone e concentrarsi su obiettivi chiari e misurabili. Questa è la logica post-industriale, dove l’obiettivo è creare valore in modo creativo e innovante.
Nel video qui sotto sviluppo questo concetto.
4 – Adattare il proprio stile di management
Se si vuole più impegno al lavoro, da parte di tutti, allora è necessario capire cosa vuol dire mettersi al servizio degli altri, ovvero come diventare un buon servant leader.
In un contesto di complessità il management è sostituito dalla leadership.
Management tradizionale
Servant Manager
Focus sulle persone
Focus sul sistema (vincoli, regole semplici non imposte)
Impone soluzioni
Fa domande, le risposte e le soluzioni arrivano dalle persone che fanno il lavoro
Orientato ai task (cosa e come fare)
Orientato obiettivi (perché fare)
Focalizzato sulle performance della persona
Focalizzato sul risultato del team (utilizzatori contenti?)
Confronto fra management tradizionale e servant manager
Tanti altri esempi sono possibili, questi sono i primi che mi sono venuti in mente. L’importante è capire che le caratteristiche di un servant manager sono quelle di venire in supporto alle persone che fanno il lavoro per assecondarle e supportarle nelle loro decisioni.
Per sapere se le decisioni sono giuste o sbagliate, bisognerà concentrarsi sugli utenti del prodotto, andare in produzione il più spesso possibile per ottenere feedback e migliorarsi continuamente.
Per saperne di più, esplora il contenuto qui sotto per saperne di più sul Servant Manager! Esplora come, facendo evolvere il nostro modo di essere, stimoliamo l’innovazione, rendiamo i nostri prodotti migliori e i clienti più contenti.
In questo episodio esploriamo la Sprint Retrospective agile, l’evento conclusivo dello Sprint dedicato al miglioramento continuo del team. Scopriremo come questa retrospettiva Scrum permette allo Scrum Team di evolvere e ottimizzare il proprio modo di lavorare, garantendo maggiore efficacia e qualità Sprint dopo Sprint.
🎧 Ascolta l’Episodio
🎯 Cos’è la Sprint Retrospective
La Sprint Retrospective Scrum è l’evento finale dello Sprint dove l’intero Scrum Team si riunisce per migliorare la Scrum Team effectiveness. Gli obiettivi principali sono:
Analizzare l’andamento dello Sprint concluso
Identificare punti di forza e aree di miglioramento
Pianificare azioni concrete per ottimizzare il lavoro futuro
Incrementare qualità ed efficacia del team
🔄 Caratteristiche Principali
Timeboxing e Partecipanti
Durata massima: 3 ore per Sprint mensili
Durata proporzionalmente minore per Sprint più brevi
Partecipanti: intero Scrum Team (Developers, Product Owner, Scrum Master)
Focus sull’Ispezione
Come parte fondamentale degli Scrum events, lo Scrum Team ispeziona:
Relazioni e interazioni tra i membri
Processi di sviluppo
Strumenti utilizzati
Definition of Done
Dinamiche con gli stakeholder
💡 Elementi Chiave per il Successo
Psychological Safety Scrum
Creazione di un ambiente sicuro per l’espressione
Importanza della trasparenza e del feedback onesto
Possibilità di comunicare liberamente preoccupazioni e proposte
Tecniche di Facilitazione della Retrospettiva
Utilizzo di post-it per coinvolgere anche i più introversi
Atmosfera informale ma produttiva
Esercizi di team building e discussione strutturata
Strumenti di facilitazione retrospettiva specifici per team distribuiti
Focus sulle Azioni
Identificazione di almeno un’azione di miglioramento concreta
“La Sprint Retrospective non è solo un momento di riflessione, ma un’opportunità concreta per evolvere la Scrum Team effectiveness. Il segreto sta nel bilanciare la serietà dell’evento con un’atmosfera che favorisca l’apertura e la partecipazione attiva di tutti i membri del team.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo gli artefatti di Scrum.
Questo articolo è basato sull’episodio 15 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, approfondiamo la Sprint Review, un evento cruciale di Scrum che si concentra sull’ispezione dei risultati dello Sprint e sull’adattamento dei piani futuri. Scopriamo come i Team Scrum possono trasformare questo evento da una semplice presentazione a una sessione di lavoro collaborativa che aumenta il valore del prodotto e il coinvolgimento degli stakeholder.
🎧 Ascolta l’Episodio
🎯 Cos’è la Sprint Review
La Sprint Review è il penultimo evento dello Sprint, timeboxed a un massimo di 4 ore per uno Sprint di un mese. I suoi scopi principali sono:
Ispezionare il risultato dello Sprint
Determinare i futuri adattamenti
Verificare i progressi verso il Product Goal
Collaborare con gli stakeholder sui prossimi passi
🔄 Caratteristiche Principali
Timeboxing e Partecipanti
Durata massima: 4 ore per Sprint di un mese (generalmente più breve per Sprint più corti)
Coinvolge l’intero Scrum Team
Include gli stakeholder chiave
Focus sulla collaborazione invece che sulla presentazione
Struttura Efficace
Verifica del raggiungimento dello Sprint Goal
Utilizzo dell’Increment funzionante
Feedback e interazione con gli stakeholder
Discussione del Product Backlog e direzione futura
Previsione della timeline di consegna
💡 Benefici della Sprint Review
Feedback diretto degli stakeholder sul prodotto funzionante
Maggiore trasparenza dei progressi
Migliore collaborazione tra Scrum Team e stakeholder
Maggior allineamento con le esigenze degli utenti
Identificazione precoce delle necessità di adattamento
⚙️ Best Practices
Coinvolgimento degli Stakeholder
Invitare stakeholder rilevanti che useranno o saranno impattati dal prodotto
Spiegare lo scopo e l’importanza della loro partecipazione
Fornire interazione diretta con il prodotto
Raccogliere e organizzare il feedback sistematicamente
Gestione della Sessione
Mantenere la presentazione iniziale breve (20-30 minuti)
Concentrarsi sull’utilizzo del prodotto funzionante
Utilizzare strumenti come feedback board (Mi piace/Da migliorare/Nuove idee)
Riservare tempo per la discussione collaborativa
Condividere il potenziale Sprint Goal successivo e la direzione del Product Backlog
📚 Errori Comuni da Evitare
Trasformarla in una presentazione PowerPoint
Limitare la partecipazione al solo Scrum Team
Mostrare solo video o screenshot invece del prodotto funzionante
Presentare al Product Owner invece che agli stakeholder esterni
Non raccogliere feedback actionable
🎓 Note del Trainer
“La forza della Sprint Review sta nella sua natura collaborativa. Quando i team vanno oltre le semplici presentazioni e attivano un vero coinvolgimento degli stakeholder con il prodotto funzionante, sbloccano preziosi insight e creano un allineamento più forte con le esigenze degli utenti. Ricordate, non è una riunione di reporting – è una sessione di lavoro che guida il valore del prodotto.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove esploreremo la Sprint Retrospective in Scrum.
Questo articolo è basato sull’episodio 14 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.
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.
