LeSS: why broader Product Definition, who is the Real PO and what we are scaling? (Artem Bykovets)
•
1 like•180 views
Slides from talk: "LeSS: why broader Product Definition, who is the Real PO and what we are scaling?" from Online Project Management Day Ukraine conference (29/01/2022) by Artem Bykovets In this talk: The difference between Multiple Scrum Teams and Multi-Team Scrum What is Product and what is not? Why LeSS recommends to use broader product definition Why Feature Teams and what about specialization? What about dependencies? Who is the Real Product Owner and (s)he should do? And some stories, metaphors and jokes as usual :)
Report
Share
More Related Content
What's hot
What's hot (20)
Similar to LeSS: why broader Product Definition, who is the Real PO and what we are scaling? (Artem Bykovets)
Similar to LeSS: why broader Product Definition, who is the Real PO and what we are scaling? (Artem Bykovets) (20)
More from Artem Bykovets
More from Artem Bykovets (19)
Recently uploaded
Recently uploaded (20)
LeSS: why broader Product Definition, who is the Real PO and what we are scaling? (Artem Bykovets)
- 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!
- 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)
- 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)