• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

Fixing your Scrum: Scaling

 
Sheriff
Posts: 16578
277
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.")
 
Author
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic