The dysfunctional Agile team member

dysfunctional agile team member - team analysis content on a Kanban board

When you have a fantastic Agile team, you can just feel it. The customers are happy. People are having fun at work. Management is thrilled. Overall, work is getting done collaboratively with high quality.

You can also feel it when you have a dysfunctional Agile team. Work isn’t completed, with activities punted to the next sprint or release. Some are anxious, some are uninspired, and some are flat-out hostile.

Ideally, you would like to address these issues in well-run retrospectives. Unfortunately, my experience has been when you have an unbalanced team that’s not performing, retrospectives aren’t as valuable as they could be. The team doesn’t change. Or even worse, they don’t see any need to change. This is when you need to work with your ScrumMaster and/or Management to reconsider team composition to address the team dysfunction.

It’s weird to me, but many of my clients don’t want to switch up teams – it’s a sacred cow. “Oh, no. We can’t reconfigure the team. This is who we have. There’s no one else. Period.” I’m saying, “Yes. You can make changes.” No, I’m not talking about flat-out firing someone (although, there are the exceptions where this is the clear and obvious course of action). And no, mixing up team members is not something you do frequently. But, sometimes you just need to switch out team members for the good of the team, stakeholders, and your customers.

I offer the following matrix with both Capability and Willingness as the axes for consideration. Capability refers to “technical skills”, such as coding skills, testing skills, business analyst skills, etc. as well as demonstration of Agile values and principles. Willingness refers to the “people” portion of skillset – how they openly embrace and buy into fundamental Agile values and principles, such as collaboration, responding to change, feedback, working as a complete team (not as a specialist), and so forth.

Capability vs Willingness

While it’s ideal to have all your team members be in the upper right quadrant from the outset, this is rarely the case. I usually run into teams assigned by Managers because the resources are available. To get more people towards the upper right quadrant, I much prefer to pair folks that both share high willingness. This enables a person with more experience to more easily transfer technical skills and knowledge to the person with less experience. I have seen time and time again tremendous growth of the junior person with this pairing.

In the case of high capability/low willingness, this can be a sign of someone with tremendous and valuable experience. I have seen some, over time, transition into greater willingness, especially when they see their own work product acknowledged. However, this tends to be more exception than the rule. This often requires investing quite a lot of energy – this could be in the form personal one-on-one coaching. In a public setting, it may require very active facilitation of group meetings, especially when this person starts to bring a room down.

But, if the high capability/low willingness person is unwilling to share, play as a member of a team, teach others, and pick up the ball in another area, they are not as useful and can be a low return on investment. Worse, I have seen a poor attitude (either passive, aggressive, or combination thereof) negatively impact others on the team. I much rather have someone who is honestly willing to give something a real try who is less technical, than someone who is rigid, won’t change or ask for help, but is technically heads above others. So, consider making this person a consultant to the team, thereby limiting exposure while still reaping benefits from their specialization.

Finally, for those with low capability and low willingness, there needs to be heart to heart conversations from the outset. I have asked even in a first sprint to have these types of folks removed from the team altogether, sometimes with very negative impact from management. This typically passes over time, especially when the team performs.

In the end, the important thing is to deliver working, high quality product that delights the customer with significant business value. Don’t let fear of reorganizing non-optimal teams hold you back. After all, the person who might be introducing the dysfunction might eventually thank you for it.