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