I get the whole staggered development approach, I work in a company that heavily utilizes it. However, it must be done well. Poorly managed you still end up with bottlenecks. For example you could have all these staggered development teams, but then another critical department that is seriously understaffed, if all these other teams rely on that one department to, let's say: shred and layer the cheese, then it really doesn't matter how many other pizza teams you have cranking out dough/sauce and standing by to deploy toppings, you've got delays while that one group is trying to engineer new and better ways to apply cheese 2.0, 2.1, 2.2 and 2.3 for these other groups.
Pizza. I like pizza! Gonna watch the video later, I'm all hungry now.Now I just want Pizza... can we make an official Test Squadron Pizza? it has to be black and yellow. Cheddar Cheese on the top right and bottom left? then something black on the top left and bottom right, like well done Haggis?
Yeah, I would not want to participate in merging those tens of thousands of hours of work every 3 months.The biggest issue I've had with staggered development is attempting to merge the codebase back to the mainline especially on core functionality that impacts the other team's codebase.
It's worse its 6 months as you typically would have your mainstream then you branch it at the start of the project cycle and then attempt to merge it back to the mainline at the end which at this point is no longer remotely close to you starting point as the other team merged their code back in. This is relatively easy if there is no overlap but is a nightmare if two programmers touch the same methods and classes.Well, I'm happy I helped to inspire this video. A good explanation about the actual benefits of staggered development.
(And I'm happy as long as nobody is saying it gives more time to complete a feature. It's same amount of man-hours, maybe used more efficiently.)
Yeah, I would not want to participate in merging those tens of thousands of hours of work every 3 months.
Yes, I meant you need to go through it every 3 months, as that's still the span between updates.It's worse its 6 months as you typically would have your mainstream then you branch it at the start of the project cycle and then attempt to merge it back to the mainline at the end which at this point is no longer remotely close to you starting point as the other team merged their code back in. This is relatively easy if there is no overlap but is a nightmare if two programmers touch the same methods and classes.
Finally, I understand! Thank you a lot for this!If anybody has any other questions about staggered development, this still shot from the outtake reel may help answer them:
View attachment 13587
We are looking at you UI team ʕ; •`ᴥ•´ʔI get the whole staggered development approach, I work in a company that heavily utilizes it. However, it must be done well. Poorly managed you still end up with bottlenecks. For example you could have all these staggered development teams, but then another critical department that is seriously understaffed, if all these other teams rely on that one department to, let's say: shred and layer the cheese, then it really doesn't matter how many other pizza teams you have cranking out dough/sauce and standing by to deploy toppings, you've got delays while that one group is trying to engineer new and better ways to apply cheese 2.0, 2.1, 2.2 and 2.3 for these other groups.