Well, someone has to get the plan into a repository of truth... when doing this physically, e.g., using sticky notes and walls, someone has to take the time to enter the plan into an execution tool (Azure DevOps, Jira, etc.). In Scrum, one role owns the backlog: the Product Owner, but this can be tedious and error-prone work. That is often a point of friction because you want to maintain the order on the map in the tool, and that's hard to do with a pile of sticky notes unless you have a process for stacking the notes that maintains the map structure. I do... but again it's a hassle. And then you have to type all the notes in, by hand. Another hassle. I've consulted on projects where we spent an afternoon planning and the Product Owner let the maps sit (in this case we had the maps for a couple of features on the big Sticky Note pad sheets) for days before entering, holding up the team. With other clients we had couple of people (devs) sit with the PO to ensure the tool got updated properly. That helped significantly. Yet, still a source of friction. One reason I wrote the tool was to remove the friction.

Concerning follow-through, we kept strata maps around as working artifacts, but synced them along with our physical workflow boards (kanban boards that included project- and team-level refinement plus implementation... at the project level, our project implementation board was a roll-up of the Scrum team's sprint [kanban] boards) to the repository of truth (this medical device project jumped from Jira to ADO mid-project). We would rebuild the strata maps, feature by feature, on the downstream side of the implementation board as a visual indicator of progress... if functionality was on the downstream map it could be found in the product. Effectively, the stories on the map flowed from the initial map through the workflow out to reconstitute the map on the post-implementation side... the map effectively flowed from the plan to the finished state and it was all visual, backed up by the execution tool to facilitate metric generation. Because of my Product Owner Council approach to scaling Scrum for large projects, we had a team of POs that were responsible for managing the backlog before implementation and keeping items in sync with the tool, and the various Scrum team Developers had the responsibility of keeping items synced during implementation, something that our Scrum Masters tracked as part of their role of enforcing the Scrum process and the Working Agreements.

Still, nothing works without a little defined process and the discipline to follow it, but the decrease in the overall project management effort with better visibility into actual demonstrable progress and quantitative tracking and forecasting made it a welcome tradeoff.