Wow.. SCRUM is **horrible**...
-
I think some of the other groups are using scrum "successfully", but in the other groups, I've noticed that the PM calls the shots, and the developers manager generally leaves them alone. If that is how we worked on this team, that would be cool. Unfortunately, our PM isn't an experienced SCRUM master and she isn't technical enough to actually specify what she wants. We get user stories like "as an admin, I'd like to be able to manage users" and she doesn't take into account any of the details. She is also the product owner and has barely used the product to this day. The other product owner / stakeholder was involved for a week or two, but doesn't get involved anymore. Which are all epic fails of SCRUM.
The situation you describe is unfortunate. An agile development process will not fix incomplete or missing specifications and lack of planning. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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?
SledgeHammer01 wrote:
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".Presumably this isn't sarcastic... If you are like most professional developers no one cares about your opinion and certainly not what you think is cool. And that isn't flippant because what matters to the company is sales. Which is driven by customers. So the customers opinion matters and what they think is cool matters. This is often filtered through sales and business analysts so their opinion is of secondary importance as well.
SledgeHammer01 wrote:
Apperently though, SCRUM doesn't apply to my boss..Worst methodology ever.
That is a management failure and a process implementation failure. It has nothing to do with a specific process methodology.
-
I personally think that SCRUM is fine, but it's very easy to misuse it beyond sane limits. If it's not managed and run properly, it can be horrible. Idiot managers can make it a nightmare (which happened in my previous company).
"Real men drive manual transmission" - Rajesh.
-
Not necessarily trying to be a gun slinger lol. I guess I was a bit frustrated before when we had no management and just did everything randomly. Problem is now we have gone formal, but the manager is still stuck in his random ways which is in conflict with SCRUM. I agree... he should have ZERO say on the product, but unfortunately, he thinks he does because the PM / Owner / Scrum Master who doesn't show up to scrum meetings doesn't really know whats going on.
Quote:
the PM / Owner / Scrum Master who doesn't show up to scrum meetings
Well there's your problem (or at least one of them). Unless everyone on the team is at least minimally aware of what is going on, and what the priorities are, then Scrum isn't going to work for your team. Having a boss who says "Do that SCRUM thing" and then doesn't do it himself is usually a real killer for any project. I am a Certified Scrum Master and have only had problems when the management want to do SCRUM because it sounds cool and forward thinking but don't actually want to change the way they do things. I suggest you give up now and go back waterfall project management and only working on what you feel like doing at the time... it won't be any better and your projects will still be messed up and not what the stakeholders want - but you will enjoy it more.:cool:
- Life in the fast lane is only fun if you live in a country with no speed limits. - Of all the things I have lost, it is my mind that I miss the most. - I vaguely remember having a good memory...
-
Project management ideologies were created to, and continue to exist to, give PM's and other noncoder assholes jobs. This industry is diluted and hurt by people wanting to be part of it, simply because it pays well, and there is still some growth. These people don't want to, or simply can't code, so they take any other approach to gain entry. If, nay, when I start my company, everybody will have the ability to code, if you are in a non coding position, that one of your previous jobs will have been coding or you are currently learning. Everyone should understand the love affair with coding, the frustration, the rewards. Everyone. Lawyers, sales, human resources. Everyone.
-
I think some of the other groups are using scrum "successfully", but in the other groups, I've noticed that the PM calls the shots, and the developers manager generally leaves them alone. If that is how we worked on this team, that would be cool. Unfortunately, our PM isn't an experienced SCRUM master and she isn't technical enough to actually specify what she wants. We get user stories like "as an admin, I'd like to be able to manage users" and she doesn't take into account any of the details. She is also the product owner and has barely used the product to this day. The other product owner / stakeholder was involved for a week or two, but doesn't get involved anymore. Which are all epic fails of SCRUM.
-
That's actually quite the opposite. I used to get along great with my boss because we both enjoyed the "cool / unofficial" environment where you just want to get stuff done and move forward and scratch each others back environment. I think his boss wanted us to do SCRUM on this project, but my boss doesn't really want to conform to it. He never shows up to stand ups (hell, nobody does), SCRUM rules don't apply to him, etc. He never cared about documenting ANYTHING... granted that was an issue too though lol, because half the stuff he would tell me to do, i would be like "wtf? never heard of that before" and he expected you to be a mind reader. Thats the issue though. We are trying to do SCRUM, but as I said, SCRUM rules don't apply to my boss, so he does the "hey, why don't you re-write this to work like this?" and I say "well, this is what the PM wanted" and he says "I don't care what the PM wanted, this is what I want".
SledgeHammer01 wrote:
I think his boss wanted us to do SCRUM on this project, but my boss doesn't really want to conform to it. He never shows up to stand ups (hell, nobody does), SCRUM rules don't apply to him, etc.
Standard problem in business is that software development is almost always an unknown cost - often wildly unregulated. Which is not a good situation to be in. Process methodology when actually successfully used can provide proven benefits in terms providing real cost estimates, real delivery schedules, real bug reduction, etc. Doing it successfully is hard however. And note that this has nothing to do with a specific methodology. It is true for all of them. Of course the alternative is chaos which means no control at all.
SledgeHammer01 wrote:
Thats the issue though. We are trying to do SCRUM, but as I said, SCRUM
Yes the problem is your boss. And probably your bosses boss. That however has nothing to do with SCRUM.
-
I agree: when scrum is applied religiously it can disrupt the development process and alienate the participants and don't get me started on the waste of time that are daily scrums! I've used a modified system in the past, picking out the bits that best serve the team and the process, in that order. Scrum puts the process first and people second which, to me, is the wrong way round if you expect to get buy-in from the people you are expecting to build your system.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
mark merrens wrote:
Scrum puts the process first and people second which, to me, is the wrong way round if you expect to get buy-in from the people you are expecting to build your system.
If it wasn't "work" then you wouldn't get paid to do it. Same as if you went to your local steak restaurant and instead of a steak the waiter delivered a salad to you because they 'decided' that you needed it instead of the steak.
-
Project management ideologies were created to, and continue to exist to, give PM's and other noncoder assholes jobs. This industry is diluted and hurt by people wanting to be part of it, simply because it pays well, and there is still some growth. These people don't want to, or simply can't code, so they take any other approach to gain entry. If, nay, when I start my company, everybody will have the ability to code, if you are in a non coding position, that one of your previous jobs will have been coding or you are currently learning. Everyone should understand the love affair with coding, the frustration, the rewards. Everyone. Lawyers, sales, human resources. Everyone.
wizardzz wrote:
If, nay, when I start my company, everybody will have the ability to code, if you are in a non coding position, that one of your previous jobs will have been coding or you are currently learning. Everyone should understand the love affair with coding, the frustration, the rewards. Everyone. Lawyers, sales, human resources. Everyone.
Good luck with that. The most significant role in a company that actually succeeds is that at least someone must have the ability to sell something. And to do that over and over again. Whether you create software, how you create it, how happy you are doing it and even how well the software actually works or even exists it all means nothing without sales. And with a good sales person will mean nothing as to whether everyone gets paid. But without sales NO one gets paid.
-
mark merrens wrote:
Scrum puts the process first and people second which, to me, is the wrong way round if you expect to get buy-in from the people you are expecting to build your system.
If it wasn't "work" then you wouldn't get paid to do it. Same as if you went to your local steak restaurant and instead of a steak the waiter delivered a salad to you because they 'decided' that you needed it instead of the steak.
I don't get your point - not sure how it relates to what I said.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I think some of the other groups are using scrum "successfully", but in the other groups, I've noticed that the PM calls the shots, and the developers manager generally leaves them alone. If that is how we worked on this team, that would be cool. Unfortunately, our PM isn't an experienced SCRUM master and she isn't technical enough to actually specify what she wants. We get user stories like "as an admin, I'd like to be able to manage users" and she doesn't take into account any of the details. She is also the product owner and has barely used the product to this day. The other product owner / stakeholder was involved for a week or two, but doesn't get involved anymore. Which are all epic fails of SCRUM.
SledgeHammer01 wrote:
Which are all epic fails of SCRUM.
In fact it says nothing at all about SCRUM. You have described failure scenarios for a company that would be true regardless of methodology or no methodology at all. You have several people who are not doing their job. If those people were doing an absolutely perfect job and yet the all of the developers on the team were absolute idiot slackers then the project would still fail.
-
wizardzz wrote:
If, nay, when I start my company, everybody will have the ability to code, if you are in a non coding position, that one of your previous jobs will have been coding or you are currently learning. Everyone should understand the love affair with coding, the frustration, the rewards. Everyone. Lawyers, sales, human resources. Everyone.
Good luck with that. The most significant role in a company that actually succeeds is that at least someone must have the ability to sell something. And to do that over and over again. Whether you create software, how you create it, how happy you are doing it and even how well the software actually works or even exists it all means nothing without sales. And with a good sales person will mean nothing as to whether everyone gets paid. But without sales NO one gets paid.
Where in my statements do I say there will be no sales people? Where do I even imply that? I know many people who have gone from coding to sales, and I'll never hire a salesman that never professionally coded. Believe me, there are plenty of developers that want to move to sales. I see the results of salesman who work for commissions without a clue as to what development entails. It's shitty deadlines and bad promises that "must be kept at all costs" even if the cost is greater than that one sale, the man hours of developers to build product or feature is higher than the revenue generated to company minus sales commission. I have seen this happen firsthand, and you know what the decision came down to? Saving face and keeping one more customer away from a competitor. Meanwhile, to the salesman, the commission won't be docked, so what do they care about developers' long nights? The salesman biting off more than the team should ever try to chew is the only winner, and continues to be rewarded for making a decision that's bad for the company.
-
Project management ideologies were created to, and continue to exist to, give PM's and other noncoder assholes jobs. This industry is diluted and hurt by people wanting to be part of it, simply because it pays well, and there is still some growth. These people don't want to, or simply can't code, so they take any other approach to gain entry. If, nay, when I start my company, everybody will have the ability to code, if you are in a non coding position, that one of your previous jobs will have been coding or you are currently learning. Everyone should understand the love affair with coding, the frustration, the rewards. Everyone. Lawyers, sales, human resources. Everyone.
wizardzz wrote:
If, nay, when I start my company, everybody will have the ability to code, if you are in a non coding position, that one of your previous jobs will have been coding or you are currently learning. Everyone should understand the love affair with coding, the frustration, the rewards. Everyone. Lawyers, sales, human resources. Everyone.
Not everybody has the ability to code. Not everyone can be taught to code. Thats why not everybody in the world codes. Has nothing to do with liking it or hating it. Lots of people just don't have the ability to think in a linear, step-by-step, methological way like that. To me & you, a for loop makes perfect sense, but to somebody who has no knowledge of programing, they just don't get the concepts of data structures, etc. work. You can teach anybody to program to some extent, but to do it professionally? Nope.
-
SledgeHammer01 wrote:
Which are all epic fails of SCRUM.
In fact it says nothing at all about SCRUM. You have described failure scenarios for a company that would be true regardless of methodology or no methodology at all. You have several people who are not doing their job. If those people were doing an absolutely perfect job and yet the all of the developers on the team were absolute idiot slackers then the project would still fail.
It would not. The PM, PO, etc. would see that the developers are not doing their jobs and would replace them. One of the points of scrum is that you document everything, every day. That way mgmt has total visibility of whats going on. With other methologies, they don't know whats going on until its too late. With Scrum, they'll see danger with-in a single 2 week period (sprint).
-
wizardzz wrote:
If, nay, when I start my company, everybody will have the ability to code, if you are in a non coding position, that one of your previous jobs will have been coding or you are currently learning. Everyone should understand the love affair with coding, the frustration, the rewards. Everyone. Lawyers, sales, human resources. Everyone.
Not everybody has the ability to code. Not everyone can be taught to code. Thats why not everybody in the world codes. Has nothing to do with liking it or hating it. Lots of people just don't have the ability to think in a linear, step-by-step, methological way like that. To me & you, a for loop makes perfect sense, but to somebody who has no knowledge of programing, they just don't get the concepts of data structures, etc. work. You can teach anybody to program to some extent, but to do it professionally? Nope.
SledgeHammer01 wrote:
Not everybody has the ability to code. Not everyone can be taught to code. Thats why not everybody in the world codes. Has nothing to do with liking it or hating it. Lots of people just don't have the ability to think in a linear, step-by-step, methological way like that.
Your last sentence is exactly why I don't think those people deserve to work at a software company. Programming is simply giving detailed instructions to a computer. If people can't define problems, and break them into small executable steps, what can they do? I only want to work with people that can think like this, as I view on the most basic level, it is having rudimentary reasoning abilities.
-
Rob Grainger wrote:
supposed to empower the developers
As soon as you use the term "empower" you know it's headed down the wrong trail. I feel so empowered having said that
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
It empowers developers to be wankers. :wtf:
-
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 don't agree with you. When used right SCRUM can work well. One of the most frequent reasons why we loose money is because of customers asking for changes without following the correct procedures. The changes they're asking for looks like small changes but it doesn't reflect its correct weight. There are lots of things that doesn't get considered at the time. SCRUM is suppose to prevent your boss from just randomly telling you what changes to make. Either you are a people pleaser saying yes to everything your boss tells you or your boss is super controlling. Either way someone needs to change in order for SCRUM to work on that front.
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
-
I was going to say that, but sarcastically since that's the go to excuse about any dogmatic methodology. In all their glory SCRUM and Agile suck and make no damn sense. My overwhelming experience is that SCRUM and Agile do deliver software faster initially, but with much less quality and, largely due to this, increasingly longer delivery cycles and increasingly messy code. I've also found these methodologies are used by managers as an excuse to look like they're doing something and by a subset of bullying engineers (who all too often don't follow their own claims--it has gotten to the point where I'm close to positing that there is an inverse relationship between how much someone champions Agile/Scrum/extreme/etc methodologies and the quality of their code.)
One of the biggest, and most important, things about agile programming is that it puts product advances firmly in the hands of the developers, by letting them know what is needed, and letting them decide on the most effective ways to implement it. Whenever I've seen it not working, it's because that element is broken, either: -- By management people who are taking that responsibility away from the developers/keeping the developers in the dark about things. -- By people on the development team who are not up to handling that kind of responsibility. -- By people who treat the methodology as if it were a Dungeons & Dragons game, where arcane rules created/ interpreted by one person must be followed to the letter, or you'll lose points. Being pissed off about it doesn't help. It's a problem; developers are supposed to be problem solvers. Banging heads solves nothing. Identify some specifics of the problems, and *discuss them with the team* to find a solution.
I wanna be a eunuchs developer! Pass me a bread knife!
-
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?
Actually, with the overhaul of the past few weeks, I'm glad my company uses SCRUM method. Clients can be overdemanding and that's where SCRUM becomes effective to manage workflow
-
I don't agree with you. When used right SCRUM can work well. One of the most frequent reasons why we loose money is because of customers asking for changes without following the correct procedures. The changes they're asking for looks like small changes but it doesn't reflect its correct weight. There are lots of things that doesn't get considered at the time. SCRUM is suppose to prevent your boss from just randomly telling you what changes to make. Either you are a people pleaser saying yes to everything your boss tells you or your boss is super controlling. Either way someone needs to change in order for SCRUM to work on that front.
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
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.