understand safe in 8 pictures

1 Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved

SAFe® in 8 Pictures A Walkthrough of the Scaled Agile Framework ®

NG Solutions BY Ali Bentaleb, SPC, CSP,CSM, PMP, MBA, ITIL

AGILE TEAMS COACH & TRAINER

2 Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved

PROVEN

FRAMEWORK

RELENTLESS

IMPROVEMENT

CODE

QUALITY

THE

BACKLOGS

THE CADENCE

THE PEOPLE

THE LEVELS

ECONOMIC

PRIORITIZATION

SAFe® in 8 Pictures


1. PROVEN


•  SAFe is base of proven, integrated success patterns for

implementing the power of Lean-Agile management of software development at enterprise

•  SAFe is an adaptive framework ready to help managing complex software and hardware projects.

Integrated of success patterns


The case studies citing the business benefits of SAFe


•  To find certified members of the SAFe community, navigate

to ScaledAgileAcademy.com, click on the Community menu, and select Member Directory.

•  Look for SPC’s to train and coach your teams

[email protected]

Be a part of the SAFe Community


Next Steps


SAFe Agilist (SA) Certification Process

Meet qualifications

Pass SA Exam ?

What You Are Certified SAFe Agilist (SA)

What You Get

•  SA certification mark •  Access to

ScaledAgileAcademy.com SA Members Only area

•  New workbook releases •  Optional directory listing

Can retake after 60 days

Take Leading SAFe

course from any SPC

Yes

No


SAFe Big Picture : Discover it in the next slides


2. THE

LEVELS


Centralizing strategy and decentralizing execution Project as Demand flow management Agile budgeting Decentralized, rolling-wave planning Self managing Agile Release Train Agile estimating and planning


Portfolio Level

•  Vision based on value stream delivery


•  Better adaptability •  Faster value delivery •  Lower cost and

overhead

ART 1

ART 2

ART 3

Portfolio Level

Program"Portfolio"

Management""

Por

tfolio

Bac

klog

•  Easy Strategic Planning and budgeting


•  Connect Strategy to Execution : Roadmaps

Portfolio Level Example using VersionOne tools


•  On line Enterprise Visibility and Tracking

Portfolio Level Example using VersionOne tools


Agile Release Train

Define new functionality Implement Acceptance

Test Deploy

Repeat until further notice. Project chartering not required.

!  A virtual organization of 5 – 12 teams (50-125 individuals) that plans, commits and executes together

!  Driven by Vision and Roadmap

!  Lean, economic prioritization

!  Frequent, quality deliveries and Fast customer feedback


Agile Release Train and DevOps


Program Level

!  Common cadence and sprint lengths and estimating !  Aligned to a common mission via a single program backlog !  Operates under architectural and UX guidance

!  Regular Inspect and Adapt drives continuous improvement

!  Value description via Features and Benefits


Team Level

! Empowered, self-organizing, self-managing cross-functional teams

! Valuable, fully-tested software increments every Sprint

! Scrum project management practices and XP-inspired technical practices

!  Teams operate under program vision, system, architecture and user experience guidance

! Value description via User Stories


Lean Management


The Goal : Value

THE GOAL :

!  Sustainably shortest lead time !  Best quality and value to people and

society

!  Most customer delight, lowest cost, high morale, safety


3. THE

PEOPLE


Lean Thinking Provides the Tools We Need

People !  Develop individuals and

teams; they build products !  Empower teams to

continuously improve !  Build partnerships based

on trust and mutual respect

Respect for people

and culture


The foundation: Leadership

LEADERSHIP: ! Management is trained in

lean thinking ! Bases decisions on this

long term philosophy

LEADERSHIP


People are: ! Trained in practices and tools od

continuous improvement !  Teach problem solving and corrective

action !  Develop people. People develop solution.

Key Roles

Key Teams

Managers and Executives empower individuals and teams


4. THE

BACKLOGS


The Enterprise Backlog Model !  A backlog is a list of things to

do. If a thing is in there, it might get done. If it isn’t there, there is no chance that it will be started.

!  It represents opportunities, not commitments.

!  The Enterprise Backlog Model translates the allocation of strategic investments to the portfolio, program, and team level

!  Detail is defined just-in-time and progressively elaborated

Scaling the Backlog

Epics are in the Portfolio Backlog

Features are in the Program Backlog

Stories are in the

Team Backlog


Backlogs: •  Backlog items are elaborated at a

level of detail appropriate to the phase of development.

•  They are not commitments. Rather,

they represent opportunities.


4. Portfolio Backlog

Epics/Features Stories

2. Review

1. Funnel

3. Analysis

AGILE TEAMS

A G I L E R E L E A S E T R A I N

A G I L E R E L E A S E T R A I N

Business Epic

Business Epic

Story

Spike

Story

Story

Story

Spike

Spike Spike

Spike

GO Decision

Feasibility Implementation

Por

tfolio

P

rogr

am

Team

Feature

Feature


Program Backlog Capacity Allocation

New Features

Architecture

Product Management (Content Authority) WSJF Prioritization

Architect (Design Authority), WSJF Prioritization

Portfolio Backlog

Team Backlogs

Alignment between Backlogs


5. THE

CADENCE


Develop on Cadence. Release on Demand.

Development occurs on a fixed cadence. The business decides when value is released.

Release on Demand

Major Release Customer

Upgrade Customer Preview

Major Release New

Feature

Develop on Cadence

PI PI PI PI PI


Synchronize to Assure Delivery

Sys 1 Sys 2 Sys 3 Sys 4 Sys 5 Sys 6 Sys 7 Sys 8

Iterate Iterate Iterate Iterate Iterate Iterate



PSI

PI

PI

Continuous Integration

Continuous Integration


6. CODE

QUALITY


Agile Architecture

Con/nuous Integra/on

Test-‐First

Refactoring

Pair Work

Collec/ve Ownership

! You can’t scale crappy code


Demonstrations of tested code at the Team and Program Levels

Team Demo

System Demo


!  Design must be grown incrementally by those who best know how to implement specific functionality

!  Evolves hand-in-hand with business functionality; constantly tested and enabled by continuous refactoring and integration

!  Agile teams evolve the system design

!  System Architects provide architecture guidance

!  UX designers, security and data architects help guide the train

!  The System Team collaborates with Agile teams and System Architect to enhance system testability

Intentional Arch. and Emergent Design


Intentional Arch. and Emergent Design

Intentional Architecture and Emergent Design enable programs to create and maintain large-scale solutions

Leve

l of

abst

ract

ion

High

Low Teams

Intentional Architecture

Emergent Design

Now

System Architect

The Principle of Early Contact: Make early and meaningful contact with the problem.

—Don Reinertsen


7. RELENTLESS

IMPROVEMENT


RELENTLESS

!  A constant sense of danger

!  Small, steady improvements

!  Consider all data carefully, then implement change rapidly

!  Reflect at key milestones to identify and improve shortcomings

!  Use tools like retrospectives, root cause analysis, and value stream mapping

!  Protect the knowledge base by developing stable personnel and careful succession systems

“We can do better”

Respect for People

Product Development

Flow Kaizen

BECOME RELENTLESS IN: !  Reflection !  Continuous improvement as

an Enterprise value


At a team level: The Sprint Retrospective

!  At the end of each iteration, the entire team, including the Product Owner, does the following: –  Reflects on the results of the process –  Learns from that examination

–  Adapts the process (and organization) to produce better results

!  The team decides what is working well, what isn’t, and what one thing they can do differently next time

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. –Agile Manifesto

Read more: Davies and Sedley, Agile Coaching

Retro


At the program level : Inspect & Adapt

Retro

At regular intervals, team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. –Agile Manifesto


Inspect and Adapt Process

I&A has three parts: !  Part 1. The PI demo

of the solution’s current state to program stakeholders

!  Part 2. Quantitative measurement

!  Part 3. The problem solving workshop

Inspect and Adapt (I&A) is to a Release Train what the sprint demo and retrospective are to a team


Inspect & Adapt for Program Performance

The key question is “what can we do to improve overall program performance?”

Part 1: The PSI Demo Part 2: Quantitative Measures

Part 3: The Problem Solving Workshop


8. ECONOMIC

PRIORITIZATION


Retro


QUESTIONS OR

Feedback?

understand safe in 8 pictures

Documents