This document discusses principles for reducing organizational complexity at scale. It argues that complexity is the main cause of dysfunction in large organizations and must be reduced. It provides examples of how complexity negatively impacts organizations with thousands of employees across multiple sites. The document then outlines several principles for product development organizations to reduce accidental complexity, including: having end-to-end product teams rather than component-based teams, minimizing product components, focusing on factors that drive product complexity, and establishing minimum viable product owners. It advocates for building a learning organization where teams have both technical and business domain accountability.

1. ConneXo
X
Vuoi più agilità?
Riduci la complessità (organizzativa)
Pierluigi Pugliese
© 2023 Connexxo GmbH, based on ScaleAgility © 2023 by The ScaleAgility Group, licensed under CC BY-SA 4.0.

2. c
e
r
t
i
fi
e
d
s
c
r
u
m
t
r
a
i
n
e
r
certified less practitioner
s
y
s
t
e
m
i
c
s
t
r
u
c
t
u
r
a
l
c
o
n
s
t
e
l
l
a
t
i
o
n
s
coach, dvct
t
r
a
i
n
e
r
pmi project manager professional
s
p
e
a
k
e
r
coach
certified scrum professional
certified scrum master
dott. ing. (electronics)
embedded systems
social panorama
solution focus
e-commerce
certified agile leadership
scrum coach
trainer inlpta
media
blogger
telecom
Pierluigi Pugliese

3. ScaleAgility: Principles Over Frameworks for Agility at Scale
Jan B. Olsen
Denmark, CTC […]
Matt Roadnight
England, CST […]
Colin Bird
England, CST […]
Pierluigi Pugliese
Germany, CST […]
Simon Roberts
Scotland, CST […]

4. TCConsult
TCConsult
TCConsult
TCConsult
Aziende e Complessità

5. Cominciamo da un team…

6. Su larga scala…
“Product
Development
Organisation”

7. • E troppo grande e complesso
• I nostri dipartimenti sono organizzati diversamente
• Non si può cambiare l’organizzazione
• Siamo organizzati su troppi siti
• La nostra architettura è troppo complessa
• …
Ma…
😬
😭
😢
😤
😵💫

8. Alcuni esempi: prodotti su larga scala
#persone #siti note
250 3
110 1 con tecnologie arcaiche!
500 2 hw, sw, meccanica, x, y, z, …
2000 13 non ho parole…

9. Due aziende, stesso prodotto
#persone
tempi di risposta
(per showstopper,
giorni)
soddisfazione
del cliente
A 1100 27 - - -
B 200 1-2 + + +

10. Complessità
In grandi aziende: CA >>> CE
Essenziale →CE
Accidentale →CA
- Frederick P. Brooks, The Mythical Man-Month, Anniversary edition with 4 new chapters, Addison-Wesley (1995)
- Proceeding of the IFIP Tenth World Computing Conference, H.-J. Kugler, ed., Elsevier Science B.V.,
Amsterdam, NL (1986) pp. 1069-76

11. Strumenti,
Processi
Architettura
Cliente
(vuole...)
Cliente
[utilizzato da
qualche altra parte
dell'azienda...]
qualcosa che
arriva da un
fornitore
Cliente
Prodotto
Servizio, ...
Prodotto
Servizio, ...
Cliente
(vuole...)
Cliente
(vuole...)
Complessità Accidentale in azione
Teams
Product
Owners/
Managers/...
“Composite
Value Stream”
Confini di
dipartimento
Dip. 1 Dip. 2
Dip. 3
Dip. 4
Dip. 5
Dip. 6
Lingue, Culture

12. Il motivo principale di disfunzionalità in azienda:
Complessità
Accidentale
Dobbiamo ridurla!
Ed è compito della leadership!!!

13. TCConsult
TCConsult
TCConsult
TCConsult
Alcune idee: Prodotto

14. Principio 1: End-to-End Product!
Su larga scala…
“Product
Development
Organisation”

15. Principio 2:
Evitate
Componenti
Se non fosse possibile…

16. Principio 3: Lavorare
sui fattori che contribuiscono
alla complessità del prodotto
Se non fosse possibile…
Constraint Dimensions • fattori umani
• politica interna
• strutture organizzative
• # tecnologie
• eccellenza tecnica
• dimensione prodotto
• complessità del value stream

17. Utilizzare le Constraint Dimensions
Complexity
Difficulty in addressing it
⦿ Technological
⦿ Company Structure
⦿ Internal Politics
⦿ Human Factors
⦿ Value Stream Complexity
⦿ Product Size
⦿ Technical

18. Workshop evoluzione di prodotto
Improve
End-To-End Product
Improve
Business Synergies
Improve
Avoid organising
teams on
components
Specialisation (if any):
Codec
Team
Specialisation (if any):
IOS
Team
Specialisation (if any):
Android
Team
Specialisation (if any):
Web
Output
Description
Team
Specialisation (if any):
Windows
Desktop
Work
Description
Team
Specialisation (if any):
Backend
Work
Description
Team
Team
Specialisation (if any):
Database
Team
Specialisation (if any):
Acceptance
Testing
Team
Specialisation (if any):
Performance
Testing
Team
Specialisation (if any):
Integration
Team
Specialisation (if any):
Requirements
Work
Description Internal Product
Description
Deliverable Product
Description
Output
Description
Output
Description
Output
Description
Output
Description
Output Description
Work
Description
Work
Description
Work
Description
Work
Description
Work
Description
Team
Specialisation (if any):
Visual
Design
W
o
r
k
D
e
s
c
r
ip
t
io
n
Document Output
Description
Work
Packages for
the Teams
Nat Cos
(UK, GEr,
Hun)
Security/
Data Prot
SVPs Biz
Units
Output
Description
Improve
End-To-End Product
Improve
End-To-End Product Improve
End-To-End Product
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve avoid
organising teams on
components
Improve Business
Synergies
Remove the hand over
of documented work
packages as it cause
product quality isess to
to lack of clarity
A team has all the skills
(one of .. Windows,
Desktop, Web, Android,
IOS) to integrate and
acceptance test their work
Improve inconsistent
journeys across different
product end points
(Windows, IOS, Android,
Web)
Bring together UI
specialists with database
and backend specialists
in the same team
Bring together UI
specialists with database
and backend specialists
in the same team
A team has all the skills
(one of .. Windows,
Desktop, Web, Android,
IOS) to integrate and
acceptance test their work
Many business stakeholder
requests are taken across
different end consumer
products (IoS, Android, Web,
Windows) causing priority
clashes
Improve clarity of
requirements between
different stakeholder
that have differing views
Bring requirements
and visual design
specialists into the
the same team

19. TCConsult
TCConsult
TCConsult
TCConsult
Alcune idee: Product Owner

20. Importante!
Principio 4:
MinimumViable Product Owners
È più facile
aggiungere un ruolo
che toglierne uno!

21. TCConsult
TCConsult
TCConsult
TCConsult
Alcune idee:Team

22. Principio 5: Learning Organisation
• Aumentare le conoscenze di dominio
• tecnico
• business
Tech. Domain Accountability
Business Domain Accountability
Peter Senge
business-analisi-design-implementazione(x,y,z)-testing-operations

23. Verso l’Organizzazione “End-to-End”
lity
ples for
ScaleAgility
Towards: End-to-end Organisation
Towards: End-to-end Product
Towards: End-to-end Product Ownership
Craft
Towards: End-to-end Teams
Teams Coordination and Learning
Progressive
Enablement
Leadership provide Vision,
Guidance, grow Capabilities,
Resources, Role models of a
Learning Organisation
Iterate!
The Definition of Product
identifies and enables the
structural changes needed
in the organisation
Technical Excellence,
Coordination structures and
Learning culture enable high-
performing, product-focused
Teams
Synergies
Constraints
Progressive
Enablement

24. Domande?
24
Prossimi Meetup
su questi temi
Blog

25. https://connexxo.com
ConneXo
X
ppugliese@connexxo.com
` https://scaleagility.org