Fred Brooks had it right oh so many years ago. Communication is an exponential cost, so the more skills that you can give to a single person, the more they can do.
But it's even better than that, as every time communication occurs you are playing a game of telephone with translation errors. The essential complexity might be very easy, but when you need to translate that problem from users to project managers to architect to developer(and I'm sure many teams have many more layers than this) the complexity grows out of control.
I thought about this topic when the StackOverflow blog on Scrum ruining great engineers came out[0].
Imagine you have a chart where the x-axis is trust, and the y-axis is skill. x-axis at the far left is management focused. x-axis all the way to the right is developer focused. x-axis in the middle is mutual trust. bottom y-axis is no skill, top y-axis is extremely skilled.
Now let's look at some of the spaces this chart provides. If we start at the top right, we have Professors. They have a lot of skill and have tenure to be able to do what they want. On the bottom right, I imagine something like Adam Sandler's character from Billy Madison(1995), a son of a billionaire who wasted his life and had no productivity.
On the bottom left side we have government contractors or outsourced developers. They do the work they are told to do. In this spot Scrum can be a reasonable way to filter between the very least skilled workers and someone who is doing decent work. But by applying Scrum, you are naturally holding the management axis to the left.
The Top Left doesn't exist. The developer leaves for some place better.
So now we can talk about the middle. At the top of the middle we have Skunkworks projects. And as we can see, this balance between management and development can yield incredible results, if the developers have the skill to back it up.
So we can see there is a careful balance, most developers are probably somewhere in the middle "strike zone", and by applying Scrum to a developer who is highly skilled you are handi-capping them, and if you apply to much force they leave for better pastures.
When you have developers in this strike zone, give them advice, allow them to learn, but let them make their own decisions.[1]
But it's even better than that, as every time communication occurs you are playing a game of telephone with translation errors. The essential complexity might be very easy, but when you need to translate that problem from users to project managers to architect to developer(and I'm sure many teams have many more layers than this) the complexity grows out of control.
I thought about this topic when the StackOverflow blog on Scrum ruining great engineers came out[0].
Imagine you have a chart where the x-axis is trust, and the y-axis is skill. x-axis at the far left is management focused. x-axis all the way to the right is developer focused. x-axis in the middle is mutual trust. bottom y-axis is no skill, top y-axis is extremely skilled.
Now let's look at some of the spaces this chart provides. If we start at the top right, we have Professors. They have a lot of skill and have tenure to be able to do what they want. On the bottom right, I imagine something like Adam Sandler's character from Billy Madison(1995), a son of a billionaire who wasted his life and had no productivity.
On the bottom left side we have government contractors or outsourced developers. They do the work they are told to do. In this spot Scrum can be a reasonable way to filter between the very least skilled workers and someone who is doing decent work. But by applying Scrum, you are naturally holding the management axis to the left.
The Top Left doesn't exist. The developer leaves for some place better.
So now we can talk about the middle. At the top of the middle we have Skunkworks projects. And as we can see, this balance between management and development can yield incredible results, if the developers have the skill to back it up.
So we can see there is a careful balance, most developers are probably somewhere in the middle "strike zone", and by applying Scrum to a developer who is highly skilled you are handi-capping them, and if you apply to much force they leave for better pastures.
When you have developers in this strike zone, give them advice, allow them to learn, but let them make their own decisions.[1]
[0]: https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-...
[1]: https://jessitron.com/2021/05/26/a-high-resilience-org-chart...