Committenti e sviluppatori devono lavorare insieme
quotidianamente per tutta la durata del progetto.

Fondiamo i progetti su individui motivati.
Diamo loro l’ambiente e il supporto di cui hanno bisogno
e confidiamo nella loro capacità di portare il lavoro a termine.

Una conversazione faccia a faccia
è il modo più efficiente e più efficace per comunicare
con il team ed all’interno del team.

Agile Manifesto – 2001 aa.vv.

Il modello di ingaggio cliente fornitore

E’ uso comune, specie nelle aziende di medie e grandi dimensioni, “affittare” persone per la formazione di team ibridi in cui parte del personale è fornito dal cliente (tipicamente il Product Owner) e parte dal fornitore che offre i Developers. Lo Scrum Master è spesso messo a disposizione dal fornitore ma a volte anche dal cliente stesso.

Questi schemi contrattuali, sebbene fortemente radicati nelle aziende di medie e grandi dimensioni, rendono difficile la collaborazione. Ma tali contratti invece si basano su accordi a corpo o time&material: nel primo caso il fornitore viene pagato se produce un tot di funzionalità entro una certa data (e tipicamente viene multato in caso di ritardi); nel secondo ogni giornata viene contabilizzata e retribuita in base agli accordi.

Quasi mai, in nessuno dei due casi, c’è spazio per discutere insieme su quale sia la cosa migliore da fare per produrre il maggior valore possibile.

La situazione descritta evidenzia una sfida comune nelle organizzazioni di medie e grandi dimensioni che adottano framework agili come Scrum. La creazione di team ibridi, con membri del personale forniti sia dal cliente sia dal fornitore, può complicare la dinamica di collaborazione necessaria per un approccio Agile efficace. Ecco alcuni punti chiave su questa problematica:

• Team Ibridi: nella formazione di team ibridi, si possono verificare disallineamenti e conflitti di interesse tra le varie parti. Il Product Owner proveniente dal cliente e gli Sviluppatori forniti dal fornitore possono avere prospettive e priorità diverse. Lo Scrum Master, a prescindere da chi lo fornisce, può trovarsi in una posizione difficile per mediare questi interessi e promuovere una collaborazione efficace.

• Contratti basati su output anziché outcome: i modelli contrattuali come “time&material” o a “corpo”, focalizzati sull’output (come il numero di funzionalità prodotte o le ore lavorate) piuttosto che sull’outcome (il valore generato), possono ostacolare la flessibilità e l’adattabilità richieste in Agile. Questi contratti tendono a limitare la capacità di reagire rapidamente ai cambiamenti e di adattare le priorità in base al feedback degli utenti o alle esigenze di mercato.

• Mancanza di focus sul valore aggiunto: questi schemi contrattuali spesso non incentivano una discussione congiunta sulle azioni più appropriate per massimizzare il valore. La pressione per rispettare scadenze e budget predefiniti può ridurre lo spazio per valutazioni strategiche e decisioni basate sul valore a lungo termine per l’utente finale.

• Sfide nella comunicazione e nell’allineamento: la collaborazione tra cliente e fornitore può diventare complicata a causa di differenze culturali, obiettivi disallineati e mancanza di una comunicazione aperta e trasparente. Questo può portare a incomprensioni e a una scarsa qualità del prodotto finale.

Per affrontare queste sfide, le organizzazioni dovrebbero considerare:

• Rivedere gli schemi contrattuali: spostare il focus dai contratti basati su output a quelli incentrati sull’outcome e sul valore aggiunto.
• Favorire la collaborazione e la comunicazione: promuovere una cultura di collaborazione e comunicazione aperta tra tutte le parti coinvolte.
• Allineamento degli obiettivi: assicurarsi che tutti i membri del team, indipendentemente dalla loro provenienza, condividano gli stessi obiettivi e siano allineati sulla visione del prodotto.
• Empowerment e responsabilizzazione: dare maggiore autonomia al team Scrum, compresi il Product Owner e lo Scrum Master, per prendere decisioni basate sul valore e sul feedback degli utenti.

Gli antipattern dei team ibridi

L’adozione di modelli ibridi in cui ruoli chiave come il Product Owner e lo Scrum Master sono divisi tra cliente e fornitore può portare a diversi antipattern, che sono comportamenti o pratiche che ostacolano l’efficacia dell’approccio Agile. Ecco alcuni antipattern specifici per i due scenari menzionati:

Scenario 1: Product Owner e Scrum Master del cliente, Developers del fornitore

In questo scenario di fatto c’è una “distanza” fra PO/SM e il resto del gruppo. Questa separazione porta a diversi problemi, fra cui:

• Barriere comunicative: la comunicazione tra il Product Owner/Scrum Master e i Developers può essere ostacolata da differenze culturali, logistiche o di linguaggio.
• Conflitti di priorità: Il Product Owner può avere una visione del prodotto che non è completamente condivisa o compresa dai Developers del fornitore, portando a conflitti sulle priorità.
• Responsabilità diluita: i Developers potrebbero sentirsi meno responsabili dell’outcome finale, percependo le decisioni come imposte dall’esterno.
• Mancanza di Coinvolgimento: i Developers potrebbero non essere completamente coinvolti nelle decisioni strategiche, limitando la loro capacità di contribuire con idee innovative o feedback critici.
• Mancanza di focus sul miglioramento: fra le molte cose che lo Scrum Master non riesce a fare bene è supportare il team nella crescita e nel miglioramento continuo (perché è un team esterno).

Questo scenario porta con se altri problemi:

• Mancanza di ingaggio e Motivazione: i Developers del fornitore potrebbero non sentirsi pienamente coinvolti o motivati, poiché le decisioni chiave e la leadership provengono dal cliente.
• Difficoltà nel gestire il cambiamento: le richieste di cambiamento del Product Owner potrebbero incontrare resistenza o lentezza nell’implementazione da parte dei Developers del fornitore, a causa di processi interni o mancanza di flessibilità.
• Scarsa qualità del feedback: il feedback tra il Product Owner/Scrum Master e i Developers potrebbe essere superficiale o ritardato, limitando la capacità di miglioramento continuo e di adattamento rapido.

Scenario 2: Product Owner del cliente, Scrum Master e Developers del fornitore

In questo caso la divisione è fra il  Product Owner e il resto del gruppo. I possibili problemi stavolta sono legati al valore rilasciato, fra cui:

• Conflitto di ruoli: il Product Owner potrebbe sentirsi escluso dal processo decisionale, specialmente se lo Scrum Master e i Developers tendono a prendere decisioni senza un’adeguata consultazione.
• Visione del prodotto non integrata: potrebbero emergere divergenze tra la visione del Product Owner e l’esecuzione del team di sviluppo, compromettendo l’allineamento sul prodotto.
• Mancanza di autonomia del Product Owner: il Product Owner potrebbe non avere sufficiente influenza o autorità per guidare effettivamente lo sviluppo del prodotto.
• Dipendenza dal fornitore: eccessiva dipendenza dal fornitore per la gestione quotidiana, che può ridurre il senso di proprietà e impegno del cliente verso il prodotto.
• Silos informativi: Il flusso di informazioni tra il Product Owner e il team di sviluppo può diventare frammentato, con il rischio di creare silos informativi.
• Disallineamento strategico: potrebbe esserci una mancanza di allineamento strategico tra le esigenze del cliente e l’approccio operativo del team di sviluppo.
• Scarsa comprensione del mercato: i Developers e lo Scrum Master del fornitore potrebbero non avere una comprensione approfondita del mercato o del settore del cliente, portando a soluzioni meno efficaci o innovative.

In entrambi gli scenari, è fondamentale lavorare per semplificare la comunicazione efficace, un allineamento chiaro sugli obiettivi e una collaborazione stretta tra tutte le parti per superare questi antipattern. È importante che tutti i membri del team, indipendentemente dalla loro affiliazione organizzativa, si sentano parte integrante del processo e siano impegnati a lavorare insieme verso gli obiettivi comuni.

Cliente e il fornitore devono lavorare attivamente per superare questi ostacoli. Questo può includere l’istituzione di canali di comunicazione aperti e frequenti, sessioni regolari di allineamento e feedback, e una forte enfasi sull’importanza della collaborazione e della condivisione delle responsabilità. Per evitare questi antipattern, è essenziale creare un ambiente in cui tutti i membri del team si sentano valorizzati, ascoltati e impegnati nel processo Agile.

Un cambio di prospettiva: i Contratti Agili

L’introduzione di schemi di ingaggio basati su modelli agili, come i contratti agili, può aiutare a superare molti degli antipattern associati ai modelli ibridi in ambienti Scrum. Questi schemi si concentrano sulla flessibilità, sulla collaborazione e sull’allineamento agli obiettivi di business, piuttosto che su metriche fisse come il tempo e il materiale o il lavoro a corpo. 

Ecco alcuni aspetti chiave dei contratti agili e di altri schemi di ingaggio ispirati all’Agile:

• Focus su outcome piuttosto che su output: i contratti agili enfatizzano la consegna di valore e risultati tangibili (outcome) piuttosto che il semplice completamento di attività specifiche (output). Questo allineamento verso l’outcome favorisce una maggiore flessibilità nel processo di sviluppo.

• Pagamenti basati sul valore: invece di pagamenti basati su tempo o raggiungimento delle milestone, i contratti agili possono prevedere pagamenti legati al raggiungimento di specifici risultati di valore, incoraggiando così il fornitore a concentrarsi sulla creazione di valore per il cliente.

• Collaborazione e partnership: questi contratti incoraggiano una partnership stretta tra cliente e fornitore, con una comunicazione continua e un’attiva partecipazione di entrambe le parti nel processo di sviluppo.

• Time & Material con limiti flessibili: alcune organizzazioni adottano un modello time&material, ma con maggiore flessibilità in termini di scopo e consegna, permettendo adattamenti basati sul feedback continuo e sulle esigenze emergenti.
• Contratti con opzioni di cambiamento incorporate: alcuni contratti includono clausole che permettono ai clienti di apportare modifiche al progetto senza oneri eccessivi, riflettendo la natura iterativa e adattativa dell’Agile.

• Accordi basati su fiducia e valore condiviso: un approccio più relazionale e meno transazionale, dove la fiducia e la comprensione reciproca sono alla base dell’ingaggio. Questo richiede una forte cultura di collaborazione e un impegno condiviso verso obiettivi comuni.

Conclusione

In conclusione, adottare schemi di ingaggio che riflettono i principi agili può aiutare le organizzazioni a superare le sfide dei modelli ibridi, promuovendo una maggiore collaborazione, flessibilità e un focus sul valore. Questo richiede però un cambiamento sia culturale sia contrattuale, con un’impostazione più aperta al cambiamento e all’adattamento.

Giovanni Puliti

Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.