I recently attended the LeSS (Large-Scale Scrum) training, a course focused on scaling Agile practices across multiple teams working on a single product. While Scrum itself is quite familiar, LeSS takes a distinct approach. It doesn’t introduce more roles or layers to handle scale. Instead, it asks us to simplify, align, and continuously learn together.
The training was a full five-day course that combined both theory and hands-on practice. Beyond learning the concepts, we had the opportunity to apply the principles in real exercises, working directly with the practices we were taught. This approach provided grounded, practical lessons that can help teams build better systems, reduce complexity, and improve delivery at scale. Here’s a summary of the key ideas that stood out and how they might influence the way we approach our work.
1. What is LeSS All About?
LeSS also known as Large-Scale Scrum is a framework developed by Craig Larman and Bas Vodde to extend Scrum to large product groups. Its core idea is deceptively simple: apply the same Scrum principles, but across multiple teams, while keeping the organisation as lean as possible.
LeSS follows the mantra “More with LeSS”, fewer roles, fewer rules, and fewer layers. It favours shared ownership and customer-centric product thinking over project management overhead. Where many scaling models add structure to manage complexity, LeSS removes it so teams can focus on learning and delivering value faster.
2. The Principles That Stood Out
a. “Always Be Arriving” & “Always Be Leaving”
This concept emphasises the dynamic flow of knowledge within a product organisation. “Always be arriving” encourages teams and individuals to continuously acquire knowledge, understanding what needs to be done and how to do it by staying open to new ideas, teammates, and changing contexts. “Always be leaving” focuses on preserving knowledge by ensuring it doesn’t reside with a single person, and the team actively shares and documents both the what and the how.
By acquiring and preserving knowledge collectively, the team becomes more resilient, reduces the risk associated with personnel changes, and avoids territorial ownership of code or tasks. Practices like pairing, documentation, and knowledge-sharing sessions help make this continuous cycle of learning and preservation tangible and sustainable.
b. AI-Augmented Software Development
AI-augmented software development in a LeSS environment enhances the team’s ability to deliver end-to-end value while preserving agility and learning. In this approach, the development loop begins with context, including product requirements, specifications, past examples, coding standards, and team conventions. AI tools then generate code based on this context, assisting developers by reducing repetitive work, suggesting solutions, or filling boilerplate, while the team maintains ownership and ensures alignment with the product vision.
The generated code moves through automation, where tests, static analysis, and quality checks provide immediate feedback. Outcomes are then enriched, feeding lessons learned, improved documentation, and AI model refinements back into the system. This completes the loop, updating the context for the next iteration. By embedding AI into this continuous cycle, LeSS teams accelerate delivery, enhance knowledge sharing across teams, and maintain high-quality outcomes without compromising the principles of empirical learning and cross-functional collaboration.
c. Legacy Code
Every organisation has legacy code, not just old code, but code that’s difficult to change or poorly understood. A useful analogy from the training is that working with legacy code is like digging a deep tunnel: if we keep digging without understanding the structure, we risk collapse. To proceed safely, we need tests that define the behaviour of the code. These tests act as guardrails, ensuring that changes don’t break existing functionality.
When tackling a bug in legacy code, one of the recommended practices is to add characterisation tests. These tests capture the current behaviour of the system, even if it’s imperfect, so developers can safely refactor or modify the code with confidence. LeSS emphasises making continuous improvement part of normal work: frequent small changes, supported by strong automated test coverage, gradually improve legacy systems while reducing risk.
d. Component Team vs. Feature Team
This was a topic that stood out to me during the training because of its practical impact on team structure and delivery. Component teams focus on specific parts of the system (like backend, API, or UI), while feature teams can deliver a complete user feature end-to-end.
Component teams often create dependencies and coordination overhead, each team finishes its part and waits for others to integrate. Feature teams, on the other hand, can release working features directly, reducing handoffs and speeding up feedback. While moving toward feature teams is challenging (especially with complex systems or specialised expertise), LeSS treats it as a long-term goal. The aim isn’t to eliminate specialisation, but to reduce dependency chains so teams can learn and deliver more independently.
e. Specification by Examples
Specification by Examples encourages defining requirements through concrete, testable examples instead of vague descriptions. In LeSS, it’s helpful to follow a flow, starting with the Goal (what the feature needs to achieve), define the Scope (what is included or excluded), and then provide Key Examples to illustrate expected behaviour. This approach improves clarity, reduces rework, and establishes a foundation for automated acceptance testing, ensuring shared understanding between business and development teams.
LeSS also emphasizes three complementary practices: Specify with Examples → Concurrent Engineering → Live Document. Requirements are expressed as concrete examples, enabling all team members to align on “what done looks like.” Concurrent engineering ensures that development, testing, and design work together from the start, validating examples early and minimizing rework. Finally, specifications are maintained as live documents, dynamic artifacts that evolve as the product develops, providing a single, up-to-date source of truth for the team and supporting continuous learning and collaboration.
f. “Small Test”
Small Test refers to writing small, fast-running tests that validate behaviour close to the code, typically unit or component-level tests. These tests provide quick feedback and confidence during development. Traditional testing often follows a pyramid: many unit tests, fewer integration tests, and very few end-to-end (E2E) tests. The Small Test approach encourages maximizing these small, fast tests (unit and component) and using larger integration or E2E tests sparingly, reversing the reliance on slow, fragile tests and ensuring developers can move fast safely.
g. Spillover ≤ 1
This principle comes from managing work within a sprint. Spillover happens when stories remain incomplete at the end of a sprint. LeSS promotes the idea that spillover should be less than or equal to one story per sprint.
This isn’t about enforcing strict rules, but about encouraging predictability and focus. Too much spillover signals over commitment or unclear slicing of stories. By keeping spillover low, teams maintain a sustainable pace and ensure that work truly reaches “done” before taking on more.
h. Test-Driven Development (TDD)
TDD was reinforced as a foundation for sustainable agility. It’s not about writing tests for the sake of coverage, but about designing code through tests. The cycle: red, green, refactor, encourages developers to think about behaviour before implementation.
When done well, TDD leads to cleaner code, better modularity, and fewer regressions. It gives teams confidence to refactor and evolve the codebase safely, which is crucial when multiple teams work on the same product.
3. My Personal Reflection
The LeSS training didn’t redefine what Agile means, it sharpened it. It took familiar ideas like Scrum and testing and reframed them for scale, showing how to maintain clarity and quality even as teams grow.
In essence, LeSS reminded me that scaling is less about process and more about design. Designing teams, systems, and code in ways that enable continuous learning. It’s not about being more Agile, it’s about creating conditions where improvement never stops.
T.8ytes by Titansoft 