Wow.. SCRUM is **horrible**...
-
I've worked for a lot of different companies, but this company is the first one where they have been "official" / "gone overboard" on SCRUM. Why does anybody use this garbage methodology? It is HORRIBLE. Personally, I prefer a cool environment where everybody on the team works together, wants to make the product cool, you scratch my back, I'll scratch yours, etc. SCRUM just breeds a "me" mentality. Sorry Bob, I don't care about your issue until you open a defect and get it approved by a PM and get it inserted into a sprint. Yeah Jim, that feature sounds cool!! Write up a user story and submit it to the PM for approval and get it inserted into the current or future sprint. SCRUM is just anti-team work, anti-pride of ownership, anti-innovation. I used to want to make my product cool and get along with my fellow team members, but now with SCRUM, I have to be a dick and say "write it up and get the PM to approve it". Apperently though, SCRUM doesn't apply to my boss. He can come and randomly tell me to make changes when he is neither the PM or the PO. I'm also discouraged from doing anything above and beyond because everything requires a ton of paper work and 73 people to get involved. Use to be.. hey John, can you bust that out real quick? You mean change this bool to false? Sure, no problem!! Be done in a sec. Now its "submit all the proper paperwork and get the PM to approve it". Worst methodology ever. Thoughts?
Having my first experience with SCRUM. Not overly impressed. Common sense codified at best where it actually does something good. One. SCRUM is lauded and promoted by management as a Holy Grail because it gives the appearance to the client of increased productivity by frequent release of usable software. But what about all the re-testing, all the design, all the riga-ma-role that goes into that one tiny incremental releases? Double or triple the overhead per delivered item. Frankly, I think it is just a way to make the hamsters (us) run faster even though I don't see any real decrease in time to stable, largely complete system. Two. It is very, very brittle. If anything is missing or weak, particularly if the client does not fully embrace the Product Owner duties, then it degrades quickly into the all too familiar daily endurance contest. If the team leader does not lead and only holds a daily stand up and while avoiding communication with the lower level hamsters the consequences are the same as a non-communicative leader regardless of project methodology. Oh, wait, there is no hierarchy in a SCRUM team. My bad, forgetting human nature naturally results in a flat organization. (Sarcasm intended). I could go on. But the point is that, in my observation, SCRUM is fine but only if executed perfectly. Otherwise it is just being used by management to mollify clients and makes us work faster and harder while being less productive and definitely less creative. I would say SCRUM is unfortunately usually implemented imperfectly and therefore creates situations opposite of the intentions for both the clients and the developers while making the usual management job of stomping on both fires at once all the more nauseating and difficult. Use carefully, use some of the modified Agile methods for larger projects. SCRUM is a White Elephant and not a Holy Grail in most cases.
-
I've worked for a lot of different companies, but this company is the first one where they have been "official" / "gone overboard" on SCRUM. Why does anybody use this garbage methodology? It is HORRIBLE. Personally, I prefer a cool environment where everybody on the team works together, wants to make the product cool, you scratch my back, I'll scratch yours, etc. SCRUM just breeds a "me" mentality. Sorry Bob, I don't care about your issue until you open a defect and get it approved by a PM and get it inserted into a sprint. Yeah Jim, that feature sounds cool!! Write up a user story and submit it to the PM for approval and get it inserted into the current or future sprint. SCRUM is just anti-team work, anti-pride of ownership, anti-innovation. I used to want to make my product cool and get along with my fellow team members, but now with SCRUM, I have to be a dick and say "write it up and get the PM to approve it". Apperently though, SCRUM doesn't apply to my boss. He can come and randomly tell me to make changes when he is neither the PM or the PO. I'm also discouraged from doing anything above and beyond because everything requires a ton of paper work and 73 people to get involved. Use to be.. hey John, can you bust that out real quick? You mean change this bool to false? Sure, no problem!! Be done in a sec. Now its "submit all the proper paperwork and get the PM to approve it". Worst methodology ever. Thoughts?
I think SCRUM works very good in some arrears. But not for writing of a "cool" product incorporating all features you can think about. SCRUM works very well for strictly regulated products or products with strict hardware limitations (medical system, defence contracts, embedded software and so on). I’m sure, you don’t want to read tons of tongue-tied regulations every time you have a bright idea, to make sure you new “cool” feature will be legal; won’t be life-threatening for patients in some weird cases; or its memory and processing time consumption is within specified boundaries. You want you PM to assign some BAs to do this job and report before the next sprint. Therefore, I think SCRUM is a great methodology in certain cases, but should not be used everywhere.
-
shiprat wrote:
the GUI, software components and exception handling (among other things) were invented at Xerox PARC
That's true, but in interviews I've read with Alan Kay, he endorses the approach. In fact Agile methodologies came from the Smalltalk community, which also invented GUIs, Refactoring, Test-Driven Development. As for C++, it's a bit of abomination really. No module architecture in 2013? No standard library for networking in 2013? Unfortunately, it remains the best way to write low-level code, but that shouldn't be counted as a sign of good design. Its lack of true support for dynamic dispatch is the reason we still have to regularly restart programs/systems when updating software.
..and C++ being what it is, all it takes is for somebody to implement dynamic dispatch, inline method cacheing, object prototyping and whatever else and use the much maligned C++ operator overloading to embed their extension snugly in a familiar syntax and ultimately submit the extension to one of C++'s gobnsmackingly and uniquely powerful open source libraries, Boost probably, and there you have it, a C++ as dynamic as Smalltalk or Javascript will ever be, and compiling to assembly language, therefore capable of verification and retargeting and probably smaller and faster as well. No wonder M$ have abandoned C#/.NET and returned to C++ for Windoze 8, which might yet be the best doze since win2k, despite being even! :D
-
..and C++ being what it is, all it takes is for somebody to implement dynamic dispatch, inline method cacheing, object prototyping and whatever else and use the much maligned C++ operator overloading to embed their extension snugly in a familiar syntax and ultimately submit the extension to one of C++'s gobnsmackingly and uniquely powerful open source libraries, Boost probably, and there you have it, a C++ as dynamic as Smalltalk or Javascript will ever be, and compiling to assembly language, therefore capable of verification and retargeting and probably smaller and faster as well. No wonder M$ have abandoned C#/.NET and returned to C++ for Windoze 8, which might yet be the best doze since win2k, despite being even! :D
shiprat wrote:
a C++ as dynamic as Smalltalk or Javascript will ever be
Well, I guess you could say that as V8 is implemented in C++ that's already been done, but I don't think that counts as a dynamic language.
-
It sounds like they're doing it badly wrong. They can only do it one way because the people selling SCRUM to the enterprise don't care how it is done. It's the responsibility of those making a living out of SCRUM to do it better. Whoever (a) wrote a book on SCRUM, (b) makes money providing SCRUM solutions, or (c) behaves or actually is a SCRUM-master. The people causing the problem are those who should be fixing it.
I think every methodology ever invented has good points, but is typically misapplied by people who understand it little. The methodology is then blamed rather than individuals who attempted to apply it without sufficient understanding. Remember the early days of OO?
-
Can you please tell me, since in all your replies you haven't, why it is a bad idea for everyone in a company that produces, sells, and supports software to spend 80 hours learning to code?
wizardzz wrote:
Can you please tell me, since in all your replies you haven't, why it is a bad idea for everyone in a company that produces, sells, and supports software to spend 80 hours learning to code?
It is a cost that provides no benefit. Repeating what I said from the first the number one thing that matters to a company is sales. If the company doesn't sell something it fails. Period. The same can not be said about software. It is in fact possible to make software that doesn't work and still make money. Probably not something that works long term but it does happen. So in terms of company success it would better if everyone spent 80 hours learning how to sell.
-
wizardzz wrote:
Can you please tell me, since in all your replies you haven't, why it is a bad idea for everyone in a company that produces, sells, and supports software to spend 80 hours learning to code?
It is a cost that provides no benefit. Repeating what I said from the first the number one thing that matters to a company is sales. If the company doesn't sell something it fails. Period. The same can not be said about software. It is in fact possible to make software that doesn't work and still make money. Probably not something that works long term but it does happen. So in terms of company success it would better if everyone spent 80 hours learning how to sell.
jschell wrote:
If the company doesn't sell something it fails.
Untrue. Many companies exist based on one single contract, a single major contract that does not require more than one salesman to make one sale. Often this is the CEO/owner anyways.
jschell wrote:
It is in fact possible to make software that doesn't work and still make money.
jschell wrote:
So in terms of company success it would better if everyone spent 80 hours learning how to sell.
I really hope you are being sarcastic as these are some of the most ridiculous statements I've read on this site.
-
Lol... so when your boss comes to you and tells you to make a random change, you tell him no? I tell other people no, don't really do that to my boss since he is my boss.
Our structure of our company is in such a manner that it prevents bosses from butting in. Bosses can't simply make demands as the team has the best knowledge of the impact of the demands. The bosses come to the team with a request. The team discusses this request and gives the boss a answer based on facts. Something like that in any case.
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
-
Scrum is great for weekly release cycles in e-business Zend or Rails shops that feel the need to tweak the user experience in step with the customer's attention span. Scrum is obsessive compulsive disorder for the enterprise. Luckily, scrum wasn't in vogue when packet switching was invented at DARPA or the World Wide Web was invented by TBL at CERN or the mouse pointer, Ethernet, the laser printer, the GUI, software components and exception handling (among other things) were invented at Xerox PARC and lucky scrum wasn't around when Linus Torvalds started work on Linux or Bjarne Stroustrup on on C++ or Brian Kernighan and Dennis Ritchie on UNIX and C or John McCarthy on LISP or Guido van Rossum on Python or Warren McCulloch and Walter Pitts on neural networks or Alan bleeding Turing on general computation or John von Neumann on the things wot do it because... ...NONE OF THESE THINGS WOULD HAVE BEEN DONE BY A SCRUM.
SCRUM is basically for client relations to keep clients in check. For innovations, Release Cycles do not work, but rather take away from the functionality of the task at hand. I don't think SCRUM would be effective if the company was not doing clients and should however be pushing its product to the market. SCRUM doesn't apply in that term.
-
shiprat wrote:
a C++ as dynamic as Smalltalk or Javascript will ever be
Well, I guess you could say that as V8 is implemented in C++ that's already been done, but I don't think that counts as a dynamic language.
name me something that isn't implemented in C/C++... I mean, yes ok, but the irony is that people are like, oh language X is so much more [adjective] than C, but you have to ask where did language X come from? maybe somebody wrote it in assembler or soldered it together out of logic chips, but the chances are higher that they wrote it in C or C++!