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