SCRUM kills development. After a while you get so scared to change a thing risking to miss a deadline.
SCRUM kills your development team, after a few sprints anyone will fight anyone because yet again the deadline was not met.
SCRUM kills your project, quick hacks are implemented and there is no time to fix it.
SCRUM makes the developers depressed. Every demo you realize that you failed again
SCRUM is a beating stick for the business. You told them that you would fix it and you failed yet again.
I do develop in an very agile mode, but unlike SCRUM I develop out of sequence depending on what I need, if I am focused or sleepy, and if there is bug to hunt down or when everything works.I also use soft target dates, it does not matter if I reached it or reached it a week later. Once in a while you need a time to wrap it up as long as that date is not set in stone.
In the developers world, there is an artistic component. SCRUM kills that artistic component and you end up with bad results.
Something ales that is also in line with SCRUM and Agile, that is Unit testing. The idea sound great until you start developing unit tests. It quickly becomes messy. So You become scared to develop new code scared to make some tests fail, so you end up with hacked code.
But worst of all, you trust the unit-test warnings. Green lights does not mean that your code is perfect. It might have huge design flaws but no one questions the code and fixes things because it would turn lights red.
If you want SCRUM to succeed then you must follow these steps;
Do not create stories! Create fuzzy goals. The code will be written on the fly during depending in what is needed with the information you have now.
No hard end dates, fuzzy dates that could be spread over a week. It is done when everyone feels that it is done. Not because time is up.
Have at least one guy that is not confined to the SCRUM team. He must be able to roam free and look at the code and fixes bugs. This is a very vital person!
No graph, no one wants to know how they are doing. That graph will only show failure and make anyone feel like losers yet again.
Developers are not equal. Not everyone can do the development of that one guy. There is no such thin as all developers being equal.
Hold on your high horses! I have been hearing lots of developers and and analysts now getting interested in SCRUM master courses. It is spreading like wild fire.
Funny. I've been coding (with a very small team) for over ten years without any formal structure in place. If there's a feature that needs to be implemented we start working on it. No deadline, just an estimate that comes from experience.
Definately agile, but the monitoring is on a very broad level. We focus on solving the problem and not the process.
Scrum and Agile are not about software development, it's about cultivating the mistrust between developer and stakeholder. Companies profit off that mistrust by selling training materials to organizations and certifications to people wholly unsuited for application development (Scrummaster? Please. Get a real job.)
It promotes a commoditization of developers by pretending they're interchangeable and all equally qualified of doing all tasks, denies that good development work has basis in creativity and artistry, and has directly led to lowest-bidder offshoring and H1Bs. Burndown charts and other metrics are used as an invitation to micromanage by showing how sausage is made.
It comforts stakeholders into thinking it's ok not to know what you want, instead of demanding rigorous thinking about business process and how that translates to technical process. It shunts responsibility of bad design resulting from bad requirements onto the people that were the least responsible for those requirements. Just like matter cannot be created or destroyed, making changes doesn't suddenly stop taking time because the decisions weren't firm to begin with. Addressing failures in an agile fashion only sends the signal to stakeholders that mistakes are a-ok and therefore encourages them.
Agile was hailed as a savior to development compared to Waterfall, but Waterfall as presented by Agile aficionados is a strawman. Developers were never hidden away from stakeholders during the development process, certain aspects of a particular design are engineered to be flexible if deemed likely to change (compare with "you aren't going to need it" from today). Older development simply demands that requirements exist and people that know what they're doing assemble them. It certainly never was a one-way street, and mistakes got caught and addressed all the time without having to wait until the end of initial development.
The only defense Agile has against criticism is "then you're not doing Agile correctly." It's a methodology, therefore, that only works when 100% of the participants are 100% perfect 100% of the time: except for the stakeholders, who have no obligation to do anything correctly. Know what? I can't fly either, but no one would accuse me of not flapping my arms correctly.
Scrum is alright for rapid development/prototyping when the requirements are unclear. It may not be optimal for developers but it at least creates a predictable environment for planning and prioritizing items/features, which is a big achievement in it of itself when end-user requirements are up in the air.
12 comments
5 u/Datawych 31 Aug 2016 18:24
I love that people are finally standing up and admitting that Agile sucks just as much as most other processes.
0 u/alexkobold 01 Sep 2016 13:20
5 u/roznak 31 Aug 2016 21:33
Also
I do develop in an very agile mode, but unlike SCRUM I develop out of sequence depending on what I need, if I am focused or sleepy, and if there is bug to hunt down or when everything works.I also use soft target dates, it does not matter if I reached it or reached it a week later. Once in a while you need a time to wrap it up as long as that date is not set in stone.
In the developers world, there is an artistic component. SCRUM kills that artistic component and you end up with bad results.
2 u/caelaorn 31 Aug 2016 18:16
Scrum is the worst project management strategy in the world - except for all the other ones.
1 u/Manana [OP] 31 Aug 2016 19:44
agree with you more than the article
2 u/roznak 31 Aug 2016 21:37
Something ales that is also in line with SCRUM and Agile, that is Unit testing. The idea sound great until you start developing unit tests. It quickly becomes messy. So You become scared to develop new code scared to make some tests fail, so you end up with hacked code.
But worst of all, you trust the unit-test warnings. Green lights does not mean that your code is perfect. It might have huge design flaws but no one questions the code and fixes things because it would turn lights red.
2 u/roznak 31 Aug 2016 21:45
If you want SCRUM to succeed then you must follow these steps;
1 u/roznak 31 Aug 2016 21:22
Hold on your high horses! I have been hearing lots of developers and and analysts now getting interested in SCRUM master courses. It is spreading like wild fire.
1 u/Morbo 01 Sep 2016 04:33
ITT: @roznak has lots to say about Agile and SCRUM.
I'm with you man. Of all the bad methodologies I've worked with through the years, this shit is the worst.
0 u/FreeTheWorldFromFat 03 Sep 2016 07:44
Funny. I've been coding (with a very small team) for over ten years without any formal structure in place. If there's a feature that needs to be implemented we start working on it. No deadline, just an estimate that comes from experience.
Definately agile, but the monitoring is on a very broad level. We focus on solving the problem and not the process.
0 u/Northvvait 06 Sep 2016 13:53
Scrum and Agile are not about software development, it's about cultivating the mistrust between developer and stakeholder. Companies profit off that mistrust by selling training materials to organizations and certifications to people wholly unsuited for application development (Scrummaster? Please. Get a real job.)
It promotes a commoditization of developers by pretending they're interchangeable and all equally qualified of doing all tasks, denies that good development work has basis in creativity and artistry, and has directly led to lowest-bidder offshoring and H1Bs. Burndown charts and other metrics are used as an invitation to micromanage by showing how sausage is made.
It comforts stakeholders into thinking it's ok not to know what you want, instead of demanding rigorous thinking about business process and how that translates to technical process. It shunts responsibility of bad design resulting from bad requirements onto the people that were the least responsible for those requirements. Just like matter cannot be created or destroyed, making changes doesn't suddenly stop taking time because the decisions weren't firm to begin with. Addressing failures in an agile fashion only sends the signal to stakeholders that mistakes are a-ok and therefore encourages them.
Agile was hailed as a savior to development compared to Waterfall, but Waterfall as presented by Agile aficionados is a strawman. Developers were never hidden away from stakeholders during the development process, certain aspects of a particular design are engineered to be flexible if deemed likely to change (compare with "you aren't going to need it" from today). Older development simply demands that requirements exist and people that know what they're doing assemble them. It certainly never was a one-way street, and mistakes got caught and addressed all the time without having to wait until the end of initial development.
The only defense Agile has against criticism is "then you're not doing Agile correctly." It's a methodology, therefore, that only works when 100% of the participants are 100% perfect 100% of the time: except for the stakeholders, who have no obligation to do anything correctly. Know what? I can't fly either, but no one would accuse me of not flapping my arms correctly.
0 u/hereonachair 13 Sep 2016 13:14
Scrum is alright for rapid development/prototyping when the requirements are unclear. It may not be optimal for developers but it at least creates a predictable environment for planning and prioritizing items/features, which is a big achievement in it of itself when end-user requirements are up in the air.