My general answer is start with Vanilla scrum and change your environment to get better throughput, quality and team work.
First off, Scrum is a receipt that works. I and many of our coaches tell folks to implement vanilla scrum to see how it positively affects the whole system. Also, see where the pain remains and keeps you from getting the cost of iterating down.
A great way to do this for a new team is to have them run daily sprints for a week. (I learned this from a team at in Vancouver - Agile Vancouver's 2008 "Much a do about Agile" conference.) The great thing about doing planning and retrospecting daily is that it teaches you the practices very quickly. It also forces you to keep your planning time down to less than an hour and drives learning very fast with daily retrospectives.
When you are a novice at Scrum, the benefits of the individual practices and the overall receipt are hard to see apart from each other. The fast daily feedback loops shine lights on your problems. But, the extremely fast pace forces you to live with these pains for at least a week. Now we all know it is so easy to rationalize or justify the difficulties/problems away, but if you don't let that happen you can use that pain to make some major strides in the quality, throughput and value that your team delivers.
So, I totally understand making a hybrid version of scrum like Scrumban. But, I only support that in a team that has visibility, transparency and measurements in place. Adjustments to vanilla scrum should be put forth as tests. If the tests yield better results, you should keep them and hybrid it. If they do not yield better measures, you should not. Of course this begs a strong technical infrastructure, like Rally or AgileZen to manage metrics reporting:)
Again, Hybrid for better results not to satisfy your long, linear and late current behaviors. Way more on this topic on our blog from Ed Willis - "In Defense of Half-Assed- part 1 & 2"