Planning is what makes sense for the project scope, and can easily be recursive through orgs and teams. Each layer works out the core components needed, then wh

Planning is what makes sense for the project scope, and can easily be recursive through orgs and teams. Each layer works out the core components needed, then which teams would be needed for those components. Those teams then work out what sub components are most effectively done by which teams, and repeat recursively. Teams may find overlap for components and assign subsets from multiple teams to work together to plan for those overlapping areas. This would seem like the obvious way to plan for anything. Why would business side have significant input into UX - that’s the whole reason you have hired UI and HI teams? An effective bug tracker has the concept of related and blocking bugs, along with priorities, etc. Anyone can see how progress is happening in trackers. Occasional meetings between ICs or PMs can identify where things are falling behind or getting blocked, and either work to reprioritise or re-resource as appropriate. I my experience that has never been significant impedance between ICs and managerial types communicating directly. This feeds into ICs being able to decide what to work on - if another IC comes to you needing help or needing some particular bug fixed earlier than expected you can always in crease the priority or provide short term work around, etc - or talk to other ICs in your team to see if someone else has capacity to get it fixed earlier. To me this all seems like the sensible way to get software done at large scale. As I’ve said elsewhere maybe it’s different at small or young companies, but the share interminable “process” of scrum, “agile”, etc seems asinine.