[cmdkeen]

As someone in similar circumstances a couple of things jump out which trouble me:

Project Managers - That this role is mentioned, but not that of Scrum Master, is odd but unsurprising. PMs aren't mentioned in Scrum at all and often the way they want to do things clashes with the Scrum way of doing things. In the given example of the PM moaning about estimation Scrum at least forces that realisation quickly, something which Kanban lacks. There may well have been a Scrum Master, one of the things I've experienced them doing is guiding my team down from 1 month sprints through 2 week ones down to a single week. "It's really hard to plan for 2 weeks work" is a classic moment for the Scrum Master to say "what about..."

"We tossed out the retrospectives" - Despite acknowledging them as a good thing? For me retrospectives are the most powerful part of Scrum. Stopping retrospectives might save you a few hours and some awkward conversations but is likely to hamper your continued development. Scrum is really good about moving a team to the "conscious incompetent" phase - i.e. you are forced to be aware you are bad at something and really need to work on it. Retrospectives are the way to improve and grow.

"We kept our deadlines" - That you had deadlines (again the sign of a PM somewhere), and view them as important enough to mention again is interesting. It hints at quality not being the most import factor, which is one of the keys to doing Scrum well.

For me moving to Kanban was a fix for a Scrum team that wasn't working well. I've worked on a good Scrum team, that took a while to get going, but got there by being able to be open and honest about poor morale and then dealing with it. The new team didn't get there, we moved to Kanban and while everyone is happier our productivity is much, much lower. I do feel there is a place for switching to Kanban - when the scope of the project has moved into "we know how to do this" space, often close to a major release (if you do infrequent releases) where 3rd party involvement plays havoc with planning. If you're dealing with points high on the "the business don't know what they want" or "we don't know how to do this" chart then, for me, Scrum is still king. If you're high on both axes then you might want to switch projects / companies...

[eitally]

One of the biggest problems with Scrum (as mentioned in other comments) is that in a lot of large companies you have strong top-down enforcement of budgets, deadlines & expectations, which usually means the PMO is in control. This means you end up with a project manager as an awkward intermediary between the stakeholders & the product team. In almost every case, the product owner should be the project manager, but this very rarely happens in enterprise, and Scrum fails.

[cmdkeen]

I agree with that assessment except for "the product owner should be the project manager". I do internal dev so product owners are from the business and know the problem domain and (with our help) know what they want. It's going to be different for software for selling - but still, the project owner should be the person with the vision who is the "single wringable neck", they should be responsible for negotiating on budget, deadlines etc. The job of being a PM is always going to be in tension with that of the PO, I can see them forming a good team but fundamentally the PM is the representative of management imposed from above.

[eitally]

I should have been clearer. I meant the tech-side PO. There has to be a PO in the IT org If there isn't, the product will languish under the weight of mounting technical debt and eventually die. The same often happens if there's no biz-side PO, but in those cases someone from the tech org usually adopts the product and just does their best, for better or for worse.