Epic battle of component feudalism vs scaled agile
Download as PPTX, PDF0 likes48 views
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.
Epic battle of component feudalism vs scaled agile
- 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
- 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
- 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