I think the core observation that teams are best allowed to adapt to their own situation is a good one. One thing I want to take on though is this:
> “Kitchen sink teams” which have everything thrown at them, typically find that managing stakeholders with a heavyweight process like Scrum is a win. Stakeholders are educated to understand that an ongoing sprint cannot be interrupted and that new feature requests need to be groomed.
I have repeatedly see teams that run like this fail. They're happy in their own right, they've got their process, they get what is in front of them done, but the process makes them entirely unable (actually more often just unwilling) to respond to urgent issues or adapt to a changing environment.
It's absolutely great for a team that has a large number of external stakeholders with diverse needs to be able to point at some process and say "Oh well here's the process we follow, here's what you need to do". But in reality what they're saying is "We're entirely unable to respond to the actual requirements of our stakeholders, so instead we've decided there are only a subset of requirements we're going to fulfill" and anything outside those requirements you just have to work around the team. It very often also works to provide barriers between the stakeholder and the engineer, so by the time they tackle they're either doing the wrong thing, or it's no longer needed or they fail to actually deliver it to the stakeholder. It's a great system to build a well functioning team that entirely fails to deliver what the larger organisation needs. /rant over I guess
That's where short cycles come into play. If something is urgent for business (and often everything is "urgent") then it can fall in the next cycle which is just 14 days away. It's rare that something is so urgent that it should disrupt your entire dev team flow and focus.
Also what happens is you end up with a never ending dev cycle where business expedites an item making the cycle a little longer, business sees the cycle is longer and thus adds in more items to be included further lengething the cycle... I think you get where this is going.
At my startup company we have suffered from just this in past, where we would have never ending dev cycles while our maintenance back logs filled up and never got worked on properly.
> “Kitchen sink teams” which have everything thrown at them, typically find that managing stakeholders with a heavyweight process like Scrum is a win. Stakeholders are educated to understand that an ongoing sprint cannot be interrupted and that new feature requests need to be groomed.
I have repeatedly see teams that run like this fail. They're happy in their own right, they've got their process, they get what is in front of them done, but the process makes them entirely unable (actually more often just unwilling) to respond to urgent issues or adapt to a changing environment.
It's absolutely great for a team that has a large number of external stakeholders with diverse needs to be able to point at some process and say "Oh well here's the process we follow, here's what you need to do". But in reality what they're saying is "We're entirely unable to respond to the actual requirements of our stakeholders, so instead we've decided there are only a subset of requirements we're going to fulfill" and anything outside those requirements you just have to work around the team. It very often also works to provide barriers between the stakeholder and the engineer, so by the time they tackle they're either doing the wrong thing, or it's no longer needed or they fail to actually deliver it to the stakeholder. It's a great system to build a well functioning team that entirely fails to deliver what the larger organisation needs. /rant over I guess