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

5 © 2015 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLDSource: Anish Bhimani: A Leader in Risk Management at http://engineering.cmu.edu/alumni/profiles/2013/bhimani_jpmorgan_chase.html


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.03.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

https://youtu.be/WZzeNQm7L0w


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 lateNo 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

Res

pe

ct f

or

pe

op

le a

nd

cu

ltu

re

Flo

w

Inn

ova

tio

n

Rel

entl

ess

imp

rove

me

nt

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

Res

pec

t fo

rp

eop

le a

nd

cu

ltu

re

Flo

w

Inn

ova

tio

n

Rel

entl

ess

imp

rove

men

t

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:0010:30

1:004:00

5:006:00

10:3011:30

4:005:00

11:301: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:009:00

9:0011:00

11:001: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:002: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

Prior to Release Planning


Content Preparation

Executive BriefingState 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 ContextChanges 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

Pro

gram

Bac

klog

NFRs

Release Planning Day 1


Sample Day 1 Agenda

8:00

9:00

9:0010:30

1:004:00

5:006:00

10:3011:30

4:005:00

11:301: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/

PinkGreen

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: 34Load: 30




Velocity: 34Load: 0

Objectives /Business Value1. ….2. ….3. ….

Stretch Objectives1. ….

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.4Sprint1.5

(IP)Milestones/

Events

Unicorns

Dolphins

Bears

Iguanas

Blue = FeaturesRed 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

Release Planning Day 2


Sample Day 2 Agenda

8:009:00

9:0011:00

11:001: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:002: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&AReprinted 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 PlanningEnterprise 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

http://cainc.to/Nv2VOe

http://bit.ly/1wbjjqX

Technology

An Introduction to Scaled Agile Framework (SAFe)