I hope you enjoy this audio recording of my LeSS case study covering the work I did a large server hardware company. This is a podcast or audio book style recording as you might listen to while driving in your car as an alternative to reading the written version. The YouTube and Spotify versions of the recording have a video component which displays slides of the relevant figures as they are discussed. If you would prefer a recording of an interactive overview and discussion of the presentation co-presented by myself and "Mitya" please see the "Case Study Walkthrough Presentations" playlist on the Agile Carpentry YouTube channel instead. Organizational benefits from the incremental approach covered in the case study include: Locally improved adaptability and value delivery within the extended component boundary Improved technical practices that created improved quality, along with improved awareness of what additional improvements could bring Early identification and resolution of defects related to the extended component Improved employee collaboration, engagement, and learning within the extended component teams Increased awareness of organizational impediments and the need to make even more organizational changes The written version of my case study includes a large number of figures. I recommend you review the figures included in the case study prior to or while listening to this recording. Video versions of this reading found on YouTube and Spotify display each figure as it is being discussed. Thank you for your interest. Please feel free to reach out to me regarding any questions you may have, as well as any consulting or training needs. The written version of the case study can be found at: https://less.works/case-studies/large-server-hardware-company More details about myself (James Carpenter) can be found at: https://agilecarpentry.com/ Section Index: 00:00:00 Audio Recording Forward 0:00:52 Synopsis 0:02:21 Skimming Hints 0:02:45 Product Overview and People Involved 0:05:59 Initial Agile Adoption Focus 0:09:15 LeSS-oriented Adoption within BIOS Group 0:12:48 Initial Focus on Firmware Not Hardware Development 0:15:12 Demonstrate Benefits of a Scrum Team 0:16:49 Desired Characteristics of Pilot Multi-Component 0:18:35 Appropriate Diagnostics Feature Set Identified for Pilot Scrum team 0:20:21 Diagnostics Team Behavioral Achievements 0:21:17 Diagnostics Team Technical Achievements 0:22:08 Diagnostics Team Launch Steps 0:23:57 Diagnostics Team Photos and Artifacts 0:25:03 Diagnostics Team Culturally Relevant Elements 0:36:44 BIOS Management Interest 0:38:35 BIOS Overview 0:42:12 BIOS Expanded From the Bottom Up 0:45:24 “In-Between” BIOS Teams 0:48:29 BIOS Organizational Context 0:51:55 BIOS Component Boundaries and Geography 0:57:50 BIOS Geographically Dispersed Teams 0:59:30 Quality Assurance Group Very Poorly Named 1:00:56 BIOS Testers Brought End-to-End Knowledge 1:02:33 Expanded BIOS Multi-Component Goals and Constraints 1:05:31 BIOS Adoption Story in Diagrams Alone 1:06:01 BIOS Engineering and Cultural Challenges 1:14:33 BIOS Adoption Efforts 1:15:02 BIOS Launch Steps 1:17:00 BIOS Component Backlog 1:27:55 BIOS Definition of Done 1:43:10 BIOS Teams Self-Selected 1:44:41 BIOS Cadence and Sprint Timing 1:44:56 BIOS Retrospective Structure Adaptation 1:50:19 BIOS Alignment to LeSS Rules 1:51:15 LeSS Structure Alignment 1:58:17 LeSS Product Alignment 2:00:10 LeSS Sprint Alignment 2:03:14 BIOS Triage Rules 2:05:26 BIOS Unit Testing Is Possible 2:07:54 BIOS Team Count Increases 2:09:17 BIOS Component Boundary Expanded 2:13:22 BIOS India Team Challenges 2:15:49 Coaching Support 2:16:36 Waterfall Pressures on India-Based BIOS Engineers 2:18:38 The Support System Collapses 2:20:07 Conclusion 2:20:07 Reflections on Deep Organizational Change 2:22:00 Summary of Benefits 2:31:57 Wrapping Up 2:32:25 Appreciations

Gene and James discuss why agile roles are being eliminated in some companies. In order to understand the situation in full, from organizational design and systemic implications perspective, these decisions need to be well researched and analyzed. Things to consider, while analyzing: Understanding the real purpose of agile frameworks (e.g. Scrum, Large Scale Scrum) Funding/budgeting that are aligned to products (not projects, programs, portfolios) HR norms/policies, supporting career path, compensation and promotion of agile roles Understanding the differences between job security and role security Have you been impacted by what is described herein? Do you feel that soon you might be impacted by similar decisions of your  company?  Is your company at the point of decision-making, such as: Should Scrum Master role be discontinued in favor of an ‘agile lead’ (or similar) role? Should Agile lead role be eliminated, as next step in agile maturity journey?

The following two LeSS guides for technical excellence are captured in Large-Scale Scrum: More with LeSS. Guide: Communicate in Code.  This is the best way for developers to exchange information and understand each other's work.  Reading someone's clean code and not having the need to be given additional interpretation of what the code means is a strong indicator of developer's proficiency Guide: Integrate Continuously:  "We have installed Jenkins and connected it to Jira" - is hardly an indication that a team has CI/CD pipeline.  The ladder should be viewed as developer's practice/behavior, not as a tool. Below are some LeSS experiments that are supportive of these two guides: Try… Very early, develop a walking skeleton with tracer code Avoid… Architects hand off to ‘coders’ Try… Technical leaders teach during code reviews Try… Raise awareness of the negative impact of legacy code In their short recorded message, James and Gene are talking about these guides, experiments and some real life experience. The above experiments are detailed in Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum

How to embrace and digest the entire body of knowledge that Large Scale Scrum (LeSS) offers? How to understand what is foundational, what is minimally required and what is optional? There is a graphic on less.works site that graphically illustrates LeSS Principles, Frameworks (Rules), Guides & Experiments. However, how the aforementioned relate to one another may require some additional explanation.  In their short recorded message, James and Gene are trying to explain how to read the complete picture of LeSS. Understanding this, will help you navigate less.works site, understand LeSS case studies and read LeSS books.

There are two key information flows in Scrum related to the Product Owner: (1) Adaptively deciding the direction to evolve the product and reflecting that decision in Product Backlog prioritization, and (2) Discovering and clarifying the details of user needs and items. In the first flow (direction and prioritization), information is sought and analyzed related to profit drivers, strategic customers, business risks, etc. In the second flow (details and clarification), the objective is to discover the fine-grained behavior and qualities of items, the user experience, etc.   -- Guide: Prioritization over Clarification; Large-Scale Scrum: More with LeSS; p 178   As Product Owner, you focus on thinking hard about direction and prioritization, but delegate to the teams as much of the detailed discovery as possible. You encourage and help teams enter in a direct conversation with users, acting as a connector, not an intermediary. In short, you are mostly focusing on prioritization rather than detailed clarification, which is delegated to the teams.

Gene and James discuss how LeSS training alone is not enough. Sub-topics include:  LeSS badge is a validation of training content authenticity and quality  LeSS badge is not proof of attendee's post-training capability  LeSS training is not enough to ensure success with a LeSS adoption, even if training is authentic  Self-study BEFORE and self-reflection AFTER LeSS training is a huge plus  Initial LeSS adoption coaching is important

Why do we need more fancy frameworks? Why not re-focus on having small successes with good-n-old fundamentals? The history of Agile Manifesto (AM) and Scrum has 20+ years. Yet, the % of companies that are consistent with basic principles of AM that can demonstrate rudimentary success with Scrum is still very low. These are the current market trends: Agile and Scrum – are now a mainstream/trend/fashion/style Agile coaching – has become another name for many ex-roles Enterprise scaling – seems to be the main goal for companies Large consultancies and business opportunists: Take full advantage of the situation and create “magic scaling solutions”, by relabeling/repackaging/hijacking good-n-old concepts Trivialize what has been already known for decades, to upsell their own, “improved solutions” (analogy: you cannot sell your own brand of a dish detergent, unless you convince your customers that all other brands are ineffective). What the market needs: Less up-sale and marketing Less “magnificent new frameworks” and “enterprise operating models” More successes with basic fundamentals

Gene and James discuss common internal distortions of LeSS concepts and terminology.  * Concurrent Sprints != LeSS * LeSS-Huge is a bad goal * 1-2 Teams per Product Area != LeSS-Huge * Technology Area  != Requirement Area (of LeSS Huge) * "Area Product” (meaningless term) != [Product] Requirement Area

Gene and James discuss the following: * Deep and narrow organizational design changes aligned with adaptablity can produce fruitful outcomes far faster than applying management pressure to squeeze improved performance out of the status quo system. * A deep and narrow LeSS adoption will rapidly produce improvement in adaptablity and value delivery, even when the discomfort resulting from increased transparency sometimes makes it feel otherwise. * The value of using a private Certified LeSS Practitioner or Certified LeSS for Executives course as a way to achieve management alignment at the begining of a LeSS adoption. * The ability of an external Certified LeSS Trainer to provide consultation which is less influenced by the existing power dynamics of a client organization when compared to inside council. * Balancing between external vs. internal agile training and coaching support, and the benefits of decentralized vs. centralized internal agile coaches within an organization. Relevant Links: Learn @ James: https://agilecarpentry.com/ Learn @ Gene:  https://www.keystepstosuccess.com/ #lessworks #less #largescalescrum #agile

For so many companies, inability to estimate, forecast, budget, and manage expectations of clients, users, and management is a big issue.  Below, are some of the most commonly heard concerns:  Our teams cannot accurately estimate work. Our teams are not stable and not dedicated. Capacity is unpredictable. Not everyone is cross-functional and everyone does their own work. What is the point of estimating together? Our teams get confused with historical Velocity-driven planning vs. Capacity-driven planning. When to use what and why?  Our teams have hard dependencies on other teams. Some resources are shared. What can we do?  Our estimation and metrics get so-so fudged, as they roll up through multiple organizational layers to the top.  Our organization is fractal: one PO per one team, each team works in a silo. We cannot “standardize” estimation.  Individual teams are more or less OK, with estimation, but how to we "normalize" estimation across multiple teams?  How do we "scale estimation", so that our sr. management can get a sense of how much work we have?  When is the best time to estimate? How should we provide estimates?  How can we effectively estimate with many developers not be co-located?  When and where is knowledge about the estimated work being used?   Let’s talk about how most of these problems can be addressed in Large Scale Scrum. Instead of implying that LeSS is a silver bullet or blanket solution to everything, lets focus on specific dynamics of LeSS, with respect to:   Specifics of LeSS product group design  Intimate synergy between teams  Roles & responsibilities, artifacts & events   This will provide insight on WHY estimation and forecasting by LeSS product group (e.g. 50 developers) would be more reliable than the same, done by e.g. 50 developers of a traditionally-designed organization.   Relevant Links:  Learn @ James: https://agilecarpentry.com/ Learn @ Gene:  https://www.keystepstosuccess.com/ #lessworks #less #largescalescrum #agile