Author’s note: I write about improving systems and invariably get a response that we should not impose practices on people. This article is to explicit state that systems thinking does not impose practices on teams.

When a person using systems-thinking suggests looking at the system to improve results, she is in no way implying that this means to impose anything on the people in the system. Systems thinking includes attending to the culture of the people involved.  Imposing roles, rules, artifacts or events on a group of people is usually not a good idea (See Resistance Is Not To Change).

Systems thinking has us focus on the system because the system is the cause of most problems created. For example, distributed teams have a more difficult time collaborating. When looking at how to improve the system this must, of course, include how it affects the people. But part of this is including the people in creating how to improve their work. The other reason we focus on the system is that we trust our people. Put a person in a good system and you’ll get the best they can give. Put a person in a bad system and you’ll get poorer quality work than the person is capable of.

I find it ironic that in the Agile community imposing practices is common place. Many organizations have trouble with Scrum because managers decide “we’re going to use Scrum” but Scrum’s immutable practices, roles, rules and artifacts are not necessarily the ones the team would choose. I have run across many teams trying to implement Scrum half-heartedly because of this. Systems thinking would have us use a framework where the practices adopted by the team can be chosen by the team.

Scrum can be a good baseline for this. In fact, Scrumban is a variant of Scrum more directly based on Lean than Scrum. Team can chose a flow or iteration model. Roles don’t need to change and there is a focus on explicit workflow which helps collaboration.