Lviv PM Day 2019

1. ГАЛИНА ДОКСВЕЛЬ
EPAM Україна

2. • Що таке масштабований
аджайл?
• Чи потрібен нам масштаб?
• Огляд фреймворків
• Сильні та слабкі сторони
SAFe
• Наш контекст та виклики, з
якими ми стикнулись
• Акценти

3. Аджайл в масштабі означає різні речі для
різних організацій – від підходу, який
дозволяє управляти залежностями та
допомагає організаціії синхронізуватись
на всіх її рівнях (команда-команда, бізнес-
розробка і тд.) до реалізації аджайл-
практик в усіх департаментах.

4. • Що ми розуміємо під аджайлом в масштабі?
• Які проблеми ми намагаємось вірішити?
• Яка структура нашої організації
(централізована/децентралізована)?
• Який в нас підхід до прийняття рішень?
• Який розмір нашої організації?
• Які процеси вже є в організації на командному рівні?
• Як взаємодіють наші команди?
• В якому домені оперує організація?
• Чи є в нас або в когось з наших колег досвід роботи з
якимось конкретним фреймворком?
• Який наш бюджет та інші внутрішні ресурси?
• Як ми будемо міряти ефект від впровадження
масштабу?
• Та ін.

5. Aspects / Criteria
Scaled Agile Framework
(SAFe)
Leffingwell
Large Scale Scrum
(LeSS)
Larman/Vodde
Nexus / Scaled
Professional Scrum
Scrum.org
Scrum-of-Scrums (SoS)
PO meta-scrum
Discipled Agile Delivery
(DAD) + Agility at Scale
Ambler/Lines
Recipes for Agile
Governance
(RAGE)
DSDM Drive Strategy
Deliver More
Scrum at Scale
Sutherland/Brown
Spotify "model"
(Tribes, Squads, Chapters &
Guilds)
Kniberg
Description
The method documented by Dean
Leffingwell and Scaled Agile, Inc.
Larman / Vodde model as
documented in "Scaling
Lean & Agile
Development"
Scum-based scaling with
an "exoskeleton" called
Nexus plus over 40
practices
An important mechanism that
may be enough for smaller
organizations but is not a full
scaling approach
Scott Ambler model documented
in the book "Disciplined Agile
Delivery"
Traditional-agile hybrid
of portfolio-project
planning
DSDM is a robust Agile project
management and delivery
framework that delivers the right
solution at the right time
Scrum Inc.’s modular framework
for scaling Scrum
The method used at Spotify, featuring
Squads, Tribes, Chapters & Guilds.
Popularity / Adoption
(new/growing (low) vs.
established/leader
(high)
High Medium Low High Low Low Low Low Low
Flexibility / Emergence:
Prescriptive (low) vs.
emergent (high)?
Low High Medium High Medium High Medium Medium High
Typical Cost to
Implement
High Low Low Medium Low* Medium Low
What Team level
frameworks are
supported? (Scrum,
Kanban, XP, etc.)
Scrum / Kanban / specific XP
practices "mandated"
Scrum Scrum Scrum Scrum /Lean Scrum /Lean Own Hybrid Agile Scrum method Scrum Own method though partly Scrum-like
Scale / Target size
(small - med - large)
Large - Enterprise Med - Large
Small but Nexus+ can go
over 9
Small Med - Large Small Medium Large Med - Large Small - Large Med - Large
Used typically by what
Organization Types?
Focused on enterprises
Has 2 suggested
structures for different
size organizations
New, so adoption is
unclear
Any that are running Scrum Used in many diverse organizations
Adapts to any size.
There is no typical
organization.
Mature Complex Organization
Adapts to any size. There is no
typical oranization.
Only intended for Spotify - perhaps fits
other relatively flat & agile orgs
Focus on CHANGE in
(People, Process,
Product, other…)
1) Process
2) Product
1) Process
2) Product
1) Process
2) People
1) Process
2) Practices
Very agile scaling with little
overhead; team affiliations; cross-
team concern handling
1) Process
2) People
Big Positives / Key
Differentiatiators
The "big picture" and
completeness; getting Agile "in the
door" at large corporations;
actively evolving.
Good PO scaling; strong
principle alignment, Non-
prescriptive - gives
"suggestions"
Authored by Ken
Schwaber
simple, standard Scrum
focus on dependencies &
resolutions
Lots of content; strong in areas
such as architecture, design and
dev ops; incorporates many good
models.
Fluid and adaptive
Very established following in the
UK
Lightweight
authored by Jeff Sutherland
very agile, entrepreneurial, distributed
teams, low overhead
Key Risks / Concerns
Little info on "how", most need
certified SPCs to implement
properly;
Seen as prescriptive; not "agile
enough" in its structures; "quick
start and leave" issues some places
A more "radically agile"
approach that may be a
hard sell in larger
traditional orgs with
many layers and
specializations.
New approach that is
growing and adapting.
Some of the parts are
"secret" unless you go to
the class.
limited scaling, limited
documentation, not clearly
defined
Not likely "sufficient" for large
scale; some differences in
implementation
vague in some areas about the
"how"; can come across as a bit
disjointed. Not prescriptive in
lifecycle.
New approach that is
growing and adapting.
Heavy process overhead.
New approach that is growing and
adapting.
very limited detail about the "how",
Not really a framework; may only fit certain
cultures

6. За різними даними SAFe використовують 23-45%
організацій, які працюють за масштабованним
аджайлом

8. 1. Розвиток фреймворку – вихід нових версій
2. Прозорість – всі артефакти у відкритому доступі
3. Має пропрацьовані конфігурації/розширення для
державного сектору
4. Підтримка – один з найпоширеніших фреймовків
5. Набір інжинерних практик, які інтегровані в підхід
6. Підтримка різних процесів на рівні команда (Scrum,
Kanban, XP, etc.)
7. Поєднує кращі практики та інтсрументарій в одному
«місці»
8. Менежмент залежностей

9. 9. Наполягає на залученості Спонсорів та Бізнес-
власників
10. Синхронізація (Бізнес-Бізнес, Бізнес – IT, IT - Бізнес)
11. Визначена каденція/послідовність
12. Пропонує рішення рівня портфоліо (масштаб в
масштабі)
13. Наявність Roadmap – бізнес, архітектура
14. Відстоює довготривалі команди
15. Гнучкість в контексті зобов’язань (Stretch objectives)
16. Підтримуюча візуалізація на всіх етапах

10. 1. Складність, наявність специфічної
термінології
2. Вартість впровадження та підтримки
3. Відсутніть гнучкості

11. • Працюємо з SAFe 3+ роки
• Один комплексний продукт віком 20+
років
• В релізному потязі 12 команд розобки +
4 сервісні команди
• 120+ інжинерів та 35+ стейкхолдерів
• Розподілені команди - 5 локацій, 3
часові зони

12. - Відсутність прозорості та
синхронізації/узгодження
- Відсутність фокусу і відсутніть розуміння
довгострокових планів
- Підтримка продукту
- Невимірюваність процесів

13. • Проведення планінгу
• Відслідковування залежностей
• Innovation Sprint, підготовка до
наступного інкременту та continious
learning
• Проведення System Demo та I&A
workshop
• Confidence vote
• Термінологія

14. 1. Можна використовувати елементи
SAFe і без імлементації будь-якого
варіанту конфігурації
2. SAFe може допомогти у вирішенні
певних проблем, але він не гарантує
вирішення ВСІХ проблем
3. Малоімовірно, що фреймворк
повністю підійде ващому контексту AS
IS