iTranslated by AI
3 Things I Learned from LeSS Training When Scrum Didn't Feel Right
Introduction
"We're doing Scrum, but is this actually right?"
I used to work while carrying that doubt.
In May 2025, I joined a Scrum team and started full-scale Scrum development for the first time. Before that, I had worked in teams interested in Agile, but there was no one with basic knowledge such as the Scrum framework, and to be honest, we were in a state of "just doing something that felt vaguely Agile."
It has been more than six months since I joined the Scrum team. We run sprints, do Daily Scrums, and conduct retrospectives. However, I hardly felt that we were doing good work as a team by leveraging the framework.
- Is this because I am inexperienced?
- Are there deviations from the rules?
- Is Scrum supposed to be like this in the first place?
While carrying such fuzzy feelings, I decided to participate in the Certified LeSS Practitioner (CLP) training. In this article, I will share the insights I gained during the three-day training. I hope it will be helpful for those who have similar concerns.
Overview of the Training
| Schedule | Theme |
|---|---|
| Day 1 | Philosophical Background of Scrum |
| Day 2 | About LeSS and Scrum Events |
| Day 3 | Organizational Adoption and Challenges |
Insight 1: The Three Principles of Agile Development
The theme of the first day was the "Philosophical Background of Scrum." What was introduced here were the three principles of Agile development:
- Focus on the most important
- Ability to adapt
- Learning organization
What emerges from these three is the mindset of aiming for global optimization rather than individual optimization.
Amidst increasing diversification and complexity, value can be realized by converging on and focusing on the single most important thing and committing to it as a team. Driving progress through individualism may seem efficient and speedy at first glance, but proceeding individually increases the information context, which takes time to understand and consequently causes delays for the whole.
Furthermore, I learned that efforts toward task refinement are necessary as an initiative to optimize team learning. This means that to refine and subdivide a single task, people with the necessary skills decompose the tasks they are performing. Then, other members delve deeper into them. By running such a cycle of cooperation across the entire team, the expertise of the whole team increases.
My Takeaway: The idea of "committing to the single most important thing" is also connected to the discussion of the "illusion of tracking progress through quantification" that comes up later. Instead of chasing numbers, the team should engage in dialogue and focus on what is truly important. I understood that this is the fundamental philosophy at the root of Agile.
Insight 2: Scrum Events Based on LeSS Concepts
The theme of Day 2 was "About LeSS and Scrum Events." Here, I learned the original purpose of Scrum events and the unique concepts of LeSS.
The True Role of User Stories
In what format are Product Backlog Items (PBIs) written in your team?
"Add a △△ button to the 〇〇 screen"
"Implement the □□ endpoint of the API"
Are specific solutions written directly like this?
What I learned in the training is that PBIs should originally be written in the form of user stories that explain "whose problem is being solved and how." Deciding on a specific solution from the beginning robs the team of its creativity.
The way a team engages is completely different between being told "Please implement this" versus being told "Please solve this problem" and thinking about it themselves.
Definition of Done (DoD) and UNDONE
What does "Done" mean? Is it done when the code is finished? When the review passes? When it's deployed to production?
In the training, I learned the importance of the "Definition of Done (DoD)." The DoD is a clear set of criteria that the team agrees upon to say, "If we satisfy this, we can call it done."
Any work not included in the DoD is called "UNDONE." For example:
- Regression testing performed outside the sprint
- Integration checks with external services done all at once before release
- Postponing documentation updates
When such work accumulates as UNDONE, the state of "it should be finished, but there's still work to do" continues every sprint. Like technical debt, this comes back later as a significant cost. The team has a responsibility to reduce UNDONE.
The Original Purpose of Each Event
Are you just "going through the motions" of Scrum events? In the training, we reconfirmed the original purpose of each event.
Refinement has two important purposes:
- Alignment among members: A place to check "Does everyone have the same understanding of this PBI?"
- Providing impact information to the PO: Helping the Product Owner make decisions by conveying information such as "If we do this, it will have this much impact."
It might be good to reflect on whether it has become a mere estimation meeting. Also, a method for bringing up specific use cases (examples) was introduced. By giving concrete examples like "What happens in this case?" or "Is this case covered?", it becomes easier to align the whole team's understanding.
In Planning, based on the PBIs aligned during refinement, the team commits to what will be achieved in the sprint.
What's important here is to add a context of "education" into the plan. This is based on the idea of a "Learning Organization" mentioned in the three principles of Agile. In other words, a way of proceeding where tasks are subdivided into individual tasks for each person to handle is a structure that shouldn't exist if you're aiming for a professional team. It is assumed that the team progresses while learning together.
The purpose of a Retrospective is not "reflection" or "blame."
- Expansion of DONE: Broadening the Definition of Done (i.e., reducing UNDONE)
- Reviewing Working Agreements (WA): Updating the team's rules
If your retrospectives have become routine, it might be good to think about topics from these two perspectives.
My Takeaway: Looking back, my team might have had many solution-based PBIs. Also, regression testing and external service checks, which were cited as UNDONE, are done each time in my team, so it seems there's no need to categorize those as UNDONE. However, there is a dilemma that specifying them in the DoD increases the number of check items, so I felt that solving this through automation is ultimately the best approach.
Insight 3: Organizational Adoption
The theme of Day 3 was "Organizational Adoption and Challenges." I learned the concepts for introducing and establishing Scrum within an organization.
Theory X and Theory Y
The discussion on Theory X and Theory Y was particularly impressive.
- Theory X: The belief that people are inherently lazy and will not work unless managed and monitored.
- Theory Y: The belief that people naturally seek fulfillment and can work autonomously.
Scrum is predicated on the Theory Y mindset. However, even if a team has adopted Scrum, elements of Theory X thinking and philosophy can sometimes be seen in various aspects.
I learned that three conditions are necessary to realize a state of Theory Y:
- Freedom
- An environment where learning is possible
- Authority
Only when these are in place can people work autonomously.
The Illusion of Tracking Progress through Quantification
This was the most memorable topic of the training.
Do you think you "understand the progress" by subdividing tasks, estimating time, and measuring it?
It was pointed out in the training that this is an illusion of visualizing and understanding the situation through numerical values.
By measuring quantitatively, it only "feels like you can see it," but in reality, the team's actual situation might not be visible. Focusing on chasing numbers can lead to losing sight of what is truly important.
To escape this situation, collaboration is necessary. Talk as a team and commit to the single most important thing. Understand the team's situation through dialogue rather than numbers.
My Takeaway: I think it is necessary to communicate constantly to resolve the state where Theory X thinking remains. However, I also felt that it probably won't be resolved unless both sides within the hierarchy show a willingness to reach out. The moment a relationship of "what is demanded" versus "what is provided" is born, achieving Theory Y might become difficult.
Conclusion
Through the three days of CLP, I was able to learn deeply about LeSS. The insights I have stated here are what I felt after those three days, and they are not something that can be fully conveyed in this amount of text alone.
With that as a premise, I hope this serves as a catalyst for those who have read it.
I reaffirmed that Scrum is not just a framework, but a philosophy for delivering value as a team.
Instead of just performing events formally, understanding the meaning of each activity and improving while discussing as a team—that is the essence of Scrum.
I was able to clear up several thoughts and actions that I had been proceeding with while feeling anxious.
For those currently incorporating Scrum who have similar worries or anxieties, what I want to convey is that I don't think there is ever a perfect state or a single correct answer. However, I now feel it is important to return to the ideas and axes you value and keep in mind how you should make decisions.
Discussion