SPC SAFe5.

1 Notes By Jim Bowen

Lesson 1: Thriving in a digital age

 5 stages of tech revolution




Production capital follows financial capital

Installation period

 Start with a network add hierarchy for stability and execution  then starts to decline  we need a
secondary system  don’t trash what we’ve got (Kotter)  dual operating system, to speed up innovation
and to bring efficiency and stability  this is SAFe

Lesson 1.2: Safe as an operating system for business agility

 Business agility uses technical agility and business level commitment to product and value stream thinking
 https://www.scaledagileframework.com/
 SAFe configurations
 Essential configuration – basic one train
 Portfolio configuration – one or more trains
 Large solution configuration – many trains – train of trains
 Full configuration – very rare – often never needed

Lesson 1.3: 7 core competencies of business agility

left is doing

right is strategic

bottom is leadership

all equally as important

known as the 3 dimensions

 Team and technical agility  high performing cross

functional teams  teams of business and
technical teams build solutions
 Agile product delivery  customer at the center  decouple value release train from development cadence
 Enterprise solution delivery ► Apply Lean system engineering practices to build really big systems ►
Coordinate and align the full supply chain

SAFE notes
  Lean portfolio management ► Align strategy, funding, and execution ► Optimize operations across the
portfolio
 Organisational agility ► Create an enterprise-wide, Lean-Agile mindset ► Map and continuously improve
business processes
 Continuous learning culture - ► Everyone in the organization learns and grows together ► Exploration and
creativity are part of the organization's DNA
 Lean agile leadership - ► Inspire others by modeling desired behaviors ► Align mindset, words, and actions
to Lean-Agile values and principles
 Commitment  if you can’t come, send no one – need commitment – deeming

 Measure and grow towards business agility  Measure and Grow is the way each portfolio evaluates their
progress toward Business Agility and determines their next improvement steps
 Must set a baseline

SCRUM BUILD UP MODEL

Points
1. overview of scrum
2. increments – are 1 to 4 weeks (guide suggests 2 weeks)
3. stories – 1 to 4 weeks – big broken down into smaller chunks – more likely to succeed
4. SAFe uses Scrum out of the guide
5. SAFe scales up  team of Agile teams  the challenge is how to scale up
6. SAFe uses features  much bigger than scrum  need to define quality  new definition of the DoD 
as much a planning feature or planning tool as a checklist (i.e. have all the features been completed)
7. Features live in a PROGRAM BACK LOG  known as a TEAM BACK LOG
8. NOTE: no single team owns the BACK LOG at program level
9. PGM backlog owned by PRODUCT MANAGEMENT along with PO and other stakeholders  know the needs
of stakeholders
10. PI or PROGRAM INCREMENT  10 – 12 weeks – a look ahead
a. Made up of sprints
b. Features can span across multiple sprints
c. Usually 5 PI’s per year
d. Large number of teams working together – need TECHNICAL STRATEGY – managed by
SYSTEMS ARCHITECT – can be more than one person
11. SYSTEMS ARCHITECT  usually specialist knowledge – doesn’t have to be technically competent  good
coordinator  COLLABORATE with multiple teams  technical competence MUST be embedded in the
teams
12. RELEASE TRAIN ENGINEER  they manage releases  every few weeks releases take place  the RTE is
PURE FACILATATION similar to the SCRUM MASTER (on diagram they wear the driver hat)
13. On the drawing this is FIRST LEVEL or ESSENTIAL configuration

14. Next LEVEL is PORTFOLIO

15. Need EPICS (not same as SCRUM)  these drive BUSINESS CHANGE  i.e. what we need to do  need a
business case and infrastructure
16. Need AN EPIC OWNER  they are realized through FEATURE RELEASE  I.e. profits up / inefficiency down
17. EPICS live in a BACKLOG  owned by the LEAN PORTFOLIO MANAGEMENT  multiple executives
18. NOTE: budget is sent straight directly to the RELEASE TRAINS  helps us stay in control

19. Drawing goes straight to ENTERPRISE ARCHITECTURE which basically controls everything
20. End of drawing

Lesson 2: Becoming an Agile Leader

 SAFe core values

SAFE notes
 SAFe core values
Alignment
Transparency
Built in quality
Program execution

 SAFe house of Lean

 Value – achieve the shortest lead
time and best Quality
 Respect for people and culture –
build culture -people
do the work – think long term gain
 Flow – optimise sustainable value delivery and quality
flow
 Innovation – comes from the producer – provide space
and time – innovate the people
 Relentless improvement – optimise the whole – beware
of danger, base ideas on facts
 Leadership – adopt a growth mindset / lead by example

 Agile manifesto – 12 principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's
competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the
shorter timescale.

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.

6. The most efficient and effective method of conveying information to and within a development team is face-to-
face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.

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.

Lesson 2.2: Lean and Agile at Scale with the SAFe principles
SAFE notes
SAFe has its own principles

#1 Take an economic view

#2 Apply systems thinking

#3 Assume variability; preserve options

#4 Build incrementally with fast, integrated learning cycles

#5 Base milestones on objective evaluation of working systems

#6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths

#7Apply cadence, synchronize with cross-domain planning

#8 Unlock the intrinsic motivation of knowledge workers

#9 Decentralize decision-making

#10 Organize around value

Principle 1 take an economic value

 Deliver incrementally
 Earlier delivery has higher value
 Solution economic tradeoffs - Sequence jobs for maximum benefit, do not consider money already spent,
make economic choices continuously, empower local decision making, if you only quantify one thing,
quantify the cost of delay
Principle 2: Apply system thinking

The Solution and the Enterprise (which are also considered systems) are both affected by the following:
► Optimizing a component does not optimize the system
► For the system to behave well as a system, a higher-level understanding of behavior and architecture is required

SAFE notes
Optimise the full value stream - most problems with your process will surface as delays, most of the time spent
getting to market is a result of these delays, reducing delays is the fastest way to reduce time to market.
Principle 3: Assume variability, preserve options

 Development occurs in an ever-changing world - ► You cannot possibly know everything at the start ►
Requirements must be flexible to make economic design choices ► Designs must be flexible to support
changing requirements ► Preservation of options improves economic results
 Apply a SET BASED APPROACH – learning points mean you can reduce errors later – quicker / more efficient /
quicker to market

Principle 4: build incrementally with fast, integrated learning cycles

 Apply fast learning cycles – PDCA  shorten the cycles – the faster the learning
 Use PDCA AT ALL LEVELS – but integration points need to overlap
 Frequent integration points WILL reduce risk
 If you don’t integrate – can lead to FALSE POSITIVE INTEGRATION POINTS – via waterfall – frequent
integration points mean you learn as you go

Principle 5: base milestones on objective evaluation of working systems

 The problem of phase gate milestones - ► They force design decisions too early; this encourages false-
positive feasibility. ► They assume a ‘point’ Solution exists and can be built correctly the first time. ► They

SAFE notes
 create huge batches and long queues, and they centralize requirements and design in program
management.
 Adopt objective milestones - Program Increment (PI) System Demos are orchestrated to deliver objective
progress, product, and process Metrics – through inspect and adapt – learning points
 Iterate to the optimum solution

Principle 6: visualise and limit WIP, reduce batch sizes and manage queue lengths

 This focus is on FLOW  don’t have too much in development at any one time  one story at a time 
collaboration around that story  too much at one time means little progress – danger
 SMALLER BATCH SIZES  brings team closer together  ID problems quicker  better for REWORK as it
can be completed quicker  better collaboration
 High utilization causes variation  use M25 example

Find the optimum batch size  ► Total costs are the sum of holding costs and transaction costs ► Higher
transaction costs make optimal batch size bigger ► Higher holding costs make optimal batch size smaller (get to
market quicker), holding costs are fixed cost storage costs. Transaction costs are shipping costs (fixed costs) the
more you ship the cheaper per unit it becomes
 Reducing the batch size will reduce the overall transaction costs
 Swarming around a feature – like F1 car – quickly gets car back on the track – competition
Manage Queue lengths
 Long queues = poorer quality / corners cut / longer transaction time / unhappy customers –
 Use LITTLES LAW = queue length / average process time
► Understand Little’s Law - Faster processing time decreases wait - Shorter queue lengths decrease wait
► Control wait times by controlling queue lengths: - WIP limits, small batches, defer commitments
Note:
Backlog is not a queue – it’s a commitment / wish list – wherever possible small batches – can improve forecasting /
productivity  try explaining that to an executive

Principle 7: Apply Cadence, synchronize with cross-domain planning

Cadence:
► Converts unpredictable events into predictable occurrences and lowers cost

SAFE notes
► Makes waiting times for new work predictable
► Supports regular planning and cross-functional coordination
► Limits batch sizes to a single interval
► Controls injection of new work
► Provides scheduled integration points

Synchronize

► Causes multiple events to happen simultaneously

► Facilitates cross-functional trade-offs
► Provides routine dependency management
► Supports full system integration and assessment
► Provides multiple feedback perspectives

 Note: Cadence without synchronization is not enough!!!!

 It’s all about efficiency
 Planning with cadence will help to limit too much drift away from the original plan – i.e. continuous planning

Synchronise with cross domain planning

► Everyone plans together at the same time

► Management sets the mission with minimum constraints
► Requirements and design emerge
► Important decisions are accelerated
► Teams take responsibility for their own plans

Principle 8: Unlock the intrinsic motivation of knowledge workers

 ‘without pressure no diamonds’ – knowledge workers are considered this when they have more knowledge
than their boss - Workers themselves are most qualified to make decisions about how to perform their work
- The workers must be heard and respected for management to lead effectively - Knowledge workers must
manage themselves. They need autonomy.
 ► Autonomy is the desire to be self-directed and have control over what we work on, how we do our work,
and who we work with
 ► Mastery is the urge to get better at what we do and improve our personal and team skills

Principle 9: Decentralise decision making

SAFE notes
  https://bit.ly/Video-GreatnessMarquet
 Video of a submarine Captain –
never giving orders accept one 😊

Centralise

► Infrequent – Not made very often and usually not urgent (Example: Internationalization strategy)
► Long-lasting – Once made, highly unlikely to change (Example: Common technology platform)
► Significant economies of scale – Provide large and broad economic benefit (Example: Compensation strategy)

De-centralise  KEY to practice decentralizing decision making

► Frequent – Routine, everyday decisions (Example: Team and Program Backlog)

► Time critical – High cost of delay (Example: Point release to Customer)
► Requires local information – Specific and local technology or Customer context is required (Example: Feature
criteria)

Principle 10: Organise around Value

 Management need to connect the silos – crucial  ► Value delivery is inhibited by handoffs and delays ►
Political boundaries can prevent cooperation ► Silos encourage geographic distribution of functions ►
Communication across silos is at best difficult
 Organise around development value streams
and not silos
 Identify the various value streams that can come
together to build one or more ART’s
 Define build validate release  for product lifetime

Lesson 3: Team and Technical Agility

Why team and technical agility???  Agile Teams create and support the business Solutions that deliver value to
the Enterprise’s Customers. Consequently, an organization’s ability to thrive in the digital age is entirely dependent
on the ability of its teams to deliver Solutions that reliably meet a Customer’s needs.
e Teams and teams of
3.1 – Forming cross functional agile teams
SAFE notes
Agile Teams are cross-functional, self-organizing entities that can define, build, test, and where applicable, deploy
increments of value.
► Optimized for communication and delivery of value
► Deliver value every two weeks
► Contain two specialty roles:
– Scrum Master
– Product Owner
Responsibilities of Agile Team
► Five to eleven team members
► Create and refine Stories and acceptance criteria
► Define, build, test and deploy Stories
► Build quality in to each increment of the solution.
► Develop and commit to team PI Objectives and Iteration Goals

SAFE notes
Scrum Master
• Coaches the Agile Team in self-management
• Helps the team focus on creating increments of value each Iteration
• Facilitates the removal of impediments to the team’s progress
• Ensures that all team events take place, are productive and kept within the timebox
 Helps the team interact with other teams
Product Owner

• Contributes to the Vision and Roadmap

• Acts as the Customer for team questions
• Creates, clearly communicates and accepts Stories
• Prioritizes the Team Backlog
Seen as the business representative

 In SCRUM – don’t use sprints / timeboxes  use ITERATION PLANNING

 Use KANBAN  a policy can be applied to any of these processes if necessary
 The more you move away from engineering the more ambiguous the approach becomes i.e. marketing /
growth. This can be applied to any business SO
o Get your business to become Agile
o Know your value stream systems
o Specialise your principles and practices

3.2 Build in quality

You can’t expand CRAPPY code  build in quality. ► Ensures that every increment of the Solution reflects quality
standards ► Is required for high, sustainable development velocity ► Agile quality practices apply to every team,
whether business or technology
Built-in quality practices for software teams  Include software quality practices (most inspired by XP) like, Agile
testing, behaviour-driven development, test-driven development, refactoring, code quality, and Agile architecture.
Built-in quality practices for hardware teams  Support hardware quality with exploratory, early iterations,
frequent system-level integration, design verification, Model-Based Systems Engineering (MBSE), and set-based
design.

3.3 Organising the ART around the flow of value

The ART
► A virtual organization of 5 – 12 teams (50 – 125+ individuals)
► Synchronized on a common cadence, a Program Increment (PI)
► Aligned to a common mission via a single Program Backlog

 ART’s are cross functional  all needs are contained within the ART (including systems and value streams)
 Stream-aligned team – organized around the flow of work and has the ability to deliver value directly to the
Customer or end user. 5 – 11 people – deliver value
 Complicated subsystem team – organized around specific subsystems that require deep specialty skills and
expertise. On their own can’t deliver value – need to collaborate
 Platform team – organized around the development and support of platforms that provide services to other
teams. They do not deliver value directly
 Enabling team – organized to assist other teams with specialized capabilities and help them become
proficient in new technologies. These are specialist teams – deliver then disbanded

ARTs are organized to deliver value continuously  Consider the

necessary interactions between the teams and organize to
maximize flow – through STREAM ALIGNED TEAMS

SAFE notes
Roles on the ART Engineer acts as the

Release Train Engineer acts as the Chief Scrum Master for the train

System Architect/Engineering provides architectural guidance and technical enablement to the teams on the train.

Business Owners are key stakeholders on the Agile Release Train – can be 100’s of them own the businesses on the
outside – often provide funding – they can guide the PI on the ART – often the only PART TIME ROLE

Product Management owns, defines, and prioritizes the Program Backlog.

System Team provides processes and tools to integrate and evaluate assets early and often. Specialists – similar to
system DevOps pipeline

Lesson 4: Building solutions with Agile Product Delivery

Why Agile product delivery?? In order to achieve
Business Agility, Enterprises must rapidly increase their ability to deliver innovative products and services. To be sure
that the Enterprise is creating the right Solutions for the right Customers at the right time, they must balance their
execution focus with a Customer focus.

4.1 – customer centricity and design thinking

Customer-centric businesses generate:
► Greater profits
► Increased employee engagement

Customer-centric governments and non-profits create:

► The resiliency, sustainability, and alignment needed to fulfil their mission

 Customer centricity is a mind-set  are we delivering what the customer expects?

 Note the problem is separate from the solution
 Use the tools under the diamond to introduce value
 The diamonds are sets of stories
o Diverge to gain ideas
o Converge to deliver real value – solution
 Use PERSONAS to understand customers
 Use EMPATHY MAPS

The empathy map is a tool that helps teams develop

deep, shared understanding and empathy for the
Customer ► Use it to design better user experiences and Value
Streams
 What is the customer journey – below is an example of a mortgage  relay information to all stakeholders /
devs

SAFE notes
  Use STORY MAPPING  what stories are needed to complete the feature – also potential future stories to
bring improvements
o Features are grabbed in PI planning

4.2 Prioritising the PROGRAM BACK LOG

The Program Backlog is the holding area for upcoming Features that will address user needs and deliver business
benefits for a single Agile Release Train (ART).
 Features are releasable POINTS. The Back log also contains enablers
 Vision – helps build the backlog – our future vision – get AGREEMENT

Features represent the work for an ART

► The Feature benefit hypothesis justifies development cost and provides business perspective for decision-making
► Acceptance criteria are typically defined during Program Backlog refinement
► Reflect functional and non-functional requirements
► Fits in one PI

► Stories are small increments of value that can be developed in days and are relatively easy to estimate
► Story user-voice form captures role, activity, and goal
► Features fit in one PI for one ART; Stories fit in one Iteration for one team

Enabler Stories represent different types of work, such as: Exploration, Architecture, Infrastructure, Compliance.

User stories  As a book purchaser I can see the price for each shipping method for my current order so that I can
select a shipping method based on price.

Business feature  Feature: Shipping Method Selection Benefit hypothesis: Users can select a shipping method
based on cost, delivery speed, and carrier

Estimation:

Whole team exercise stakeholders that don’t add value should note vote – i.e. some PO’s and Scrum Masters

– Volume: How much is there?

– Complexity: How hard is it?

– Knowledge: What do we know?

– Uncertainty: What’s not known?

Story points can be seen as estimation of effort – in distance (usually) how far do we have to go?

Planning Poker

6 steps to go through – remember to keep your previous attempts as estimates called “velocity estimating”

Estimating Ladder

More visual than planning poker

Prioritise features as a way to optimise ROI

JOB SEQUENCING  do the most important thing first.

 Must measure
SAFE notes
 o Cost of delay
o What is the cost to implement the valuable thing?

Example – what would happen to the costs if a building site stopped working??

o Cost of equipment hire

o Wages
o Interest on loans
o Reputational damage etc
 Always go with the option that provides the shortest focus and quickest financial advantage (combine
harvester)
 Always look for the weighed shortest job first (WSJF)
 WSJF = cost of Delay(CoD) / job duration (size)

 In the general case, give preference to jobs with shorter duration and higher CoD, using weighted shortest
job first (WSJF):
 Components of the CoD
These can impact different stakeholder groups differently
1. User business value  relative value to customer or business
2. Time criticality  how user/business value decays over time
3. Risk reduction and opportunity enablement (RR&OE) what else can this do for our business?

Calculate WSJF with relative estimating

WSJF stakeholders: Business Owners, Product Managers, Product Owners, and System Architects

Lesson 4.3 PI Planning

Essential – must do this otherwise not doing SAFe

Program Increment (PI) Planning is a cadence-based event that serves as the heartbeat of the Agile Release Train
(ART), aligning all teams on the ART to a shared mission and Vision.
This is the heart beat to the ART

Spend 2 DAYS every 10 – 12 weeks

Aligns ALL TEAMS on the ART – 50 to 125 people

PRODUCT MANAGER owns the FEATURE PRIORITIES

DEV TEAMS own STORY PLANNING

Draft in specialists as needed during the planning – opportunity for teams to collaborate

Architect/Engineering and UX work as intermediaries for governance, interfaces, and dependencies

Benefits of PI Planning
► Establishing personal communication across all team members and stakeholders
► Aligning development to business goals with the business context, Vision, and Team/Program PI Objectives
► Identifying dependencies and fostering cross-team and cross-ART collaboration
► Providing the opportunity for just the right amount of architecture and Lean User Experience (UX) guidance
► Matching demand to capacity, eliminating excess work in process (WIP)

SAFE notes
► Fast decision making

 What is the PI Planning Process?

Vision and top 10 features input  PI planning  produces team and Progrma PI objectives and the Program board

 Create alignment with PI Objectives

Similar to a SPRINT GOAL

 Objectives are business summaries of what each team intends to deliver in the upcoming PI.
 They often directly relate to intended Features in the backlog  features tend to be 2 weeks in duration
o Committed objectives  what we’ve committed to deliver
o UNCOMMITTED objectives  Uncommitted objectives help improve the predictability of delivering
business value
 ► They are planned and aren’t extra things teams do ‘just in case you have time’
 ► They are not included in the commitment, thereby making the commitment more reliable
 ► If a team has low confidence in meeting a PI Objective, it should be moved to uncommitted
 ► If an objective has many unknowns, consider moving it to uncommitted
 ► Uncommitted objectives count when calculating load
 Actively participating in a simulated PI Planning event will enable you to improve: communication; setting
objectives; managing risks; estimating capacity

Simulation exercise:

 Expect this first PI Planning to feel a bit chaotic. Future PI Planning meetings will become more routine.

Product Owners:

 You have the content authority to make decisions at the user Story level

Scrum Masters:

 Your responsibility is to manage the timebox, the dependencies, and the ambiguities

Agile Team:

 Your responsibility is to define user Stories, plan them into the Iteration, and work out interdependencies
with other teams

Don’t forget at the end of day 1 - management meet to make adjustments to scope and objectives based on the
day’s planning.

Often changes will be needed to the plan these may include:

► Possible changes:

SAFE notes
 – Business priorities
– Adjustment to Vision
– Changes to scope
– Realignment of work and teams

End of day 2

Recap day 2:

PI Planning – essential

Unlock knowledge of knowledge workers  INTRINSIC MOTIVATION  autonomy / mastery / purpose

Principle 9 – push decisions to the edges  centralise strategy BUT localise execution – autonomy

Principle 10 – what is value  deliver it quickly and effectively

Then establish team and technical agility

Must consider the TEAM TOPOLOGY  Teams in the ART  organised to enable FLOW 

Stream aligned

Complicated sub system

Platform teams

Enabling teams

Design thinking

First understand the problem

Second design the correct solution

 Features represent the work on the ART  come from everyone  must ID the acceptance criteria
 WSJF  weighted shortest job first  work with the CoD – cost of delay
 PI planning you’ll get INTERDEPENDENCIES between teams  important to show these on the board 
teams MUST negotiate with each other
 OBJECTIVES  high level statements on what we are going to deliver through the ART  features make
good goals
 IMPORTANT  make sure the teams make the STORIES during the PI planning session

Start Day 3:

4-63 Draft plan review  go through capacity / load / risks / objectives  provide visibility

 Note 100% utilisation is not good  need slack

 Keep this exercise quick  get everyone to hear presentation  not really detailed
 Key message  are Needs being MET?????

Note: carrying on with PI Planning

SAFE notes
 With FINAL PLAN REVIEW this must be quick  looking mainly for program risks and impediments  if you
have 12 teams each taking 10 minutes – this is 120 minutes  TOO LONG

 Build the final plan

o Business Owners  do you accept the plan???
o TEAMS  continue planning  its extreme cases the ART can be closed down – unlikely

RISKS

ROAM  categories

Resolved record at program level  risks will need senior involvement  throw them out there

Owned See who takes them on  this is a PULL MECHANIC  if not the RTE takes over

Accepted negotiations of who is going to do it

Mitigated

 Next is the confidence vote  the FIST OF CONFIDENCE no fingers no confidence; 5 fingers total
confidence
o 2 points 1. teams agree; 2. Teams escalate
 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
 Anything less than a 3 can be a problem  stop and reflect  could be a minor issue BUT could also
result in replanning  ouch

Run a planning Retrospective

 Need to start thinking about the next PI planning event

 Needs to be quick and effective  ask 3 questions
o What went well
o What didn’t
o What can be done better next time?
 Ask what 3 things would you address in the next PI
 Challenges  feedback must be addressed
 Engineers aren’t often involved in this event  mainly PO / BO / SM

4.4 Develop on Cadence; release on demand

 Manage the flow of work with the KANBAN  provides transparency and collaboration


Art events drive the train  closed loop

The outer ring is for the ART  the inner ring is for the teams

 ESSENTIAL  must sync aspects together  SCRUM OF SCRUMS & PRODUCT OWNERS
 Usually this is done weekly 30 – 60 minutes  known as the ART SYNC
 The ART SYNC coordinates progress

SAFE notes
 o SOS  Visibility into progress and impediments ▸ Facilitated by RTE ▸ Participants: Scrum Masters,
other select team members, SMEs if necessary
o PO Sync  Visibility into progress, scope, and priority adjustments ▸ Facilitated by RTE or PM ▸
Participants: PM, POs, other stakeholders, and SMEs as necessary
 Demo the full integrated system every 2 weeks
o Integrate ALL TEAMS  how are we doing?  use SYSTEM TEAM to integrate these requirements
o This provides closure to the accountability loop (visibility) and must happen
 Innovation and Planning IP iteration  is an iteration within the PI – program increment
o Usually a well-planned event  2 weeks
o ► Innovation: Opportunity for innovation, hackathons, and infrastructure improvements
o ► Planning: Provides for cadence-based planning
 IP iteration calendar covers the 2 weeks of the IP event  providing a BUFFER
 Without the IP event  will result in problems ► Lack of delivery capacity buffer impacts predictability ►
Little innovation; tyranny of the urgent ► Technical debt grows uncontrollably ► People burn out ► No
time for teams to plan, demo, or improve together
 INSPECT AND ADAPT EVENT
o Three parts of Inspect and Adapt:
o 1. The PI System Demo  SHOW AND TELL
o 2. Quantitative and Qualitative Measurement
o 3. Problem-Solving Workshop
 This is limited to 3 – 4 hours per PI
 At the end of PI  complete the PI system demo
o At the end of the PI, teams demonstrate the current state of the Solution to the appropriate
stakeholders.
o ► Often led by Product Management, POs, and the System Team
o ► Attended by Business Owners, ART stakeholders, Product Management, RTE, Scrum Masters, and
o Teams


Teams met to discuss and decide what value HAS been achieved

This is PROGRAM PERFORMANCE REPORTING

Compare planned BV against ACTUAL  show %

 MEASURE ART PREDICTABILITY  aim for 80%- 100% band  shows you’re in control
o Predictability is essential  you can’t work out your performance systemic optimisation if you aren’t
predictable  why? well you won’t be able to work out if the results came from your changes or are
just randomness i.e. unpredictable
 Run a problem-solving workshop
o Address the problems from the train  decide on actionable options  take forward

4.5 Building a continuous delivery pipeline with DevOps

The continuous pipeline is regular release to the operations team
through transactions  which will REDUCE HOLDING COSTS

REMEMBER  DevOps is a MINDSET

TO DELIVER MAX SPEED AND STABILITY

C.A.L.M.R / calmr
SAFE notes
► Culture - Establish a culture of shared responsibility for development, deployment, and operations.

► Automation - Automate the Continuous Delivery Pipeline.

► Lean flow - Keep batch sizes small, limit WIP, and provide extreme visibility.

► Measurement - Measure the flow through the pipeline. Implement full-stack telemetry.

► Recovery - Architect and enable low-risk releases. Establish fast recovery, fast reversion, and fast fix-forward.

 Need a continuous delivery pipeline

 ART runs this pipeline  can be shared between ARTs  each ART maintains or shares a pipeline
 You must run CONTINUOUS exploration to truly understand the customer needs
 Must have continuous integration  a critical technical practice of the ART  robots continue to test
 Must have continuous deployment  multiple releases into the work environment
 Decouple release elements from the whole solution  breakdown into individual components and release
on their own merits  this is more RAPID and brings quicker BENEFITS
o Empower teams to make this decision (submarine) – allow to test and work independently of other
teams
o Decouple into modules rather than on monolithic whole
 Separate deploy / deployment and release  ► Separate deploy to production from release
o ► Hide all new functionality under feature toggles
o ► Enables testing background and foreground processes in the actual production environment
before exposing new functionality to users
o ► Timing of the release becomes a business decision
o Release to small audiences first  grow accordingly  release feature by feature  allows for
testing in background
 Release on demand  watch for patterns and release accordingly
 Continually improve architecture  Architectural Runway is existing code, hardware components,
marketing branding guidelines, etc., that enable near-term business Features.
o ► Enablers build up the runway
o ► Features consume it
o ► Architectural Runway must be continuously maintained
o ► Use capacity allocation (a percentage of train’s overall capacity in a PI) for Enablers that extend
the runway
o This helps to maintain an FFP architecture for the future

Lesson 5 LEAN PORTFOLIO MANAGEMENT

The lean portfolio looks after MANY ARTs

Why Lean Portfolio  traditional approaches to portfolio management were not designed for a global economy or
the impact of digital disruption. These factors put pressure on enterprises to work under a higher degree of
uncertainty and yet deliver innovative Solutions much faster.

SAFE notes
5.1 Defining a SAFe portfolio
 It’s a set of development value streams (through ARTs) allowing business to deliver what is needed and
when  such as sales / accounting / marketing / IT.
o ► Each Value Stream builds, supports, and maintains Solutions
o ► Solutions are delivered to the Customer, whether internal or external to the Enterprise
 Enterprise may have one or multiple portfolios  these are seen as INVESTMENT VEHICLES to set up a
structure within an organisation
 Define the PORTFOLIO with a CANVAS template  collaborative event  generates business ideas 
defines the DOMAIN of the portfolio and other key events
 Map solutions by HORIZON MODELS
o Horizon 3  looking for investment return in 3 years
o Horizon 2  2 year look ahead – can decommission here if necessary
o Horizon 1  looking for investment return within 1 year
o Horizon 0  expenditure now outstrips return  preserve your profits by decommissioning
o If not can result in ZOMBIE systems – draining resources
o KEY POINT  always invest in the future to have a future

5.2 Connect the PORTFOLIO to the ENTERPRISE strategy

 Strategy and investment funding ensure that the entire portfolio is aligned and funded to create and
maintain the Solutions needed to meet business targets.


Needs lots of inputs

Formulation

 Next  connect the portfolio to enterprise with strategic themes

o These are destination points where we want to get too  can be measured
 Influence of strategic themes 
o Strategic Themes influence portfolio strategy and provide business context for portfolio decision-
making.
o Strategic themes examples
 Setting up overseas channel
 Tetro pack – use less plastic
 Deuscha Bank – looking to expand into USA – CEO then does a U-turn

5.3 Maintaining the Portfolio Vision

 Identify portfolios future state via a SWAT analysis
 Run a TOWS  ► The key difference between the SWOT and TOWS analyses are the outcomes that they
create
 ► TOWS analysis is used primarily for identifying strategic options to create a better future state
 ► SWOT analysis is a great way to uncover the current situation of your Value Stream, product, or portfolio
o Envision the future state ► The portfolio canvas captures the current state
o ► Use SWOT and TOWS to brainstorm potential future states
o ► Evaluate your options and select a future state
o ► Identify the Epics that will get you to this future state

SAFE notes
  Express the future state as a VISION  convince certain people to come on the journey

5.4 Realising the portfolio VISON through EPICS

 What are portfolio vision EPICS  2 types?
o Business epics
o Enabler epics  similar to indirect value (improvements)
 Portfolio Epics  more cross functional
 All Epics require a BUSINESS CASE
 NFR’s apply to everything above them in the BACKLOG
 EPICS initially described in the EPIC HYPOTHESIS STATEMENT

Epics are described with four major fields in the hypothesis statement:

► The value statement – Describes the Epic in general terms: the “for-who-the …” portion

► Business outcomes hypothesis – States the quantitative or qualitative benefits that the business can anticipate if
the hypothesis is proven to be correct

► Leading indicators – Describe the early measures that will help predict the business outcomes

► Non-functional requirements (NFRs) – Identify any NFRs associated with the Epic  more detail may be required

5.5 Establishing Lean Budgets and Guardrails

Problem – cost centre budgeting

A project requires collaboration of cost centres and assignment of people, budget, and schedule. It takes multiple
budgets to build a single project budget.

This leads to: ▸ Slow, complex budgeting process; ▸ Leads to utilization-based planning and execution; ▸ Low
program throughput; ▸ Moves people to the work

 Project overruns cause re-budgeting and increase the cost of delay – question: does this really matter?
 Solution  fund VALUE STREAMS on the ARTs and not PROJECTS
o Funding Value Streams provides for full control of spend, with:
o ► No costly and delay-inducing project cost variance analyses
o ► No resource reassignments
o ► No blame game for project overruns
 Budgets are not affected by Feature overruns or changing priorities  using this approach means we keep
the focus on WHAT needs to be completed  true value  subordinate all other lower value features 
without the need of lengthy project interventions
 Maintain the Guardrails  Lean Budget Guardrails describe the policies and practices for budgeting,
spending, and governance for a specific portfolio. SAFe provides strategies for Lean budgeting that
eliminates the overhead of traditional project-based funding and cost accounting
o Maintain the guardrails- how?
 ► Apply investment horizons
 ► Utilize capacity allocation
 ► Approve Epic initiatives
 ► Continuous Business Owner engagement  get involved in planning events

SAFE notes
5.6 Establishing Portfolio Flow
 Govern Epic flow with the Portfolio Kanban
o ► Makes largest business initiatives visible
o ► Brings structure to analysis and decision-making
o ► Provides WIP limits to ensure the teams analyse responsibly
o ► Helps prevent unrealistic expectations
o ► Helps drive collaboration among the key stakeholders
o ► Provides a transparent and quantitative basis for economic decision-making
 EPICS flow through the portfolio Kanban 
The Portfolio Kanban system describes the
process states that an Epic goes through from
the funnel to done.
 The EPIC OWNER can support this event
 NOTE: you must FEED the portfolio tunnel
o Inputs can come through many ARTs
 MVPs foster innovation and control scope  use experiments to decide if we are going to move forward
with the idea
o What is the minimum we can do to make this acceptable and gain sign off?

Lesson 6: Leading the Change

Why Lean Agile Leadership?

An organization’s managers, executives, and other leaders are responsible for the adoption, success, and ongoing
improvement of Lean-Agile development and the competencies that lead to Business Agility. Only they have the
authority to change and continuously improve the systems that govern how work is performed.

6.1 Lead by example

 ► Authenticity requires leaders to model desired professional and ethical behaviours
 ► Emotional intelligence describes how leaders identify and manage their emotions and those of others
through self-awareness, self-regulation, motivation, empathy, and social skills
 ► Lifelong learning depicts how leaders engage in an ongoing, voluntary, and self-motivated pursuit of
knowledge and growth, and they encourage and support the same in others
 ► Growing others encourages leaders to provide the personal, professional, and technical guidance and
resources each employee needs to assume increasing levels of responsibility
 ► Decentralized decision-making moves the authority for decisions to where the information is Leaders
provide organisations with patterns of EXPECTED BEHAVIOURS


Generative culture – performance

related is seen as the most desirable

 Leading the change

o 8 points by John Kotter
 ► Establish a sense of urgency
 ► Create a powerful guiding coalition

SAFE notes
  ► Develop the vision and strategy
 ► Communicate the vision
 ► Empower employees for broad-based action
 ► Generate short-term wins
 ► Consolidate gains and produce more wins
 ► Anchor new approaches in the culture
 Be aware of the SAFe implementation road map

TRAIN EVERYONE  LAUNCH TRAINS

Pick everyone that will help determine what is

needed

Lesson 8: Reaching the SAFe tipping point

8.1 Establishing a vision for change
 Reaching the tipping point for Agile at Scale
o ► To achieve effective change, every Enterprise must reach its ‘tipping point’—the point at which
the overriding momentum is to change, rather than resist it.
o ► Two primary reasons to change:
o A burning platform – The company is failing to compete, and the existing way of working is
inadequate to achieve a new solution in time.
o Proactive leadership – In the absence of a burning platform, leadership must create the sense of
urgency to proactively drive change by taking a stand for a better future state.
 Establish the vision for change  motivate people in the benefits that will follow change  empower
people to drive the change forward

8.2 Building a powerful guiding coalition

 ► Transformations led by a sole leader or a low credibility committee rarely succeed
 ► There is a need for an effective team that has:
o Enough powerful people to drive change and deter blocks
o The expertise to make informed and quick decisions
o The credibility to be taken seriously
o Leaders who can set the Vision and leaders who can implement
 SPC’s communicate the vision and urgency  Motivating change requires a sense of urgency; Leaders must
communicate the challenges the company faces
 NOTE: LEADING SAFE is designed to train executives, managers and leaders
 NOTE: SAFe for Government: Lean-Agile practices in a government context

 LACE  LEAN AGILE CENTER OF EXCELLENCE

 LACE is your Agile team  it is ongoing
 LACE  ► A LACE Typically operates as an exemplary Agile Team of four to six individuals per business unit.
 ► A Scrum Master facilitates the process and helps remove roadblocks.
 ► A Product Owner works with stakeholders to prioritize the transformation backlog.
 ► The team is cross-functional. Credible people from various functional organizations are integral members
SAFE notes
  of the team. They can address backlog items wherever they arise, be they organizational, cultural, process,
or technology.
 ► A senior C-level leader typically acts as the team’s Product Manager.
 Compile a LACE Mission statement slide 8-20 is an example
 Create a baseline with business agility assessment

Lesson 9: Designing the Implementation

9.1 Designing value streams and Agile release trains
 Why organise around value?
o ► Fewer handoffs, faster value delivery
o ► Easier to build in quality
o ► Built-in alignment between the business and technology
o ► Optimizing the system as a whole
o ► Result: Faster delivery, higher quality, higher Customer satisfaction
 Value streams in SAFe
o 1. Operational Value Streams  The sequence of activities needed to deliver a product or service to
a Customer. Examples include manufacturing a product, fulfilling an e-commerce order, admitting
and treating a patient, providing a loan, and delivering a professional service.
o 2. Development Value Streams  The sequence of activities needed to convert a business
hypothesis into a technology-enabled Solution that delivers Customer value. Examples include
designing and developing a medical device, developing and deploying a CRM system, and an
eCommerce web site
 Steps for delivering value streams and ARTs
o 1. Identify an Operational Value Stream
o 2. Identify the Solutions the Operational Value Streams use or provide to customers
o 3. Identify the people who develop and support the Solutions
o 4. Identify the Development Value Streams that build the Solutions
o 5. Realize Development Value Streams into ARTs
 Types of operational value streams - examples
o Fulfillment Operational Value Stream for a consumer loan
o Manufacturing Operational Value Stream for a vehicle
o Software product Operational Value Stream
o Supporting Operational Value Stream for annual audit
 Large enterprises may have many operational value streams  not essential  car manufactoring may have
one or two  size does not translate into multiple OVS’s
 Questions for Identify operational value stream maps slide 9-10
 Example of a loans operational value stream map


 Grey figures above are in the OVS  the dark figures are the customers
 The solutions we build support these
operational value streams
 Are any of these systems shared with other
OVS’s

SAFE notes
 Are any systems listed external, these could
be services that we need
 Are systems shown tightly couple  in other words, update one you’ll need to update them all
 People who develop and support the solution
o They keep the servers running
o Complete audits


 Build a fulfilment development value stream


The yellow tickets are the system

Break these down into DVSs to

deliver those yellow tickets

 There are also software product VSs / manufacturing VSs

 Supporting multiple development stream patterns  create an ENTERPRISE RESOURCE PLAN  ERP
o This can encompass many different value streams across the enterprise
 You must always identify the development value streams  group them together  follow logic
 Add resources to these groups as necessary  potentially from all over the world
o If not embedded will slow down ability to deliver i.e. having a legal team present
 Sizing Agile Release Trains  Effective Agile Release Trains are most efficient at about 50 – 125 people
o This is known as the Dumbars number
o Empirical evidence: Beyond 125, logistics and inter-team dependencies are more difficult. Alignment
and governance are harder to achieve.
o Do not go beyond 125 within the ART
 Realize Value Streams with Solution Trains and ARTs
o Some Value Streams fit well within the limit, and can be realized by a single ART
o Multiple, smaller Value Streams can be realized by a single ART
o Larger Value Streams require multiple ARTs in a Solution Train  larger ARTs can be broken down
 Guidelines for splitting a large value stream
o ► Focused on a holistic system, products, or set of services
o ► Long-lived, consistently delivers value over time
o ► Minimize dependencies with other ARTs
o ► Can release value independently from other ARTs
 Multiple ARTs brought together is known as SOLUTION TRAIN
 ART topologies
o Stream-aligned ARTs are aligned to a single, valuable stream of work, empowered to build and
deliver Customer or User value as quickly, safely, and independently as possible, without requiring
hand-offs to other ARTs to perform parts of the work (favoured)
o Complicated-subsystem ARTs are responsible for building and maintaining a part of the system that
depends heavily on specialist knowledge, thereby reducing the cognitive load on other ARTs.
o Platform ARTs provide the underlying internal services required by streamaligned ARTs to deliver
higher-level services or functionalities, thus reducing their cognitive load.
 Stream aligned can get complicated and lead to technical debt
 Need excellent coordination between the various levels
 Organizing ARTs with ART Topologies in a Solution Train

SAFE notes
 ► Stream-aligned ARTs (best)

o – By product, Solution, or service

o – By Customer or market segment
o – By Solution feature areas
o – By value streamlets
o – New product innovation

► Complicated Subsystem ART

o – Highly specialized system components

o – Safety critical systems elements
o – Specialty algorithm or business rules
o – Part of a cyber-physical system

► Platform ART

o – Sets of services consumed by other ARTs

 When realising the ARTs  if you have groups larger than 125  you’ll need to break them down in
multiple value stream trains  DON’T CREATE SILOS
 DON’T FORGET
o ART needs a PI planning event
 Some groups of resources will not be required to form a TRAIN  instead bundle them onto a train 
they’re not an ART
 SAFe Collaborate gives distributed teams the interactive templates they need to work together in the same
ways that we work in person  this is known as VSAIW template

9.2 Creating the implementation plan

 Selecting your first ART  Opportunistic ARTs are found at the intersection of converging factors.
o Significant program challenge or opportunity
o Clear products or Solution
o Collaborating teams
o Leadership support
 First ART must be successful  don’t waste time  increase the CoD
 ARTs can run in parallel to reduce the cost of delay CoD  business don’t like waiting too long
 Create the implementation plan 
o ► Vision without an action plan leaves people unmotivated
o ► A transformation Roadmap defines how to:
 – Incrementally implement the transformation
 – Inspect and adapt for course correction
o ► The ART rollout can be done sequentially or in parallel
 Outputs from this process are used to create the development value stream canvas
 Your ART organisation will evolve over time  a few rules of thumb
o 1. The answer may not be clear. Consider the trade-offs, launch your initial ART(s), and inspect and
adapt. Understand your pain points over time and how they may relate to your ART definitions.
o 2. ARTs are long-lived, but if alignment on a design cannot be reached, pick one and test it for a few
PIs.
o 3. Many Enterprises re-evaluate their ART definitions due to initial compromises, revised portfolio
investments, or new target optimizations.
o ► Early compromises may be made due to the impact of organizational change.
o ► Target optimizations may change over time.

SAFE notes
Lesson 10: Launching an ART
10.1 Preparing for ART launch

 Set the launch date

o A forcing function is a commitment that forces a sequence of actions to happen. Use it to start your
train.
o ► By scheduling the PI Planning event, you will create the timebox in which the preparation must
happen.
o ► This will minimize the expansion of work during preparation. Not everything can (or needs to) be
o perfect.
o ► Assure people that the Inspect and Adapt Workshop creates a closed-loop system so that
impediments can be made visible and addressed as soon as possible.
 Train ART Leaders  focus on mindset and culture
o ► Launching the first ART is crucial. It builds a framework to allow employees to apply the Vision to
o meaningful change.
o ► Training the leaders helps them create the mindset they need to empower employees for further
o action.
o ► Training gives stakeholders the skills and motivation they need to change the organization.
o ► As a team of teams, the ART removes silos that inhibit flow.
 Who should attend the leading SAFe course ?
o POs
o Program managers
o Executives / business owners
o Change agents
o Scrum masters SMs
 Define the ART canvas  can have multiple PMs and system architects
 NOTE  ONLY ONE RTE per ART
 When would you use
o Stream aligned teams
o Platform teams
o Complicated subsystems
o Enabling teams
 Capture the teams, roles and locations
on a team roster
o Note a developer in SAFe is usually a system team member and not a developer in the true sense
 Determine who will play the parts in the ART
o Program roster  roles may be missing  UX, operations, system team
 Prepare ART Launch
o Once an ART has been selected for launch, the SAFe ART Readiness Workbook will guide you through
the preparation.
 ► ART readiness checklist
 ► Content checklist
 ► Facilities checklist
 ► Supplies checklist
 ART readiness checklist
Planning scope and context  Is the scope (product, system, technology domains) of the planning process
understood? Have we identified our Value Stream(s) and ARTs?

SAFE notes
Release Train Engineer (RTE)  Have we identified the Release Train Engineer? Do they understand the scope of
the role in preparing the organization and preparing for the PI Planning event?
Planning time frame, Iteration, and PI cadence  Have we identified the PI Planning dates, the Iteration cadence,
and the PI cadence?
Agile Teams  Does each Feature/component team have an identified SM and PO?
Team makeup / commitment  Are there dedicated team members on every team?
Agile Team attendance  Are all team members present in person or are arrangements made to involve them
remotely?
Executive, Business Owner participation  Do we know who will set the business context and present the Product /
Solution Vision?
Business alignment  Is there reasonable agreement on priorities among the Business Owners and Product
Management?
Vision and Program Backlog  Is there a clear Vision of what we are building, at least over the next few PIs? Have
we identified the top 10 or so Features that are the subject of the first PI?
System Team  Has the System Team been identified and formed?
Shared Services  Have the Shared Services (User Experience, Architecture, etc.) been identified?
Other attendees  Do we know what other key stakeholders (IT, infrastructure, etc.) should attend?
Agile Lifecycle Management tooling  Do we know how and where Iterations, PIs, Features, Stories, status, etc. will
be maintained?
Development infrastructure Do we understand the impact on and/or plans for environments (for example,
Continuous Integration and build environments)?
Quality practices Is there a strategy for unit testing and test automation? Are there any other practice guidelines?

10.2 training the teams and launching the ART

ART readiness checklist  similar to the PAQ in Agile

Top 9 are MUST HAVES

Bottom 6 are OPTIONAL

NOTE: SM is dedicated to

 Their ART but can be

shared

D – Determine if necessary or
not

 5 elements that we
need to get to the
planning cycle
o Prioritised back
log  PM and
PO
o Facilities and
facilitation 
SM and RTE
o Architectural
Runway 
system
SAFE notes
 architects  need to know DoD  build backlog  ID technical features to support the main
backlog  estimate features
o Aligned stakeholders  train them  develop vision and road map
o Trained teams  train as late as possible  doing their day jobs
 NOTE: the DoD is needed for technical understanding


 Benefits of training all the teams on the ART together up to 125 people  1. Accelerated learning, 2. A
common scaled Agile Paradigm, 3. Cost-efficiency, 4. Collective learning
 SAFe for TEAMS course  good at building team spirit
 The quickstart approach to the ART launch
o When you find a Value Stream, go all in and all at once for each ART. The one week launch is a
proven adoption model.
o Still a good idea to cover over 2 weeks

 The importance of the first PI planning

o ► First impression of SAFe
o ► Generates a short-term win
o ► Builds the ART as a team
o ► Teaches teams about assuming responsibility for planning and delivery
o ► Creates visibility
o ► Creates confidence in the commitment of Lean-Agile leaders to the transformation
 Distributed planning meetings: distributed teams
o ► If members on the same team are distributed:
o – Establish more planning overlap time for intra-team collaboration
o – Have more intra- and inter-team checkpoints and synchronization
o – Consider the non-ideal situation of concurrent planning (someone may stay up all night!)
o ► If a program has distributed whole teams:
o – Team planning is easier; however, dependency management with other component teams
becomes more complex
o – Have more inter-team checkpoints and synchronization
o – Leverage a centralized program board

 Guidance for distributed planning meetings  may require more preparation and facilitation
o ► Have a dedicated facilitator and tech support person at each location
SAFE notes
 o ► Test audio, video, and presentation-sharing connectivity, and then test it again
o ► Have a common understanding of how plans will be shared (Video, Wiki, Email, PowerPoint, etc.)
o ► Establish team-based audio/video communication for breakout sessions
 Always show a respect for people and cultures  especially across time zones
o SAFe collaborate for distributed PI planning events  SAFe Collaborate gives distributed teams the
interactive templates they need to work together in the same ways that we work in person.
 PI Planning templates include
o ▸ ROAM board
o ▸ Program board
o ▸ Team boards
o ▸ PI Planning room
o ▸ SoS radiator

Lesson 11: Coaching ART Execution

11.1 Coaching the Train and the Teams

 Short term wins  showcase your success
o ► The PI Planning event itself is a short-term win, as it creates clear commitment to goals.
o ► Next, it’s important to showcase that the ART is meeting its PI Objectives and relentlessly
improving its program performance.
o ► Invite stakeholders and showcase the success of the Team Demos and System Demos, as well as
the PI System Demo.
o ► Communicate real wins, not gimmicks.
o ► The first PI is the most crucial to lead. Existing team, program, and organizational issues become
highly visible. You must have confidence and clarity.
o ► You will provide ongoing program consulting and team coaching to build the organization’s Lean-
Agile capabilities.
 Team activities and events are opportunities to coach the team
o ► Helping teams plan, execute, review, and retrospect the first Iterations
o ► Coaching new Scrum Masters and Product Owners in their roles
o ► Initiating and supporting Agile technical practices
o ► Helping teams establish the infrastructure, practices, and culture needed for DevOps and the
Continuous Delivery Pipeline
 Coaching the ART typically starts with essential ROLES and events
o ► Helping to build and maintain the Vision and Roadmap
o ► Helping define and manage the Program Kanban and Program Backlog
o ► Coaching Product Managers, System Architects, and RTEs in their roles
o ► Supporting frequent system-level integration, including the System Demo
o ► Participating in scrum of scrums, PO sync, and ART sync meetings
o ► Helping to facilitate Inspect and Adapt and follow-up of backlog improvement items
o ► Supporting the System Team and others in building development and deployment infrastructure
and automation
o ► Keeping a focus on the Architectural Runway
o ► Supporting release management in the new way of working
o ► Supporting or delivering additional training
o ► Establishing communities of practice (CoPs)

11.2 continually improving program performance with inspect and adapt

SAFE notes
 Improving inspect and adapt
o ► Three parts of Inspect and Adapt:
 1. The PI System Demo
 2. Quantitative and Qualitative Measurement
 3. Problem-Solving Workshop
 ► Timebox: 3 – 4 hours per PI
 Attendees  teams and stakeholders
 PI SYSTEM DEMO
o Very high level
 ► At the end of the PI, teams demonstrate the current state of the Solution to the
appropriate stakeholders
 ► Often led by Product Management, POs, and the System Team ► Attended by Business
Owners, program stakeholders, Product Management, RTE, Scrum Masters, and teams
 ► Suggested timebox: 45 – 60 minutes
 Team performance assessment
o ► All teams’ PI Objectives were assigned a business value from 1 to 10.
o ► Review and rate your PI achievements: – How well did you do against your stated objectives,
including timeliness, content, and quality? – Rate on a scale from 0 up to the planned business value
assigned during PI Planning.
o ► Average these across all objectives and give yourself a program percent achievement score.
o ► Suggested timebox: 45 – 60 minutes
o Separate from business value  need to be in the gold band
 Team PI performance report
o ► Planned total does not include uncommitted objectives
o ► Actual total includes uncommitted objectives
o ► Percent achievement equals actual total divided by planned total
o ► A team can achieve greater than 100% (as a result of uncommitted objectives achieved)
o ► Effort required for uncommitted objectives is included in the load (i.e., not extra work the team
o does on weekends)
o ► Individual team totals are rolled up into the program predictability report

 Collect all necessary program metrics  must be measurable

 Problem solving workshop review 11-16
o After a short retrospective, teams systematically address the larger impediments that are limiting
velocity by using root cause analysis.
o Solve one problem per team  as many problems as there are teams
 Problem solving board  fishbone
 Agree on the problem to solve
o ► Clearly stating the problem is key to problem identification and correction
o ► You must define the undesirable problem or situation, so everyone involved in the
countermeasures understands
o ► A clearly defined problem focuses your investigation efforts and saves time. Honest effort at
careful definition will avoid the 'ready, fire, aim' approach that is so common in problem-solving
o ► A problem that is not well-defined may result in failure to reach the proper countermeasure
 Anatomy of a well-defined problem  Think about the What, When, Where, and Impact
 Finding the root cause using 5 whys
o ► The Five Whys is a proven problem-solving technique used to explore the cause-and-effect
relationships underlying a particular problem
o ► The key is to avoid assumptions and logic traps
o ► Instead, trace the chain of causality in direct increments from the effect to a root cause
 ART execution artifacts in the PI Execution toolkit
o ► SAFe ART Events and Activities presentation
o ► Inspect and Adapt Event template
o ► Program Performance Metrics spreadsheet
SAFE notes
 o ► Program Predictability Measure spreadsheet
o ► Self-Assessments and Metrics resources

Lesson 12 Extending to the portfolio

12.1 Launching more ARTs and value streams

 You can launch more ARTs in the same or NEW value streams
 ► Leverage wins to launch more ARTs and scale the implementation
 ► Launch all ARTs in a Value Stream
 ► Move to the next Value Stream
 ► Celebrate short-term wins but don’t declare victory too soon!
 ► Keep urgency high
o ► Don’t forget to support existing trains as you scale
 Collect data and manage impediments
 ► Number of practitioners on each ART
 ► Start and end date for each Kanban state
 ► Number of people trained
 ► Date of first PI Planning
 ► Date of second PI Planning
 ► Program predictability measure

12.2 enterprise Solution delivery

Why enterprise solution delivery?
 Humanity has always dreamed big; and scientists, engineers, and software developers then
 turn those big dreams into reality. That requires innovation, experimentation, and knowledge
from diverse disciplines. Engineers and developers bring these innovations to life by defining
 and coordinating all the activities to successfully specify, design, test, deploy, operate,
evolve, and decommission large, complex solutions.
 The Enterprise Solution Delivery competency describes how to apply Lean-Agile principles
and practices to specification, development, deployment, operation, and evolution of the
world’s largest and most sophisticated software applications, networks, and cyber-physical
systems.

 For large systems, Solution Trains align ARTs to a common mission
 ARTs power the solution train
o ► Each ART within a Solution Train contributes to the development of a large Solution
o ► Solution Management, Solution Architect/Engineering, and the Solution Train Engineer foster the
coordination and the delivery of value

 Coordinate planning across ARTs with pre- and post-PI Planning

o ► Typically attended by Customers, STE, Solution Mgmt, Solution Architects/Eng, Solution Train
stakeholders, and select representatives from ARTs and Suppliers
o ► The pre-PI Planning meeting helps build an aligned plan for the next PI and match Solution
demand to ART capacities
o ► The post-PI Planning meeting reviews, recaps, communicates, and provides feedback

 Solution Demo requires ‘continuish’ integration

o  Frequent Solution integration and testing provides the best objective evidence
o  A joint responsibility of ART’s and Solution Train’s System Teams
o  Provides early validation and regular risk reduction
o  Increases actual velocity

 Capture system specification as fixed/variable Solution Intent

SAFE notes
 o Solution Intent: Single source of truth as to the intended and actual behaviour of the Solution
 ► Records and communicates requirements and design decisions
 ► Supports compliance, contractually, traceability, high assurance
 ► Preserves flexibility to evolve toward optimum Solution alternative
 ► Fixes minimum requirement and designs
 Continuously address compliance concerns
 Build the solution and compliance incrementally
 Organize for value and compliance
 Release validated Solutions on demand
 Build quality and compliance in
 Continuously verify and validate

12.3 Extending the portfolio

 Traditional project portfolio management challenges
 Traditional project portfolio approaches inhibit the flow of value because of:
 ► Project cost accounting
 ► Annual planning and rigid budgeting cycles
 ► Perpetual overload of demand versus capacity
 ► Phase-gate approval processes that fail to mitigate risk
 ► Overly detailed business cases with speculative ROI
o Portfolios are generally not lean at this point



Moving to a LEAN portfolio management

Traditional approach / lean agile approach

 Lean portfolio management



 Align organise strategise operate govern measure and grow

12.4 Participatory Budgeting

The enterprise establishes the total portfolio budget

 Changes to Strategic Themes

 Enterprise & portfolio performance
 Market changes
 Product feedback
 Internal/external economic conditions

This is our budgeting starting point

 Value stream budgets are adjusted over time

o ► Typically, Value Stream budgets are adjusted twice annually
o ► Adjusted less frequently and spending is fixed for too long, and it may limit agility
SAFE notes
 o ► Adjusted more frequently and planning may be more challenging
 Need to balance budgets across the multiple value streams  force portfolio to meet demands
 Participatory budget overview
o Current value stream budgets feed into  participatory budgeting forums  these get input from
 Business context
 Total portfolio budget and guardrails
 Run the business solution investments
 Grow the business solution initiatives (EPICS)
o These in turn will produce the new value stream budget
o This is a series of negotiations between the teams  the minimum the value stream needs to keep
going  therefore the funds pass the value streams to fund the EPICS
o This is a STRATEGIC TOOL and not a TACTICAL TOOL

12.5 Establishing Agile portfolio operations

 Agile portfolio operations: Collaboration and responsibilities 12-30
 Agile portfolio operations coordinate and supports decentralized program execution, enabling operational
excellence.
o Coordinate Value Streams
o Support program execution
o Foster Operational Excellence
 You must coordinate the value streams  coordinate the releases  and release on demand
 The APMO supports portfolio operations and program execution
o Facilitates the portfolio sync
o Works with the LACE or lace to develop, harvest, and apply successful program execution patterns
across the portfolio
o Facilitates Lean budgeting and coordinates portfolio governance
o Fosters decentralized PI Planning and operational excellence
o Fosters more Agile contracts and leaner Supplier and Customer partnerships
o Some Enterprises refer to the APMO as a VMO (Value Management Office)
 Fostering operational excellence with the APMO
o ► Transitions themselves and the portfolio to new ways of working
o ► Participates in the SAFe rollout
o ► Helps cultivate and apply successful program execution
patterns across the portfolio
o ► Leads the move to objective Metrics and reporting
o ► Leads process excellence and supports RTEs (and STEs)
and Scrum Master CoPs
 Establish Lean portfolio management Events
o The effective operation of the LPM function relies on three significant events:
 ► Strategic Portfolio Review
 ► Portfolio Sync
 ► Participatory Budgeting
 LPM events overview
o Strategic Portfolio Review
 • Focused on achieving and advancing the portfolio Vision
 • Provides continuous strategy, implementation, and budget alignment
 • Typically held once a PI, at least one month before the next PI Planning
o Portfolio Sync
 • Focused on portfolio operations
 • Provides visibility into how well the portfolio is progressing toward meeting its objectives

SAFE notes
  • Typically held monthly and may be replaced on a given month with the Strategic Portfolio
Review
o Participatory Budgeting
 • Focused on establishing and adjusting Lean budgets
 • Provides a forum for stakeholders to decide how to invest the portfolio budget across
Solutions and Epics
 • Typically held every two PIs

12.6 Establishing Lean Governance

Lean governance manages spending, audit and compliance, forecasting expenses, and measurement.
 Forecast and budget dynamically
 Measure portfolio performance
 Coordinate continuous compliance
 Forecasting an Epic’s duration (and roadmap) requires an understanding of three data points:
 ► An Epic’s estimated size in Story points for each affected ART
 ► The historical velocity of the affected ARTs
 ► The percent (%) capacity allocation that can be dedicated to working on the Epic as
 negotiated between Product and Solution Management, Epic Owners, and LPM
 If the deadlines are forecast to be missed you must change the focus immediately

 Examples of Lean portfolio management
performance measures – metrics

 Development Value Stream key performance indicators (KPIs) are the quantifiable measures used to
evaluate how a Value Stream is performing against its forecasted business outcomes.
 Coordinate continuous compliance
 A Lean-Agile quality management system (QMS) improves quality and makes compliance
more predictable.
 Don’t  Defer compliance to the end of Solution development.
 Do  Validate ongoing compliance with relevant standards and regulations.

Lesson 13 Accelerating business agility

13.1 Establishing organisational Agility
Why organisational agility?

Without Organizational Agility, Enterprises simply cannot respond sufficiently to the challenges and opportunities
that today’s rapidly changing markets present. Without it, employees and the Enterprises associate an individual’s
value with their functional skills, rather than business outcomes.

SAFE notes
The Organizational Agility competency describes how Lean-thinking people and Agile Teams optimize their business
process, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to
capitalize on new opportunities.

 Grow Lean thinking people and Agile teams  use the Manifesto and Principles
 Implement Agile HR Practices
o 1. Embrace a new talent contract, explicitly acknowledge the need for value, autonomy, and
empowerment
o 2. Foster continuous engagement, to both the business and technical mission
o 3. Hire people for Agile attitude, team orientation, and cultural fit
o 4. Eliminate annual performance reviews. Replace with continuous iterative performance feedback.
o 5. ‘Take the issue of money off the table.’ Eliminate destructive financial incentives.
o 6. Support meaningful, impactful, and continuous learning and growth
 HR doesn’t really need to change  managers need to employ the right people with the right skills
 Analyse and improve business operations  identify the delays in the value stream and delete them
 What is strategy agility?
o Strategy Agility is the ability to change and implement new strategies quickly and decisively when
necessary and to persevere on the strategies that are working—or will work—if given sufficient focus
and time.
o If your strategy dynamics change then you need to improve also
 Market sensing  must adjust as the market evolves
 Flow strategy changes to how we execute  get the new EPICS identified and into the backlog as quickly as
possible
 Ignore Sunk costs  they have no baring on future affordability
 Change the network to meet changing mission demands  move people to where the demand currently
lays  hopefully not a hire and fire strategy

13.2 building a continuous learning culture

Why have a continuous learning culture?

In order to thrive in the current climate, organizations must evolve into adaptive engines of change, powered by a
culture of fast and effective learning at all levels. Learning organizations leverage the collective knowledge,
experience, and creativity of their workforce, customers, supply chain, and the broader ecosystem.

The Continuous Learning Culture competency describes a set of values and practices that encourage individuals, and
the Enterprise as a whole, to continually increase knowledge, competence, performance, and innovation.

3 elements make up the continuous learning culture:

o Learning Organisation:
 ► Personal Mastery – Build individual “T-shaped” breadth of knowledge in multiple disciplines
for deep and broad expertise
 ► Shared Vision – Leaders envision and articulate exciting possibilities and invite others to
contribute to a view of the future
 ► Team Learning – Teams achieve common objectives by sharing knowledge, suspending
assumptions, and ‘thinking together’
 ► Mental Models – Teams surface their existing assumptions and generalizations with an open
mind to creating new models
 ► Systems Thinking – Everyone recognizes that optimizing individual components does not
optimize the system

SAFE notes
 o Relentless Improvement
 ► A 'constant sense of danger' drives improvement activities that are essential to the survival of
an organization
 ► Optimize the whole – improvements increase the effectiveness of the entire system
 ► A problem-solving culture is the driver for continuous improvement
 ► Reflect at key Milestones – improvement activities are treated with as much urgency as new
Feature development, fixing defects, and responding to the latest outage
 ► Fact-based improvement leads to changes guided by the data about the problem rather than
conjecture or opinions
o Innovation culture
 ► Innovative People – instilling innovation requires a commitment to cultivating courage and
aptitude for innovation and risk-taking
 ► Time and Space for Innovation – providing work areas conducive to creative activities; setting
aside time to innovate
 ► Go See – innovate by witnessing how Customers interact with Solutions and understanding
their problems
 ► Experimentation and Feedback – conducting experiments iteratively is the most effective
path to learning
 ► Pivot Without Mercy or Guilt – When fact patterns dictate that a hypothesis will be proven
false, pivot quickly to a new one
 ► Innovation Riptides – Innovation flows continuously up, down, and across the Enterprise

Establish CoP  communities of practice  Communities of practice are groups of people who share a
common concern or a passion for something they do and learn how to do it better as they interact
regularly

Community A group of individuals with shared passion about a topic

Domain An area of shared interest
Practice Shared knowledge and experiences

13.3 Measure and grow towards business agility

Measure and Grow is the way portfolios evaluate their progress toward business agility and determine their next
improvement steps.  assess your own competencies and decide where we need to go next

Complete a business agility assessment form

Set your business improvement strategy

through the business agility assessment
framework

7 core competencies

Seven core competencies

Competency assessment

 ► One assessment for each one of the seven core competencies

 ► Assess at a greater level of detail to generate deeper insights
SAFE notes
 ► Measure the progress being made toward a specific core competency
 ► Identify specific practices for potential improvement

 Assessments brings focus to lean agile ways of working

 Reinforce the ten critical ART success factors
 Reinforce the 10 critical ART success factors



 Apply learnings across the enterprise
o ► Success in one portfolio does not ensure success in other portfolios
o ► Leverage the learnings and successes of the pioneering organization to transform the remaining
portfolios
o ► Provide change agents from the initial portfolio with the opportunity to transplant into
subsequent portfolios, bringing with them all of the experience and insights of implementing SAFe
o ► Cultivate the next generation of leaders in every role so they are prepared to step in when change
agents move on to launch the transformation in other portfolios to avoid crippling the previous
portfolios

SAFE notes