Venetia Foo on how one team member can destroy a whole team

Many of us have been in teams where there’s a “dominant” team  member. But have we thought about the possible consequences that it may bring to the team? In this episode we explore the possible consequences that dominant team members can trigger. We also discuss a very unusual way to address such situations, one that takes into account the whole team, not just the dominant team member.

About Venetia Foo

Venetia has been on her agile journey since 2007 and has been a witness to the best and to the worst of it. She is passionate about learning and continuous improvement. She uses a variety of skills to empower and enable teams to perform at their best.

You can link with Venetia Foo on LinkedIn and connect with Venetia Foo on Twitter.

2 thoughts on “Venetia Foo on how one team member can destroy a whole team”

  1. I think asking scrum masters to demo their experience is not always the best. Scrum masters should never hit the ground running. They need to observe listen, take notes and experiment with the team. Every team is unique and scrum masters should be given time to bond and understand their new team. Football coaches are hired based on their experience and knowledge, Scrum masters can be hired based on this too or hired and encouraged/improved through training and other things. I think the QA probably didnt ‘gel’ with the team because the team felt somewhat to him or her. If its the whole team who have an issue with the QA then other incoming members to the team may not really survive. Teams need time to bond and i dont think four weeks is enough to make this happen. Agile is about being flexible, respective and a lot of face to face conversations around and outside work could have been done. Was the QA welcome, celebrated and got to be known outside before any work was done, was there a list of expectations the team expected the QA to achieve? I stand to be corrected but even if the team didnt need a QA, did the team do enough to accept the person and show respect to the QA that was hired. Thanks so much for this toolbox. Its a lot of blessing to me personally

  2. Hi
    Thank you for your comments. In this instance the QA did initially gel with the team on a social/personal level. They did team activities outside of work together, went for coffee together, lunch together etc. It might not have been clear in the podcast, but the issues didn’t really materialise until week 5 or 6. Again, I must stress that the issues were around his abilities and not him as a person. Numerous sessions were held with the team (that included him) to discuss and agree his responsibilities as a QA, their responsibilities as Devs, and ways of working, which also included various Definitions of Done (with a story, sprint, release). I would like to think that under no circumstances did we ever show any dis-respect towards him.
    I hope this helps. Thank you again for listening!

Leave a Reply

Your email address will not be published. Required fields are marked *