I have just taken over a team of developers that appear to be quite technologically sound and on the ball. That said they are all very quiet, hours can pass without anyone really talking.

This is not necessarily a bad thing as they appear to be delivering their content in a timely manner.

That said, I find that discussion facilitates the effective creation of team norms/documentation/expectations and want to ensure that key points are not missed when we have these discussions.

What is a good method to elicit input from in this situation?

Right now I am looking at reviewing the definition of done with the team, but it could be sprint planning or a team norms document just as easily.

Edit: As discussed in the comments I am not attempting to alter the behavior of the team members. Attempting to turn an introvert into an extrovert is misguided and futile at best and outright damaging to the individual and team at worst.

More specifically my intent is to find a method that will ensure I get everyone's input so each has their say in the creation of these documents and thus buy's into the team norms.

  • 1
    Danger! Danger!! You have a productive team with a cultural norm. You want to change that because "you find discussion facilitates the effective creation of team norms". I'm not saying you're wrong, but I am very very cautious when you interfere with a functional team, and even more cautious about changing people's essential personalities. You run the risk of transmitting the message that discussion is more important that diversity. Does the team share your value for discussion? if not, that would be my first step. (Just to repeat, I'm not criticizing, merely noting a risk). – Mark C. Wallace May 24 '16 at 19:12
  • 1
    @MarkC.Wallace You are absolutely correct to point this out and I should have been more specific. More succinctly put I want to ensure everyone's input is heard and any concerns are addressed. My personal concern is that the team's personality may result in underlying resentments even though the cause would be an unwillingness to speak up. I have no intention of making them all outspoken extroverts – James May 24 '16 at 19:27
  • 1
    Additionally, as I mentioned I have only recently taken this team over, from my initial glances and experience limited as it is the team does good work and delivers in a timely manner. That said the team has not had a consistent scrum master for the last 18 months so no one has been collecting metrics to the point that the team is not even tracking hours for burn down...so while it appears all is good, I just don't know that. – James May 24 '16 at 19:28
  • 2
    @James you make it sound like tracking hours is a requirement. It's not. Lots of folks deliver early and often without tracking their hours. Take some time to get to know this team before trying to change them to fit into what your particular idea of agile development looks like. My team is currently dealing with a new lead developer who seems to think just like you. He's done nothing but throw us off our game, delay releases, hurt quality, and generally earn the resentment of the team he was hired to lead. Be wary. Observe first. Only act to fix dysfunction. – RubberDuck May 24 '16 at 23:35

The most important part of this is: be yourself. Your team will work best when they are being themselves too. Having said that though, the dynamic of the team is changing (naturally) because a new team member (you) is joining. So everyone (you included) will have to adjust to find the new collective norm.

You may be introverted or extroverted naturally, and it's good you recognize the team has it's own collective personality. I've found it best to approach your role slowly (even with deadlines looming or customers raging), and establish your own credibility. You have to trust each member of the team but they also have to trust you.

So my suggestion is to:

  • Sit down with each of them informally and just chat, visit, dream, ask questions, and let each of them understand who you are so you can understand who they are.
  • At first, privately ask each person what they think of the process and what needs improving, and what they think of the team and what needs improving. At this stage, just listen. Everyone instinctively knows what's wrong and what to fix, whether they'll voice it or not. They just need someone to listen.
  • Then introduce the same questions about process and team in a team setting (the very end of the daily standup is a good time). Doesn't have to be a long conversation unless it naturally goes there.
  • Your experience and leadership has value too, that's why you were hired and/or put in this role. So make your suggestions or directives when it's appropriate. I think you'll find once a discussion is started, you'll hear everything you need to know.

I think the place to start is with the actual scrum ceremonies: planning, standup and retro and see if you can gather the information you want instead of forcing it elsewhere.

For standup:

What you did yesterday and what you are doing today are straight-forward. When I was a team lead / scrum master I found out that replacing "What are my impediments?" with "What is slowing me down?" tended to provided better insight into the impediments.

For planning:

I've found that having people use planning poker cards / tools where they estimate individually first and then reveal to the group can spawn a valuable discussion that might not normally happen if you have especially quiet or overbearing people on the team.

For retrospective:

Once again, introduce a tool or process to generate discussions. If people are worried about confrontation collect the negatives in an anonymous fashion. Provide the initial feedback as scrum master to get the conversations started.

Other Ideas

Depending on your work environment, it might be worth having a release retro to generate a discussion about how to make things better that doesn't focus on the team individually.

  • +1. I currently work with an extremely introverted team (both individuals and team norms) and we have found success in outlining and discussing agile processes/connected goals, then having each team member think about and propose alternatives that meet the same goals but fit their work style and comfort levels. – Jeff Lindsey May 26 '16 at 14:42

My suggestions are:

  • Apart from having meetings, ask them for input individually; being a technically-minded, nerd introvert myself, group settings generally make for discomfort, which can be amplified when they are put on the spot or asked to share their feelings in public.
  • Gamify where possible; nerds love games and will never turn down an opportunity that sounds like fun. Hand out rewards for providing input. I will leave it up to you to determine what type of rewards are appropriate (candy, red bull, skip the next retrospective free card, etc...). I know it seems simple, but you might be amazed how well it can work. One popular example of this is Planning Poker; Centare made a great free iPhone app for this so you don't need to buy any actual cards.
  • Use an anonymous digital voting and polling service like PollEverywhere.com. This makes contributing less stressful, and nerds generally love their phones and using cool digital apps on them, so it's a win-win. They can use their mobile phones to vote or comment.
  • Help them to buy into why you are doing it. If they understand and agree with your approach, and are as on the ball as you say, they will see the value in providing feedback and begin to work with you more. It may be a slow process, so do what you can to help them not feel distracted by having to provide feedback. For example, if you schedule meetings with them, ask for their feedback on the meeting, and shorten the meeting to match the amount of interaction that you are or aren't getting. If you begin to see more traction, lengthen the meeting

My advice would be:

  • Keep meetings to as few people as possible.
  • Keep the meetings short and succinct.
  • Create a relaxed and informal atmosphere in meetings. Things like snacks and fizzy drinks help the team to relax.
  • Do not try to lead the meetings too much. Allow the introverted team members to speak even when you feel there is something you want to say in response.
  • Make sure the team values the Scrum ceremonies. If they do they will be more inclined to speak out.
  • Don't be stressed by quiet spells in the meetings. Allow the introverted team members to fill the silences so they become used to speaking and leading the discussions.

Create sense of freedom by introducing The Core Protocols, especially Pass and Check-In protocols. That will give them a safety belt when needed, it's universal and can be used beyond Scrum. You, on the other hand, would be more encouraged to ask the team and engage them, as they'll just simply pass if not interested.


Be careful to push them to follow standard scrum steps, sometimes introverts don't like it. I'd suggest:

  1. you have to ensure that each team-member understands the theory and benefits
  2. after successful achievement of point #1, you have to implement scrum activities point-by-point
  • Pushing them to follow standard scrum steps completely ignores context - in this particular case, there is significant context in each individuals' behaviors and preferences, and in the current team culture norms. – Jeff Lindsey May 26 '16 at 14:38

Your Answer

