Hacker News Reader

Comment by JohnFen | Hacker News Reader

In my daily work life, academic discussions of "what is scrum (or whatever)" isn't of practical value. What matters is what your employer is requiring you to do. I have yet to work at a company that uses agile methodologies in a manner that doesn't effectively torture devs.

I'm not saying such companies don't exist, only that I've never personally worked for them.

I use "agile" as a filtering term these days. If the job description mentions being an agile shop, I know that job isn't for me. If they use agile principles but don't advertise it, I want to see what the process actually is before deciding to accept the position.

View on HN

I think you are missing one thing: why do you allow managers to say how to develop software when you are hired to be an expert on that matter? I know, I know, it is convenient to not to take responsibility and just complain, but that would be so frustrating for me that I couldn't take it. And, yes, in my experience I saw many times where people who are not experts say how something should be done, for example they say "refactor is not needed" or "tests are too expensive". In that case I ask them one simple question: "how many contributions to the codebase you made last month?" The answer is usually silence. If they still oppose I just quit the job and watch the project fail from my colleagues' reports. Simple as that.

> why do you allow managers to say how to develop software when you are hired to be an expert on that matter?

Because at most companies, you have a simple choice: follow the prescribed procedures, or work somewhere else. I have absolutely quit jobs that were too egregious, but that doesn't change the situation at that company.

Maybe losing valuable people is not affecting company straight away, but it surely affect the project. And with few project failing miserably (as they will if you do corporate waterfall) something might change. If not, then the whole company might fail. Remember, companies compete with each other, it just takes more time for some to fail.

It is important if you want to fix it. If you think scrum is the problem, then changing scrum to something else might appear to make sense. However if the problem is not in your framework but with tangential organizational goals then it won't matter which framework you use. I'd say that's pretty relevant to discuss.

Reply on news.ycombinator.com