Old school team management was always a disaster. No project manager in my 36 years of software development could ever accurately "estimate" the level of effort

Old school team management was always a disaster. No project manager in my 36 years of software development could ever accurately "estimate" the level of effort for developers. Asking us to estimate was never helpful either. I've worked on scrum and other types of agile project management over the last ten years. In that time, I've seen many bad implementations and only one good one. At Redbox, they had it down to a science and it worked perfectly. They had meetings for developing stories run by business analysts. They had sprint planning meetings run by scrum masters that only involved fully vetted and story-pointed stories. They used Fibonacci numbers for voting and everyone had a vote, including the QA people. They had QA people! We only started a sprint if everyone agreed on the stories. We (the developers) selected stories. We were never assigned anything. Stand ups were very quick. What are you working on, what did you complete, do you have any blockers. The entire point of agile/scrum is transparency and to focus on delivering incremental value. Over time, that value can be packaged and reported upward to show management what features are being added or improved. No one can hide. If you're not pulling your weight or invested in your work, everyone will know within a day or two. If you legitimately have issues with your assignment, you need to communicate that and the team will help you. The issue that comes up over and over with agile/scrum is how management and budgeting interact with the backlog and prioritization. There is often zero trust from the people writing the checks on "incremental continuous delivery". They want feature X boxed and completed by an arbitrary date. In my experience this _always_ fails. What you end up seeing is "something" being delivered by that date, but with an "acceptable" number of "defects". Which is to say the entire feature isn't really complete and everyone has agreed to lie about that fact. So continuous delivery via an agile process is the only way to do the work and make sure things stay on the rails. The harder problem is getting people in management circles to understand this process and embrace it and set aside their old school project success reporting techniques. Like I said. In ten years I've only seen this done well once. And then a few places did it "okay". Most places do what everyone laughingly calls "fake agile", which is a mix of waterfall and agile. Don't get me started on things like SAFe or Pivotal. Those are ways of putting process behind agile and that breaks one of the primary tenets of agile. People over Process. It's also clearly an attempt to monetize agile through testing and certification or by putting an app in front of it.