Doubling down on my comments about ShapeUp (et al) as I reflect.
Engineering management, in my experience, has an allergy to agility. They can and do take any methodology, turn it into a process with a rigor (they love that) and strip agility from the mix. They are addicted to well defined requirements, some degree of estimation and being able to predict/project things like delivery, velocity, contributor performance, etc.
We engineers love the principles of agility, so engineering management tries over and over to find that happy medium where they have a well defined process that gives them what they want but imposes the least friction against the agility your engineers crave.
Custom solutions win the day. I have lived through all of the above. I remember when Agile was introduced, do you? Do you recall how violently reactive engineering managers were to this concept? It goes against everything they are supposed to do - manage. Agility inherently means they lose some degree of management ability. It means they lose their precious waterfall where things are meticulously (ridiculously, inaccurately, elegantly, uselessly) pre-planned on paper.
IMHO this is why we see every methodology that supports being Agile - bastardized to the point of confusion, academic arguments based on (not having actually learned, practiced, or gotten good at anything) gut feelings of “how we should do it here”.
Leading, managing work, organizing resources and getting shit done is a skillset that encompassing multiple disciplines. All are documented and practicable - we apparently don’t have the discipline to actually read and practice. We’re like a bunch of yokels on YouTube commenting on who’s a better MMA fighter, telling Joe Rogan he’s wrong - but only a select handful of us actually speak from authority. Only a small handful will actually take on the RISK of trying to understand the literature and practice a methodology like a beginner - without questioning the teacher or the teachings.
All that said. I have seen both Kanban and Scrum be wildly successful. The key ingredient in each of these was a shared humility and curiosity between engineers and managers and an environment that celebrated learnings and put no penalty on getting it wrong. The lack of hubris was absolutely the ticket to an agile environment where shit just got done, engineers had a GOOD TIME, we built meaningful product and we weren’t worried about blasting time in meetings because it never impeded our ability to get shit done. Once the engineering org can demonstrate its key metric (getting shit done) the battles with product cease!!! Product can trust that engineering will get shit done - without handwringing on “when” - and they can properly focus on “what” shit to get done.
When engineering is flailing around on their methodology, process or agility - they lose trust. That’s when product starts thrashing. That’s when you start to see initiatives/projects start and never finish, along with shifting priorities.
ShapeUp does an excellent job of giving product a tool to direct what work we’re doing - hopefully making sure we’re working on the right thing. However, if you’re trying to bastardize ShapeUp to fit your engineering org structure - it’s VERY difficult to demonstrate and project “well get this done”. Further, if you think you’re gonna keep your teams intact and do pitches per team - you’re already broken, committing to more than the org can deliver, creating conflict between teams on how to do the work, leading you right back to waterfall. Rather than building the right team of resources for the pitch/cycle - you now force all your teams to produce design docs, plans, backlogs - which have to go through review, get picked apart by other engineers, only to find your assumptions were wrong and the deliverable looks quite different than the design (shocker!!)
I’ll conclude to say we’re likely all doing some degree of waterfall++, branded as some form of “agile” methodology.
If you wish to see that change, encourage your peers and your managers to start with your team, pick a methodology, go exactly by the book, get “good” at it with practice over an extended period, collectively enjoy and DOCUMENT the many “aha!” moments along the way, the proliferate that out to the rest of the org. High performing teams are hard to ignore and at some point the org will ask why - simply be prepared with HOW you adopted and your learnings.
Good luck out there