An Introduction to Scaled Agile Framework (SAFe)

An Introduction to
Scaled Agile Framework
(SAFe)
James Chan
Agile Management
CA Technologies
Director, ITBM Technical Sales
AMX10E
Michelle Templeton
CA Technologies
Senior Principal Consultant, ITBM Technical Sales

2 © 2015 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD
For Informational Purposes Only
© 2015 CA. All rights reserved. All trademarks referenced herein belong to their respective companies.
The content provided in this CA World 2015 presentation is intended for informational purposes only and does not form any type of
warranty. The information provided by a CA partner and/or CA customer has not been reviewed for accuracy by CA.
Terms of this Presentation

Abstract
To compete in today’s application economy,
organizations have adopted agile execution
techniques. But is that enough? Learn about
SAFe and how to leverage this methodology to
elevate your agile teams to deliver quality
outcomes and align at the enterprise level.
James Chan
CA Technologies
Director, ITBM
Technical Sales

Agenda
THE APPLICATION ECONOMY AS A DISRUPTER
FOUNDATIONAL PRINCIPLES OF SCALED AGILE FRAMEWORK
INTRODUCING THE SCALED AGILE FRAMEWORK
GETTING A FEEL FOR RELEASE PLANNING
1
2
3
4
QUESTIONS AND ANSWERS4

Experience is everything.
In business and in life, we choose the things we like,
seeking them out over and over again. The things we
don’t enjoy we avoid like the plague.
Experience drives our decisions. Of course, that’s
never been more true than in the application
economy. Today’s customers are empowered and have
more choices than ever.
Providing a superior customer experience is a simple
concept, yet deceptively difficult to execute.
The Bottom Line: Customer Experience is THE prime differentiator in business today.
© 2015 CA. ALL RIGHTS RESERVED.

Organizations
Thought
Speed Was
The Magic
Bullet

SCRUM
KANBAN
Product
Backlog
Sprint Backlog Sprint Review Meeting
Release
Sprint
2 Weeks
Sprint Burn DownDaily
Meetings
Stack of Requirements
Ready to Develop Development Testing/Acceptance Customer
Done Done Done
Agile 101: Multiple Approaches/Methodologies

What Does this Number Represent?
37%

Speed Alone is Not Enough
Even with agile development
providing engineering
optimization, there are still
challenges insuring that the
right investments are being
chosen to begin with.
37%
Only 37% of product
managers stated their
efforts are aligned
with their firm’s
business strategy.
Source: Actuation Consulting 2015 Study of Product Team Performance

Focus on
Speed Alone
Did Not Yield
the Intended
Results

Product-Focused Frameworks

The Scaled Agile Framework is a proven, public-facing framework
for applying Learn and Agile practices at enterprise scale
The Scaled Agile Framework® (SAFe)
 Synchronize alignment, collaboration and
delivery
 Well-defined in books and now on the Web
 Scales successfully to large numbers of
practitioners and teams
Core Values:
1. Code Quality
2. Program Execution
3. Alignment
4. Transparency

Agile
Systems
Engineering
Lean Product
Development
Lean Thinking
2012 2013 2014
2.0
3.0
1.0
Field Experience at Enterprise Scale
4.0
2015
Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
The SAFe®
Journey

Quick Overview of What SAFe is
Scaled Agile Framework – SAFe

Agenda
1
2
3
4

Foundations of the Scaled Agile Framework®
Values, Principles, Practices, Implementation

We Thought We’d be Programming Like This:

But Sometimes it Feels Like This:

Problems
discovered
too late
No way to
improve
systematically
Hard to
manage
distributed
teams
Late
delivery
Too little
visibility
Too early
commitment
to a design
that didn’t
work
Poor
morale
Massive
growth in
complexity
Phase gate
SDLC isn't
helping
reduce riskUnder-
estimated
dependencies
And Our Retrospectives Read Like This:

The Management Challenge
It is not enough that management commit
themselves to quality and productivity, they must
know what it is they must do.
Such a responsibility cannot be delegated.
—W. Edwards Deming
“…and if you can’t come, send no one”
—Vignette from Out of the Crisis, Deming,1986

What it is They Must Do
 Embrace Lean-Agile Values
 Apply Lean-Agile Principles
 Implement Lean-Agile Practices
 Lead the Implementation

Embrace Lean-Agile Values
LEADERSHIP
Respectfor
peopleandculture
Flow
Innovation
Relentless
improvement
VALUE

Value in the Shortest Sustainable Lead Time
 Achieve the sustainably
shortest lead time with
– Best quality and value to
people and society
– High morale, safety,
customer delight
LEADERSHIP
Respectfor
peopleandculture
Flow
Innovation
Relentless
improvement
VALUE
There is only one boss. The customer. And he can fire
everybody in the company.
—Sam Walton

Agenda
1
2
3
4

3.0

Nothing Beats an Agile Team
 Cross-functional Agile Teams deliver working software every two weeks
 Scrum roles and project management practices, XP-inspired technical practices; Kanban for flow
ScrumXP Kanban

Except a Team of Agile Teams
 Cross-functional teams-of-agile-teams deliver working system increments every two weeks
 Operate with common Vision, architecture and UX guidance
 Collaborate, align, and adapt with face-to-face planning and retrospectives

Agenda
1
2
3
4

Release Planning
 Two days every 8–12 weeks
 Everyone attends in person if at all possible
 Product Management owns feature priorities
 Development team owns story-planning and high-level estimates
 Architects and UX folks work as intermediaries for governance, interfaces, and dependencies
Cadence-based Release Planning meetings are the pacemaker of the agile enterprise
Result: A committed set of program objectives for the next PI

Sample Day 1 Agenda
8:00
9:00
9:00
10:30
1:00
4:00
5:00
6:00
10:30
11:30
4:00
5:00
11:30
1:00
 State of the business and upcoming objectives
 Vision and prioritized features
 Architecture, common frameworks, etc.
 Agile tooling, engineering practices, etc.
 Facilitator explains planning process
 Teams present draft plans, risks, and impediments
 Teams develop draft plans and identify risks and
impediments
 Architects and Product Managers circulate
 Adjustments made based on challenges, risks, and
impediments
1 2 3 4

Sample Day 2 Agenda
8:00
9:00
9:00
11:00
11:00
1:00
 Planning adjustments made based on previous day’s
management meeting
 Teams present final plans, risks, and impediments
 Teams develop final plans and refine risks and impediments
 Business Owners circulate and assign business value to team
objectives
2:00
2:15
1:00
2:00
 Remaining program-level risks are discussed and ROAMed
 Team and program confidence vote
After
Commitment
2:15
???
 If necessary, planning continues until commitment is
achieved
 Retrospective
 Moving Forward
 Final Instructions
!
1 2 3 4
1 2 3 4

Content Preparation
 Executive Briefing
State of the business and upcoming objectives
 Product Vision Briefing(s) Vision and top 10
features
 Architectural Vision Briefing Vision for
architecture, new architectural epics, common
frameworks, etc.
 Development Context
Changes to standard practices, new tools and
techniques, etc.
In preparation for release planning, leadership creates a series of briefings to set context

Before Release Planning: The Cadence
Program Level Calendar:
 Release Planning Meetings
 PI Demos
 Inspect and adapt Workshops
Team Level Calendar:
 Sprint Planning Meetings
 Sprint Demos
 Sprint Retrospectives
The program planning calendar can be set for a year in advance
Reprinted by Permission of Yahoo!

The Release Planning Process
Input: Vision and Top Ten features
Output: PI Objectives and Program Board
Top 10
features
Vision
Team A PI
Objectives
Team B PI
Objectives
Team C PI
Objectives Team J PI
Objectives
Program PI
Objectives
...
Program Board
ProgramBacklog
NFRs

Sample Day 1 Agenda
8:00
9:00
9:00
10:30
1:00
4:00
5:00
6:00
10:30
11:30
4:00
5:00
11:30
1:00
 State of the business and upcoming objectives
 Vision and prioritized features
 Architecture, common frameworks, etc.
 Agile tooling, engineering practices, etc.
 Facilitator explains planning process
 Teams present draft plans, risks, and impediments
 Teams develop draft plans and identify risks and
impediments
 Architects and Product Managers circulate
 Adjustments made based on challenges, risks, and
impediments
1 2 3 4

Business Context
There is no prescribed format, but some
options include:
 The key portfolio priorities are
communicated
 The organization’s strengths,
weaknesses, opportunities, and threats
(SWOT) are analyzed
To kick off Release Planning, executive leadership shares
the state of the business and upcoming objectives
Alex Sun, CEO, Mitchell International
Reprinted by Permission of Mitchell
International

Product / Solution Vision
Product Management presents the vision and the high priority features
Reprinted by Permission of TradeStation TechnologiesReprinted by Permission of Discount Tire
Corporation

Architecture, UX, and Dev Practices
Architecture, UX, and Development Practices are first class
citizens in release planning, not afterthoughts!
 A System Architect presents the vision for
architecture, new Architecture Epics, and
common frameworks
 Development management may provide
updates on Agile tooling and improvements in
engineering practices
 UX professionals provide user experience
guidance
Reprinted by Permission of Nordstrom

Planning Context: Setting the Stage
The facilitator sets a shared understanding of the planning process
and deliverables for the planning process
Walkthrough of:
 Team planning process
 Planning acceptance criteria
 Program Board
Each team had the same deliverables:
 An objectives sheet
 One sheet per sprint for stories
 One risk sheet for risks and impediments

Team Breakout #1
In breakouts, each team breaks down their
features into user stories which are estimated
and placed into Sprints
There is a lot of back and forth between the
teams, mostly understanding and minimizing
dependencies
Photos Reprinted by Permission of TradeStation Technologies

Team Breakout #1: Color Coding
We can visually see
that some teams may
have significant
backlog items
dedicated to things
like maintenance
Yello
w
Purple
Red/
Pink
Green
Orang
e
= Risks and
Dependencies
= Dev Infrastructure /
Improvement Stories
= User Stories
= Maintenance
= Spikes
Red/
Pink
= Addressed Risks and
Dependencies

We color code the backlog items to give visibility into the investments

Team Breakout #1: Team Deliverables
Sprint 1.1 Sprint 1.2 Sprint 1.3 Sprint 1.4 Sprint 1.5
PI OBJECTIVES RISKS
Velocity: 34
Load: 30
Velocity: 34
Load: 30
Velocity: 34
Load: 30
Velocity: 34
Load: 30
Velocity: 34
Load: 0
Objectives /
Business Value
1. ….
2. ….
3. ….
Stretch Objectives
1. ….
IP Sprint
X
For velocity, use historic
information or 8 x (number
of developers + testers)
Be sure to adjust for
holidays and vacation.
Velocity (Capacity): ____
Load: ____

Sprint 1.1 Sprint 1.2 Sprint 1.3 Sprint 1.4
Sprint1.5
(IP)
Milestones/
Events
Unicorns
Dolphins
Bears
Iguanas
Blue = Features
Red String = A dependency requiring stories
or other dependencies to be completed
before the feature can be completed
= Significant
Dependency
Antelope
Tarantulas
Eagles
Needs UX Help
Needs Sys Arch
Help
Orang
e
=
Milestone
/ Event
PI 2 >>>
Red/
Pink
Program Plan Reflects Feature Delivery,
Dependencies and Milestones

Align to a Mission with PI Objectives
Team’s PI Objectives:
They often will map directly to the features in the backlog ... and they
sometimes may not. For example:
 aggregation of a set of features stated in more concise terms
 a milestone like trade show demo
 an architectural feature?
 a major refactoring
Objectives are brief summaries in business terms of what each team
intends to deliver in the upcoming PI
Objectives for PI 1
• Structured locations and
validation of locations
• Build and demonstrate a
proof of concept for context
images
• Implement negative
triangulation by: tags,
companies, and people
• Speed up indexing by 50%
• Index 1.2 billion more web pages
• Extract and build URL abstracts
———Stretch Objectives———
• Fuzzy search by full name
• Improve tag quality to 80% relevance
Bus. Value

Scrum of Scrums
The hourly scrum of scrums checkpoint helps keep teams
on track and facilitates early identification of risks
Hourly Scrum of Scrums Planning Checkpoint:
 Keeps teams on track with hourly planning milestones
 Helps drive out risks, impediments, and dependencies
Simple Planning Radiators

Reprinted by Permission of TradeStation Technologies
Draft Plan Review Agenda:
1. Velocity (Capacity) and Load
2. Plan Flow: Describe what will be
done and when
3. Draft PI Objectives
4. Program risks, impediments, and
Program Board dependencies
Draft Plan Review
Plans are peer-reviewed by all teams

Management Review & Problem Solving
Common Questions During the Managers Review:
 What did we just learn?
 Where do we need to adjust Vision? Scope? Resources?
 Where are the bottlenecks?
 What sacred features must be sacrificed?
 What decisions must we make between now and tomorrow to
address these issues?
Reprinted by Permission of Hybris Software
At Day 1 end, management meets to make adjustments to scope
and objectives based on the day’s planning

Sample Day 2 Agenda
8:00
9:00
9:00
11:00
11:00
1:00
 Planning adjustments made based on previous day’s
management meeting
 Teams present final plans, risks, and impediments
 Teams develop final plans and refine risks and impediments
 Business Owners circulate and assign business value to team
objectives
2:00
2:15
1:00
2:00
 Remaining program-level risks are discussed and ROAMed
 Team and program confidence vote
After
Commitment
2:15
???
 If necessary, planning continues until commitment is
achieved
 Retrospective
 Moving Forward
 Final Instructions
!
1 2 3 4
1 2 3 4

Planning Adjustments
Possible Changes:
 Business priorities
 Adjustment to plan
 Changes to scope
 Movement of resources
Reprinted by Permission of TradeStation Technologies
Reprinted by Permission of
Discount Tire Company
Based on the previous day’s Management Review and
Problem Solving meeting, adjustments are discussed

Team Breakout #2
 In the second team breakout, business owners
circulate and assign business value to release
objectives (1–10)
 Teams finalize the Program Increment plan
 Teams also consolidate program risks,
impediments, and dependencies
 Stretch objectives provide the capacity and
guard band needed to increase cadence-based
delivery reliability
Based on new knowledge (and a good night’s sleep),
teams work to create their final plans

SMART Team and Program PI Objectives
SMART Objectives are:
 Specific — State the intended outcome as simply, concisely,
and explicitly as possible. Try starting with an action verb.
 Measurable — It should be clear what a team needs to do to
achieve the objective. The measures may be descriptive,
hit/miss, or a sliding scale.
 Achievable — It should be within the team’s control and
influence.
 Realistic — Recognize factors which cannot be controlled.
Avoid making happy path assumptions.
 Time-based — The objectives should be scoped to fit within
the PI.
Well-written objectives can focus a team like a laser.
The SMART framework can help.

More on Stretch Objectives
 Stretch Objectives do count in velocity/capacity:
They aren’t things teams do in case they end up with extra time
 Stretch Objectives are tools for commitment:
– If a team has low confidence in meeting a PI Objective which involves factors beyond their
control, encourage them to move it to a Stretch Objective
– If there are many unknowns which are spiked in earlier Sprints which may dramatically change
estimates, move those to Stretch Objectives
Central control of strategy; decentralized control of execution.
Stretch objectives provide reliability guard band.

Final Plan Review
Teams and Business Owners peer-review all final plans
Final Plan Review Agenda:
1. Changes to velocity and load
2. Final PI objectives with business
value
3. Program risks, impediments, and
Program Feature Board
dependencies
4. Q&A
Reprinted by Permission of SEI Global
Wealth Services

Building the Final Plan
 Final plans are reviewed by all teams
 Business Owners are asked whether they accept
the plan
 If so, the team’s plan and program risk sheet is
brought to the front of the room
 If not, the plans stay in place and the team
continues planning after the review
Reprinted by Permission of Discount Tire Corporation
Final plans are collected at the front of the room

Addressing Program Risks
ROAMing Risks:
 Resolved – has been addressed; no longer a
concern
 Owned – someone has taken responsibility
 Accepted – nothing more can be done. If risk
occurs, release may be compromised
 Mitigated – team has plan to adjust as
necessary
After all plans had been presented, remaining program risks and
impediments are discussed and categorized

Confidence Votes: Team and Program
“Fist of Five” confidence vote for hitting objectives:
1 = No confidence; will not happen
2 = Little confidence; probably will not happen
3 = Good confidence; the team should be able to meet the objectives
4 = High confidence; should happen
5 = Very high confidence; will happen
A Commitment with Two Parts
1. Teams agree to do everything in their power to meet the
agreed-to objectives
2. In the event that fact patterns dictate that it is simply not
achievable, teams agree
to escalate immediately so that corrective action can be taken
After dependencies are resolved and risks are addressed,
a confidence vote is taken at the team and program levels

Plan Rework if Necessary
The Program Timebox
 Just as the Sprint Planning Meeting is timeboxed, so is
the Release Planning Meeting
 Leaving the two day planning meeting without a
committed plan is not an option. Teams stay to rework
their plans and “ROAM” their risks and impediments
What happens if there is low confidence? Rework!

Executing Strategy in an Agile Portfolio
 Organize Agile Release Trains around Value Streams
 Centralize strategy; decentralize execution
 Empower decision makers with Lean-Agile budgeting
 Provide portfolio visibility and WIP limits
 Leverage objective metrics for governance and improvement

CA PPM Provides a Business-Facing Tool

CA PPM and Agile Landscape
Strategic Planning / Capital Planning
Enterprise Portfolio Planning / Enterprise Resource Planning
Governance
Hybrid
Enterprise Scale Agile and
Agile Team Planning
Agile Execution
Agile
Tools
CA PPM
ChecklistWaterfall

Integrated Planning Regardless
of Execution Mode
Business Case –
Intake from the
Business
Prioritization –
making the right
investment
choices
Resource
Planning &
Annual
Funding
Agile
Complex Projects
Check Lists
 Prioritization and funding is very relevant in the enterprise… and CA PPM is valued for this
 Traditional work execution is changing – bi-modal (more adaptive processes)

Q & A

For More Information
To learn more, please visit:
http://cainc.to/Nv2VOe
CA World ’15

An Introduction to Scaled Agile Framework (SAFe)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to An Introduction to Scaled Agile Framework (SAFe)

Similar to An Introduction to Scaled Agile Framework (SAFe) (20)

More from CA Technologies

More from CA Technologies (20)

Recently uploaded

Recently uploaded (20)

An Introduction to Scaled Agile Framework (SAFe)