1. Agile@Scale: Portfolio Level
13 – 14 Ottobre 2014
Portfolio Management
Felice Pescatore

2. Agile@Scale: Portfolio Level2
get in touch
ABOUT ME
felice.pescatore@gmail.com
Agile Coach – Agile Enterprise Architect
Microsoft MVP Visual Studio ALM
GetLatestVersion.it il primo sito in
italiano sull'Application Lifecycle
Management
felicepescatore.it
@felicepescatore
Felice Pescatore
Disciplined Agile Delivery Italy Group

3. Agile@Scale: Portfolio Level3
… we will talk about…
Agenda
Holistic Vision
Value Innovation
Portfolio
Portfolio Management and Portfolio Strategies
From Portfolio to Product
Agile@Scale holistic framework

4. Agile@Scale: Portfolio Level4
Storytelling: Jelly Monster… il clone di Pac Man
«Sai che Atari ci farà causa perché
detengono i diritti di
commercializzazione di Pac Man negli
USA?»
MichaelS.Tomczyk
VIC20 development and marketing
«Va bene. Metteremo una royalty in
garanzia e quando ci faranno causa, gli
pagheremo la royalty e smetteremo di
produrre il gioco, ma nel frattempo ne
avremo venduti un milione.»
JackTramiel
COMMODORE founder and CEO
Vendite del VIC20
con Jelly Monster
Royalties e costi legali Profitto e posizionamento
da leader sul mercato
Tomczyk aveva ragione: Atari fece causa a Commodore e la costrinse a ritirare il clone,
ma... Tramiel aveva più ragione di lui!!!

5. Agile@Scale: Portfolio Level5
Holistic Vision

6. Agile@Scale: Portfolio Level6
The Idea, the Build, the Environment
• Creare il Program Backlog (Feature), Creare i Team Backlog (User Story), Identificare i PSI
(Potential Shippable Increment), ….
Program Level & Inception
• Prendere in carico il Team Backlog, Definire le iterazioni in relazione ai PSI, Definire i Task,
Scegliere le pratiche da utilizzare, …
Team Level & Construction
• Completato lo sviluppo, il sistema deve essere manutenuto in erogazione e fruibile correttamente da
client di tipologia diversa (anche molto!)
Program Level & Transition
Aggredire il mercato con una nuova idea
• Generata dall’esigenza, Pensata per creare un’esigenza
• Chi finanzia il progetto? Quali sono i rischi? Di quante persone ho bisogno? Quanti
Team? Dove avvengono le attività? Quali sono le tecnologie di supporto?, ...
• Riorganizzare (creare se non presente) il Product Backlog
Portfolio & Inception

7. Agile@Scale: Portfolio Level7
Value Innovation: Red Ocean Strategy & Blue Ocean Strategy
Compete in existing market space
Beat the competition
Exploit existing demand
Make the value-cost trade-off
Align the whole system of a firm’s Activities with
it’s strategic choice of differentiation or low cost
Defend Current Position
Compete in existing market space
Make the competition irrelevant
Create and capture new demand
Break the value-cost trade off
Align the whole system of a firm’s activities with
pursuit of difference and low cost
Innovate and Pursue new Opportunities
Kim&Mauborgne

8. Agile@Scale: Portfolio Level8
Portfolio, Program and Project
KevinThompson,cPrime’sR.A.G.E.
A PORTFOLIO “is a collection of programs or projects and other work
grouped together to facilitate effective management in order to meet
strategic business objectives”.
A PROGRAM can be defined as “multiple related projects that
are managed in a coordinated fashion”.
A PROJECT is “a temporary endeavor undertaken to
complete a unique product, service, or result”.

9. Agile@Scale: Portfolio Level9
The Uncertainty of the Fourth Management Quadrant
BUSINESS
ProgramProductManagementPortfolioManagement
OPERATIVE
TeamManagementHolisticManagement

10. Agile@Scale: Portfolio Level10
Not “The One”, but “Collaborative Management”
flat structure
fourth quadrant
portofolio
product
team
program

11. Agile@Scale: Portfolio Level11
• Optimizing the holistic portfolio over protecting departmental budgets
• Courage to change over following a plan
• Ability to evaluate the portfolio on a frequent basis over infrequent (i.e. annual) planning cycles
• Responding to emerging opportunities over sticking to the plan
• Maximizing value over managing cost
• Collaborating on decisions over centralized authority
Scrum Coach Retreat, December 2011
Adaptive Portfolio Credo: We Value...
http://wiki.scrumcoachretreat.com/Adaptive_Portfolio_Management
Certified Scrum Coaches

12. Agile@Scale: Portfolio Level12
• Apply a consistent calculation to determine business value
• Apply a common estimation methodology to portfolio initiatives
• Apply a clear definition of enterprise risk
• Limit portfolio work in process (WIP) to optimize ROI, IRR, and organizational liquidity
• Employ smaller projects to reduce risk, shorten time-to-market, minimize budget commitments, and increase portfolio diversity
• Develop a clear portfolio vision to create alignment across business units
• Ensure visibility of portfolio priorities and programs' status across the enterprise
• Generate and prioritize a holistic portfolio through frequent face-to-face communication and collaboration across the organization
• Periodically re-allocate funds from lower value initiatives to higher value initiatives
• Frequently review the portfolio to:
• Enable rapid course corrections
• Allow the organization to identify and harness changes that will result in the highest value
• Maintain flexibility to quickly take advantage of emerging market opportunities
Adaptive Portfolio Credo: We follow these principles…

13. Agile@Scale: Portfolio Level13
Road to Portfolio Backlog: Portfolio Backlog Grooming
Company Roles
• Senior executives
• Senior solution managers
• Line-of-Business owners
• CTO
• Senior Solution Architect
• Chief Product Owner
• Senior Development Managers
• Program Management Director
Knowledge around
• market knowledge
• technology awareness
• understanding of financial constrains
understanding of market conditionsStrategy Process

14. Agile@Scale: Portfolio Level14
ROI (VALUE) Optimization
Road to Portfolio Backlog: Process Strategy Planning and Canvas
RED OCEAN
PRESENT SYSTEM/EXPERIENCE
(Where currently are we?)
Business Model Mapping
Strategic Tool
Business Model Canvas
BLUE OCEAN
(Where must we go?)
Short/Medium/Long-‐term
Tactical Tool
Lean Canvas
FUTURE PRODUCT / OPPORTUNITY
PAORTFOLIO MANAGEMENT STRATEGIES

15. Agile@Scale: Portfolio Level15
Portfolio Planning: Strategy Planning, scheduling
Trattandosi di un planning che viene
rivisto costantemente, l’importante è
raggiungere un’opportuna accuratezza
e non inseguire una presunta
precisione che spesso si rivela non
corretta e porta solo allo spreco di
tempo (waste).
Lifecycle Profit
Quali sono i KPI (Key Performance
Indicator) di riferimento che
consentono di massimizzare il profitto
del Portfolio Backlog?
Accuracy, not precision Cost of Delay
Nella scelta della priorizzazione del
Portfolio Backlog è fondamentale
considerare il margine finanziario
perso a causa del ritardo di immissione
sul mercato del singolo prodotto.
Approve the Product: balance the choice

16. Agile@Scale: Portfolio Level16
Strategy Planning: scheduling, cost-of-delay
Progetto A Progetto B
Investimento 100.000€ 100.000€
ROI 20% (20.000€) 15% (15.000€)
Tempo di realizzazione 6mesi 6mesi
Quale progetto realizzereste per primo,
sapendo che non è possibile avviarli
parallelamente ma a distanza solo a distanza di
un mese l’uno dall’altro (ad es: attesa
formalizzazione assunzione nuove risorse)?
Start Delayed
Project Revenue Project Revenue Totale
T0 Progetto A 20.000€ Progetto B -5.000€ 15.000€
T1 Progetto B 15.000€ Progetto A 15.000€ 30.000€
Cost of Delay (1 mese) 5.000€ 20.000€ e ora?
Il CoD viene raramente preso in considerazioni dal management aziendale (da alcune indagini risulta che
stento si sfiora il 15%). Si tratta però di una delle metriche più importanti per gestire proficuamente il
Portfolio Backlog, evidenziando la dipendenza diretta del ROI dal fattore «tempo».
A T0 non ha senso avviare
il progetto B

17. Agile@Scale: Portfolio Level17
Strategy Planning: scheduling, cost-of-delay KPI & Profiles
Il Cost-of-Delay è difficile da stimare:
• utilizzare specifici KPI: User Value + Time Value + Risk Value;
• utilizzare «profili» di riferimento in cui inquadrare i nostri progetti.
Profilo Descrizione
Lineare Il CoD aumenta linearmente in funzione del
tempo
Large fixed cost Si tratta di un prodotto che genera un CoD alto
nell’immediato se non avviato prontamente.
Must do now Il prodotto deve essere realizzato adesso, pena
la perdita consistente e continua di Valore.
Fixed date Si tratta di un prodotto che deve essere
rilasciato ad una data prefissata. Finché la data
non viene raggiunta non vi è alcun CoD, ma al
suo raggiungimento un eventuale ritardo genera
l’intero CoD all’istante.
Logarithmic In questo caso il CoD è concentrando in gran
parte all’inizio per poi crescere con poca
incidenza nel seguito.
Intangible Si tratta di un prodotto il cui CoD non è
inizialmente visibile ma che poi, all’improvviso,
fa sentire tutti i suoi effetti.

18. Agile@Scale: Portfolio Level18
Strategy Planning : scheduling, lifecycle profit
Cost of Delay (CoD) Tempo di Sviluppo/ Dimensione Scheduling
Simile Significativamente differente Prodotto che richiede minor tempo
Significativamente differente Simile Prodotto che ha il maggior CoD
Significativamente Differente Significativamente Differente Weighted Shortest Job First (WSJF)
*I KPI del CoD sono calcolati sfruttando la sequenza di Fibonacci a valore crescente
Cost of Delay*
User Value Time
Criticality
Risk Reduction
Opportunity
Value
Totale Job Size
/Effort
WSJF
(Tot/Effort)
Feature A 3 13 8 24 5 4.8
Feature B 8 5 3 16 8 2
Feature C 5 8 5 18 5 3.6
Obiettivo: realizzare prima i progetti con CoD maggiore, tenendo però conto della dimensione del progetto stesso.
Questo perché più è lungo il progetto meno le stime effettuate (compreso il CoD stesso) sono accurate.
W
S
J
F
PROJECT
SCHEDULING

19. Agile@Scale: Portfolio Level19
Strategy Planning: scheduling, accuracy - not precision
Size/Effort Intervallo di costo approssimativo
Extra-small (XS) $10K to $25K
Small (S) $25K to $50K
Medium (M) $50K to $125K
Large (L) 125K to $350K
Extra-large (XL) >$350K

20. Agile@Scale: Portfolio Level20
Portfolio Planning: Strategy Planning, inflows
Gestire il Product Backlog in
modo dinamico, così da
avere una serie di prodotti
che è possibile rimuovere
laddove si presentino nuove
opportunità di mercato.
Economic Filter Arrival Rate Emergent Opportunity Smaller, more frequent
releases
Go/non-Go: si tratta di
decidere quando il prodotto
rientra effettivamente nei
piani economici aziendali,
superando i vincoli imposti da
un «filtro economico» di
riferimento.
Bilanciare il numero di
prodotti che «escono»
(approvati/esclusi) dal Product
Backlog e quelli che
«entrano».
Piuttosto che avere nel
Product Backlog un unico
grande progetto, è meglio
ragionare in termini di
Minimal Marketable
Product (MMP) e pensare a
più rilasci incrementali.
Approve the Product, knowledge data: the «what» question

21. Agile@Scale: Portfolio Level21
Strategy Planning: inflow, chose the right products
Dopo un’analisi preliminare del ROI associato ad un
prodotto, è fondamentale verificare se esso supera i «filtro
economico» di riferimento, in modo che sia allineato con i
requisiti minimi per considerarlo vantaggioso ed inserirlo
(go) nel Portfolio Backlog.
In caso contrario il progetto va scartato (no-go).
Se il prodotto supera il «filtro economico», viene inserito nel Product Backlog.
Tale operazione va fatta bilanciando il numero di soluzioni presenti in esso, in modo da
massimizzare l’efficienza aziendale, senza andare in oversize e comprometterne l’efficacia
dell’attività aziendale stessa:
• Troppi prodotti si trasformano in spreco di risorse di gestione e in un sovraccarico di
attività;
• Pochi prodotti rischiano di rendere sotto utilizzate le unità (risorse) aziendali.

22. Agile@Scale: Portfolio Level22
Strategy Planning: inflow, new opportunities
Una gestione dinamica del Portfolio Backlog predispone il contesto ad una estrema
flessibilità, consentendo di catturare le nuove opportunità di mercato, aggiungendo o
sostituendo (più realisticamente) prodotti esistenti.
In questo caso (Blue Ocean) il tempo di reazione è fondamentale, poiché il Valore e il ROI
associato ad una nuova opportunità decresce velocemente con il passare del tempo ed il
posizionamento relativo dell’azienda (es: innovatore vs inseguitore).
L’adattabilità al mercato è favorita da un approccio «Smaller, more frequent releases», teso a
rilasciare sempre, il prima possibile, un Minimal Marketable Product (MMP), piuttosto che
attendere di avere un unico grande prodotto omni-comprensivo.

23. Agile@Scale: Portfolio Level23
Portfolio Planning: Strategy Planning, outflows
Una efficace gestione del Product
Backlog mira a raggiungere l’ottimo e
non il massimo in assoluto,
considerando gli obiettivi di business,
come, ad esempio, la soddisfazione
degli Stakeholder.
Il cuore operativo di ogni prodotto è il
Team (o i Team), per cui iniziare lo
sviluppo di nuovo prodotto quando non
si ha a disposizione un Team completo
da dedicargli è fortemente
controproducente
Idle Work, not idle workers WIP Limit Complete engaged Team
L’obiettivo di una efficiente gestione
del Product Backlog è quello di
massimizzare il throughput relativo ai
prodotti, non quello del massimo
impiego delle risorse.
Approve the Product, current company engagement: the «when» question

24. Agile@Scale: Portfolio Level24
Strategy Planning: outflow
• ottimizzare il ROI, ovvero il numero di prodotti attualmente in lavorazione. Ciò
non corrisponde all’impiego al 100% della singola risorsa: si pensi alla corsa a
staffetta in cui l’importante è arrivare primi al traguardo con l’ultimo corridore,
non che tutti i corridori vi arrivino.
• limitare i prodotti in essere, raggiungere un opportuno bilanciamento che
garantisca l’ottimo, piuttosto che il massimo lavoro possibile in assoluto,
focalizzandosi sugli obiettivi di business, come, ad esempio la soddisfazione
degli Stakeholder.
• avere a disposizione almeno un Team completo a cui affidare la realizzazione
del prodotto, evitando di avviare il processo quando ho a disposizione solo
parzialmente il Team. Questo, chiaramente, perché il cuore delle attività nel
mondo Agile è l’Agile Team, con tutto ciò che ne consegue. Avviare un nuovo
progetto con un Team «parziale» è controproducente sia in termini
organizzativi che in termini di qualità e ri-organizzazione in funzione del suo
completamento successivo.
La scelta di avviare lo sviluppo di un nuovo prodotto (o di una nuova release) presente del Product
Backlog, è subordinata a tre fattori fondamentali:

25. Agile@Scale: Portfolio Level25
Portfolio Planning: Strategy Planning, marginal economics
Marginal Economics
Il fatto che sia stato speso un solo dollaro sul prodotto non
implica che bisogna continuare obbligatoriamente la sua
realizzazione se nuovi investimenti non sono giustificati.
Ugualmente, metterlo in produzione, è sensato solo se
quanto realizzato è appetibile sul mercato.
Questa strategia si applica ai
prodotti «in process», in modo
da ri-valutare costantemente se
essi sono effettivamente ancora
validi o se sono emersi nuovi
fattori che ne mettono in
dubbio le revenue associate.
Refinance a Product: the «when» question

26. Agile@Scale: Portfolio Level26
Road to Product Backlog: The Product Canvas and the Product
Backlog Grooming Process

27. Agile@Scale: Portfolio Level27
the road ahead

28. Agile@Scale: Portfolio Level28
• Framework maturo per l’adozione di
pratiche Agili all’interno di contesti
Enterprise
• In grado di gestire, con successo, un
ampio numero di «Agilisti» e di Team
• Costruito sui principi delle
metodologie Agile@Core e Lean
• Sincronizzazione tra sviluppo e
delivery
Grazie alla «Big Picture» è possibile
evidenziare le relazioni ed i ruoli dei vari
attori aziendali che concorrono al processo
Agile@Scale, unitamente agli artefatti e le
cerimonie di riferimento
SAFe, Scaled Agile FrameworkAgileReleaseTrains:ValueStream

29. Agile@Scale: Portfolio Level29
SAFe, Portfolio Vision…
• Centralized strategy, decentralized execution
• Investment themes provide operating budgets for release trains
• Business and architectural epic kanban systems provide visibility and work-in-process limits for product
Enterprise architecture is a first class citizen
• Objective metrics support governance and kaizen
• Value description via Business and Architectural Epics

30. Agile@Scale: Portfolio Level30
• Framework per lo sviluppo di soluzioni
End-to-End con ampia libertà di
personalizzazione
• Costruito sui principi delle metodologie
Agile@Core e Lean
• Scalabile, people-first oriented,
learning oriented, goal-driven,
enterprise aware, risk and value driven
• Linee guida per la governance di team
enterprise secondo le best-guide Agili
Grazie alla «Big Picture» è possibile evidenziare le fasi di sviluppo di una soluzione end-to-end
in ambito enterprise secondo i principi Agili.
DAD è un framework ibrido, Value & Risk driven, fortemente orientano alle persone e al loro
apprendimento, il tutto con la finalità di produrre in modo ottimale il delivery della soluzione.
I
C
T
Inception
Construction
Transition
DAD, Disciplined Agile Delivery

31. Agile@Scale: Portfolio Level31

32. Agile@Scale: Portfolio Level32Quest'opera è distribuita con Licenza Creative Commons Attribuzione - Non commerciale 3.0 Italia.