Earlier quoted context omitted.
That argument can be used either way around so it's fairly useless. In reality we don't have good software development because people at some level or another don't want to do the things that make it possible. They're always going to pretend they care but do what suits them. It can be from the most basic thing: the customer doesn't want to pay what it really costs to get something good but can be made to pay for some…
> n reality we don't have good software development because people at some level or another don't want to do the things that make it possible. If you're confessing that it's contrary to human nature and/or the engineering thought process, then I humbly accept your concession in this debate.
Scrum is a cancer
451–460 of 486 posts
Re: Scrum is a cancer
#452Earlier quoted context omitted.
Scrum includes retrospectives - they exist to change the process. If the process cannot be changed then it's not scrum. OTOH when you're starting out it takes some time to find out what works and a scrum master will probably want to make you try to stick to the basics until you've given them a chance. Most people cannot see the point of one part or another until it has helped them personally once. After a while the t…
In my experience, the best you can hope for from retrospectives is small tweaks. The length of sprints, how standups should go, who writes what in tickets. But you can't change the process to be not-Scrum. Once a company has decided "we do Scrum", you can't argue in retrospectives that sprints are completely artificial and unnecessary for the project in this phase, or that things would go much smoother if devs talked…
I talked to customers as a dev - it's just that customers couldn't come and pester me to make me do extra work or change priorities. Is that too hard or inconvenient to understand?
Scrum fits new development more than maintenance and I've never found any other "phase" where it doesn't fit reasonably. I've been in situations where I've thought we needed longer sprints.
Ultimately if the overhead is too much we used the retrospectives to remove it.
The problem is if you're the only one in the team that wants some change - then you cannot force it.
Re: Scrum is a cancer
#453Earlier quoted context omitted.
We manage short standups most of the time - why didn't you tell the manager to shut down after 15 minutes? All these agile processes require the team to take some responsibility and have some courage.
First, there was major miscommunication on the part of the new management [1] and who I thought was my manager wasn't [2]. Second, I was raising the alarm that the "agile and scrum" methods weren't working, and got it raised to a VP of the company [3]. He was let go. Did I cause him to be fired? I don't know. All I know, the new VP just said "that's a shame" when I brought up my points. I knew then, it was time to go…
Re: Scrum is a cancer
#454Earlier quoted context omitted.
Office space is actually accurate once you replace TPS reports with Status reports/JIRA tickets/Performance reports/Incident reports etc. The amount of dancing required for the sake of management in this industry is just insane.
As a long time PM (of all sorts of P)... If you don't want to have to talk to customers, which only one developer who I've ever worked with has actually wanted to do, you need a way to equip someone else to do so. Same thing if you want to keep your investors happy, your counterparts in other departments informed of when they need to have the hardware to pair up with your software ready, etc. There's definitely such…
1. If other departments need metrics/insights/visibility, why don't they go collect it? As a PM, go collect that information yourself and deliver it to stakeholders? Why does everything need to be done by engineers?
2. When engineers get measured, evaluated and pitted against each other using these activities, it breaks camaraderie. We don't enjoy these activities because we see through the management practices of rating people based on the number of proverbial TPS reports or the quality of the cover sheet or the number of story points completed - none of which are actually important to the success of business but very important to the manager who will just recycle them upwards. Do you really think people are motivated to do this meaningless work?
Re: Scrum is a cancer
#455Earlier quoted context omitted.
My most informative experience was had at this huge auction company that I was doing frontend on. At one point, I was working on what we'd now call a component, but was at that time manually created dom elements generated with a very long series of logic branches that depended on a number of external, possibly async conditions. It was extremely hard and time consuming to test and keep all of the possible conditions l…
scrum masters should only bother you at the standup. They also shouldn't add requirements. So .... the one you were dealing with was just an average bullshitter pretending to do scrum.
Either way, it was awful, and it was looked down upon to try and find some peace and quiet to actually get things done.
Re: Scrum is a cancer
#456Re: Scrum is a cancer
#457You get the senior devs who have been a law unto themselves for years and they certainly don't like anything that distributes power across the team. It might mean they have to do work they don't like sometimes.
From the start they're out to sink the whole scheme and even one of those in a team makes it very difficult to achieve any change.
That's just ontop of the fact that middle management don't like a method that removes their ability to interfere with the details or put pressure on individuals.
And of course in the end there are those developers who expect to do nothing but write beautiful lines of code all day long and consider every other part of delivering software to be beneath them - reviewing other people's code, writing tests, working on requirements, maintaining old code.
Re: Scrum is a cancer
#458Earlier quoted context omitted.
50%?? Scrum is like a 1-2 hour planning/retrospective meeting per fortnight plus 10-15 minute standups every 1-2 days. How could that possibly take 50% of your time?
I once had twice weekly refinement sessions 1 hour each. twice weekly grooming sessions one hour each. daily standups 30 minutes, weekly planning 2 hours, weekly retro 2 hours. This was industry standard according to the consultants brought in with mckinsey to train the whole company. 10.5 hours before any other technical meetings,
Re: Scrum is a cancer
#459Earlier quoted context omitted.
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement. But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master…
So, would it be fair to summarize this as, "You weren't doing True Scrum" ?
Much less TLDRish, but zooming out to take a broader perspective:
There seems to be an intense agreement with both of the following statements:
1. The practices in the industry that the people imposing them call “Scrum” are often quite bad, and
2. The practices in the industry that the people imposing them call “Scrum” often bear very little relationship to the methodology laid out in any version of the Scrum Guide.
Apparently because consensus is a bad thing and there aren’t enough real issues to argue about, some people who agree on points #1 and #2 seem to have squared off into a weird tribal battle over whether “Scrum” is bad due to #1 specifically that mostly turns on whether or not the One True Meaning of “Scrum”” is the thing they agree is very often bad in #1 or the thing they agree that thing differ differs from in #2. My position is that this is mostly silly, especially since there are very few contexts where both of those things are meaningful to consider: the first is so inconsistent in terms of actual practices that it is useless describe as a single thing in the context of concrete development practice, though it may be interesting to discuss as an industry cultural phenomenon, whereas particular practices or combinations of practices within its ambit can be discussed more productively when the focus is on concrete development practice; the second is specific enough to be useful to discuss in the context of concrete development practices, but not much else, except maybe in terms of its historical role in relation to the cultural phenomenon. With a little care to being clear what they are talking about and the what it is people are looking for from a discussion, the whole semantic side-debate can be avoided.