Artem Bykovets: LeSS: чому слід брати Product Definition якомога ширше, хто є справжнім РО і що ми взагалі масштабуємо? UA Online PMDay 2022 Website - https://pmday.org/online Youtube - https://www.youtube.com/startuplviv FB - https://www.facebook.com/pmdayconference

1. LeSS: чому слід брати Product
Definition якомога ширше, хто є
справжнім РО і що ми взагалі
масштабуємо?
ARTEM BYKOVETS
(AGILE COACH & ORG CONSULTANT)

2. Few words about myself
• CEO/ Agile Coach & Org Consultant at SimpleSense
• we are helping companies and teams to work more efficiently by coaching and
consulting them.
• Working in Agile since 2011 acting as a QA and ScrumMaster for few teams in
several companies. Best QA specialist of Ukraine by IT Awards 2015
• Guest lecturer at KMBS MBA programs
• I love to share experience & knowledges
• Active speaker on several conferences & creator of Simplicity Day
international Agile conference
• I love not only to teach but also to learn:
• CSM, CSPO, CSP, CAL-I by Scrum Alliance
• PSM I & PSM 2 by Scrum.org
• CLP & Certified LeSS Coach (1 of 16 in world) by LeSS organization
• KMP-I by Kanban University.
• Happy husband and father of Girl & Boy J

3. Про що доповідь?
▪ РІЗНИЦЯ МІЖ РОБОТОЮ "БАГАТЬМА КОМАНДАМИ SCRUM" І "БАГАТО-КОМАНДНИМ
SCRUM"
▪ ЧОМУ LESS РЕКОМЕНДУЄ ВИКОРИСТОВУВАТИ ШИРШЕ ВИЗНАЧЕННЯ ПРОДУКТУ
▪ ЧОМУ FEATURE TEAMS, А ЯК ЩОДО СПЕЦІАЛІЗАЦІЇ РОЗРОБНИКІВ?
▪ ХТО Є СПРАВЖНІМ ВЛАСНИКОМ ПРОДУКТУ І ЩО ВІН ПОВИНЕН РОБИТИ?

4. LeSS & Scrum basics
LARGE-SCALE SCRUM

5. SCRUM IS
A framework within which
people can address complex
adaptive problems, while
productively and creatively
delivering products of the
highest possible value.
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
Version 2017

6. LESS IS
LeSS is a scaled up version of one-team
Scrum, and it maintains many of the
practices and ideas of one-team Scrum
2 versions:
• LeSS: Up to eight teams (of eight
people each).
• LeSS Huge: Up to a few thousand
people on one product
Version 2017

7. Feature team (in LeSS)

8. Structure is based on multiple Teams (of Developers) not multiple Scrum Teams
multiple Scrum Teams multiple Teams (of Developers)

9. What does it mean to be the same as One-Team Scrum?
• a single Product Backlog (because it’s for a product, not a team),
• one Definition of Done for all teams,
• one Potentially Shippable Product Increment at the end of each
Sprint,
• one Product Owner,
• many complete, cross-functional teams (with no single-specialist
teams),
• one Sprint.

10. Product Definition in LeSS
BROADER

11. Narrow Product definition often leads to “so-called” products J
1. How many Products are we
Developing?
2. Is Shopping cart is REAL
independent Product?
3. Are these 2 top features from
Backlog ”A” more important than
10 & 11 from “Z”?

12. Why do we prefer broader Product definition over narrow?
1. Broader Product definition (with one Product Backlog for whole Product) leads to
bigger overview and better prioritization on System Org level
2. To avoid overlapping / duplication of work / sandbox dynamic and also to reduce
coordination efforts
3. Narrow Product definition often leads to similar to component teams dynamics
between “so-called” products
4. Narrow Product definition leads to work on stated requirements (aka coding what was
said / written). Broader definition makes it easier to step back & work on solution
(Product Development approach)
5. Broader Product definition help to De-Scale organizational complexity

13. Org Complexity Caused by many “so-called” Products or 1 Product

14. But you will need to find The Real
Product Owner to stop SCALING the
Complexity!

15. The Product Owner

16. PO should maintain 5 relationships
1. Teams (mostly prioritization & explaining the vision and strategy)
2. Customers (ask and analyze, collect feedback, etc…)
3. Higher Management (align expectations of stakeholders, escalate ??? provoke them
to Enable more opportunities for self-organized Feature Teams)
4. Customers << >> Teams relationships (mostly “matchmaking” activities: connecting
developers with proper customers / users)
5. Scrum Master (in “many Teams” setup with many SM’s usually the most experienced
SM is working at least once per week with The PO)

17. PRIORITIZATION & ACTUALIZATION

18. Feature team (in LeSS)

19. component vs. feature teams

20. About Feature Teams & dependencies ?
[Q] What if Team A and Team B working on the same component in
the same code around feature logic at the same time?
[A] They can solve such “async” dependencies using CI
(continuous integration) (not a tool, but technique and way of
working). They should integrate really often (maybe even 10-15
times per day)

21. About Feature Teams & dependencies ?
[Q] What if Developer A-2 broken feature Developer B-1 is working
on?
[A] Proper Testing Automation done by developers (TDD like)
should prevent them from surprises

22. About Feature Teams & dependencies ?
[Q] So all of the Teams should know the whole System and all
components, workflows, etc?
[A] The same as in traditional Scrum (single Team Scrum), we are
not expecting the “everyone knows everything”

23. Adding to that and summarizing
• Specialization (including deep) is Good! Not bad!
• When specialization is a constraint to deliver real value to end
user – this should become a trigger to learn / knowledge sharing
• With feature teams, we setup a system which will inspire
learning
• There is no Component ownership by 1 Team in Development.
But there should be Component ownership on Production
(made either by Feature Team, Community or some virtual
group from different Teams)

24. Contacts:
My site: www. simplesense.com.ua
Linkedin: https://linkedin.com/in/abykovets/
Facebook: https://facebook.com/artem.bykovets
Mail: artem@simplesense.com.ua
+38 063 495 36 22 (telegram / viber / whatsapp)