Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Vaidas Adomauskas, profile picture
Uploaded byVaidas Adomauskas
PPTX, PDF47 views

20220923 - Vaidas Adomauskas - LeSS conference 2022.pptx

The document discusses scaling strategies for unicorn companies, focusing on case studies from Revolut and Uncapped. It highlights the importance of organizational structures like 'less' (Large Scale Scrum) for managing growth and improving product development efficiency. Key lessons include decentralization, the significance of product ownership, and the value of adapting team structures to enhance performance.

Business◦
Download to read offline
1 LeSS to Scale Unicorns experiences from Revolut and Uncapped Vaidas Adomauskas 2022-09-23 LeSS conference, Warsaw
2 How many unicorns are out there?
3 https://news.crunchbase.com/unicorn-company-list (2022-09-18) 1403 companies
5 Which Agile scaling framework do unicorns use?
6 https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
7
8
9 Context: Revolut & Uncapped
10 Customers: ● Consumers: 7M -> 15M -> ±20M ● Businesses: 200k -> 0.5M -> ±1M Employees: ● Total: 1.3k -> 2.2k -> ±5k ● Business product team: 70 -> 150 -> ? Distributed: London, St. Petebourg, Moscow, Vilnius, Berlin, Krakow. www.revolut.com
11 Employes: 20 -> 120 Product team: 10 -> 55 Fully remote: Five Lessons Learned Fully Remote, while scaling from 20 to 120+ www.weareuncapped.com
12 The Million Dollar Question: How do you Scale a Multi-Product Business? https://www.linkedin.com/pulse/million-dollar-question-how-do-you-scale-business-vaidas-adomauskas/
13
15
16
https://www.slideshare.net/vaidasa/agile-and-agile-methods-what-is-the-most-important-to-understand-to-succeed 17
18 Decentralisation (2019) -> centralisation (2020) -> decentralisation (2021) -> ? ROI = revenue / cost Revolut
19 Example: build (new) banking services: • Build basics fast -> optimise for delivery (even with bugs) • Fix based on data -> optimise for quality (fix bugs, optimise UX…) • Add value -> optimise for learning (customer interviews, pains, gains…) Uncapped
20 Execution = what2 * how
22 What structure was the most fun and efficient you worked in?
23 Startups within startup
25 “Culture follows structure” - systems-thinking thought leader John Seddon “Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behaviour (the culture) is a product of the system; when you change the system peoples’ behaviour changes.” https://less.works/less/structure
Product Owners - CEOs 29 1. Product Owner (as defined in Scrum Guide) 1. Visioner and leader (aligned with company/founders vision) 1. Line manager (team member’s career and development goals)
30 https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/
31 https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/
32 https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/
33 https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/
34 https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/
35 https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/
36 KPIs - quarterly + yearly • Company, department, team (POs accountable) • Business numbers driven • Attached bonuses - WARNING!!! Revolut
Uncapped 37 OKRs - quarterly + 12 months rolling • Company Objectives - mostly cross-department • Key Results business numbers driven - owned by teams (POs accountable) • Prioritised - as we had more than advised - WARNING!!! • Alignment tool - not used for performance management
Functional managers 39 1. Hiring: skills interviews 1. Development: 1:1s, reviews etc., shared competency matrix 1. Performance reviews & promotions: 50/50 split with PO (line manager)
Splitting teams at high growth stage 43 1. Hire into existing team 1. Split team when >±9 1. Hire into both teams till ±7 (avoid small teams)
44 1. Build co-located teams to build new products failed - WARNING!!! 1. Splitting teams too early failed (many too small teams) - WARNING!!! Revolut
Additionally to each team ceremonies 47 1. Weekly prioritisation: one company backlog 1. Weekly design review: one design system 1. Bi-weekly product demo: continuous delivery 1. Bi-weekly retrospectives: continuous improvement 1. Weekly operational meeting: operational topics
Direct, candid opinions and discussions are key 48
49
50 Were we “doing” LeSS? https://less.works/less/rules (Structure, Product, Sprint)
LeSS Structure 52 • Structure the organization using real teams as the basic organizational building block. • Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived. • The majority of the teams are customer-focused feature teams. • Scrum Mastersare responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices. A Scrum Master does not focus on just one team but on the overall organizational system. • A Scrum Master is a dedicated full-time role. • One Scrum Master can serve 1-3 teams. • In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus shifts from managing the day-to-day product work to improving the value-delivering capability of the product development system. • Managers’ role is to improve the product development system by practicing Go See, encouraging Stop & Fix, and “experiments over conformance.” • For the product group, establish the complete LeSS structure “at the start”; this is vital for a LeSS adoption. • For the larger organization beyond the product group, adopt LeSS evolutionarily using Go and See to create an organization where experimentation and improvement is the norm.
LeSS Product 53 • There is one Product Ownerand one Product Backlog for the complete shippable product. • The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/users and other stakeholders. • All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders. • The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might expand. Broader definitions are preferred. • One Definition of Done for the whole product, common for all teams. • Each team can have their own stronger Definition of Done by expanding the common one. • The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently).
LeSS Sprint 54 • There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated whole product. • Sprint Planning consists of two parts: Sprint Planning Oneis common for all teams while Sprint Planning Two is usually done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items. • Sprint Planning One is attended by the Product Owner and Teams or Team representatives. They together tentatively select the items that each team will work on that Sprint. The Teams identify opportunities to work together and final questions are clarified. • Each Team has their own Sprint Backlog. • Sprint Planning Two is for Teams to decide how they will do the selected items. This usually involves design and the creation of their Sprint Backlogs. • Each Team has their own Daily Scrum. • Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized coordination. Emphasize Just Talk and informal networks via communicate in code, cross-team meetings, component mentors, travelers, scouts, and open spaces. • Product Backlog Refinement (PBR) is preferably done with multiple teams to increase shared learning and to exploit coordination opportunities. • There is one product Sprint Review; it is common for all teams. Ensure that suitable stakeholders join to contribute the information needed for effective inspection and adaptation. • Each Team has their own Sprint Retrospective. • An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and create improvement experiments. This is attended by Product Owner, Scrum Masters, Team representatives, and managers (if any).
55 Wrap up More with LeSS
56
Takeaways 57 1. LeSS (LeSS is more) is very well suited for scaling high growth companies 1. Many unicorns are using structures similar to LeSS, but… work those out organically 1. Huge opportunity for LeSS community to be more active within unicorns 1. Huge opportunity for high-growth companies to avoid “reinventing the wheel”
58 Who will share the next LeSS story from high growth company?
59 Thank you! Vaidas Adomauskas www.agilecoach.lt