My general answer is start with Vanilla scrum and change your environment only when those changes PROVE to deliver better throughput, quality and team work.

Vanilla scrum is a receipt that works. It is a complete system of practices that help you achieve greater throughput, higher quality and more joy.  I and many of our coaches tell folks to first implement vanilla scrum to see how it positively affects your whole system. Also, we ask teams to see where the pain remains that 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 that 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 continue to make major improvements in the quality, throughput and value.  And, most organizations need to make those strides, as they tend to increase the scale, complexity and distribution of their agile efforts as the proof pours in.

So, I totally understand making a hybrid version of scrum like Scrumban.  However, I only support Hybrid efforts in teams that have shown the visibility, transparency and metrics to prove their changes.  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:)  It also requires a team that can reflect and retrospect on the qualitative measures.

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][1] & [Part 2][2]


  [1]: https://web.archive.org/web/20120522095654/http://www.rallydev.com/agileblog/2010/08/in-defense-of-the-half-assed-part-1/
  [2]: https://web.archive.org/web/20120522091539/http://www.rallydev.com/agileblog/2010/09/in-defense-of-the-half-assed-part-2/