The document discusses challenges faced when transitioning an engineering organization from a component-based structure to a more stream-aligned scaled agile structure. Key points include: 1. The transition was difficult and faced resistance as it disrupted existing component "feudalism" and required new ways of working across domains and teams. 2. Some goals of the transition like improving dependencies and establishing a single product backlog were partially successful, while others like building a unified team spirit faced more challenges. 3. Lessons included starting with scoping reforms before organization changes, recognizing different team motivations, and allowing gradual transitions versus "one big step" approaches. Component structures can work but may obscure inefficiencies.

1. Epic battle of
Component Feudalism
vs
Scaled Semi-Agile
Agile Tour 2021
October 27
Alexey Kovaliov

2. Context

3. About EIS
Headquarters:
San Francisco, USA (SFO)
Minsk, Belarus (MNSK)
Toronto, Canada (CAN)
Vilnius, Lithuania (VNO)
Saint Petersburg, Russia (SBP)
Suzhou, China
(SUZ)
Riga, Latvia (RIX)
Odessa, Ukraine (ODS)
Cork, Ireland (IRL)
Australia (AUZ)
https://www.eisgroup.com/

4. Big Platform Solution for Insurance
https://www.eisgroup.com/digital-insurance-solutions/eis-suite/
Closest match- ERP or BSS systems
● Modular
● Extendable
● Configurable
● BIG…
Modern cloud oriented tech stack

5. Engineering Place in the Value Flow
Product Management
Engineering
Sales & Marketing
Professional Services
&
Partners
Delivery
Here we are!

6. Scaled Agile Engineering Organization
Engineering Program
Program
Governance
Product Domain Product Domain
Platform Domain
Agile Teams
Product
Management
Product
Management
Product
Management
Agile Teams Agile Teams
Shared Services Teams
Product Domain
Product
Management
Agile Teams
Product Strategists Sales & Marketing Executives Team
Professional Services &
Partners

7. Scaled Agile Engineering Organization
Engineering Program
Program
Governance
Product Domain Product Domain
Platform Domain
Agile Teams
Product
Management
Product
Management
Product
Management
Agile Teams Agile Teams
System and Shared Services Teams
Product Domain
Product
Management
Agile Teams
Product Strategists Sales & Marketing Executives Team
Professional Services &
Partners
Sizing
10+ Product Domains
50+ Product Components
30+ Agile Teams
5 Countries
4 Time Zones

8. Synchronized Cadencies for all Domains and Teams
Product Domain
Annual Roadmap
Quarterly roadmap Quarterly roadmap Quarterly roadmap Quarterly roadmap
Sprint
Sprint
Sprint
Sprint Product Backlog
Cross-domain Cross-team alignment
Consolidated plans confirmation
Keeping % capacity for change

9. Standardized Sprints for all Teams + CI + Release
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Scrum
SOS
Week #1 Week #2
Sprint
Week #3
Planning
Review
/
Demo
Retro
Test Cases Design
Stabilization
Backlog Refinement
Feature Freeze
Release Candidates
Release Quarantine &
Launch
Auto-Testing
Testing Automation Development
Manual Testing
Design & Development

10. Product Domain
FWKs
Clear Code & Support Ownership for Components
MS
Gateway
UI Team
BE Team
Vertical Team
UI
FWKs
MS
Gateway
UI
Feature set | Capability Feature set | Capability
Releasable
Components
Releasable
Components

11. Platform Domain
Platform Domain
Product Domain
Product Domain Product Domain
Multi-Module / Multi-Component Architecture
Tooling
Example →

12. Inevitable
Cross-Team
Dependencies
and
Hand offs
UI Platform
Team
Domain A
UI Team
BE Platform
Teams
Domain B
BE Team
Domain A
BE Team
Shared Services
UXD Team
Shared Services
System Team
Staged Versions
Release Candidates
Ready to test deployment
UI
Reminder:
50+ releasable components

13. Product Domain
Journey of Optimizing Hand Offs
UI Components
Teams
BE Components
Teams
Centralized
Gateway Team
Centralized
BE+UI Platforms Teams
Centralized
QA
UI+Gateways
Components
Teams
BE Components
Teams
Centralized
BE+UI+Gateway
Platforms Teams
UI Components
Teams
BE Components
Teams
Centralized
Gateway Team
Centralized
BE+UI Platforms Teams
Core BE Components
Teams Centralized
BE+UI+Gateway
Platforms Teams
Vertical Feature
Teams
(UI+Gateways+BE)
Contribution to Platforms code
1.
2.
3.
4.
Distributed to teams
Product Domains teams trained
Platform & Tools
as a product
In transition…
Mix of #3 and #4
2 local experiments
with
Staffing
&
Training

14. Benefits of Domain/Component Teams organization
● Naturally designed Organization
● Good for Planning based on Teams’ Capacity
● Clear ownership of all aspects of Modules and Components in “one hands”
○ Designs, Code, CI, Release, Support
● Deep Domain knowledge
○ Both functional and technical
● Reasonable Cognitive load
○ know-how of tech stack and designs, artefacts etc.
● Reasonable Communication load
○ stable dependencies map
● Flow and skills optimizations possible
○ Proof @ prev slide
● Scalable organization up to 50% within existing Domains and Leadership lines

15. “Annoying” Theories

16. Conway’s Law
https://en.wikipedia.org/wiki/Conway%27s_law
Any organization that designs a system (defined broadly) will produce a design
whose structure is a copy of the organization's communication structure
— Melvin E. Conway
Extension for the Conway’s Law
Initial design will produce an organization which is a best available fit to implement
the design, and then ….(see above)
— Alexey Kovaliov :)

17. Component Feudalism
https://www.linkedin.com/in/alexeykrivitsky/
Organizational design models in the evolution of managerial thinking
(Part 1, Part 2, Part 3, Part 4)
If we'd only had the single common true Product Backlog for all (...), then it would have become transparent
what's important and what's not so. But there is no such thing as a Product Backlog, but instead, such a
company lives in the area of feudalism and internecine wars for their small land plots.
How adaptive is such a company? Will the "product owner" of the "messaging product" give her team to the
"workflow product owner"? That a rhetorical question.
In my experience - no way she would do it. The thirst for status, the fear of losing a job, the ability to invent
features, and politics playing skills - all of this will work contrary to the common sense, which shouts:
"everyone should work on the workflow and nothing else!" So nothing will change and the company will be
slowly doing what is so important, while simultaneously spending resources on what is not important at all.
That drastically reduces adaptability. Yet increases the local focus.
Ouch, that hurts :(

18. LeSS
https://less.works/less/structure/feature-teams
● Component teams = Evil
● Platform teams = Evil
● Everything is Evil, except
Feature Team with T-
Shaped skills
● Platform as a Product =
>:D muahahaha

19. SAFe & Teams Topologies Academy
https://www.scaledagileframework.com/organizing-agile-teams-and-arts-team-topologies-at-
scale/
https://teamtopologies.com/
● Component teams = Evil,
unless they are
○ C-S Team
○ Platform Team
● Stream-aligned | Feature
Teams
● Platform as a Product - ok
● Consider Cognitive Load
● Apply Careful Rotation
● Hand-offs inevitable

20. Very Challenging Project

21. Quiz
Which approach did I chose to try for
the new Very Challenging Project?
1.LeSS?
2.SAFe + Teams Topologies?

22. Very Challenging Project Off the Beaten Track
● Tight Deadline: 6 months
● Goal: MVP for Product Domain X
● Scope: Huge & Undefined
● Architecture: Evolving
Domain X Domain Y Domain Z Partner
Domain
classification
Functional Functional Platform n/a
Management Domain specific Domain specific Program Domain specific External
Product Owner Component specific Domain specific It’s complicated :) Domain specific n/a
Teams BE and UI
separated
BE and UI
separated
BE only Vertical Vertical, but not
established
Technology New Savvy Creators Savvy plus New
Collaborative work Never did From time to time Quite often From time to time Continuously

23. LeSS Inspired Transformation
● Virtual organization of teams as “vertical” and as “universal” as possible
○ Dedicated and empowered Project Manager
○ Mixed and Expanded teams
○ Single backlog
○ Single PO with a team of Proxies and BAs
○ Lead Architect with a joint Architecture Runway team
● Break “component feudalism” walls as much as possible
○ Strive for One Team spirit!
○ Joint Sprint Events
■ Each finishes with joint Demo
○ Continuous cross-team synchronization and knowledge sharing
○ No pre-assignment based on technical components
○ Localized dependencies
○ Straightforward Platform adjustments
https://less.works/

24. Dev Teams
LeSS Inspired Transformation → Joint Flow
Product
Management
Architecture Runway
Team
Product Strategy Team
Client
Other Engineering Domains and Teams
Project Management
Dev Teams
Dev Teams
Dev Teams
Dev Teams
Dev Teams
Dev Teams
Proxy-PO
Feature
streams
Scoping (Kanban)
Joint
Refinement 1
Implementation
Scrum of Scrums
Delivery
Shared
System Team
Joint
Sprint
Planning
Joint
Review
+
Retro
Other Engineering Domains and Teams
Other Engineering Domains and Teams
Other Engineering Domains and Teams

25. “One Giant Leap for Mankind”
https://thehistoryjar.com/wp-content/uploads/2020/04/feudal-pyramid.jpg https://less.works/
Yes, We Can!

26. https://www.pinterest.com/pin/86975836527454312/
“One Giant Leap for Mankind”
https://thehistoryjar.com/wp-content/uploads/2020/04/feudal-pyramid.jpg https://less.works/
Yes, We Can!

27. Transformation Goals Assessment After 4-5 months
Goal Assessment Why
Minimize dependencies between Teams Slowly → Yes Teams were not “Vertical” initially, dependencies from
external turned to internal
Improved teams setup on the → 4/6 teams are vertical
Reduce/Speed up dependencies on Platform Yes Project Stream aligned priorities only
Ensure priority for external dependencies Slowly → Yes Priority conflicts with other Product Domains initially
Learned to resolve by proper facilitation and contribution to
others’ Domains code
Optimize Scoping phase by Kanban Partially Improved for sure, but key was not there
Optimize Scoping phase by technology/component
agnostic Vertical Features
No → Yes Long and painful switch to another style of analysis artefacts,
backlog management, release notes etc. Good for the long
term
Measure progress based on working System Demos Partially Took longer to start making really jointly built Demos
Continuous Learning and Collaborative work on the
scope by joint Sprint events
Partially No desire for continuous learning of other Domain specifics,
too high cognitive load
Close the gaps in Technology skills, establish
Continuous Learning by example
Partially → Yes Took longer than expected, too high cognitive load
Build One Team Spirit and improve motivation No We’ve lost some people. Almost everybody wants to get
back to their Domain.

28. Was it a Failure? Not really
● We clarified and implemented a HELL of THE SCOPE
○ Much more comparing to work as usual
● We introduced component agnostic Vertical Features approach for product
management
○ Will be global for all Domains in 2022
● We revised and refactored MVP designs jointly
○ Prevented of long term risks
● We improved Platform and cookbooks focusing on the real demand
○ Good for all Domains
● We learned how to facilitate joint events - plannings, demos, retro of retro
○ Revised and optimized couple of times
● Engineering Leads and majority of Teams got a habit to look for optimizations and
improvements
○ Revised and optimized teams setups few times
○ Open and bitter Retro of Retros with lots of in-teams improvements
● We will make the MVP by EOY
It’s just Supposed-to-be-Nice initiative turned into Pragmatic, Nervous and Tiresome

29. Lessons Learned
● Study ”Annoying” Theories better, don’t scratch the surface
● First start from proper Scoping reform, then experiment with the Flow and Teams
○ Don’t do both at once
● No single step from Component organization to Stream aligned | Vertical Feature Flow
○ Collapse of traditions is not taken for good even if the metrics show the opposite
○ Intervention of the new approaches and “aliens” offend veterans
○ Transparency and direct comparison of skills & performance may produce hostile environment
○ Beware of “Schrödinger's teams” in Component organizations
○ Alignment on coding standards and design patterns takes time for the teams from different units
● These are not universal motivators, whatever some Agile books say
○ Working on Business oriented Features
○ “Eating your Dog Food”
○ Joint events, Involvement and Collaboration
○ Continuous learning
○ Transparency
● These are still good for complex solutions, whatever some Agile books say
○ Platform team and “Platform as a Product”
○ Guardrails / limits for shared code ownership
○ Specialization, limited cognitive load on teams
● Joint Sprint Events can be boring and wasteful
○ Unless the scope is prepared in an engaging way
○ Unless teams’ skills allow them to engage

30. Inspired by Schrödinger's cat thought experiment
Until the team stays within the established organizational unit, it can be either performing
or non-performing, but the real state is invisible for the external observer because the
established organization can obscure the internal ecosystem. Thus such team can be
considered both as performing and non-performing.
Once the shelter organization is transformed all accumulated inefficiencies, troubles and
toxins accompanied with new learning curve destroy the team and it turns to non-
performing (or non-existing).
“Schrödinger's teams”
Designed and sold by HAUNTERSDEPOT

31. Summary
● Component organization is easy to build and can be reliable, even if not
attractive
● Stream aligned organization experiment can be destructive, even if
attractive
● Scope reform first, Skills second, Organization and Flow third