I'm also putting this video of AI aided pair programming by @realgenekim.bsky.social and Steve Yegge at the top of my watch list www.youtube.com/watch?v=Htqx...

Completely agree on the tough line to walk. I find direct learning is also hard to apply in another team's context, so the transferrable learnings are more about method/approach, which is definitely still useful. Creating incentives for that sharing across teams is another challenge.

I suspect 2 elements of measurement strategy would significantly help here:
- a deeper specification than "cycle time." Incorporating even a rough taxonomy of categories of work tasks into our measures could be really helpful
- testing for *within-group* changes relative to a specific intervention

Perhaps that's why we see more self-led team level interventions, such as team retrospectives, driving change where the team can "just see it's better", compared to better measurements of changes across groups of teams.

Thanks for this work! Even in a mid-size org (~300 devs), I find getting the necessary alignment on task creation/completion definitions, or other pre-reqs for a consistent measurement strategy, can be a big hill to climb already.

@bethcodes.bsky.social is there a good place to read about "Plan Half"? I'm not familiar with it, unless you mean just keep 50% of time unplanned.

Does that mechanism need to be something like the exec sponsored project with a new method & no rules / bring in outside help / carve out an internal startup and grow culture in order to take a big enough step?

I like the idea of attractors, and maybe retros play the role of the gradient descent step: find one small thing to make better next time.

That raises the question of what type mechanism is needed to take the big enough steps to go from one basin (desert) to another (forest).

At Pivotal (pre VMware/Broadcom at least) this was the standard for most SW teams. Doing lots of pair programming, the desktop (usually iMac) was shared among the whole team, and there was no sense of "my machine".

One side effect was devs in a meeting room rarely had laptops as a distraction.