Agility to manage IT Complexity
-
Upload
etienne-laverdiere -
Category
Business
-
view
614 -
download
2
Transcript of Agility to manage IT Complexity
#SAFeDT
Agility to manage IT Complexity
Etienne Laverdière, SPC4, DA, CSP
Agile Coach, Digital Tango Ltd.
www.digitaltango.ca @2016 DigitalTango
#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 [email protected]
2
#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… »
#SAFeDT
IT Complexity
4
#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
#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.
#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
#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
#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
#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
#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
#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
#SAFeDT
Alignment Knowledge 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
#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
Alignment Knowledge Control on Outcomes
#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
#SAFeDT
Enterprise Agility
16
#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.
#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
#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
Co
vera
ge
tea
ms
Pro
gra
m
Port
folio
/ E
nte
rpri
se
DAD 2012
SAFe 2012
Low
Adoption
High
Medium
Agile @ Scale Offering
#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 20some 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
#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
#SAFeDT 22 22
#SAFeDT
Complexity management with SAFe
23
Portfolio
Executive Support
Governance
Budget
Knowledge
Focus
Program
Alignment
Synchronization
Teams
Self-Orgarnized
Autonomous
Empowered
Control on Outcomes
#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
#SAFeDT
Alignment
25
Scrum of Scrums Scrum of Pos Release Planning Vision PI Objectives Architecture Runway
Knowledge
Alignment Control on Outcomes
#SAFeDT
Control on Outcomes
26
Autonomy Disciplined agility Collaboration PI Planning Creativity Innovation Mastery
Knowledge
Alignment Control on Outcomes
#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