Product Owner

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.

Navigating the Project Seas: Unraveling the Roles of Technical Program Managers and Scrum Masters

In the fast-paced and ever-evolving landscape of project management within agile businesses, the roles of Technical Program Managers and Scrum Masters stand out as crucial components for driving successful project outcomes. Both positions offer unique skill sets and carry specific responsibilities that contribute to the overall efficiency and success of a project. In a recent scenario within my company, the need arose to explicitly define and highlight the individual functions and spheres of influence associated with each role. This served as a means to enhance the comprehension of our contributions and the pivotal value we bring to the projects we manage.

Let’s start with the similarities:

1. Leadership and Facilitation:
   – TPMs: Excel in guiding teams through the complexities of large-scale projects, providing strategic direction. They usually do this across multiple, cross-functional teams, often facilitating meetings to coordinate dependencies, risks, and issues.
   – Scrum Masters: Facilitate Agile ceremonies, ensuring the team adheres to Scrum principles and practices. They are usually responsible for team performance. They, too, coordinate dependencies, risks, and issues.

2. Communication:
   – TPMs: Act as the bridge between technical teams and stakeholders, ensuring effective communication. This takes shape in the form of information radiators (reports, Confluence pages, etc.) and fosters transparency across the org.
   – Scrum Masters: Foster open communication within the Scrum team, removing impediments and encouraging collaboration. They also use information radiators through reports or through tools like Jellyfish.

3. Problem Solving:
   – TPMs: Tackle overarching project challenges, addressing risks and finding solutions.
   – Scrum Masters: Focus on immediate impediments, helping the team overcome day-to-day hurdles.

Now let’s discuss the differences:

1. Scope:
   – TPMs: Handle end-to-end project management, considering budget, timelines, and overall success.
   – Scrum Masters: Concentrate on the Scrum process, emphasizing iterative development and continuous improvement.

2. Focus on Details:
   – TPMs: Dive into the nitty-gritty details of project planning, risk mitigation, and resource allocation.
   – Scrum Masters: Concentrate on the details of the Agile framework, ensuring the team adheres to Scrum rituals and principles.

3. Responsibility Level:
   – TPMs: Often have a higher organizational impact, dealing with cross-functional teams and aligning projects with business objectives.
   – Scrum Masters: Primarily focus on the team level, ensuring that Agile practices are followed for efficient development.

Where there is synergy:

1. Clear Communication Channels:
   – Establishing transparent communication channels between TPMs and Scrum Masters is crucial for aligning strategic goals with day-to-day tasks. Scrum Masters have the unique position of being directly involved with their teams and can then communicate in real-time when blockers occur. TPMs can take this information and help the wider org make intelligent decisions.

2. Balancing Priorities:
   – TPMs can support Scrum Masters in prioritizing tasks aligned with the overall project objectives, maintaining a balance between short-term goals and long-term vision. Scrum Masters can provide data such as velocity and capacity to TPMs so that project plans are more realistic.

3. Continuous Improvement:
   – Scrum Masters contribute to continuous improvement by providing feedback on processes, while TPMs ensure these improvements align with overarching project goals.

The collaboration between Technical Program Managers and Scrum Masters is truly akin to a well-choreographed dance, each party bringing their distinctive strengths to the table, ultimately culminating in a harmonious project management symphony. This seamless partnership intertwines the structured approach and strategic oversight of the Technical Program Manager with the agile methodology and team-focused guidance of the Scrum Master. Recognizing the complementarity and disparities inherent in these roles is pivotal to unlocking their full potential and harnessing their collective capabilities to propel projects toward success. By fostering a deep understanding of the nuanced interplay between these roles, teams can optimize their processes, streamline communication, and adapt swiftly to the evolving demands of complex projects.