Brilliant points.
“start finding one person to be the single Product Owner for all teams. The other “fake PO’s” should be moved inside the development teams as subject matter experts so they can provide detailed requirements”. — Yes. And a ramification of that is that a PO does not have a-lot of time to spend with each team. That’s the reality. Scrum got it wrong. And we need business analysts on each team: those are the people who have time and knowledge to write detailed gherkin test scenarios.
And BTW, BDD does not fit well into the Scrum process, because BDD is inherently a workflow. It does not fit Kanban well either, because BDD entails a-lot of parallelism. So to do BDD well, one must think outside these Agile boxes!! — and that is what being Agile really is: thinking for yourself rather than following someone else’s process template.
“placing the UX-ers visible at desks close to the teams” — yes. The UX people should spend some time with each UI-facing team each week.
“groups building and supporting components in dev-ops teams” — this is a core element of building reusable microservices. But not all components are “core”. Thus, there needs to be a decision about which components need to be maintained by one team, and which should be maintained across teams — that is, which “feature teams” collectively own which non-core components.
“teams were not willing to provide operational support on each other’s code, because there was no common coding standard and agreed DoD at group level. This dynamic is very common for component teams.” — Yes. The problem is that DOD should be at a product level — not a team level. A feature is done, or not, regardless of which team did what. Again, Scrum and old Agile are wrong in their team-centric view: the right view is product-centric. DevOps is product-centric: it encourages an end-to-end view — a “systems” view, rather than a team view. A team is a little silo.
About too-many-meetings, the Agile community fails to accept that programmers often communicate best in non-face-to-face ways in texting (Slack/etc.), in wikis (people mark up each other’s designs), and sharing code. The Agile community fails to leverage that, because of its obsessive focus on face-to-face.
We don’t want 1990s throw-doc-over-the-wall, but the opposite extreme — everything face-to-face — is just as bad.
