SAFe for teams

There are four different configurations :

Introducing SAFe

Connect with the Scaled Agile Framework

Our development methods must keep pace with an increasingly complex world.

• We’ve had Moore’s Law for hardware, and now software is eating the world
• Our development practices haven’t kept pace; Agile shows the greatest promise but was developed for small teams
• We need a new approach, one that harnesses the power of Agile and Lean and applies to the needs of the enterprises who build the world’s most important software and systems

Explore Lean, the Agile Manifesto, and SAFe Principles

Value

• The best quality and value to people and society
• High morale, safety, and Customer delight

There is only one boss. The customer. And he can fire everybody in the company – Sam Walton

Respect for people and culture

• Generative culture
• People do all the work
• Your Customer is whoever consumes your work
• Build long-term partnerships based on trust
• To change the culture, you have to change the organization

Culture eats strategy for breakfast – Peter Drucker

Flow

• Optimize sustainable value delivery
• Build in quality
• Understand, exploit, and manage variability
• Move from projects to products

Innovation

• Innovative people
• Provide time and space for innovation
• Go see “Gemba”
• Experimentation and feedback
• Innovation riptides
• Pivot without mercy or guilt

Relentless Improvement

• A constant sense of danger
• Optimize the whole
• Problem solving culture
• Base improvements on facts
• Reflect at key Milestones

Leadership

• Lead by example
• Adopt a growth mindset
• Exemplify the values and principles of Lean-Agile and SAFe
• Develop people
• Lead the change
• Foster psychological safety

Agile Manifesto :

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

SAFe® Lean-Agile Principles

Agile economics : Deliver early and often

Use iterations and program increments to learn quickly

Base milestones on objective evaluation of working systems

Visualize and limit WIP, reduce batch size, and manage queue lengths

Visualize and limit work in progress with BVIR (Big Visible Information Radiator)

Reduce batch size for higher predictability

Apply cadence, synchronize with cross-domain planning

Cadence-based planning limits variability.

Identify Scrum, Kanban, and Quality Practices

In a nutshell Agile :

Agile for teams : Scrum

Roles :

• Agile team
• Scrum Master
• Product Owner

Events :

• Iteration planning
• Daily stand up
• Iteration review
• Iteration retrospective

Agile for teams : Kanban

Visualize work flow. Limit work in progress. Improve flow

Examples for quality practices inspired from eXtreme Programming (XP)

Teams in SAFe are part of an Agile Release Train

The ART and teams continuously deliver value

Building an Agile Team

Build your team

• A self-organizing team dynamically interacts with itself and the organization
• Team members create new points of view and resolve contradictions through dialogue
• The team is energized with intentions, vision, interest, and mission
• Leaders provide autonomy, variety, trust, and commitment
• Equal access to information at all levels is critical

It is amazing what you can a ccomplish if you do not care who gets the credit – Harry Truman

Build cross-functional Agile Teams

• Agile teams are cross-functional, self-organizing entities that can define, build test, and where applicable, deploy increments of value
• They are optimized for communication and delivery of value
• They deliver value every two weeks

A collocated Agile Team is a key component of Agile development

• Critical for the Agile Team to be effective
• Recommended for programs to have efficient product development flow
• If you have distributed team members, development must be compensated with efficient remote interaction ( video-conferencing, sharing and collaboration tools, Agile lifecycle management tools, etc.)

Organize people in Value Streams

Maximize velocity by minimizing dependencies and handoffs, while sustaining architectural robustness and system qualities.

A team can be organized around :

• Features
• Components

Finding the right trade-off: Feature and component teams

Use feature teams for:

• The fastest velocity
• To minimize dependencies
• To develop T-shaped skills

Use component teams in case of:

• High reuse, high technical specialization, and critical NFRs
• Creating each component as a ‘potentially replaceable part of the system with well-defined interfaces’

Explore the Scrum Master and Product Owner roles

The Scrum Master in the Enterprise

• Coordinates with other Scrum Masters, the System Team, and shared resources in the ART Pl Planning meetings
• Works with the above teams throughout each Iteration and Pl
• Coordinates with other Scrum Masters and the Release Train Engineer in Scrum of Scrums
• Helps team understand and operate within its capacity
• Helps teams operate under architectural and portfolio governance, system-level integration, and System Demos
• Fosters team adoption of Agile technical practices

The Product Owner in the Enterprise

• Establishes the sequence of backlog items based on program priorities, events, and dependencies with other teams
• Operates as part of an extended Product Management Team
• Understands how the Enterprise backlog model operates with Epics, Capabilities, Features, and Stories
• Uses Pl Objectives and Iteration Goals to communicate with management
• Coordinates with other Product Owners, the System Team , and shared services in the Pl Planning meetings
• Works with other Product Owners and the Product Management
  team throughout each Iteration and Pl

Meet the teams and people on the train

The Agile Release Train (ART)

Each ART is a virtual organization of 5 – 12 teams (typically 50 – 125 people) that plans, commits, and develops and deploys together.

Agile Release Trains

• Align teams to a common business and technology mission
• Deliver a continuous flow of value

Roles on the Agile Release Train

Planning the Iteration

Prepare the backlog

Define Features for the Program Backlog

• Features are services that fulfill user needs.
• Feature is an industry-standard term familiar to marketing and Product Management
• Expressed as a phrase, value is expressed in terms of benefits
• Features are identified, prioritized, estimated, and maintained in the program Backlog

Features have a benefit hypothesis and acceptance criteria

• Feature is an industry-standard term that describes a specific system behavior
• Benefit hypothesis justifies Feature implementation cost and provides business perspective when making scope decisions
• Acceptance criteria is typically defined during Program Backlog refinement
• Features reflect functional and nonfunctional requirements
• Features fit into one Pl

Example :

Features have a benefit hypothesis and acceptance criteria

The Team Backlog

User stories

• Short descriptions of a small piece of desired functionality, written in the user’s language
• Recommended form of expression is the user-voice form, as follows: As a (user role), I want to (activity), so that (business value)

Using personas to better understand users : Personas are detailed fictional characters acting as a representative user.

INVEST in a good Story

• I : Independent : can be developed separately
• N : Negotiable : Scope can be negotiated
• V : Valuable : Valuable to the Customer
• E : Estimable : Can be estimated
• S : Small : fit in an iteration
• T : Testable

Writing good stories : The 3Cs

Enabler Stories

Enabler Stories build the groundwork for future user stories. There are four types of Enabler Stories:

• Infrastructure: Build development and testing frameworks that enable a faster and more efficient development process
• Architecture: Build the Architectural Runway, which enables smoother and faster development
• Exploration: Build understanding of what is needed by the Customer to understand prospective Solutions and evaluate alternatives
• Compliance: Facilitate specific activities such as verification and validation, documentation, signoffs, regulatory submissions, and approvals

Splitting Stories

In support of small batches for flow, decrease size to minimum. Split stories into essential and non-essential parts and eliminate the non-essential. Ensure you have something releasable

In support of feedback : deploy small stories to get technical/user feedback quickly (maximize feedback)

In support of Iteration Planning : Split stories so they fit into an Iteratrion

Some splitting rechniques :

• Business rule variations (e.g. single variation, then remainder)
• Workflow steps (for multi-step stories)
• Simple/complex (e.g. search for single word, then for phrases)
• Scenarios (e.g. use case exceptions)

Acceptance criteria

• Acceptance criteria provide the details of the Story from a testing point of view
• Acceptance criteria are created by the Agile Team

Sequencing Stories

Primary economic prioritization happens in the Program Backlog. Agile Teams sequence work for efficient execution of business priorities.

The Product Owner and the Team sequence work based on:

• Events, Milestones, releases, and other commitments made during Pl Planning
• Dependencies with other teams
• Local priorities
• Capacity allocations for defects, maintenance, and refactors
• Story priorities inherited from Program Backlog priorities

Initial sequencing happens during Pl Planning

Adjustments happen at Iteration boundaries

Plan the Iteration

Iteration Planning flow

1. Establishing capacity
2. Story analysis and estimating
3. Detailing Stories
4. Developing iteration goals
5. Committing to Iteration goals

Timebox : 4 hours or less, this meeting is by and for the team, SMEs may attend as require

Capacity allocation :

• Helps alleviate velocity degradation due to technical debt
• Keeps existing Customers happy with bug fixes and enhancements
• Can change at Iteration or PI boundaries

Definition of Velocity : Velocity is the number of points of Stories accepted in the Iteration. Make sure to always use the average velocity for the most recent iterations.

Establishing capacity before historical data exists :

• For every full-time developer and tester on the team , give the team 8 points (adjust for part-timers)
• Subtract 1 point for every team member vacation day and holiday
• Find a small Story that would take about a half day to develop and a half day to test and validate, and call it a 1
• Estimate every other Story relative to that one
• Never look back (don’t worry about recalibrating)

Story analysis and estimation

The product owner presents Stories in order of priority

Each story is discussed and analyzed by the team, has its acceptance criteria refined and is estimated

The process continues until the estimation of the Stories has reached the capacity of the team

Compared with other Stories, an 8 point Story should take relatively four times longer than a 2-point story.

A story point is a singular number that represents :

• Volume : How much is there
• Complexity : How hard is it ?
• Knowledge : What do we know ?
• Uncertainty : What’s not known ?

You can use estimating poker for fastr, relative estimating, everybody gives an estimation on cards, then everybody turns them up and discuss differences and re-estimates.

Estimation is a whole-team exercise, it increases accuracy by including all perspectives. It builds understanding, it creates a shared commitement.

You should spend little effort on estimating, the benefit is decreasing the more effort you put in it. A little effort helps a lot. A lot of effort only helps a little.

Iteration goals provide clarity and commitment and management information :

• Align team members to a common purpose
• Align Program teams to common PI Objectives and manage dependencies
• Provide continuous management information

Team commitment are also commitment to other teams, the program and the stakelholders, not only to the work. A team meets its commitment by doing everything they said they would do, or, in the event that it is not feasible, they must immediately raise the concern.

Too much holding to a commitment can lead to burnout, inflexibility and quality problems. Too little commitment can lead to unpredictability and lack of focus on results.

Some teams have a more responsive nature to their work , such as maintenance teams and System teams. The teams find less value in trying to plan the Iteration in detail.

Kanban teams still publish iteration goals, which consist of the known parts of their work.

They commit to the goals as well as service level agreements (SLA) for incoming work based on their known historical lead time.

Executing the Iteration

Visualize the flow of work

WIP limits improve the flow of work

Some steps have no WIP limits, while others serve as buffers and have minimum as well as maximum WIP

Measure the flow of work

You can track status with burn-up charts and cumulative flow diagrams (CFDs)

What is a cumulative flow diagram ? (CFD)

At any point you can find the Work in progress, the lead time and the done curve :

Build quality in

Building quality in :

• Ensures that every increment of the solution reflects quality standards
• Is required for high, sustainable development velocity
• Software quality practices (most inspired by XP) include continuous integration, test-first, refactoring, pair work, collective ownership, and more
• Harware quality is supported by exploratory, early iterations; frequent system-level integration; design verification; MBSE; and Set-Based Design

Emergent design and intentional architecture :

• Every team deserves to see the bigger picture
• Every team is empowered to design their part
• Emergent design – Teams grow the system design as user stories require
• Intentional architecture – Fosters team alignment and defines the architectural runway
• A balance between emergent design and intentional architecture is required for speed of development and maintainability

Architectural Runway includes existing code, hardware components, business infrastructure, etc. thjat enable near-term business features.

Traditional testing (V-Model) delays feedback

Shift testing left for fast and continuous feedback

Test first naturally creates a pyramid of tests. The test pyramid advocates a balanced portfolio of tests with many small, low-level, automated tests and fewer large, manual tests

An inverted Test Pyramid is a test strategy anti-pattern

Slows development, delays feedback, encourages larger batches

Continuously integrate, deploy, and release

A CALMR approach to DevOps :

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

Continuous code integration :

Trunk-based development

Teams continuously integrate assets (leaving as little as possible to the System Team).

• Avoid physical branching for software
• Frequently integrate hardware branches

The four activities of continuous deployment :

Separate deploy from release

• Separate deploy to production from release
• Hide all new functionality under Feature toggles
• Test processes with a sub-set of users before exposing new functionality to all users

Improve flow with communication and synchronization

Communication and synchronization with daily stand-ups

The backlog refinement session

The backlog refinement session is a preview and elaboration of upcoming Stories. 1-2 hours every iteration or even every week. Agile teams + SMEs etc. Regular cadence. Timebox each story to be discussed. Participation and dialogue. Record all decisions- Teams should not be seen for the first time during the meeting.

• Helps the team think about new Stories prior to Iteration Planning
• Provides enough time to identify and resolve dependencies and issues that could impact the next Iteration
• The team can improve Stories, add acceptance criteria, and point out missing information to the Product Owner
• Most of the focus is on the next Iteration, but it allows time to discuss future Iterations and even Features for the next Pl

Demonstrate value

Iteration review

• The iteration review provides the true measure of progress by showing working software functionality, hardware components, etc.
• Preparation for the review starts with planning
• Teams demonstrate every Story, spike*, refactor and NFR
• Attendees are the team and its stakeholders
• *Spike is a research Story, considered an exploration style Enabler

Iteration review guidelines :

• Timebox : 1 to 2 hours
• Preparation : Review preparation should be limited to 1 to 2 hours. Minimize presentation. Work from the repository of stories.
• Attendees : If a major stakeholder cannot attend, the Product Owner should follow up individually.

How we did in the iteration ?

• Did we meet the goal ?
• Story by story review

How we are doing in the PI

• Review of PI objectives
• Review of remaining PI scope and reprioritizing if necessary

Safe definition of done :

Retrospect and improve

Iteration retrospective

• Timebox : 30-60 minutes
• Purpose : Pick one or two items that can be done better for next iteration
• Outcome : Enter improvement items into the team backlog

What are potential iteration metrics ?

Executing the PI

Plan together

Objectives are business summaries of what each team intends to deliver in the upcoming Pl.

They often map directly to the Features in the backlog. For example:

• An aggregation of a set of Features
• A milestone like a trade show
• An Enabler Feature supporting the implementation
• A major refactoring

the PI planning

Cadence based PI planning meetings are the heartbeat of the Agile Enterprise.

• Two days every 8-12 weeks (10 weeks is typical)
• Everyone attends in person if possible
• Product management owns feature priorities
• Agile teams own story planning and high-level estimates
• Architect/Engineering and UX work as intermediaries for governance, interfaces and dependencies
• UX-Lean user experience on how the user interacts with the system.

Uncomitted objectives help improve the predictability of delivering business value. Uncomitted objectives do count in velocity/capacity.

• 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, encourage them to make it an uncomitted objective.
• If an item has many unknowns, consider making it an uncomitted objective and planning for early spikes.

SMART team PI Objectives

Teams should write their PI Objectives in the SMART format

• Specific – States the intended outcome as simply, concisely, and explicitly as possible (Hint: Try starting with an action verb).
• Measurable – It should be clear what a team needs to do to achieve the objective. The measures may be descriptive, yes/no, quantitative, or provide a range.
• Achievable -Achieving the objective should be within the team’s control and influence
• Realistic – Recognize factors that cannot be controlled .(Hint: Avoid making overlyoptimistic assumptions)
• Time-bound – The time period for achievement must be within the Pl, and, therefore, all objectives must be scoped appropriately.

Program Increment (Pl) Planning is a cadence-based, face-to-face event that serves as the heartbeat ofthe Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision.

The Agile Manifesto states, “The most efficient and effective method of conveying information to and within a development team is a face-to -face conversation.”

SAFe takes this to the next level with Pl planning, a routine, face-to-face event, with a standard agenda that includes a presentation of business context and vision followed by team planning breakouts where the teams create their Iteration plans and objectives for the upcoming Pl.

Briefings :

Executive + Product manager + System architect

Planning Guidance :

• 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 users Stories, plan them into the Iteration, and work out interdependencies with other teams

Agile teams use story points to relatively estimate user stories in story points. With relative estimating, the size (effort) for each backlog item is compared to other st ories. For example, an eight-point story is four times the effort as a two-point story. The team’s velocity for an iteration is equal to the sum of al l the stories completed in the prior iteration. Knowing a team’s velocity assists with planning and helps limit Work in Process (WIP)- teams don’t take on more stories than their prior velocity would allow. Velocity is also used to estimate how long it takes to deliver Features or Epics, which are also forecasted in story points. Keep in mind, velocity is based on historical data of the team’s completed story points. For the purpose of this Pl Planning simulation you will be referring to calculating Iterations capacity, since velocity is not established yet.

Velocity and Capacity

What is Velocity?

The team’s velocity for an iteration is equal to the sum of the points for all the completed stories that met their Definition of Done (DoD). As the team works together over time, their historical trend of average completed story points per iteration builds a reliable picture of the team’s velocity.

What is Capacity?

Capacity is the portion of the team’s velocity that is actually available for any given iteration. Vacations, training, and other events can make team members unavailable to contribute to an iteration’s goals for some portion of the iteration. This decreasesn the maximum potential velocity for that team for that iteration.

Management review and problem-solving

At the end of day 1, management meets to make adjustments to
scope and objectives based on the day’s planning.

Common questions during the managers’ review:

• What did we just learn?
• Where do we need to adjust? Vision? Scope ? Team assignments?
• Where are the bottlenecks?
• What features must be de-scoped?
• What decisions must we make between now and tomorrow to address these issues?

Make planning adjustments

Based on the previous day’s management review and problem-solving meeting, adjustments are discussed.

Possible changes:

• Business priorities
• Adjustment to Vision
• Changes to scope
• Realignment of work and teams

Based on new knowledge and a good night’s sleep, teams work to create their final plans.

• In the second team breakout, Business Owners circulate and assign business value to Pl Objectives from low (1) to high (10)
• Teams finalize the Program Increment plan
• Teams also consolidate program risks, impediments, and dependencies
• Uncommitted objectives provide the capacity and guard band needed to increase the reliability of cadence-based delivery

Then there is the Final plan review -> Teams and Business Owners peer-review all final plans.

Then the final plan is built

• Final plans are collected at the front of the room
• Final plans are reviewed by all teams
• Business Owners are asked whether they accept the plan
• If accepted, the team’s plan and program risk sheet are brought to the front of the room
• If not accepted, the plans stay in place, and the team continues planning after the review

Confidence vote: Team and program

After dependencies are resolved and risks are addressed, a confidence vote is taken by the team and program.

The Pl Planning event will evolve over time. Ending with a retrospective will help continuously improve it. What went well ? What didn’t ? What we can do better next time ?

Program board : Feature delivery, dependencies, and Milestones

Integrate and demonstrate together

Program events create a closed-loop system to keep the train on the tracks.

Program events and team events :

ART sync is used to coordinate progress

Scrum of scrums and PO sync :

Demo the full system increment every two weeks :

• Features are functionally complete or ‘toggled’ so as not to disrupt demonstrable functionality
• New Features work together and with existing functionality
• Happens after the Iteration review (may lag by as much as one Iteration, maximum)
• Demo from a staging environment which resembles production as much as possible

Learn together

Innovation and Planning (IP) Iteration

Facilitate reliability, Program Increment readiness, planning, and innovation during the IP iteration.

• Innovation: Opportunity for innovation, hackathons, and infrastructure improvements
• Planning: Provides for cadence-based planning
• Estimating guard band: For cadence-based delivery

IP iteration calendar :

Improving results with the Inspect and Adapt event

Three parts of Inspect and Adapt :

• The PI System Demo
• Quantitative and Qualitative Measurement
• Problem-Solving Workshop

Timebox : 3-4 hours per PI

Attendees : Teams and stakeholders

Pl System Demo

• At the end of the Pl, teams demonstrate the current state of the Solution to the appropriate stakeholders
• Pl System Demo is often led by Product Management, POs, and the System Team
• Business Owners, program stakeholders, Product Management, RTE, Scrum Masters, and teams attend.

Quantitative and qualitative measurement

The report compares actual business value achieved to planned business value.

The problem-solving workshop

Teams conduct a short retrospective to systematically address the larger impediments that are limiting velocity.