SASM = SAFe Advanced Scrum Master

stefan February 27, 2020 0 Comments

Everyone sees the results of a team. The quality of what they produce depends directly of how they feel when they work toghether. And how do they feel when they work in this team can be thought to improvement by the SM.

Characteristics of an effective Agile Team

  1. Display the enterprise competency of Team and Technical Agility
  2. Able to reliably deliver
  3. Its members are not afraid to challenge each other’s ideas for the ultimate win
  4. Makes process visible to themselves and to their stakeholders
  5. Collaborates to achieve Iteration goals and PI Objectives
  6. Produces consistent, high-quality increments of value
  7. Sustains a predictable pace of development

Apart from the impediments to developing and delivering value, Agile Teams in the Enterprise may encounter significant roadblocks to growth.

SAFe Core Values

  1. Built-In Quality
  2. Program execution
  3. Alignement
  4. Transparency

5 Competencies to become a Lean Enterprise

  1. Lean-Agile Leadership
  2. Team and Technical Agility
  3. DevOps and Release on Demand
  4. Business Solutions and Lean Systems Engineering
  5. Lean Portfolio Management

9 SAFe Lean-Agile principles

  1. Take an economic view
  2. Apply systems thinking
  3. Assume variability; preserve options
  4. Build incrementally with fast, integrated learning cycles = PDCA = Plan Do Check Adjust
  5. Base milestones on objective evaluation of working systems
  6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths
    Limit WIP & reduce batch size > limit queue > Increase flow. Investment in infrastructure > reduce transaction costs.
  7. Apply cadence, synchronize with cross-domain planning
  8. Unlock the intrinsic motivation of knowledge workers
  9. Decentralize decision-making

What is the job?

All we are doing is looking at the timeline, from when the customer gives us an order to when we collect the cash. And we are reducing the timeline by reducing the non-value added wastes.                                                                         Taiichi Ohno

Synchronize with cross-domain planning
  1. All stakeholders face-to-face, (but typically multiple locations)
  2. Management sets the mission, with minimum possible constraints
  3. Requirements and design happen
  4. Important stakeholder decisions are accelerated
  5. Teams create-and take responsibility-for plans

Clarity on how to think, without clarity on how to act, leaves people unmoved. Dan Pink

Areas from which to build cross-functional ART

  1. Business
  2. Product Management
  3. Hardware
  4. Software
  5. Quality
  6. Testing
  7. Compliance
  8. Security

ART roles:

  1. RTE acts as the Chief Scrum Master for the train.
  2. Product Manager owns, defines, and prioritizes the Program Backlog.
    Product Owner owns Team Backlog.
  3. System Architect/Engineering provides architectural guidance and technical enablement to the teams on the train.
  4. The System Team provides processes and tools to integrate and evaluate assets early and often.
  5. Business Owners are the key stakeholders on the Agile Release Train.

PI Planning

Day 1

  1. Executive leadership shares the state of the business and upcoming objectives. (Key Portfolio priorities and SWOT)
  2. Product Management presents the Vision and the high-priority Features.
  3. A System Architect presents the Vision for architecture, new architecture Epics, and common frameworks
  4. Development management may provide updates on Agile tooling and improvements in engineering practices
  5. UX professionals provide guidance around usability issues
  6. In breakouts each team
    1. breaks down their Features into user Stories
    2. that are estimated and
    3. placed into Iterations.
  7. Objectives are business summaries of what each team intends to deliver in the upcoming Pl.
  8. Stretch objectives provide a reliability guard band.
  9. The hourly Serum of Serums checkpoint helps keep teams on track and supports early identification of risk.
  10. Draft a plan review.
  11. At the end of Day 1 , management meets to make adjustments to scope and objectives based on the day’s planning.

Day 2

  1. Make planning adjustments Based on the previous day’s management review and problem-solving meeting, adjustments are discussed. Possible changes:
    1. Business priorities
    2. Adjustment to plan
    3. Changes to scope
    4. Movement of resources
  2. Team breakout #2 to create the final plan
    1. In the second team breakout, Business Owners circulate and assign business value to PI Objectives from low (1 ) to high (10)
    2. Teams finalize the Program Increment plan
    3. Teams also consolidate program risks, impediments, and dependencies
    4. Stretch objectives provide the capacity and guard band needed to increase cadence-based delivery reliability
  3. Final plan review and build
  4. Addressing program/ ROAMing risks
    1. Resolved – Has been addressed; no longer a concern
    2. Owned – Someone has taken responsibility
    3. Accepted – Nothing more can be done. If risk occurs, release may be compromised.
    4. Mitigated – Team has plan to adjust as necessary
  5. Confidence vote. If low confidence then Rework.
  6. Run a Planning Meeting retrospective
  7. Moving forward

How to estimate:

  1. For every full-time developer and tester on the team, give the team eight points (adjust for part-timers).
  2. Subtract one point for every team member vacation day and holiday.
  3. Find a small Story that would take about a half-day to develop and a half-day to test and validate. Call it a 1 .
  4. Estimate every other Story relative to that one
  5. Never look back (don’t worry about recalibrating).
Image result for program events drive the train

PI System Demo (at the end of the PI)
Often led by Product Management, POs, and the System Team
Attended by Business Owners, program stakeholders, Product Management, RTE, Serum Masters, and teams

Image result for continuous delivery pipeline

SAFe’s CALMR approach to DevOps = Developers Operations

© Scaled Agile, Inc.

For PIPP – Program Increment Planning Preparation leadership creates

  1. Executive briefing – State of the business and upcoming objectives
  2. Product Vision briefing(s) – Vision and top 1 0 Features
  3. Architectural Vision briefing Vision for architecture, new Architectural Epics, common frameworks, etc.
  4. Development context – Changes to standard practices, new tools and techniques, etc.
How to build a KanBan board
  1. Identify workflow steps/ interfaces
    1. Define
    2. Design
    3. Get SME Approval
    4. Code
    5. Integrate
    6. Test
    7. Done
  2. Arrange steps
  3. Assign initial WIP limits – sufficiently low to see bottlenecks
  4. Start operation/ adjust

Winning the Iteration: The buffet rule: “Take all you want, but eat all you take”. Jay Packlick

You can ‘t scale crappy code” (or hardware, or anything else).

Traditional V-Model testing

Fast & continuous feedback



I&A – Inspect and Adapt event
  1. PISD – Program Increment System Demo of the Solution (¾-1h)
  2. Quantitative measurement (¾-1h)
  3. The retrospective and Problem-Solving Workshop (1,5-2h)

Acronyms and Abbreviations
ART Agile Release Train -Iteration: Define, Implement, Test, Deploy
BO Business Owner
BCB Book and Coffee Break
 BV Business Value
 BVIR Big Visual Information Radiator
CFD Cumulative Flow Diagram
 CapEx Capital Expenses
 CI Continuous Integration
 CoD Cost of Delay
 CoP Community of Practice
DoD Definition of Done
 DSU Daily Stand-up
EA Enterprise Architect
 EO Epic Owner
FW Firmware
HW Hardware
I&A Inspect and Adapt – 3-4h/ PI for Teams and Stakeholders
 IP Innovation and Planning (iteration)
MBSE Model-Based Systems Engineering
NFR Non-functional Requirements
OE Opportunity Enablement
 OpEx Operating Expenses
PDCA Plan, Do, Check, Adjust
 PI Program Increment – fixed time box 10w with PI Planning of 2 days
 PM Product Manager
 PO/PM Product Owner/Product Manager
PO Product Owner
LPM Lean Portfolio Management
ROAM Resolved, Owned, Accepted, Mitigated
RR Risk Reduction
RTE Release Train Engineer
S4T SAFe® for Teams
SAFe® Scaled Agile Framework
SA SAFe® Agilest
SM Scrum Master
SME Subject Matter Experts
SoS Scrum of Scrums – 0,5-1h weekly or more frequently followed by a “meet-after”
SP SAFe® Practitioner
SPC SAFe® Program Consultant SW Software
UX User Experience
VS Value Stream
STE Solution Train Engineer
WIP Work in Process
WSJF Weighted Shortest Job First
XP Extreme Programming