This discussion tends to get muddled whenever I bring it up with others because it's seen as an inability to be a team player, or that I'm just trying to daydream instead of "get things done", but my retort is always that you can't know what to get done until you have done the day-dreaming. We need it back.
On the flip side, I've worked with a lot of folks who are way more interested in just... writing... more... code. And I would never give those people free reign, because in about two months you'd have doubled the size of your codebase, your complexity, and the amount of people you need to manage it.
And obviously you can't tell them it's a terrible idea because they're your manager.
It's a philosophy I really align with, but seems somewhat antithetical to big-A Agile
Further, to me this sounds like the ideal work environment, but I've worked with folks who would consider this a frustrating experience with no clear direction.
Allowing people to self-direct but with some guidance is quite powerful. If the team can’t self-organize then the team composition is not correct or training is missing.
However in my experience most management is quite bad and not only fails to setup a system like this but then actively sabotages it with deflating micromanagement or asinine corporate BS
In reality, most teams are working with some people who are still learning, some people who don't really want to be there, some people who are interested in writing promotion-ware, etc.
- velocity metrics go down and timelines stretch, because effort is "wasted" on things that don't get finished.
- someone needs to do the boring hard work of laying out a whole project in advanced, fairly clearly if folks are allowed to jump around on the project.
Without those two, either the team looks bad to management or folks get stuck in a dead end even if they want to work on something (or spend their whole "20%" time just gathering requirements)
I think this only works for really particular companies anyway, eg: reasonably flat hierarchy, product owner with product market success.
If you are a startup running out of money, you'll want focus, if you have a tall hierarchy, management will have the say on what you're doing and higher than them will want performance metrics as you pointed out.
It works at Valve, for example, because it rains money on them and they are a flat company. Nearly no time pressure and no overall company goal that needs direction.
A team with a decent up to date SM or coach would be looking at their cycle time and throughput as decent measures of actual useful work delivered.
