| I agree with this point of view.
In my opinion, one of the greatest fallacy of Scrum and some agile methods is: "Another note on breaking down tasks into chunks" This is the management trick of "divide and conquer". But for real good dev, that is not a good development process. Imagine you are an experienced dev and you need to refactor a 20 files low level code to change the way errors are returned: If you were in an agile/scrum setup, it would be asked to do that file by file, function by function, problem/code change type by type code change. And possibly not break the rest so that there is something 'runnable' at least every week or some other people can work on another file/function. But that does not make any sense for a great dev. What you would do if you were experienced is to know the overall direction but rework the code line by line progressively, fixing side things on the way and maybe regularly fixing in other files/functions pattern that are similars. And maybe at some point decide to change again something you did until the point where you achieve your goal. In my mind, it works more like a path searching algorithm in action. The scrum concept is probably good for the devops/web script kiddy devs, where you just change hundreds of individual small items without too much interdependance. For example, change the style of button, reorder blocks on a page, change the icons, increase the font size. Also, something that makes great dev become average is this concept that every dev should be exchangeable and a commodity. Dev become workers on a factory production line where they have no value than to follow process and apply patterns. They say "what if something happen to your autonomous great dev?" but this argument is not used for the rest of the intellectual society: you don't see 2 doctors at a time, 2 lawyers for your case, 2 CEO in the company, 2 main architects. This thinking is just applied to low level replaceable workers. Normally, if you lose a great dev and you find another great dev, the new one should be able to understand the problem and the code in a short time and be operational quite fast. One example we can easily see of efficient dev are the great open source projects. Most of them were not created and led by an army of dev clones but by a few efficient ones: linux, python, php ... In these cases, most of the time we don't consider people to be interchangeable. Some people are keys to topics/code/features and that leads to great dev. But in case of problem, there is almost always someone smart capable to take over after a short time. |
* utilize persons strong points
* reduce management
* reduce burden
* improve working environment