2. 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
4. Disciplined Agile Delivery
4
2 models – Iteration based and
Flow Based
Uses non Scrum terminology
• Iteration instead of Sprint
• Work item list – instead of a
Product backlog
Supports robust set of roles – Team
Lead, Architect, PO, Stakeholder
Teams are Enterprise aware
Governance “built in”
5. 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 Theory
Empirical Process control
Lean thinking
Systems thinking
Continuous Improvement
Whole Product Focus
6. Scaling Agile@Spotify
Squad – Scrum team
Tribe – Collection of Squads
Chapter – Small family of people having
similar skills, having same competency
area
Guilds – Community of Practice- share
knowledge tools and practices
10. 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
11. 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
12. 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
13. 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
14. 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
16. 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
19. 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
20. 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
21. 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
22. 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
This lifecycle presents a more detailed view of what we call the Agile/Basic DAD lifecycle which extends Scrum’s construction lifecycle. In addition to this being a more detailed view of the lifecycle, there are several interesting aspects to this lifecycle:
It’s iteration based. Like many agile methods, including both Scrum and XP, the solution is built incrementally in a time-boxed manner. These timeboxes are called iterations (what Scrum calls sprints).
It uses non-Scrum terminology. Although the lifecycle is Scrum-based we chose to use non-branded terminology in DAD, in the case of this diagram the term iteration instead of sprint. The terminology doesn’t really matter, so if you’re more comfortable with Scrum terminology use that instead.
It shows inputs from outside the delivery lifecycle. Although the overview diagram above showed only the delivery lifecycle, the detailed diagram below shows that something occurs before the project before Inception and that agile teams often get new requirements (in the form of change requests and defect reports) coming in from production. These inputs provide important context for the overall delivery lifecycle.
There is a work item list, not a product backlog. DAD has a greater scope than Scrum, and when you take this greater scope into account you begin to realize you need a more robust change management approach than Scrum’s product backlog. Work items include requirements, defects, and other non-functionality oriented work such as training, vacations, and assisting other teams. All of this work needs to be prioritized somehow, not just implementation of requirements. For more on this, read Agile Best Practice: Prioritized Requirements.
In includes explicit milestones. Along the bottom of the lifecycle diagram there is an indication of suggested light-weight milestones that DAD teams should strive to meet. Such milestones are an important aspect of agile governance.
We call this the basic/agile lifecycle because it’s likely where you’re going to start with DAD. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re transitioning from RUP to a disciplined agile approach.
