Essential SAFe® 4.0 is a subset of big picture SAFe 4.0 framework. It is good starting point for self-learners. This slideshow cover essential aspects of SAFe framework. It is a primer to Scaled Agile Framework.

1. Essential SAFe® 4.0
A primer to Scaled Agile Framework
Chintamani Umarani
Lead Software Engineer | Certified ScrumMaster | SAFe Agilist 4.0
chintan@umarani.com

2. • What is SCRUM ? (btw…SAFe is based on Scrum-Agile)

3. • Limitation of Scrum: ( hmm… or need of SAFe?)
• Only good for small, fast moving projects as it works
well only with small team
• Scrum lacks in program level planning
• If a task is not well defined, estimating project costs
and time will not be accurate
• Difficult to scale to large projects with many teams
and a large number of deliveries
• Scrum-of-Scrums is insufficient

4. Why SAFe?
• For larger organizations
(5-12 scrum teams or 50-125
people), especially those with
• larger and more complex systems to develop and support, SCRUM does not
provide very much guidance around scaling
• Without SAFe, There is disconnect between teams which are working on same
project
• Often there are mis-understandings and it ends with blame games
• Although SAFe builds on SCRUM, It doesn’t replace it

5. What is SAFe ?
The Scaled Agile Framework® (SAFe®) was
designed to help enterprises deliver value
continuously and more efficiently on a regular
and predictable schedule, making them more
Agile in the marketplace and more competitive
in their industry.

6. The big picture of
SAFe 4.0
Framework

9. Internal
Let’s deepdivein SAFe
9

10. • Agile Teams and Release Train
• ART is a long-lived, self-organizing team of
Agile teams, a virtual organization (50-125
people) that plans, commits, and executes
together
• Each train must include real, cross-
functional Agile teams, as well as people
from various other disciplines

11. • Without Agile Teams and ARTs:
• Teams don’t work towards a common mission.
• Teams locally optimize and can’t deliver end to end value.
• Dependencies rule the day.
• Individuals are over-specialized; bottlenecks inhibit flow and release of
value.
• There is no architectural and user experience integrity
11

12. • Cadence and synchronization
• Cadence provides a rhythmic
pattern, the dependable heartbeat
of the development process
• Synchronization required to align
development teams and the business to
a common mission at Program
Increment (PI) planning
12

13. 13
• Without cadence and
synchronization
• There’s no development rhythm.
• You constantly fight entropy and
misalignment.
• It’s impossible to schedule planning,
retrospectives, demos and key events.
• It’s hard to adjust to changing priorities.
• You can’t limit Work in Process (WIP) and
are constantly overloaded

14. • Essential Team and Program Roles
• Team roles
• Scrum Master: Facilitating team
meetings, driving Agile behavior,
removing impediments
• Product Owner: Maintains the team
backlog, acts as the customer for
team, prioritizes the work.
• Development Team: Developers,
testers, and various specialists, They
define, build, test, and deliver
software, hardware, system
components or features
• Program Roles
• The Release Train Engineer (RTE): Acts as
the chief Scrum Master
• Product Management: Responsible for
identifying customer needs
• System Architect-Engineering: Align ARTs
with a common technological and architectural
vision.
• Business Owners: Responsibility for customer
relationships, development, solution quality,
deployment, operations, Product Management,
and architecture
• Customer: The king
14

15. • Responsibilities for most everything is unclear.
• Decision-making is fractured, late, and uncertain.
• Deliverables do not meet stakeholder expectations.
• Solution features and components evolve incompatibly.
• Vision and requirements are unclear and hard to prioritize.
• Improvements are virtually impossible to achieve
15
• Without these critical roles …

16. • Program Increment (PI)
16

17. • Program Increment (PI) Planning:
• The most powerful event in SAFe which provides cadence or rhythm to ART
• All team members (50~125 people) gather for two days to work together on
plans, identify dependencies.
• Teams come together periodically to better define and design the system
that fulfills the vision, and to commit to near-term PI objectives
• This event creates, fosters and sustain a sense of shared mission,
responsibility, and collaboration
• Responsibility for planning moves from central authority to the teams.
• This event builds the social network that the ART depends on
17

18. • Example of PI planning:
• There are teams in the U.S. planning at the same time with remote teams in India, using video
conferencing. Leads from teams in Eastern Europe are attending the U.S. event in person, and
are collaborating with their teams remotely. U.S.-based Business Owners are sitting at the table
in the middle, accessible to everyone. Product Owners are with their teams in India.
18

19. • Without PI Planning …
• Stakeholders, teams, and management are misaligned.
• Demand doesn't match capacity, eliminating predictability and creating
excess WIP.
• Lack of trust between stakeholders and teams develops.
• Dependencies are discovered by “running into them.”
• The result is low commitment, ownership, and enthusiasm
19

20. 20
• System Demo:
• Primary measurement of ART
progress.
• Every two weeks, the full system—
the integrated work of all team
• Stakeholders provide the feedback
and Teams takes corrective action
• At the end of each PI, a final system
demo is held

21. • Without the System Demo:
• Things are just “waterfalled”.
• Problems and risks are discovered too late.
• Teams are sprinting, but the system is not.
• Chronic lack of trust develops between stakeholders and teams.
• There’s no feedback about the right solution.
• False progress leads to poor quality
21

22. • Inspect and Adapt:
• Inspect and Adapt (I&A) workshop is a significant event held at the end of
each PI
• A regular time to reflect, collect data and solve problems, the I&A workshop
assembles teams and stakeholders to assess the solution, and define and
take action on the improvements needed to increase the velocity, quality,
and reliability of the next PI
• The I&A has three parts:
• 1. PI system demo. Demo of all features completed by the ART
• 2. Quantitative measurement:
• 3. Problem-solving workshop: Retrospective for the PI
22

23. • Without Inspect and Adapt:
• Problems perpetuate without
systemic improvement.
• There is no way to measure or
establish delivery predictability.
• Improvement attempts address
symptoms, not root causes.
• Those who could change the
system are not engaged.
• Morale deteriorates.
23

24. • Innovation and Planning (IP) Iteration:
• When teams are working on PI objectives, Every iteration counts, and the
teams are mostly “heads down,” focused on near-term delivery so there
is very litter scope for innovations.
• To address this, the IP iteration provides opportunity, for teams to work
on activities that are difficult to fit into a continuous delivery model.
• Time for innovation and exploration, a dedicated time for the scheduled
PI system demo, the I&A workshop, PI planning events, backlog
refinement for the next PI, and even time for continuing education.
24

25. 25
Without the IP iteration:
• Lack of delivery capacity buffer impacts predictability.
• Tyranny of the urgent overrules innovation.
• Technical debt grows uncontrollably.
• People burn out.
• There’s no time for teams to plan, demo, and improve together.

26. • For further reading :
SAFe:
http://www.scaledagileframework.com
http://www.scaledagileframework.com/introduction-to-safe
http://umarani.com/how-pass-leading-safe-exam
Scrum:
http://umarani.com/how-to-pass-csm-test
http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
http://scrumprimer.org/scrumprimer20.pdf
26

27. Internal
Q & A
27

28. Internal
Thank You
Chintamani Umarani
Lead Software Engineer | Certified ScrumMaster | SAFe Agilist 4.0
chintan@umarani.com
28