Diciamolo: quando in Agile compare la parolina “management” spesso si osservano molte persone storcere il naso, immaginando ancora che si tratti di un retaggio del passato e che vada “rimosso” o, peggio ancora, “nascosto.”

Eppure l’esperienza quotidiana prima, e da “agilisti” poi, ci dimostra che la governance dei prodotti e dei processi, nonché dell’intera organizzazione aziendale conta quasi sempre più delle capacità tecniche del singolo.

“It’s the Whole System, not the singularity” potremmo esprime così la “regola del 95/5” di Deming che enfatizza l’importanza del sistema aziendale (formale, a soprattutto informale) rispetto al singolo… System Thinking… Lean… DevOps the first way!

Detto questo non deve sorprendere che DA2 identifichi nell’area di Delivery la funzione di Program Management, meglio in realtà Program Coordinator, anche se quest’ultima terminologia è meno comune e richiede a sua volta una transizione semantica che è meglio ottenere progressivamente con l’adozione diretta.

Ma perché dovremmo avere la necessità di istituire tale funzione? La risposta più evidente è la complessità e la dimensione che un prodotto software oggi può raggiungere, rendendo impossibile avere un singolo team che se ne occupi e coinvolgendo molti aspetti trasversali non strettamente tecnico-tecnologici (sales, market, financial, customer care, ecc…).

Questi progetti tendono spesso a diventare estremamente burocratizzati e il macro-team, a sua volta, tende a crescere in modo importante. Entrambi gli aspetti sono da mitigare, partendo proprio dalla dimensione del team che, come ormai abbiamo imparato, deve essere sufficientemente piccolo da potersi auto-organizzare al suo interno e adottare le pratiche di cui tanto discutiamo.

In tal modo si ottengono una serie di vantaggi chiave:

• Reorganize the problem into a collection of smaller problems. I team possono concentrarsi su specifici boundary all’interno del contesto complessivo sotto la governance del PgMO (Program Management Office, da non confondere con PMO – Project Management Office);
• Reduce the problem. Se i problemi non sono riferiti alla Big Picture ma ai specifici Goal/Feature è possibile gestirli in modo più efficace, eventualmente rivedendo le priorità o rimuovendone gli elementi costituenti;
• Address your organization’s culture. Non basta “fare Agile” ma bisogna “essere Agile”, il che significa realizzare un profondo cambiamento culturale e… gestirlo!
• Organize the large team into a collection of smaller teams. Come evidenziato, meglio piccoli team dinamici e collaborativi che un unico grande team burocratizzato.

Quest’ultimo punto nasconde anche un’ulteriore elemento da evidenziare: la revisione dell’assegnazione dei bonus e premi aziendali. Nell’approccio tradizionale, le aziende sono portate a riconoscere un bonus maggiore ai manager che gestiscono un numero maggiore di persone e team grandi. Bisogna quindi rivedere questa politica seguendo, ad esempio, un’assegnazione “Achieved Goal based” o “Aware Contribution”.

Ma come costituiamo il nostro PgMO?

Come sempre nessuna soluzione è universalmente corretta, anche se un valido approccio è quello di creare una board composta dai singoli Product Owner responsabili dei sotto-prodotti (indicando con sotto-prodotti la suddivisione Goal-Driven del sistema complessivo) che più o meno democraticamente eleggono il “Chief”, anche a rotazione.

 PgMO board

Si tratta di una scelta tutto sommato “naturale”: essendo il PgMO un gruppo di coordinamento ed allineamento, chi meglio dei singoli Product Owner possono renderlo efficace, avendo, per ognuno dei propri team, la relativa visione d’insieme di quanto realizzato e dove bisogna spingersi.

Questo anche in relazione alle principali attività di cui il PgMO si occupa: Allocate work, Prioritize work, Organize teams, Coordinate teams, Coordinate Schedules, Scheduling solution releases, Negotiate functional dependencies, Negotiate technical dependencies e Govern the program. In pratica lo stesso diventando un po’ il nodo centrale di una fitta rete di relazioni tra le diverse funzioni aziendali, definito da DA2 come Program Mangement External Workflow, con “external” ad indicare la non diretta appartenenza all’ambito IT.

Program Management External Workflow

In sintesi, è utile sottolineare come la funzione di PgMO è una funzione cruciale per il successo di prodotti complessi e di ampie dimensioni, mitigando il rischio di fallimento e creando un centro nevralgico di coordinamento che aumenta sensibilmente le opportunità di successo nelle proprie iniziative di business.

Stay Tuned!