Project case study: How to help the team remove obstacles?

What I want to share with you today is: How to help the team to eliminate "obstacles"?

In recent years, servant leadership has been accepted and known by more and more people. Eliminating team obstacles is one of the important responsibilities of servant leadership.

In the process of project advancement, it is particularly important for the project manager to identify obstacles and how to respond in a timely and effective manner to ensure the smooth progress of the project. Therefore, project managers need to master the art of removing obstacles, and need to constantly improve their communication skills, creativity, and necessary diplomatic skills.

When dealing with team obstacles, we must first determine which are the real key obstacles for the team. This is very important. For example, some obstacles may be confusing to individuals, so you can let the team members go to "Uncle Google or Senior Baidu" to find the answer. If it is an obstacle for the team, it is really a problem that needs to be solved by the project manager.

Don't be a "on call" project manager

1

I remember that I just joined a new company at that time. My subordinate is a young girl. As a project manager, she is very serious and responsible for her work. Everything in the project is resolved by hand and effort, including project planning, staffing, Problem handling, etc.

Nonetheless, the project she brought always had various unexpected situations, which caused the actual project schedule to be disconnected from the project schedule plan, and then was in a state of constantly updating the project schedule plan and continuously postponing. I saw this cute little girl being serious about her work, and she has busy project issues to deal with and communicate with every day.

Because she had to solve every "obstacle" in the project, she became the team's "nanny" and "firefighter". But obviously the effect was not good, so she came to me for help. I asked her three questions at the time :

1. Is this really a team obstacle, or is it something the development team can solve?
2. Does the project manager really need to remove this obstacle?
3. What is the real problem here?

I want her to realize that only when it exceeds the team's self-organization ability will it become an obstacle, and it is necessary for the project manager to eliminate it . Over the next few weeks, the project slowly became manageable.

Through this example, I hope everyone knows that being able to identify the real key obstacles is the most critical , so as to help the team more effectively, instead of becoming a "firefighter" in the team, extinguishing the fire, and having no time to find fire because. Doing so does not help the overall development of the team.

How did I successfully solve the two obstacles at the same time?

2

We have identified team obstacles, so how to deal with obstacles efficiently?

Here I want to share with you another case I have experienced ↓↓

Case background
At the time, we were working on a comprehensive upgrade project for the CRM system (customer relationship system) of a cross-border e-commerce platform. In this project, the demand side involves the demands of 3 business departments, the system involves the upgrade of multiple interrelated modules, and the R & D team involves 5 Scrum teams of more than 30 people in product, design, development, and testing. I act as the Scrum Master of the entire project leader and 2 core R & D teams. During the iteration process, I will organize team members to hold a meeting every day.

During a stand-up meeting, one of the senior test engineers said: "The test server has been down for the third time this week. I have to spend another day writing new test cases."

Another 90-year-old development student who has just been employed for two months said: "I have spent three days trying to write unit tests for previously completed code, and I have not encountered any obstacles at present."

Be aware that the initial estimated time for this task only took one day, and that the team did not introduce a test-driven development of TDD at the time. Having said that, I think you may have realized that these two team members have encountered obstacles. But the senior testers on the team seem to regard me as the other end of the baton.

In other words, as long as the problem is given to me, then he can do other things. The few words he said during the stand-up meeting have actually shown that he thinks that this problem is beyond his control, so he does not think that this problem needs to be solved by him. However, another young post-90s developer didn't even realize that he encountered obstacles , he was just trying to complete his work.

This is often the case. Whether we encounter obstacles actually requires careful identification. The real problem or obstacle is that he is unfamiliar with unit testing and he needs to learn it specifically; Old code.

In short, in any case, as a Scrum Master, I need to observe carefully, analyze deeply, and understand the problem, so that I can know what kind of help they need.

After the meeting, I went to talk to this development classmate. As I expected, despite the problems with the old code, his experience in writing unit tests was indeed very limited. So I wrote this question on the obstacle card with him to show full attention and to take concrete action for it. It is also to make him feel that someone is helping him, he is not isolated.

At the same time, I am not just focusing on this issue of unit testing. I also wrote a handicap card for testing server issues. And invited the senior test and me to follow up with the colleagues of the operation and maintenance to find out the problem of the test server downtime. The operation and maintenance colleagues restarted the server. Obviously the problem was a systemic cause, but the operation and maintenance did not have time to deal with it.

Just later in the day, the R & D boss came to the meeting room of our team and saw the list of obstacles. Just communicated with me that he found that the test server has become a recurring problem, he promised to start solving this matter from his own perspective, try to solve it as thoroughly as possible. At the same time, the boss also promised that if it is helpful to the development member, he can coordinator to give him unit test training or provide some books.

Therefore, these two obstacles were solved smoothly.

3 practical points to solve obstacles

3

With these two obstacle cards, let's analyze the problems and solutions of the project at that time :

First, we need to determine which are the real key obstacles for the team.

Like the post-90s development classmates in the above case, some team members are not aware of the problems in their work in time, and even if they are aware, they may not be able to accurately analyze the root cause, so this time requires team leaders to be serious Observe, find problems, remove obstacles, and make the project go smoothly.

Secondly, after identifying the obstacle, we need to solve it more efficiently through some methods and means.

Recall what I did in this case? Maybe you will say: You did nothing, it was your boss who handled it! ! ! But in fact writing barrier cards is one of the most critical actions. This is my method and method.

I can help these two team members solve their problems in a few minutes, but I need to equip some simple obstacle removal tools. Once an obstacle is raised, we need to make it visible .

The best way is to maintain a highly visible list in an area on the team ’s task wall. Write down any obstacles you encounter. As the project develops, you will find some common problems that require you to focus To solve.

In the entire life cycle of the project, the project team will encounter many unimaginable problems and problems. These may come from the external environment, the organization itself, the team and personal capabilities, and other aspects. Only when the correct and effective solutions and elimination of team obstacles can the project Successful delivery.

In fact, there are many methods and methods for efficiently identifying and solving team obstacles, which may require everyone to constantly understand and practice these methods in future work and study.

"Blockers", "Classic Obstacles" and "Mine"

4

Finally, I will summarize three types of obstacles encountered by the team during the project life cycle: blockers, classic obstacles, and mines .

The first is called "blockers." Blockers are typical problems that prevent teams from running on normal tracks. Most people tend to think that when they imagine obstacles. Maybe the hard drive cracked on the tester's laptop, leaving him completely unable to work for the next two days. Or maybe a developer ’s daughter is suddenly sick and he needs to leave early to pick up his daughter from school. Regardless of the cause of the blocker, the blocker is often easy to find because someone on the team stops as soon as it appears.

The second kind is called "classic obstacles" . Classical obstacles are a bit tricky. These are all things that slow down your team, but they do n’t necessarily stop them. The team is usually aware of these problems, but has become accustomed to solving them, so much so that they simply log them out as "this will always be the case." In some cases, the team may be so used to these problems that they no longer even notice them, or even forget their existence. Examples of common obstacles include: teams that do not have the authority to change their production environment to provide new features; or teams that have to frequently stop correcting merge conflicts due to outdated source code control systems, and they do not have the freedom to replace them.

These may require skilled technicians to discover these obstacles, because the team is usually used to deal with these obstacles. The team does not even need to raise these obstacles during the regular project meeting. The job as a project manager is to first bring these problems to the attention of the team and remind them that these problems already exist and are slowing them down.

However, once the team accepts these issues, the barriers are usually not as easy to remove as blockers.

This is because the obstacle is often a global, systemic problem that affects the entire team, not individual individuals. In addition, obstacles are often more subtle artifacts due to factors in organizational structure or culture. These will make them difficult to remove.

The third is called “mines” , and the last obstacle that project managers may find to eliminate is mines and traps waiting for their team to trip. These are probably the most difficult types of all obstacles. Unlike the classic obstacles that the team once recognized but gradually disappeared, these obstacles are mines that may never have been noticed before. Usually, an experienced project manager will recognize these problems only because he has seen them fall on similar projects, or because he needs a sixth sense and "open eyes" to notice them.

In an agile project, Scrum Master may find some mines, but it is not completely clear to the entire team, including:

Functional managers actively participate in ceremonies such as retrospectives or daily stand-ups, thus limiting the transparency or honesty that the team can easily share. Or, the daily station will move from the morning to the afternoon, which gives the team members no opportunity to plan and synchronize the team at the beginning of each day, but only at the afternoon station meeting. Even the product owner PO, they are too involved in multiple teams, thus limiting their ability to effectively clear the way for any team. Please note that in all of these situations, although the presence of such mines does not guarantee that disaster will occur every time, at least warn about impending problems.

What makes things more difficult is that when the project manager first tried to point out the mine to the team, it was not uncommon for the team to be initially resistant. This means that the project manager must have a sensitive sense of touch when guiding his team to identify and eliminate this particular type of obstacle.

So, as a project manager, how to deal with the three types of obstacles in the team: "blockers", "classical obstacles", and "mines"?

The first kind of " blocker ", as a project manager, your job is to listen to these issues and try your best to remove these obstacles so that the team can continue to move forward.

"Blocker" solution

You can tell a lot of these questions directly. Is there a spare laptop for the tester to use at the same time, or can he be paired with another tester to test his use case in parallel? However, some others may be helpless. The developer suddenly had to leave the office due to family illness. Can the development team carry out other work around this development process? Or can he work remotely while his daughter is recovering? You may need to work hard to eliminate these problems, or you may need to help the team creatively to solve these problems when they hinder the progress of the project.

The second kind of " classic obstacles ", although the first priority as a project manager may be to eliminate these obstacles so that your team can reach their maximum potential, the ideal long-term goal should be to enable your team to begin to eliminate these obstacles for yourself .

"Classic obstacle" solution

As mentioned earlier, obstacles are often signs of deeper issues in organizational culture. If this is the case, compared with the project manager rushing to solve these problems for the team, the team dedicated to identifying and finding suitable solutions to these obstacles will have a longer lasting impact. This is because the most effective way to solve deep-level problems of the organization is to recognize and solve these problems by the organization itself. Even if the project manager is also a member of the organization, it is often more meaningful to simply solve the problem for others in the team than to make the team aware of the problem and gradually solve it in behavior, which is more like the responsibility of a coach.

The third kind of " mine ", like the classic obstacles, is usually best to guide the team to eliminate these obstacles. However, how you coach depends on how open your team is to these issues.

"Mine" solution

If you find that the team is particularly sensitive to learning and solving landmine problems, then simply instructing them to identify landmines through a series of major problems may be very effective.

On the other hand, if your team resists the visibility of such mines due to strong cultural prejudices or strict organizational rules, then you ’d better stand on the side while the team is moving to the edge to help explain the failure to resolve Possible failures caused by landmines. Although this method is not ideal, it usually only takes one or two times, and the team can more easily receive feedback about where the mine may be buried

Today's Highlights

▼ The way to effectively solve team obstacles:

1. We want to determine which are the real key obstacles for the team. Instead of becoming a "firefighter" in the team, keep extinguishing the fire, but have no time to find the cause of the fire.

2. After identifying the obstacle, we need to solve it more efficiently through some methods and means. In addition to "highly visible and obstacle cards"; we can also use retrospective meetings.

▼ Three common obstacle types:

"Blocker" : It's often easy to find because someone on the team stops when it appears.

"Classic obstacles" : In some cases, the team may be so used to these problems that they no longer even notice them, or even forget their existence.

"Landmines" : These are probably the most difficult types of all obstacles, and these obstacles may have never been noticed before.

Students who need PMP preparation materials can leave a message

Published 185 original articles · praised 243 · 390,000 views

Guess you like

Origin blog.csdn.net/weixin_42400743/article/details/105512879