Project Management

What can we do when a team member isn't pulling their weight?

From the Easy in theory, difficult in practice Blog
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Securing contingency reserves is the responsible thing to do!

Let's flatten five agile fallacies!

Planning for those project disasters that no one wants to think about

What's the link between emotional intelligence and psychological safety?

How do you build your brand as a project manager?

One of the learners in a class I taught asked me how self-organizing teams would handle the situation where a single team member is not performing a fair share of the work.

In a traditional, push-based work assignment model, this issue can also occur. Usually whoever has pushed the work onto the low performer will follow up with them in a timely manner and take direct steps to ensure that performance improves, the work gets re-balanced or the team member is replaced.

But with a pull-based approach where individual team members sign up for work items as capacity frees up and where the focus is on how much is getting completed by the team as a whole, the concern is that someone could take advantage of this by letting their peers take on the more challenging work items leaving them with a relatively lighter work load. From the outside, it would appear that the work is getting done but the contribution imbalance will be less evident.

On a mature self-organized team this is not likely to be an ongoing concern. Team members recognize the importance of demonstrating courage and showing respect for the team and will exert the necessary social pressure on the low performer so that they will either feel embarrassed and start to improve or will be transferred out of the team. If the team uses agile ceremonies such as sprint planning, daily standups or retrospectives, these provide an opportunity to provide feedback with radical candor to the low performer.

But on those teams which are relatively new to working in this manner, the team members might not possess the confidence to openly discuss or challenge such dysfunctions. Passive aggressive behavior might occur such as remaining silent during a retrospective and complaining around the water cooler afterwards.

In such cases, the agile lead or Scrum Master might need to get involved to eliminate the impediment. This intervention could start in a subtle manner such as asking the individual at a daily standup if they feel comfortable with their workload for the day compared with their team members, or "seeding" the conversation during a retrospective when the topic turns to what could be improved. They might encourage other team members to ask the individual to give them a hand with their work items or to conduct a non-solo work experiment (e.g. pair programming).

If this soft approach doesn't work, the Scrum Master may have to more drastic steps such as confronting the individual one-on-one, speaking with their manager or some other type of escalation.

Deferring decision making to the Last Responsible Moment is a lean principle. While a Scrum Master shouldn't intervene if the rest of the team can address an issue for themselves, they should have the judgment to know when they will need to take a more direct approach.


Posted on: July 28, 2019 07:00 AM | Permalink

Comments (14)

Please login or join to subscribe to this item
"If this soft approach doesn't work, the Scrum Master may have to more drastic steps such as confronting the individual one-on-one, speaking with their manager or some other type of escalation."

If the Scrum Master has the authority to take "drastic" steps and confront team members then he/she is not a facilitator anymore and the team is not truly self-organized or at most it is partially self-organized.

Thank you very much, in my opinion you have proven with this article that self-organized teams don't really exist and in order to really solve problems you have to use the good old hierarchical control.

That's what I've seen also in practice but it is not the Scrum Master the one who can take drastic measures but the lead-developer. Anyway usually the role of the Scrum Master is played by the lead developer so they are the same person.

Some time ago I met a former colleague who was working as a Scrum Master and lead developer for a company that was delivering a software to a customer for which I was working.

She was leading the team with an iron-fist and when I told her that this is not how Scrum should work she said that yes you can have self-organized teams but up to a point. At some point you have to intervene in a more direct way. And I think she was right. Still I think she was intervening too often.

Self-organizing is not self-managing. As a SM we can facilitate, coach, influence, etc. There will be times when individual conversations will need to take place, and past that, escalate may be needed.
I have recently seen this type of situation. There were some underlying reasons, but in the end, it did require escalation. A SM is not a manager, not a project manager, not 'the boss'. Learning to grow in a new environment (Agile-Scrum vs. before) is a cultural change and mindset adjustment. This comes harder for some than others

Yes, but when you escalate, a manager with real authority would take a decision and issue and order that others must obey.

Self-managing and self-organizing in my opinion have close meanings, probably non perfect synonyms but still very close. In a so called self-organized team if the manager or the lead-developer wants he can lead in very directive way preventing the team from self-organizing. Like my friend did with her team, she did not allow self-organizing to happen.

So self-organizing teams exist as long as the manager allows them to exist. This has nothing to do with Agile as management can allow teams to self-organize even if they are not using Scrum or are not Agile. Many times this happens in a natural way without the organization to transform itself to Agile.

The reason that some Agile principles don't work is because they are against the way the relationships between people work in a natural way. Also many people just want to do their jobs and don't want to be involved in management and organizing. They prefer to be managed and organized by others. That's why is so hard.

Adrian, agreed, that once escalated there is a paradigm shift, and an authoritative course of action is required. And also agree, that a SM's actions can constrict a self-organizing teams growth and maturity.
I agree with your sentiments, and yes, it is quite a challenge for sure!

Interesting question Kiron. Essentially dialogue, intervention and escalation? Some ramblings...

Would it be correct to turn this on its head and suggest that people who are uncomfortable with the self-organising model *tend* to steer clear of organisations or teams that use that model? Sometimes that may mean moving on from an organisation. I agree with Adrian that some people desire a more command and control environment. The thing is that there is place for both.

I also think we need to separate the concept of self-organising around a defined set of tasks or desired outcomes from organisational strategy and goals, and the control layers that need to be in place to set, guide and support these. This is where people management is needed. I agree that self-organising doesn't mean Agile. However, it seems to me that Agile does mandate and benefit from self-organising *within* a team. Essentially I think if you want to get maximum benefit from Agile you need a team who can take a set of tasks and within the time, cost and quality parameters required plan and execute within the team. So if one team member isn't on board..........

Good to see some healthy dialogue going here! Ashleigh, I'd agree that a willingness to work in this manner is a change that some will find uncomfortable and while most will adapt, others won't and rather than have the team compensate just to be nice, sometimes drastic steps are required.

Considering that a key expectation for SMs is that they remove barriers impeding team productivity & motivation as well as product quality and they are empowered to do so, then sometimes a directive approach is needed, especially when no one else on the team has the confidence to do so.

Good point about Scrum Masters role in helping remove barriers Kiron.

Another thing that occurred to me is that can sometimes suffer from binary views of management (and what works best) to some degree eg Waterfall vs Agile, Command and Control vs Self Determination, when in reality the trick is to determine what combination will deliver the best outcome in any situation. Additionally just because we start with one mix of management approach doesn't mean we can't change or tune it along the way. So I guess dealing with low productivity team members is simply part of the fine tuning of the team. How we achieve that is to some degree irrelevant? It's the overall desired outcome/output that matters?

Scrum Masters are supposed to be facilitators and noting more. If a SM can act in another way than a facilitator then it means that he is not really a Scrum Master. This is simple logic.

The way the SM achieves his goals is extremely important because if he is not just a facilitator guiding the team then he should not be called Scrum Master anymore but Manager or Team Leader or whatever his real position is.

So I guess if you want a real Scrum Master you should appoint in this role someone who has no domain knowledge and no formal authority over the Scrum Team Members. Such a person could not be anything more than a facilitator.

Hmm. From the Scrum Guide, one Scrum Master Service (to the Organisation) is "Causing change that increases the productivity of the Scrum Team". I also see Coaching (another Scrum Master role) as at the first level understanding the people you're coaching. Then you actively steer them.

In one sense though you're right Adrian, there aren't any truly self organising teams (apart from the castaway on a desert island?). But my observation is that some get pretty close. Their productivity and value is quite phenomenal. Maybe I'm just not as wedded to definitions of roles etc I'm more interested understanding how concepts and ideas can be applied to get the best outcome (not that I'm always the best practitioner).

Adrian, an SM who is only facilitating will likely not do a lot to help the team with distractions from outside the team. Active coaching, influencing, persuading and negotiation with stakeholders is needed in contexts where these folks are still in a traditional mindset.

One important distinction of a self-managing team is the concept of Mutual Accountability. Each individual is accountable to other members of the team.

@Kiron I do understand what you are saying but the SM is supposed to be a so called servant leader. If he/she confronts team members or threatens them with escalating to their managers then this is no longer servant leadership in my opinion.

In reality if the SM is also a manager or lead-developer he will make use of his authority over the team, and my friend who was both Scrum Master and lead developer is the proof.

If the SM has no formal authority over then team members then he/she may try to escalate issues to a manager who does have authority.

My point is that in Agile the hierarchical control is used, maybe not as much, but still it is extremely important.

If you remove hierarchical control so teams end up being truly self-organized or self-managed then you may risk compromising a project or any other activity performed with self-managed teams.

Project leadership is very important. We must as leaders help teams members to pull their weight. We could engage in a job rotation of team members and focus of developing the strenght of each individual. Project is team work and every member has value to give to the project. Everybody cant be a high flyer within a project yet they can all give positive contributions

Please Login/Register to leave a comment.


"It's a small world, but I wouldn't want to paint it."

- Steven Wright