introduction to scaled agile framework
TRANSCRIPT
Introduction to Scaled Agile Framework
Why Scaling Agile ?
▸To some, “scaling agile” means going from a few agile teams to multiple, or even hundreds of, agile development teams.
▸Some unique challenges that come up whenever you have an organization where more than 3 or 4 agile teams need to work together in a coordinated fashion.
▸Need new approaches that harnesses the power of Agile and Lean and applies to the needs of the largest software enterprises
Scaling factors faced by Agile teams
www.disciplinedagileconsortium.org
Disciplined Agile Delivery
4
2 models – Iteration based and Flow BasedUses non Scrum terminology • Iteration instead of Sprint • Work item list – instead of a Product backlog
Supports robust set of roles – Team Lead, Architect, PO, StakeholderTeams are Enterprise awareGovernance “built in”
Large Scale Scrum (LeSS)
Two Agile Scaling Frameworks•LeSS: Up to eight teams (of eight people each).•LeSS Huge: Up to a few thousand people on one product.
Principles :Queuing TheoryEmpirical Process controlLean thinkingSystems thinkingContinuous ImprovementWhole Product Focus
Scaling Agile@Spotify
Squad – Scrum teamTribe – Collection of SquadsChapter – Small family of people having similar skills, having same competency areaGuilds – Community of Practice- share knowledge tools and practices
ScaledAgileFramework.com
Synchronizes
alignment,
collaboration and
delivery for large
numbers of teams
CORE VALUES
1. Program Execution
2. Alignment
3. Code Quality
4. Transparency
Scaled Agile Framework
Scaling Methods and Approaches
Version one 9th Annual State of Agile Survey
SAFe – Team Level
▸ Valuable, fully-tested software increments every two weeks
▸ Empowered, self-organizing, self-managing cross-functional teams
▸ Teams operate under program vision, architecture
and user experience guidance
▸ Scrum project management and XP-inspired technical practices
▸ Value delivery via User Stories
SAFe – Program Level▸ Self-organizing, self-managing team-of-agile-teams
▸ Working, system increments every two weeks
▸ Aligned to a common mission via a single backlog
▸ Common sprint lengths and estimating
▸ Face-to-face release planning cadence for collaboration, alignment,
synchronization, and assessment
▸ Value Delivery via Features and Benefits
Agile Release Train
▸ Long lived self organizing team of 5-12 Agile teams (50-125 individuals)
that delivers solutions
▸ Program Increment is a fixed time box (default 10 weeks)
▸ Aligned to a common mission via a single Program backlog
▸ Produces valuable and evaluate-able system level solutions frequently
Key Program roles
▸ Release Train Engineer – Chief Scrum master for the train
▸ Product Management – owns, defines and prioritizes the product backlog
▸ System Architect – provides architectural guidance and technical
enablement to the team
▸ System team – provides process and tools to integrate and evaluate
assets early and often
▸ Business Owners – Key stakeholders of the Agile Release Train
Release Planning▸ 2 days every 8-12 weeks
▸ Every one attends in person, if at all possible
▸ Each team comes out with PI objectives which are brief summaries in
business terms what each team intends to deliver at the end of the PI
▸ There is a Program Board which lists out all the features, the milestones,
the dependencies, and anticipated delivery dates of all the teams in a PI
Program Board - Sample
SAFe - Portfolio
▸ Centralized strategy, decentralized execution
▸ Lean-Agile budgeting empowers decision makers
▸ Kanban systems provide portfolio visibility and WIP limits
▸ Enterprise architecture is a first class citizen
▸ Objective metrics support governance and kaizen
▸ Value description via Business and Architectural Epics
House of Lean
Goal: Speed, Quality, Value
The Goal
Sustainably shortest lead time
Best quality and value to
people and society
Most customer delight, lowest
cost, high morale, safety
All we are doing is looking at the timeline, from the
where the customer gives us an order to where we
collect the cash. And we are
reducing the time line by reducing the
non-value added wastes. —Taiichi Ohno
We need to figure out a way to
deliver software so fast that our customers
don’t have time to change their minds.
—Mary Poppendieck
Most software problems will exhibit
themselves as a delay. —Al Shalloway
Respect for People
Your customer is whoever
consumes your work
Don’t trouble them
Don't overload them
Don't make them wait
Don't impose wishful thinking
Don't force people to do
wasteful work
Equip your teams with problem-
solving tools
Form long-term relationships
based on trust
People
Develop individuals and
teams; they build products
Empower teams to
continuously improve
Build partnerships based
on trust and mutual respect
Kaizen
Become Relentless In:
Reflection
Continuous improvement as an enterprise value
A constant sense of danger
Small steady, improvements
Consider data carefully, implement change rapidly
Reflect at 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
Product Development Flow
Don Reinertsen
Principles of Product
Development Flow
1. Take an economic view
2. Actively manage queues
3. Understand and exploit variability
4. Reduce batch sizes
5. Apply WIP constraints
6. Control flow under uncertainty:
cadence and synchronization
7. Get feedback as fast as possible
8. Decentralize control
