We've been doing Scrum for a while now at my company, and one of the conclusions we've reached is that you should never make the tech gurus the scrum masters. And that conclusion is totally independent from who you *do* want to make scrum masters, just don't pick the technical guru. The reason? Tech gurus tend to be the technical core of the team, everbody asks them deep technical questions all day long, they also have the responsibility of building the most complex technical features that nobody else can really do, which means that they spend their days entrenched in the core technical stuff of the project *which is exactly the opposite of where the scrum master should be*. The scrum master should, ideally:
1. Be able to keep some distance, what we call a "helicopter view". (Note how being entrenched in technical details doesn't fit well here?)
2. Consider the progress of items and tell people when they have unrealistic estimates of whether their items are likely to be "done" at the end of the Sprint, according to the Definition of Done that was agreed on with the Product Owner. (Again, something that requires not being entrenched in the details of technical stuff.)
3. Be able to talk to management about items on a functional level, and be able to think along with them about prioritization. (This is again something that requires more of a functional view on things.)
4. Understand enough about the technical parts to be part of the team -- the scrum master should only need half a word from his team members to understand why something is a problem. You don't want a scrum master who is to be "massaged" by team members in order to get something done, like you would have to do with a PHB.
Point 1-3 disqualifies techies, point 4 disqualifies professional project manages. Ideally, you would find somebody on the team who is not a tech guru, but also not a tech dummy; and you would find somebody who takes an interest in procedural and functional issues.
Just to state the obvious: the most important thing about Agile is that you do retrospectives: you have to think about what works and what doesn't, and fix up your process. We've been continually fixing up our process over the past couple of years, and there's *always* things that still need improvement. If the poster has to go here in order to discuss this, his team doesn't have this very basic and über important part of Agile down.
