LeSS Basics: Insights from My Recent Course with Angela Johnson

I just wrapped up a two-day LeSS (Large Scale Scrum) Basics course, and I have to start with this: if you can take any class from Angela Johnson, you should. Seriously.

Angela is a dynamic instructor with a real command of all things Agile. She speaks with confidence on nearly every topic, draws from rich real-world experience, and peppers her sessions with examples that actually make sense in day-to-day practice. On top of that, she’s funny, relatable, and real. In short, you’ll learn a lot, and you’ll enjoy the process.

The class was virtual, small (less than 10 people), and ran four hours each day. The intimate size made it interactive and engaging, which is essential when you’re discussing scaling frameworks — and trust me, there’s a lot to digest when it comes to LeSS.


What LeSS Brings to the Table

At its core, LeSS is about simplicity at scale. Unlike some scaling frameworks that can feel heavy and prescriptive, LeSS emphasizes a straightforward principle: organize teams around products, not components or functions.

Here’s why I like it:

  • Single Product, Single Backlog, Single Product Owner: LeSS centralizes priorities by ensuring there is one backlog per product and one Product Owner responsible for it. This eliminates a lot of the confusion and duplicated effort that can occur in multi-team environments. Everyone knows what matters most, and decisions flow from a single source of authority.
  • Empowered Product Owners: The framework assumes that the Product Owner is a true leader — someone empowered to say “yes” or “no” and make tough decisions. This clarity in decision-making keeps teams focused and aligned.
  • Feature Teams, Not Component Teams: Teams are expected to deliver end-to-end customer value, not just a slice of a system. This encourages cross-functional collaboration, reduces hand-offs, and ensures that every team owns the value they produce.

To me, this is elegant. It’s simple, clear, and scalable. The framework itself doesn’t try to prescribe every process or ceremony — it creates guardrails that allow organizations to grow without losing agility.


Real-World Considerations

Of course, as with any framework, there are practical realities to consider. In my current organization, for example, fully implementing LeSS would require a massive re-org. Our teams aren’t structured as feature teams, and roles and responsibilities aren’t aligned for a single-product approach.

That’s not a critique of LeSS — it’s just the reality of scaling frameworks in complex, existing environments. Re-orgs are possible, but they’re not trivial, and they’re not always feasible in the short term.

That said, even in organizations that can’t adopt LeSS wholesale, there’s a lot of value to be gained. Concepts like centralized backlogs, empowered product ownership, cross-functional feature teams, and continuous inspection/adaptation can be incrementally applied.

For me, this is exactly how I approach scaling frameworks in practice: take what works, experiment, measure the impact, and adapt along the way.


Key Takeaways from the Course

While I took a lot from the two-day session, a few points stood out the most:

  1. Simplicity is your friend. LeSS isn’t about adding more roles or ceremonies. It’s about streamlining decision-making and reducing complexity. That’s always been a theme I come back to in my work: over-engineered processes create more headaches than they solve.
  2. Alignment over activity. Having a single Product Owner and backlog ensures that all teams are pulling in the same direction. This eliminates the “siloed feature teams” problem and encourages collaboration across the organization.
  3. Inspect and adapt at every level. LeSS isn’t a rigid framework; it’s a mindset. The framework emphasizes continuous improvement, both for teams and the organization as a whole.
  4. Scaling is cultural, not just structural. You can implement processes, but the real transformation happens when leaders, teams, and stakeholders embrace agility as a guiding principle.
  5. Feature teams empower learning. Cross-functional teams delivering end-to-end value have far more opportunities to innovate and learn from real customer outcomes. This aligns perfectly with the outcome-driven mindset I advocate in my coaching work.

Putting It Into Practice

Even though my organization isn’t in a position to implement LeSS fully, I now have a new set of tools and ideas to apply to our hybrid approach.

For example, I can:

  • Experiment with centralized backlog thinking for product areas, even if we don’t have a single Product Owner yet.
  • Encourage feature-team-like behaviors — cross-skilling, shared ownership, and end-to-end delivery — within our existing teams.
  • Embed continuous inspection and adaptation into our current practices, using LeSS principles as a lens to evaluate impact.

Basically, I can integrate the essence of LeSS without overhauling the entire org. And that’s exactly what makes frameworks like this valuable: they give you a guiding philosophy, not a checklist.


Looking Ahead

I walked away from the two-day class inspired. Someday, I plan to take the three-day LeSS Practitioner course and get certified. But even before that, LeSS has earned a place in my Agile toolbox.

As with any framework, the key is pragmatism. You take the principles, experiment, gather data, and adapt based on what actually works in your environment. That’s always been my mantra, and LeSS reinforces it beautifully.


Final Thoughts

Two days, less than ten people, and a virtual classroom was all it took to make a lasting impression. Angela Johnson’s expertise and humor made the content accessible and memorable, and the principles of LeSS reminded me why simplicity, alignment, and focus on outcomes matter so much — especially at scale.

Even if your organization isn’t ready for full LeSS adoption, the course is worth it. It will expand your thinking, provide concrete strategies for improvement, and give you a framework to experiment thoughtfully with scaling Agile.

For me, LeSS is now part of the lens I use to inspect, adapt, and improve. I’ll apply what I can, gather the data, and keep learning — just like I always do.

Agility isn’t about adopting every framework; it’s about taking what works, testing it in your context, and continuously improving. LeSS reminded me that simplicity and focus at scale are not only possible — they’re essential.

Daily Collaboration: Bridging Business and Development

Back to Basics Series – Principle 4

Business people and developers must work together daily throughout the project.

https://agilemanifesto.org/principles.html


What Does It Mean?

When the Agile Manifesto was written back in 2001, this was a radical idea. Business and technology working together daily? For many organizations, those groups lived on opposite sides of the wall: business tossed requirements over, and IT tossed timelines back.

This principle is about tearing down that wall. It doesn’t say “once a month status update” or “quarterly alignment session.” It says daily. That’s how important collaboration is. Because when business and developers collaborate continuously, we don’t just build faster—we build the right thing.


My Experience

I’ve coached in organizations where this principle was ignored, and the result was predictable: business teams spent months dreaming up requirements, while developers built exactly what was asked—only to discover it wasn’t actually what the business needed.

I’ve also seen the opposite. In one case, a product team invited developers into every early-stage product conversation. Instead of being “order takers,” developers became creative partners. They brought up technical possibilities and risks early, saving weeks of rework later. The business side loved it because ideas got sharper faster, and developers loved it because they weren’t just building blindly.

It wasn’t always smooth—there were debates, even arguments—but the end product was far stronger.


Why This Matters

When business and developers collaborate daily:

  • Assumptions surface sooner.
  • Misunderstandings shrink.
  • Trust grows.
  • The product evolves in real-time to meet customer needs.

When they don’t:

  • Requirements rot in documents.
  • Developers become order processors instead of problem-solvers.
  • Products miss the mark, even if they ship “on time.”

The truth is, daily collaboration isn’t about meetings. It’s about partnership. Agile isn’t just a delivery method—it’s a way of connecting business value with technical expertise in a continuous loop.


Take It to Your Team

Try this in your next retro:

  • Ask: When was the last time business stakeholders and developers sat down together outside of a formal meeting?
  • Explore: What’s stopping daily collaboration? (Time zones? Culture? Org structure?)
  • Experiment: Pick one lightweight practice to bridge the gap—maybe a shared Slack channel, a daily 10-minute “business + dev sync,” or inviting business partners into sprint reviews more actively.

The principle isn’t about adding ceremony—it’s about removing walls.