A team is a set of people where each one may have his own purpose based on his own strong points and competencies. There is nothing wrong in a team where technical specialists and people who are oriented more to communication than to technical aspects work side by side.
Of course, it requires a good organization and a mutual respect. There is a risk that people with large technical background and a good knowledge of the codebase will use their codebase knowledge and their technical skills to consider themselves superior, smarter or whatsoever, and try to force everyone to agree with their decisions.
Some situations can make this risk higher. Examples:
having one "guru" in a small team and constantly treating him as the best of the best. For example if a developer has an opinion, and the guru has another opinion, the wrong thing for the management (project manager, director, etc.) is to say: "he's a guru, so do what he says and shut up" (or, in a more polite form: "He has enough experience and he knows the codebase well, so trust him").
having a separate team of technical specialists (is it actually the case in your company?), for the same reason: if you isolate a group of people and consider them publicly as the best of the best, they may start to neglect the opinions of people who are not part of the team.
As for your second question, you need to have enough background to lead a team of developers. Otherwise, not only you will fail to understand what are they doing, but they will also have a bad impression of being lead by an inexperienced person, and will avoid asking you for questions.
This being said, no, you don't have to be a technical specialist. It's a benefit, but if I have to choose between a person who has good communication skills but lacks some technical ones, and a guru who have no communication skills at all, I'll always choose the first one.
If you were on a team like this, what would you want your boss to do with his time?
- Remove impediments to progress.
- Mediate disputes between team members.
- Interact with business people so we don't have to.
- Keep us informed of that higher level business/project stuff so we don't feel isolated.
- Keep us honest, especially if/when a bad apple gets into the team.
- Be an advocate for the team to other departments.
- Be the unified voice of push-back against unreasonable business requests.
- Facilitate communication amongst the team.
There's probably a bunch I'm forgetting, but that's the core of it. Don't implement process, handle some of that overhead/inefficiency that naturally develops as the team size increases.
Best Answer
Nothing in agile changes how the lead developer should function. They should be involving the rest of the team with system architecture decisions, and technical direction no matter what development model is being followed.
Handing out decisions by edict is a terrible way for any development team to run. Agile just makes getting buy in from the rest of the team a more explicit process, and a lead developer should have been doing that anyway.
Just because there isn't a set lead developer role in a scrum methodology doesn't mean the more experienced programmers opinions aren't the most respected. Agile is not letting everyone go wild on their own thing and then trying to stick it all together, there is still a unified vision and direction that needs to be set.