Poor Scrum Management

This article focuses on Asian workplaces and may not be applicable to other regions. It is a translation from Chinese to English, with the original text written in Chinese. Most of the content has been thoroughly reviewed, and the conclusions have been verified to match the original text.

Introduction

The following content is based on my experiences with the current use of Scrum management in my company.

These are all personal subjective feelings, complaints, and realities.

There are no problem-solving solutions here, just pure venting.

If there are any errors or disagreements, feel free to discuss them below.

When searching for “agile” online, you’ll find an abundance of buzzwords like must-see, must-learn, powerful, simple, flexible, and true agile, or terms like the management method used by XXX company to attract learners.

As a manager, how can you not learn?

But in reality, the results may not be as good. Is your team truly agile or just superficially agile?

What is Scrum?

Scrum is an agile project management framework that helps people and teams deliver value incrementally in a collaborative manner.

In a team collaboration model structured by Scrum management, the most crucial element is trust between team members.

Without trust, all the talk from the Scrum Master about autonomy and high performance is nonsense. Team members’ actions will be passive and inefficient.

Scrum often involves the company’s perception, team behavior, attitudes, and values. It’s not just about hiring a consultant, setting up boards and lists in management software, and holding daily stand-up meetings to call it Scrum.

Those who lack the ability to identify current team problems often end up implementing fake agile.

Role Definitions

Roles in Agile

Scrum Master (SM): The facilitator of Scrum, ensuring the smooth progress of the Scrum process and promoting team self-organization and continuous improvement.
Product Owner (PO): The primary goal of the PO is to ensure that the development team prioritizes the most valuable work to meet product requirements and vision. Acts as a bridge between stakeholders and developers.
Developers: The primary goal of developers is to deliver high-quality software through collaboration and innovation. In the Scrum framework, developers are encouraged to self-organize, make collective decisions, and ensure team progress.

Roles in the Company

Based on the roles observed in my current team:

Stakeholders: People who want to gain product information or be involved in the process. They could be end-users, other teams, senior leaders, or another company.
Leader-A: The head of the entire technical department, managing multiple teams. Needs to interact with other department heads and report to the chairman. Not knowledgeable about product technology.
Supervisor-B: The team leader who has close contact with team members. Currently serves as PO and has close contact with team members, reporting to Leader-A every two weeks. Not technically proficient but actively learning.
Redundant staff-C: A person who contributes nothing or is counterproductive to the team but is still part of the team.
Characteristics of a deadweight might include:
- Talks about a lot of technical things but doesn’t know how to do them.
- Focuses on talking, often with factual inaccuracies.
- Wants to manage everything but fails to complete their own tasks.
- Creates negative emotions within the team.
- Performs tasks not relevant to their position.
Member-D: Team members with varying levels of practical experience.
- Those with good practical experience often complete or exceed expected tasks on time, receiving praise.
- Those with poor practical experience produce insufficient results and need additional training or collaboration.

The Reality of the Workplace

In the real workplace, especially in traditional industries or large teams, various human factors can lead to delays in development progress, resource waste, and inefficiency.

Technical Debt: Accumulated due to prioritizing deadlines or certain requirements, leading to shortcuts.
Rework: Due to technical debt, requiring redevelopment of architecture or software.
Unequal Treatment: Hardworking employees may earn less than senior employees who do nothing.
Inadequate Skills: Lacking key skills or knowledge to complete assigned tasks effectively.
Poor Leadership: Leaders failing to recognize and correct misdirection, wasting time.
Lack of Communication: Poor internal communication leading to unclear information transmission and task execution deviations.
Resting on Laurels: Relying too much on past experience and unwilling to accept new perspectives or methods.
Avoiding Responsibility: Preferring simpler tasks to avoid risks or additional burdens.
Bare Minimum Effort: Working just to get by, lacking passion and motivation.

There may be more issues, and any additional insights are welcome.

These problems highlight the realities of the workplace, not to judge or criticize behaviors like resting on laurels or bare minimum effort.

In some public systems, work needs to be done step-by-step, following predecessors’ methods to ensure stability and reliability.

However, in private enterprises, these behaviors can lead to the failure of Scrum. Agile development emphasizes quick feedback, flexible adaptation, and teamwork, requiring proactive members.

The final implementation results are influenced by various human and cognitive factors, leading to poor performance.

✨ Case 1:
The company plans to design a product, outsourcing it to Vendor A, who has the capability to analyze and complete the work and provide feedback.
However, the company assigns an incompetent deadweight to supervise (or the deadweight volunteers to take charge).
The PO cannot judge if this task suits the deadweight. The deadweight takes over Vendor A’s tasks and pretends that the work can only proceed with their involvement.
Ultimately, the deadweight is left to freely develop and design, resulting in no product output from the long-term collaboration.
If Vendor A had executed the task, they could have completed the execution, analysis, and fully automated the analysis faster (e.g., parameterized design variables and executed optimization analysis).
PS. The product is a placeholder name.

✨ Case 2:
Employee A independently developed a software that received positive feedback.
However, the colleague has left the company. Although the source code remains, technical debt prevents anyone from taking over the code.
Consequently, Employee B is assigned to implement similar software using a new architecture.

These two cases (or more) highlight issues like inadequate skills, technical debt, and rework in traditional teams.

In-depth analysis may reveal problems like lack of communication, avoiding responsibility, poor leadership, or unequal treatment as the root causes.

What Does a Productive Team Need?

Professional People
Ensure the right team members excel in their areas of expertise, avoiding resource waste.
This includes having an excellent leader and team members with corresponding knowledge.
Without professionals, the team will appear incompetent and unproductive.
Trust
Managers may make grand promises but ultimately change direction due to various issues, causing internal conflicts and broken trust among members. Execution will significantly decline.
Additionally, if internal members already have grievances, distrust will only lead to more conflicts.
Sufficient Compensation
Based on trust, compensation should meet a certain standard.
Once it’s known that salaries are insufficient, trust will be out of the question.
Love (❤️)
With trust and adequate compensation, love naturally follows.
Loving your job, achieving a sense of accomplishment, and contributing to the team will enhance cohesion and resource availability.

✨ Case:
A company with a free system but lacking points 1, 2, and 3. Over time, the love for the job fades.
For the company’s managers, they take a passive attitude or allow deadweights to exist too leniently, preventing root cause resolution.
Without improving professional talent, trust, and compensation, Scrum will hardly function as expected.

Current Scrum Execution

Given the lack of trust, revisiting the team’s Scrum execution reveals many humorous situations.

Story Points

Used to measure the complexity of each task, but often evaluated in terms of time by members.

As a result, members try to fill tasks with sub-tasks to inflate points, creating a busy appearance and portraying significant contributions.

Ultimately, the focus is on individual tasks rather than delivering functionality.

Additionally, Story Points can give the impression of being a KPI indicator or create a false sense of importance.

Some break down tasks into many small ones, each worth one point, while others do not. For example:

Repetitive tasks broken down into small pieces, each worth 1 point, resulting in a total of 20 points.
Tasks not broken down, but the work is difficult, and the points given are insufficient, ending up with 9 points.

In the initial planning, an experienced Scrum Master also imposed restrictions like not exceeding 13 points.

Due to the breakdown of tasks and the increase in points, but also with personal constraints on points, the result is a myriad of cognitive biases and obstacles.

There is much more to discuss about Story Points, but limitations in the system leave some parameters unassessed. For example:

Velocity: Story Points / Number of days
Task Execution Speed: Tasks / Number of days
Task Load: Tasks / Story Points

Daily Stand-up Meetings and Sprints

By quickly and briefly updating each other on what was done yesterday, what will be done today, and if there are any issues, everyone can understand the situation.

The Scrum Master said: If you finish your tasks, you can find more tasks on the board.

I believe love is essential to keep it going in a team, right?

Even if tasks are quickly completed, without trust in the team, the execution will lean more towards personal rather than company affairs.

Sprint Review

In the first meeting, there was little resonance for the Sprint Review part.

Deadweights in the team make themselves look busy, spending half an hour talking about things they didn’t do but highlighting their contributions.

In the end, we spent a lot of time discussing details in the meeting.

For example, how to crimp connectors, verify, and explore technical details.

As a result, the first product demonstration became lengthy and dull.

Questioning Each Other

Deadweight C and Member D might get along well.

When Member D explains, C provides the following views:

Did you do this work?
Ask a very professional question ____
Not sure if what you did is right
Maybe there’s another way to ____

Deadweight C often says meaningless things, but in reality, he doesn’t know how to do it either.

In the end, he just makes some statements to show off, which is exhausting.

Constantly Changing Software

From Jira, Trello, to Asana now.

When uploading data, there’s always a concern about data leakage.

However, no professionals (such as MIS) were invited to evaluate if self-hosting services were suitable.

Ultimately, it boils down to whether the company is willing to invest in such project management tools.

I imagine that once Asana’s trial version expires, there may be another software change consideration after some time.

Conclusion

No matter the company or team, these people and problems will always exist.

The only thing to do is adjust your mindset, learn to let go, adapt to the situation, or consider changing direction.

For managers, some issues are unmanageable. They may adopt a passive attitude or tolerate deadweights too leniently.

For higher-level leaders, they are often misled by the PO below them, resulting in no actual products or progress, continuing to waste time and resources.

The conclusion after agile implementation is often:

Agile won’t change the status quo; only a team genuinely wanting to change can make progress.
Agile operations are not agile in the end.
Agile is just remembered for daily stand-up meetings.

Think about it

Is using a Kanban equal to being agile?
Is daily stand-up meeting equal to being agile?
Is hiring a consultant to give lectures equal to being agile?

Many underlying factors like:

Does the team trust each other?
Can the SM identify potential obstacles to achieving the development team’s goals?
Can the PO understand the Stakeholders’ needs?
Are the team members’ professional skills sufficient to complete their tasks independently?
Do team members possess a high degree of autonomy?
Is the Sprint Review an effective meeting?
Is the Daily Stand-up conducted daily and not just a formality?
Are Sprint tasks executed carelessly just to be completed?
Does the company culture support agile development methods?
Does the SM provide customized agile solutions based on company culture?

Due to too many team members skilled at finding excuses to cover organizational, team, and personal problems.

Teams with low autonomy will never become agile even if agile is applied.

Instead, company managers or leaders can ask themselves:

How many deadweights does the company keep?
Which employees truly add value and produce results?
How to make deadweights work without interfering with others?
How to arrange members with no or poor skills?
If the company lacks manpower, are they actively and proactively seeking new employees?
Should unsuitable employees be laid off or reassigned to more suitable positions?
Is the salary of contributing employees fair compared to those who do nothing?
Are internal self-training and SOPs established?

However, for higher-level leaders, the company is not theirs.

Who would willingly undertake the personnel reform?

At most, they’ll give deadweights poor performance reviews. Does that solve the problem?