Thread by @tottinge

If your system isn't working, losing the experienced people and repopulating the system will result in a system that still doesn't work *AND* is full novices creating new problems.

Fundamentally broken systems tend to present as “people making mistakes and doing the wrong things” when they are usually people doing the things the system and incentives demand.

They have a problem in that people believe in the system, and so its brokenness *must* (it seems) be that people are doing a lousy job of following the system.
Which might be true, if the system is exceptionally unnatural or difficult to work.

“The Vector Theory of Systems: Systems run better (and last longer) when designed to run downhill.” - John Gall, The Systems Bible

The more resistance we create, and must overcome, to be successful the least successful we become.

Repopulating a system has a more troubling effect. The incumbent workers have non-portable skill: they know how THIS system, THIS code base, and THIS company run.
The replacements will know none of this.

New people may have better portable skills (general programming skills, general organizational or time management skills, knowledge of a programming stack or testing tool) but have no non-portable knowledge. They don’t know a thing about the system they’re now in.

In agile methods (properly done) teams self-organize, self-adjust, and self-architect because they understand the current system and the struggles or ease of developing in it. They are the only ones capable of improving that, so they are empowered.

Hence, all the focus on feedback and being accountable at the team level, and participatory design and architecture. And also on spreading design knowledge widely via pair programming and mob programming.

Hence all the talk about stable team rosters.
Hence all the investment in individuals and learnings.

And notice the principle about building teams around motivated individuals, giving them the environment and support THEY need, and trusting THEM to get the job done.

Because they know how this works, and so know how it might/should work better.

Ignore this, and there is no agility left.

Software agility is “discovering better ways of building software by doing it and by helping others do it.”

It is not “following process-specific ceremonies and pressuring people to work long solo hours.”

Engagement matters. It builds the non-portable skills that in turn inform the use of portable skills and the ability to experiment and learn rapidly.

How does depopulating and repopulating a system bring this about?
How does it improve the system?
How does it make accomplishment of crucial outcomes more accessible to the organization?
Has it ever worked?

Side note: not a straw man. I’ve seen this thing done a few times, to no good result. AFAIK, it never helps.
But the fearful new hires will be unhelpfully cooperative no matter how detrimental their orders are.