A survey of how tech projects run across the industry highlights Scrum being absent from Big Tech. Why is this, and are there takeaways others should take note of?
Hey Gergely - recent subscriber, now catching up on these articles. Great post that accurately summarizes my own personal experience. One small note - in the "In defense of Scrum" section, you write:
“Kitchen sink teams” occasionally appear in Big Tech, when a product team gets too many responsibilities."
It's been my observation that there are some platform teams even in Big(gish) Tech that will adopt Scrum precisely because they do have a variety of requests thrown at them. For example, some Security and Infra teams come to mind. They service engineering requests from all over the company (eg. create an S3 bucket, associate policies with that bucket, create a new VPC and so on) and hence must adopt Scrum to convey a notion of capacity and priorities.
Can you please share more details about “A European tech company struggling with shipping very slowly hired a new VP of Engineering. This person decided to move the whole organization to a NoEstimates method in the first few months of their tenure.”?
Similar to Soam, I am also a recent subscriber catching up! Lots of great material.
One aspect you didn't touch on is how teams answer the question "when will the project/feature/milestone be completed?". Do you have any insight into how the non-scrum teams you analyzed come up with timelines? Are they still using story points and velocity? Do these businesses even value predictability, or are they much more value-driven?
Hey Gergely - recent subscriber, now catching up on these articles. Great post that accurately summarizes my own personal experience. One small note - in the "In defense of Scrum" section, you write:
“Kitchen sink teams” occasionally appear in Big Tech, when a product team gets too many responsibilities."
It's been my observation that there are some platform teams even in Big(gish) Tech that will adopt Scrum precisely because they do have a variety of requests thrown at them. For example, some Security and Infra teams come to mind. They service engineering requests from all over the company (eg. create an S3 bucket, associate policies with that bucket, create a new VPC and so on) and hence must adopt Scrum to convey a notion of capacity and priorities.
"Teams rotated Scrum Master roles"
Isn't that a bad practice?
Laponzo: why would it be bad practice? Similar to different engineers leading projects (https://newsletter.pragmaticengineer.com/p/engineers-leading-projects?s=w) help those engineers grow; different engineers taking on the Scrum Master role helped other people grow in this area.
What is your experience in rotating roles over the same person playing them all the time?
TBH, I was curious to know whether that was recommended when I first read that line (since I have had experience with only one Scrum Master per team) and I had Googled it to find https://www.scrum.org/resources/blog/can-you-rotate-scrum-master-role
Can you please share more details about “A European tech company struggling with shipping very slowly hired a new VP of Engineering. This person decided to move the whole organization to a NoEstimates method in the first few months of their tenure.”?
Hi Gergely!
Similar to Soam, I am also a recent subscriber catching up! Lots of great material.
One aspect you didn't touch on is how teams answer the question "when will the project/feature/milestone be completed?". Do you have any insight into how the non-scrum teams you analyzed come up with timelines? Are they still using story points and velocity? Do these businesses even value predictability, or are they much more value-driven?
Thanks for this! This article resonated with my experience and helped clarify some questions for me.