3 ms·

If it increases your productivity up to 300%, that means that you can work for 5 months, then take a month off. You will still get ~30 months worth of work done

If it increases your productivity up to 300%, that means that you can work for 5 months, then take a month off. You will still get ~30 months worth of work done in a year. So thats a huge success.

vlisivka 17y ago
You are right in general case. In my case, I was responsible for few large subsystems (Linux and related stuff, automated testing and continuous building, packaging, deployment, automating of common tasks, configuring, support and troubleshooting, training, documentation, reviewing, enforcing best practices, developing of development standards, predicting future problems, etc.). I just cannot leave that project for long period of time, because large amounts of tickets must pass through me in some way (investigation, suggestion, implementation, reviewing/fixing, approving). I solved problem by training team, which replaces me. Then I leaved my work (IMHO, crisis is best time for that). Team works slower than me. Their solutions are not so good, because nobody has picture of whole project in his head. However, they can continue to work, while I cannot. As I can see, this scenario is typical. IMHO, problem with XP and SCRUM that they producing too much load on the few competent persons. Overall result is better than with traditional methods, but competent person burns much faster, because they contribute more than others. It is hidden magic beyond the process - XP and SCRUM just delivers task to competent person much faster than any other process. The drawback is that there no reason to grow for other developers, thus load on competent persons tend to increase over time. Pair programming and peer reviewing helps when people are roughly equal, but that is rare. If we try to model situation, then we will see few major stages in evolution of project and/or group: * fast growing of project and/or group until physical limit of few key people will be hit; * degradation of group, because key people leave project, until there no overloaded people; * stagnation. PS. I spent last few months to improve me in sport-dancing. I meet new very funny girl. I plan to work next 2 months as instructor for wind-surfing at Black Sea (Eastern Europe). I hope, it will help.

If it increases your productivity up to 300%, that means that you can work for 5 months, then take a month off. You will still get ~30 months worth of work done in a year. So thats a huge success.

vlisivka 17y ago

You are right in general case. In my case, I was responsible for few large subsystems (Linux and related stuff, automated testing and continuous building, packaging, deployment, automating of common tasks, configuring, support and troubleshooting, training, documentation, reviewing, enforcing best practices, developing of development standards, predicting future problems, etc.). I just cannot leave that project for long period of time, because large amounts of tickets must pass through me in some way (investigation, suggestion, implementation, reviewing/fixing, approving). I solved problem by training team, which replaces me. Then I leaved my work (IMHO, crisis is best time for that). Team works slower than me. Their solutions are not so good, because nobody has picture of whole project in his head. However, they can continue to work, while I cannot. As I can see, this scenario is typical. IMHO, problem with XP and SCRUM that they producing too much load on the few competent persons. Overall result is better than with traditional methods, but competent person burns much faster, because they contribute more than others. It is hidden magic beyond the process - XP and SCRUM just delivers task to competent person much faster than any other process. The drawback is that there no reason to grow for other developers, thus load on competent persons tend to increase over time. Pair programming and peer reviewing helps when people are roughly equal, but that is rare. If we try to model situation, then we will see few major stages in evolution of project and/or group: * fast growing of project and/or group until physical limit of few key people will be hit; * degradation of group, because key people leave project, until there no overloaded people; * stagnation. PS. I spent last few months to improve me in sport-dancing. I meet new very funny girl. I plan to work next 2 months as instructor for wind-surfing at Black Sea (Eastern Europe). I hope, it will help.