Development in SAFe ®

Scaled Agile An Introduction

Agenda
Focus on Development & Planning.

What is SAFe ?
®

SAFe Vs Scrum an Introduction.

®

PI (Program Increment) Planning Process.

SAFe ®
The Scaled Agile Framework® (SAFe®) is a
set of organisational and workflow
patterns for implementing agile practices
at an enterprise scale. The framework is a
body of knowledge that includes
structured guidance on roles and
responsibilities, how to plan and manage
the work, and values to uphold.
SAFe promotes alignment, collaboration,
and delivery across large numbers of agile
teams. It was formed around three primary
bodies of knowledge: agile software
development, lean product development,
and systems thinking.
SAFe Vs Scrum an Introduction
®

Scrum is an iterative method used for

developing a product that focuses on the
continuous delivery of tasks assigned. It is
dependent on cross-functional teams,
sprints(set of stories), and specific roles
that help in delivering the assignment.
Scrum is mainly developed for a small
team of ten or fewer people.
SAFe, on the other hand, is an agile
framework for an enterprise which is not
limited to smaller teams and guides
enterprises in scaling lean and agile
practices.
PI (Program Increment) Planning Process
Business Context – The respective application/business owners talk about
the as-is and to-be business state, discuss the portfolio vision, and state
how the solutions outlined will cater to consumer demands. 

Product/Solution Vision – Product Managers talk about the new features,

takeaways from previous PI sessions, and upcoming milestone/release
plans. 

Architecture Vision and Development practices – The System Architect may

present upcoming vision/features and development leads/managers may
also talk about dev best practices along with CI/CD changes being
proposed in the forthcoming PI. 

Planning Context & Lunch – Presentation by the RTE (Release Train

Engineers) on the planning process and the desired outcomes. 

Team Breakouts – Teams discuss, estimate capacity, and plan the sprints
into the draft plans – which are made visible to all, each iteration at a time.

Draft Plan Review – Teams discuss the key planning outcomes, PI

objectives, risks, assumptions and dependencies. Key stakeholders
involve and provide input in this strictly timeboxed activity. 

Management review and problem-solving – Adjustments to the draft plan to

overcome constraints and dependencies or negotiate changes in scope,
cost, or agreements to make planning adjustments by the management.
 Planning adjustments – The next day, the event begins with management presenting any changes to planning scope,
people, and resources.

Team breakouts #2 – Teams continue planning based on their agenda from the previous day, making the appropriate
adjustments. They finalize their objectives for the PI, to which the Business Owners assign business value.

Final plan review and lunch – During this session, all teams present their plans to the group. At the end of each
team’s time slot, the team states their risks and impediments and provides the risks to the RTE for use later in the
ROAMing exercise. The team then asks the Business Owners if the plan is acceptable. If the plan is accepted the
team brings their team PI objective sheet to the front of the room so everyone can see the aggregate objectives unfold
in real-time. If the Business Owners have concerns, teams are given the opportunity to adjust the plan as needed to
address the issues identified. The team then presents their revised plan.

Program risks – During planning, teams have identified program risks and impediments that could impact their
ability to meet their objectives. These are resolved in a broader management context in front of the whole train. One
by one, the risks are discussed and addressed with honesty and transparency, and then categorised into one of the
following categories:
- Resolved – The teams agree that the risk is no longer a concern.
- Owned – Someone on the train takes ownership of the risk since it cannot be resolved during PI planning.
- Accepted – Some risks are just facts or potential problems that must be understood and accepted.
- Mitigated – Teams identify a plan to reduce the impact of the risk.

Confidence vote – Once program risks have been addressed, teams vote on their confidence in meeting their team PI
objectives. Each team conducts a ‘fist of five’ vote. If the average is three fingers or above, then management should
accept the commitment. If it’s less than three, the team reworks the plan. Any person voting two fingers or fewer
should be given an opportunity to voice their concerns. This might add to the list of risks, require some re-planning,
or simply be informative. Once each team has voted the process is repeated for the entire ART with everyone
expressing their confidence in the collective plan.

Plan rework – If necessary, teams rework their plans until a high confidence level can be reached. This is one
occasion where alignment and commitment are valued more highly than adhering to a timebox.

Planning retrospective and moving forward – Finally, the RTE leads a brief retrospective for the PI planning event
to capture what went well, what didn’t, and what can be done better next time
Lean PI Planning
Focus the planning on what requires
foresight:
1. Work items to fulfill objectives
2. Work items with
interdependencies
3. Hard delivery/commitment dates,
e.g.
A. Committed release dates

B. Internal milestones

C. Critical events
SMART Team PI Objectives
Specific - State the intended outcome as simply, concisely,
and explicitly as possible. (Hint: 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,
yes/no, quantitative, or provide a range.

Achievable - Achieving the objective should be within the

team's control and influence.

Realistic - Recognize factors that cannot be controlled. (Hint:

Avoid making "happy path" assumptions.)

Time-bound - The time period for achievement must be within

the Pl, and therefore all objectives must be scoped
appropriately.
Team PI Objectives
Objectives are business summaries of what each team
intends to deliver in the upcoming Pl
They often map directly to the Features in the backlog but
not always
Examples:
Aggregation of a set of Features
A milestone like a pilot
An enabler Feature supporting the implementation
A major refactoring
Write them so that anyone understands, even though
they are not familiar with development details, using
“SMART”.
Objectives Tracking
The End