How agility manages complexity. Presentation on how Agility, and Enterprise Agile like SAFe®, as a way to manage IT and Enterprise Complexity.

1. #SAFeDT
Agility to manage IT Complexity
Etienne Laverdière, SPC4, DA, CSP
Agile Coach, Digital Tango Ltd.
www.digitaltango.ca@2016 DigitalTango

2. #SAFeDT
Agile Coach (2013 --)
• ING Bank (Paris)
• Banque Populaire (Nantes, Paris)
• Intact Insurance (Montreal, Toronto)
Agile Project Manager (2009 - 2012)
• National Bank of Canada (Montreal)
• SFR (Paris)
Team lead, development, architecture
(1998 - 2008)
• Société Générale (Paris)
• Desjardins Securities (Montreal)
• Compuware
• BCE Emergis
• Bell Actimedia
2
ETIENNE LAVERDIÈRE
SPC4, DA, CSM, CSP,
ICP-ACC, ICP-ATF,
PMP, PMI-ACP
@elaverdi
Digital Tango Ltd.
www.digitaltango.ca
info@digitaltango.ca
2

3. #SAFeDT
IT Complexity
Common understanding of Agility in IT:
Our agenda:
• What is IT Complexity?
• How Agility manages complex domain?
• How can we scale Agility to IT and to the
whole Enterprise ?
3
[We] identified a new primary challenge:
complexity. Today’s complexity is only
expected to rise, and more than half of CEOs
doubt their ability to manage it.
2010, IBM Capitalizing on Complexity
« Agility is only for small projects,
not for big ones… »

4. #SAFeDT
IT Complexity
4

5. #SAFeDT
Strategic Importance, Political
Implications, Stakeholders
Level of Change
Risks, Dependencies, and
External Constraints
Level of IT
Complexity
Urgency and Flexibility
Size / Time / Cost Clarity of Problem
IT Project Complexity
5
Katheen Hass, Project Complexity Model, 2013
Harvard Business Review, Smart Rules: Six Ways to Get People to Solve Problems Without You, 2011

6. #SAFeDT
Strategic Importance, Political
Implications, Stakeholders
Level of Change
Risks, Dependencies, and
External Constraints
Level of IT
Complexity
Urgency and Flexibility
Size / Time / Cost Clarity of Problem
IT Project Complexity
6
Katheen Hass, Project Complexity Model, 2013
Harvard Business Review, Smart Rules: Six Ways to Get People to Solve Problems Without You, 2011
Enterprise “complicatedness” increased by 6.7%
a year, on average, over the past five decades.

7. #SAFeDT
Knowledge Gap
• What are the objectives? What
does the client really wants /
needs?
Alignment Gap
• How to align team’s actions?
Control on Outcomes Gap
• How to be sure that team’s
actions are generating the
wanted result.
7
Knowledge
Alignment
Control on
Outcomes
2010, Stephen Bungay, The Art of Action
Complexity impact on IT Projects

8. #SAFeDT
Pmbok: Planning
Analysis
Architecture
Fixed-price contract
Penalties
Knowledge
Alignment
Control on
Outcomes
Pmbok: Planning, Execution
Plan, Task-driven
Detail
Complication
8
Pmbok: Monitoring&Control
Reports
KPI
Sign-off, status
Traditional Complexity Management

9. #SAFeDT
Pmbok: Planning, Execution
Plan, Task-driven
Detail
Complication
More Locks
Pmbok: Planning
Analysis
Architecture
Fixed-price contract
Penalties
Knowledge
Alignment
Control on
Outcomes
9
Pmbok: Monitoring&Control
Reports
KPI
Sign-off, status
Traditional Complexity Management

10. #SAFeDT
Agile Complexity Management
10
Knowledge
Alignment
Control on
Outcomes
Internal Discipline
Autonomy, Innovation
Empowerment
Collaboration, Creation
More Adaptation
Impact & goals, Value driven
Cadence & Synchronization,
Principles & Simplification
Contextualized Vision
More Flow
Focus on what we know (empirism)
Speed and frequency
Strategic vision
Sprint review
Team Retrospective

11. #SAFeDT
① You build it, you run it.
② All teams will expose their data and functionality through service interfaces. Teams
must communicate with each other through these interfaces.
③ There will be no other form of interprocess communication allowed (no direct
linking, no shared-memory model, no back-doors whatsoever).
④ It doesn't matter what technology they use.
⑤ All service interfaces, without exception, must be designed from the ground up to
be externalizable. That is to say, the team must plan and design to be able to
expose the interface to developers in the outside world. No exceptions.
⑥ Anyone who doesn't do this will be fired. Thank you; have a nice day
Enterprise Architecture Principles defined by
Amazon CEO Jeff Bezos (2002) :
11
Using Principles as Alignment Enabler

12. #SAFeDT
① You build it, you run it.
② All teams will expose their data and functionality through service interfaces. Teams
must communicate with each other through these interfaces.
③ There will be no other form of interprocess communication allowed (no direct
linking, no shared-memory model, no back-doors whatsoever).
④ It doesn't matter what technology they use.
⑤ All service interfaces, without exception, must be designed from the ground up to
be externalizable. That is to say, the team must plan and design to be able to
expose the interface to developers in the outside world. No exceptions.
⑥ Anyone who doesn't do this will be fired. Thank you; have a nice day
Enterprise Architecture Principles defined by
Amazon CEO Jeff Bezos (2002) :
12
Using Principles as Alignment Enabler

13. #SAFeDT
AlignmentKnowledge
Control on
Outcomes
Responding to change over
following a plan
Individuals and interactions over
processes and tools
Working software over
comprehensive documentation
Customer collaboration over
contract negotiation
13
That is, while there is value in the items on the right,
we value the items on the left more.
A
C
K
A
A

14. #SAFeDT
(6) face-to-face conversation
(7) Working software is the
primary measure of progress
(8) Agile processes promote
sustainable development
(9) Continuous attention to technical
excellence and good design enhances agility
(10) Simplicity--the art of maximizing
the amount of work not done--is
essential
(11) The best architectures, requirements, and
designs emerge from self-organizing teams.
(12) At regular intervals, the team reflects on how
to become more effective, then tunes and
adjusts its behavior accordingly.
(2) Welcome changing requirements
(4) Business people and developers must work
together daily throughout the project
(5) Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
(1) satisfy the customer through early and
continuous delivery of valuable software
(3) Deliver working software frequently, from a
couple of weeks to a couple of months
14
Conway, 1968, « Organizations which design systems are constrained to produce designs which are
copies of the communication structures of these organizations. »
PRODUCT
TEAM
AlignmentKnowledge
Control on
Outcomes

15. #SAFeDT 15
* Katheen Haas, Project Complexity Model, 2013
Traditional Roles Scrum Roles
Project Manager: Focus on Project
Management. Tasks, execution, completion,
Dependencies, Plan.
Scrum Master : Focus on team complexity,
Empowerment, Predictability, Mastery, Discipline and
autonomy.
Business Analyst: Focus on requirements,
Details, Exhaustiveness, Sign-Off, Validation.
Product Owner : Focus on Product Complexity,
Solution Intent, Strategy, Innovation and Value.
Gap Traditional Methodology Agile Approach
Knowledge Exhautivity & predictability Focus, Empirical knowledge & Iterative process
Alignment Plan conformity Adapt plan to change
Alignment Top-down solution The solution is an emergent process
Alignment Fixed-organization, like a machine
processing information
Learning organization, the team structure is
also emergent
Control Execution and control are task-based Execution and control are value-based
Control External control Team Internal control
*
Traditional vs Agile

16. #SAFeDT
Enterprise Agility
16

17. #SAFeDT
Enterprise Agility
17
Focus on Product
complexity
Focus on Product and
Team complexity
Enterprise Agility includes
enteprise concerns like Portfolio
management, Governance,
Enterprise Architecture and Team
Alignment.

18. #SAFeDT
Enterprise Agility challenges
18
How to keep team agility in a large
structure?
Which enterprise agility framework
should we adopt?
How to change the development process
and framework while respecting
organizational culture?
Scrum relies on self-commitment, self-organization, and
emergence rather than authoritarian measures.
—Ken Schwaber

19. #SAFeDT 19
Some reason to move
toward an Agile@Scale
Framework
• Number of team and
dependencies
• Coupled architecture
• Portfolio management
• Traditional – Agile
interface hard to manage
• Stakeholders management
• Get out of the
WaterScrumFall model
• Start an enterprise agile
roadmap
Agile Scaling Knowledge base: http://www.agilescaling.org/ask-matrix.html
SoS
2001
LeSS
2013
Spotify
2012
Nexus
2015
Scrum
At Scale
2014
Low, Prescriptive High, Emergeant
Flexibility
Coverage
teamsProgramPortfolio/Enterprise
DAD
2012
SAFe
2012
Low
Adoption
High
Medium
Agile @ Scale Offering

20. #SAFeDT
Put brutally SAFe seemed to be PRINCE II camouflaged in
Agile language. SCRUM as an approach was emasculated
in a small box to the bottom right of a hugely
overcomplicated linear model. (…) SAFe is not only a
betrayal of the promise offered by AGILE but is a massive
retrograde step giving the managerial class an excuse to
avoid any significant change.
[A Body of knowledge] is an highly static non-adaptive
approach.
Dave Snowden (Cynefin)
SAFe
20
I saw a Release Planning session with 20-some teams
and almost 200 people, and realized how SAFe is
Scrum, just expanded to the program level. I became
aware that Scrum itself scales beautifully.
Lyssa Adkins (Coaching Agile Teams)
SAFe gives us some good ideas for how to deal with
[enterprise] complexities where few existed before. I
am using some elements of SAFe with a client right
now but not all since some of the techniques would
not work well, which is consistent with a “pragmatic
agile” approach.
Mark Lines (DAD)
The boys from RUP (Rational Unified Process) are back.
Building on the profound failure of RUP, they are now
pushing the Scaled Agile Framework (e) as a simple, one-
size fits all approach to the agile organization.
Ken Schwaber (Scrum)
Quoting Martin Fowler

21. #SAFeDT
Respect of Culture, roles and
traditional responsibilities
• « Start where you are; go where you want »
• Less radical than « fractal agile »
• Allows real change of habits
Instills industry best practices
• Lean / Agile / Scrum / XP / Kanban
• Devops & Agile Testing
• Agile Budgeting
• Value Stream coordination
• Cost of Delay
• Principles of Product Development Flow
Gives you the help you need
• PO, SM, PPM trainings
• SP, SA, SPC, SPCT Certifications
• Tools : Rally, Blue-Agility, JIRA, Microsoft
• Real success stories on SAFe transformation
21
Why SAFe?
2016

22. #SAFeDT 2222

23. #SAFeDT
Complexity management with SAFe
23
 Portfolio
 Executive Support
 Governance
 Budget
 Knowledge
 Focus
 Program
 Alignment
 Synchronization
 Teams
 Self-Orgarnized
 Autonomous
 Empowered
 Control on Outcomes

24. #SAFeDT 24
Knowledge
Alignment
Control on
Outcomes
Frequency and rapidity
Focus (WIP)
DevOps
Portfolio and ART Metrics
System Demo
Program Increment
Release
Inspect & Adapt
System Team
Knowledge

25. #SAFeDT
Alignment
25
Scrum of Scrums
Scrum of Pos
Release Planning
Vision
PI Objectives
Architecture Runway
Knowledge
Alignment
Control on
Outcomes

26. #SAFeDT
Control on Outcomes
26
Autonomy
Disciplined agility
Collaboration
PI Planning
Creativity
Innovation
Mastery
Knowledge
Alignment
Control on
Outcomes

27. #SAFeDT
The larger coverage of SAFe and
its prescriptive approach are well
adapted to large enterprises
• It will secure sponsors
• Extend agility to a Lean/Agile
approach
• Doesn’t limits framework
customization.
The apparent linear structure of
SAFe enables better alignment
and greater team autonomy.
SAFe training and certification
paths enable alignment among
change agents and the whole
enterprise.
27
Start as soon as possible to
work on your development
toolkit:
• JIRA, Rally, etc
• Continuous Integration
• Test Automation
Organizational culture must
also be addressed
• SAFe is not a new RUP
• SAFe implies a cultural
change.
Get trained, aligned and
experienced coaches
Final thoughts

28. #atmtl2015 #rexsafe-atmtl2015
Your Digital Partner
28
Question?
info@digitaltango.ca