Ryan and Todd wrote:Although some of our stories and the techniques in this book are about or can be applied at scale, this book doesn’t focus on ways to help you scale Scrum in environments where several develop- ment teams are working on one product. If you’re considering scaling Scrum, we recommend getting really good at Scrum at a small level first, and then thinking long and hard about whether scaling is truly necessary.
Off to a good start, in my opinion.
What problems does premature scaling bring? What can we do to curb managers' enthusiasm to scale right out the gate or after seeing a few smaller-scale successes? When you write "thinking long and hard," what does that thought process look like? What questions do you ask besides "Is scaling truly necessary?" (because for most people, the answer is always "yes, it's truly necessary.")
The best question to ask is "why are we scaling"?. If it is because there are dependencies galore as a result of poor architecture and can't release without managing them then you've found the problem to fix (the tech not the process). All too often we see architecture define the products in an organization rather than the other way around. The true need to scale happens when you have multiple teams working on the same product.
To avoid criticism do nothing, say nothing, be nothing. -Elbert Hubbard. Please critique this tiny ad: