Work environment is very crowded. They believe in open style seating, so there is no privacy for developers. Who would think that a cube could be missed?
They also don't invest in resources for engineering. You're asked to write software that is highly dependent on hardware devices, and yet you have to share a hardware platform with several other developers. Other developers will snag it whenever they can, some will put a sign saying "in -use" then they go out to lunch and leave it busy all day. The managers couldn't care less about that, because as long as developers find a way to meet their SPRINT goals every 2 weeks, that's all that matters. Lack of available hardware to test and debug on means less testing is actually done by developers before it goes to the test group. This is something the engineers have complained about for 2 years and nothing was ever done.
They have pretty terrible health insurance premiums. Worse than any company I have ever worked for, including a tiny 10 million dollar company I used to work for.
SCRUM is practiced here, in a very strict manner. SCRUM is an agile methodology that has become a fad in the past couple of years. It promises great things, and really the only person who benefits is the unskilled developer and the lazy manager. The amount of actual work done is very small because you will spend so much time in meetings. There's the daily status meetings, the biweekly backlog grooming meetings, the biweekly retrospective meetings, and biweekly sprint planning meeting, and then the biweekly demo. By the way, since you've already spend half a day demonstrating your software to a product owner, whats the point of sending it to the test group anymore? Didn't you just show it works?
With the SCUM practiced there, you lose site of the real deadline, and put a lot of pressure on everyone to make the sprint deadlines. Every two weeks, there's a lot of pressure and stress to make sure you meet your sprint goals. It doesn't really matter if the task you're doing wont' actually be useful for another month or two, if its a task you promised for the sprint you better finish it or else work the weekends to get it done.
Its fine working overtime to meet a deadline that you know an external or internal customer is depending on. That's what you do at a company to support the team. But when you work over time to finish a task that no one really needs on the artificially created deadline, its very demoralizing and makes you feel like an idiot. Keep in mind, the management that expects you to work overtime to finish those tasks doesn't actually stay late themselves.
I know many others don't like SCRUM, but they don't say anything. Most developers are too shy or too scared to rock the boat. They will wait until management changes, or management decides it was a mistake..and then watch them speak out one by one once its safe and talk about how much they hated all those meetings.
The other issue with SCRUM is that it promotes a kind of generalization of the work force....it doesn't allow anyone to become specialized in anything. You're rarely allowed to work in the same area of code for more than a few weeks. Some managers believe this leads to everyone knowing how to do everything. Perhaps in some idealized reality that would be true, but if people keep leaving, that will never happen. It would take years for something like that to happen.
Some developers are stronger in writing GUI software, and some are stronger in writing database queries...you don't force them to write both. The end result is a mediocre product, with no one fully understanding anything.
I understand the problem they're trying to solve. Preventing disaster when a key employee leaves. But this isn't the solution. One of the joys of software development is being able to take ownership of a piece of code and finding ways to improve upon it and make it better. But when you realize the code you're working on won't be seen again for a few months, and that other developers are free to change it at will while you're gone makes it less likely that you'll spend the time to make that code better.