Return to Answer

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 & 2"

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 & Part 2

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"

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 & 2"

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 and where the pain is getting the cost of iterating quickly 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"

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"