Second, some MCEs tend to think that they can increase the accuracy of estimation by adding precision and granularity — by breaking down large projects into as many small tasks as possible, maybe even hundreds of them, and asking for individual estimates of each small task. This is a catastrophically terrible idea. Increasing precision does not increase estimate accuracy. In fact it does the exact opposite.
This is exactly why SCRUM fails. You are trying to quantity something you have no clue how to solve yet. You can only give a predictable SCRIM estimation if you already created the project.
On paper SCRUM cloud work if humans were perfect and every developer was equal. In reality SCRUM is being used as some kind in mechanism to blame the developer that yet again he failed. They always blame it on either it was a bad SCRUM master or a bad development team. They never question if SCRUM actually works.They never question if SCRUM actually destroys your development team?
But the more precise and granular you get, the more likely you are to reduce your overestimates — which is disastrous for your overall accuracy. What’s more, the estimation of a hundred-plus features quickly leads to “estimation fatigue.”
This is what kills your development team in SCRUM:
Sprint 1: You ask your team how long it will take and they will be wrong. When your team fails they feel bad.
Sprint 2: So you ask them another estimation and this will also fail. Now your team feels double the failure.
Sprint 3: New cycle again your developers team has to predict how long it will take, but they are scared now to give a number because they feel bad if they yet fail again.
Sprint 4: Your team end up fighting each other because they are overstressed that they will fail again.
Sprint 5: Managers gets nervousness because of these many failures they now force the developers team to be do even more their best to have correct estimates.
Sprint 6: Your development teal self destructs and some of them probably have found another company.
I always get this excuse of SCRUM proponents that you should not take failure personally and that they blame no one, but good developers are passionate people and care about good end results. Good developers will always take failure personally. It kills good developers.
1 comment
2 u/roznak [OP] 30 Apr 2016 14:53
This is exactly why SCRUM fails. You are trying to quantity something you have no clue how to solve yet. You can only give a predictable SCRIM estimation if you already created the project.
On paper SCRUM cloud work if humans were perfect and every developer was equal. In reality SCRUM is being used as some kind in mechanism to blame the developer that yet again he failed. They always blame it on either it was a bad SCRUM master or a bad development team. They never question if SCRUM actually works.They never question if SCRUM actually destroys your development team?
This is what kills your development team in SCRUM:
I always get this excuse of SCRUM proponents that you should not take failure personally and that they blame no one, but good developers are passionate people and care about good end results. Good developers will always take failure personally. It kills good developers.