I call this the "group project" problem (there's probably a catchier term kicking around out there), mainly from watching it happen time after time in group pro

I call this the "group project" problem (there's probably a catchier term kicking around out there), mainly from watching it happen time after time in group projects as a TA in school, but it plays out mostly the same in companies. Stated simply: If you split up a task and assign parts to team members, you are only 30% done when all members have completed their part of the task. 70% of the work is in combining the parts back into a coherent whole. So the teams that fail horribly are the ones that work in isolation and believe that combining the output of that work is easy. The teams that actually get a product out the door focus on the majority of the work (making a coherent whole out of disparate parts) as SOON as possible. That means sharing back with the group at the earliest possible moment, and then as often as possible as you update and change your part. Now... scrum is hardly the only way to make that happen, but I think the processes it encourages follow the same trend: Work alone for very short periods, share often, adapt as needed in response to what else is shared. The problem with scrum is just all the rest of it (especially scrum masters... those certifications are a black mark on your resume in my opinion).