La Trasformazione Agile delle Risorse Umane: Un’Evoluzione Graduale

Questi si concretizzavano in stand-up regolari in cui il team condivideva i propri progressi e potenziali ostacoli.

I responsabili di programma e delle workstream potevano quindi seguire eventuali ostacoli per risolverli o adeguare le tempistiche. 

Il valore aggiunto di questo approccio è che le persone direttamente coinvolte nella realizzazione operativa del progetto (sviluppatori di sistema, tester, raccoglitori di requisiti) avevano chiarezza sui loro compiti e non dovevano preoccuparsi di risolvere gli ostacoli—altri se ne occupavano.

Nel complesso, questa metodologia basata sugli sprint ci ha portato alcuni vantaggi significativi:

• Requisiti chiari per i deliverable suddivisi in ciò che deve essere raggiunto nello sprint successivo
• Tutti i compiti avevano un responsabile ed erano chiaramente prioritizzati
• Sono stati creati casi di test per ciascun deliverable
• Maggiore focus—non serve preoccuparsi di questioni fuori da un orizzonte temporale breve
• Un backlog di elementi noti da fare ma non affrontati subito
• Rituali di comunicazione interna per focalizzarsi sui problemi da risolvere istantaneamente
• Rituali di comunicazione esterna (a fine sprint) per condividere con gli stakeholder ciò che è stato raggiunto (e ciò che non lo è stato, spiegandone i motivi)
• Un processo di gestione del cambiamento per ogni deliverable: test, formazione, aggiornamento delle policy, ecc. (questo fa parte dei rituali di comunicazione esterna).

Questa struttura ha reso più semplice discutere e comunicare i progressi su un progetto impegnativo. 

Se eravamo in ritardo su alcune attività era facile individuare cosa fosse in ritardo e perché, anche con un'analisi delle cause profonde.

E questa era davvero la fase 1: come utilizzare una metodologia basata sugli sprint per implementare un progetto tecnologico i cui stakeholder lavoravano nelle risorse umane.

Ma questo non è poi così interessante o emozionante. Il punto chiave è come abbiamo iterato questo processo per oltre 50 sprint fino a coprire tutta la delivery delle HR e come puoi fare anche tu.

Quando abbiamo iniziato a rilasciare le parti 2, 3 e 4 della nostra infrastruttura di sistema, ci siamo resi conto che incontravamo alcune sfide—e opportunità—nella metodologia che stavamo seguendo. Tra queste:

• Opportunità: L’implementazione del nostro sistema non era isolata, ma era un facilitatore per le risorse umane e l’intera azienda per raggiungere gli obiettivi
• Sfida: Potevamo prioritizzare il tempo del nostro team ma risultava difficile farlo con il tempo degli altri membri HR (per test, raccolta requisiti, incontri con fornitori, ecc.) o degli utenti per valutare i feedback sui deliverable
• Sfida: Non era sempre chiaro a tutti come stessimo generando valore rispetto agli obiettivi organizzativi
• Sfida: Le peculiarità HR, come grandi attività scandite dal calendario—valutazioni delle performance e cicli salariali—che non possono essere spostati. Come dipartimento, inoltre, è naturale dover reagire a cambiamenti aziendali, ristrutturazioni organizzative, integrazioni di acquisizioni e alla consegna quotidiana di piani di business in costante evoluzione per quanto riguarda i processi delle persone.

Dopo un’attenta analisi, abbiamo deciso di adattare la metodologia a tutto il team HR, per superare alcune delle sfide che affrontavamo e continuare a trarre benefici dal lavoro in sprint.

Abbiamo proceduto per passi graduali trattando il processo stesso in maniera agile, ma la nuova metodologia di gestione dei progetti aveva i seguenti elementi chiave:

• Piani strutturati suddivisi in deliverable per ciascuno sprint con responsabili chiari, anche cross-funzionali, per ogni attività
• Il team di gestione HR prioritizza i progetti di ogni sprint
• Un processo di revisione in cui i team possono approvare la lista prioritaria e assicurarsi che ci siano tempo, competenze e risorse per raggiungere ciò che si prevede
• Un backlog prioritizzato di attività minori
• Il tempo di delivery in cui le priorità non dovrebbero cambiare
• Stand-up regolari durante la delivery per allineare i progressi e discutere le difficoltà
• Revisione di ciò che è stato consegnato
• Comunicazione con il team allargato e l’azienda alla fine di ogni sprint
• Retrospettiva per valutare cosa può essere migliorato nel processo
• Documentazione di tutto.

Questo modello ha portato benefici significativi ma non è stato privo di sfide. Ad esempio, gli sprint di 4 settimane si susseguivano molto rapidamente, con attività che si sovrapponevano all’inizio e alla fine e numerosi compiti amministrativi da svolgere.

Tuttavia, come per qualsiasi processo, basta continuare ad ascoltare e migliorare per ottenere risultati sempre migliori.

Nel complesso, siamo diventati più agili come funzione e più focalizzati sulle priorità. Inoltre, ci ha fornito un processo di gestione del cambiamento e una comunicazione regolare con l’azienda su ciò che stava cambiando.

Alcuni dei principali vantaggi di approcciare i progetti in questo modo sono:

• Si è molto più allineati con le esigenze più ampie dell’azienda poiché si comunica regolarmente durante l’intero processo di delivery. Questo contribuisce a valorizzare la funzione HR rendendo chiaro su cosa si sta lavorando
• I progetti vengono consegnati per passi più piccoli, ognuno dei quali avvicina all’obiettivo finale
• Ogni passo rappresenta un cambiamento che impatta gli utenti, offrendo così l’opportunità di ricevere feedback
• Aiuta ad abbattere i silos facendo lavorare insieme i diversi team sulle consegne
• Raggruppare diversi piccoli cambiamenti sotto un unico progetto aiuta a rendere le modifiche più visibili e significative
• Se ci sono problemi nella delivery, come requisiti poco chiari o problemi tecnici, li si scopre sprint dopo sprint, invece che dopo mesi
• Gli elementi di prioritizzazione permettono di integrare i progetti operativi fissi presenti nel calendario HR con i progetti di trasformazione e di cambiamento organizzativo, valutando come (o se) possano essere gestiti contemporaneamente
• Si è molto più vicini e consapevoli delle sfide di risorse—sia in termini quantitativi che di competenze—il che permette di valutarle e affrontarle più rapidamente.

Probabilmente è importante menzionare che le attività di routine come le relazioni con i dipendenti, i colloqui, la risposta alle richieste dei dipendenti, l’erogazione della formazione, ecc. erano considerate attività BAU e che i diversi ruoli disponevano di tempi differenti da dedicare ai progetti rispetto alle attività operative.

Vediamo quindi un paio di esempi pratici su come questo approccio funzioni: un grande progetto fisso a calendario e un progetto con un maggior focus sul miglioramento iterativo.

Progetto Uno: Revisione Annuale degli Stipendi (Marzo)

Questo progetto coinvolgeva la maggior parte del personale HR, collaborava con il finance, riguardava tutti i manager e i dipendenti, e doveva necessariamente procedere senza intoppi, poiché trattava dati estremamente sensibili da gestire in modo molto strutturato.

Una vera bestia pelosa!

Tuttavia, utilizzando il nostro modello agile di delivery, il processo è stato suddiviso e prioritizzato, quindi rivisto e migliorato.

Per prima cosa, abbiamo suddiviso gli elementi critici della delivery del progetto in sprint di 4 settimane, coprendo il periodo da dicembre a marzo. 

Gli obiettivi di progetto sono stati assegnati a ogni sprint, ciascun deliverable con il proprio responsabile.

Il progetto è stato quindi posto come massima priorità in ciascuno degli sprint, garantendo che tutti gli interessati potessero ritagliarsi tempo sufficiente per portare a termine la propria parte. Se si presentavano problemi, venivano segnalati rapidamente in quanto elemento prioritario.

Ciascuno sprint veniva rivisto ed eventuali problemi (di risorse, competenze, sistema) venivano discussi e risolti.

La parte fondamentale era assicurarsi che tutti sapessero cosa doveva essere fatto in ogni sprint e, dato che aveva la priorità sugli altri progetti, tutti avevano sufficiente preavviso per rivedere gli altri progetti e le priorità, così da garantire tempo sufficiente per seguire la revisione degli stipendi.  

Adattare la pianificazione utilizzando questa metodologia di prioritizzazione rende molto più chiaro cosa non si può realizzare e offre al team confini chiari su cosa rifiutare.

In secondo luogo, l’intero progetto è stato rivisto (come dovrebbe succedere per tutti i progetti) tramite un “washup”. 

I feedback sono stati raccolti dagli stakeholder HR, dal finance, dai manager e dai dipendenti (tramite feedback diretto richiesto, ricevuto o tramite le regolari indagini ai dipendenti).

Tutti i problemi (aumenti insoddisfacenti, metodologia utilizzata per suddividere la revisione tra i team, formazione, processo, tempistiche, interfaccia di sistema, ecc.), sono stati valutati, prioritizzati, suddivisi in singoli elementi, assegnati ai rispettivi responsabili e aggiunti al backlog con scadenza novembre (mese precedente al riavvio del processo) dal responsabile di progetto.  

Molti di questi elementi erano minimi, ad esempio una formulazione poco chiara nel materiale formativo o una mancanza di comprensione su come funzionava qualcosa. Altri erano più grandi e richiedevano sviluppo sui sistemi, test e aggiustamento del materiale formativo futuro.

Ogni feedback è stato ascoltato, rivisto e riceveva risposta (dove possibile) e chi lo aveva dato veniva coinvolto nel testing.  

Ad esempio, se qualcuno segnalava che un materiale formativo non era chiaro, gli veniva inviato il materiale aggiornato per verificare che fosse migliorato.  

Lavorare in questo modo è davvero efficace perché ci si concentra sul migliorare l’esperienza e si riconosce che i feedback vengono ascoltati e messi in pratica.

Nel complesso, quindi, in che modo questa metodologia ha migliorato le cose? 

La principale sfida è sempre stata quella delle revisioni salariali che arrivavano in un periodo intenso e della sensazione, da parte dei membri del team, di essere sommersi da molteplici richieste.  

Il processo di prioritizzazione ha reso chiaro a tutti cosa dovevano fare e su cosa potevano opporsi, permettendo al management di concentrarsi sulla riprioritizzazione di altri progetti.

Questo è stato un enorme miglioramento.  

In secondo luogo, l’approccio di ascoltare il feedback dopo il progetto, raccogliere i suggerimenti di miglioramento e risolverli poco a poco ci ha permesso di ottenere un processo progressivamente migliore nel tempo.

Progetto Due: Onboarding

Abbiamo avviato un importante progetto per cercare di migliorare l’onboarding dei nuovi dipendenti in molti paesi. Questo comprendeva:

• Far inserire ai nuovi dipendenti i propri dati personali direttamente nel sistema HR invece di compilare moduli cartacei o digitali che poi venivano inseriti nel sistema HR dall’ufficio HR
• I dipendenti selezionavano i propri benefit online prima di iniziare a lavorare
• Digitalizzazione di tutta la documentazione da firmare, passaggio alla firma digitale e inserimento nel sistema HR

Complessivamente, si contavano 5 esperienze locali di onboarding e circa 6 locali per 15 paesi—circa 95 attività o esperienze da digitalizzare.  

Un progetto come questo è un esempio tipico di “bollire il mare”—da dove si comincia? Quanto tempo richiederà? Può sembrare travolgente!

Ma, affrontando questo progetto con una metodologia agile, siamo stati in grado di suddividere tutte queste attività in parti gestibili.

Abbiamo utilizzato la metodologia degli sprint per procedere, combinando attività sia globali che locali. 

Siamo anche riusciti a collegare alcune delle attività ad altri progetti, per esempio la scelta di un nuovo fornitore di pensioni nel paese X ha fatto sì che la digitalizzazione del processo pensionistico per il paese X venisse portata a termine insieme all’onboarding.

Il processo di prioritizzazione è stato fondamentale per garantire che gli elementi globali venissero completati quando il team globale era disponibile e che le attività locali, che richiedevano lavoro e test dei team locali specifici, potessero essere pianificate in base alle loro esigenze. 

La maggior parte delle attività era relativamente piccola e siamo diventati più efficienti man mano che progredivamo.

Come team di management, siamo stati in grado di vedere, misurare e influenzare l’avanzamento del progetto più ampio, ma ogni attività e consegna era piuttosto ridotta.

Questo è stato un ottimo modo per affrontare il progetto, poiché alcune attività si sono rivelate più difficili di altre. 

Così, se incontravamo un problema con un benefit in un paese con pochi dipendenti, potevamo rapidamente saltare quell’attività, creare documentazione e processi chiari su come gestirla e passare alla successiva. 

Il nostro obiettivo non era la perfezione entro una data prestabilita, ma miglioramenti incrementali mese dopo mese.

Quindi, in conclusione, il progetto di onboarding ha dimostrato che affrontando ogni singola attività—con un obiettivo strategico di digitalizzazione e self-service—siamo riusciti a fare progressi sin dal primo giorno senza un piano enorme e a portare rapidamente benefici all’organizzazione in termini di esperienza dei dipendenti e risparmio sui costi.

Perché Agile è il Futuro

Poiché il lavoro continua ad aumentare in velocità, complessità e volatilità, lavorare con metodologie rigide "a cascata" di più anni presenta debolezze intrinseche. 

Adottare una metodologia e una mentalità agile offre molti vantaggi come:

• Prioritizzazione
• Obiettivi chiari per tutti i membri del team
• Abbattimento dei silos e maggiore coesione tra i team
• Scomposizione dei grandi progetti in parti gestibili
• Maggiore visibilità sul lavoro svolto al resto dell’azienda
• Miglioramenti iterativi e misurabili
• Connessione più chiara tra HR e gli obiettivi e bisogni aziendali
• Migliore gestione della domanda e delle capacità

Oltre all’adozione della metodologia di lavoro agile, creare un ambiente di lavoro agile per i tuoi dipendenti è un altro modo per permettere loro di prosperare, sia singolarmente che in team.