An overview of Systems Thinking, and how to apply the ideas of Complexity Theory to management of systems, with the results being called "Complexity Thinking".
This presentation is part of the Management 3.0 course created by Jurgen Appelo.
When we talk about things we always use abstractions. Incomplete representations of the world around us.
And we always have multiple options for choosing abstractions.
Engineers and scientists are particularly good at abstractions, which is why all system theories are created by “left-brainers”.Note: it is known that “left-brain” versus “right-brain” is bad science. But it is a useful metaphor.
But too much abstraction leads to problems. Such as executives only focusing on cold numbers in spreadsheets, instead of real human beings.
Or consultants trying to design organizations, without realizing that they cannot be objective observers.
Or the alienation of architects who create fantastic models that don’t make sense to people in real situations.
Or the idea that project management can predict and control the future.
Or the idea that there is always someone to blame whenever there is a problem.
Some people think we should strive for a holistic approach to organizations. We can call them the “right-brainers”.
In fact, it is impossible to be really holistic.
It is always necessary to place boundaries.And where to place them depends on the problem.
See book: page 41-45
This is the same as the Law of Requisite Variety. But this quote is easier to explain.Only the human mind is at least as complex as the complexity of the environment that software projects find themselves in.
I explain that the 360 degree evaluation is, in principle, a good idea. Because the point is to let the system (the team) generate its own feedback about its parts (team members).However, in some companies it is implemented badly. There are even HR tools that fully automate the 360-degree process, enabling people to fill out forms via email, anonymously, about each other. This is very bad for trust and respect in the organization.I explain that the last time I organized a 360 degree evaluation I did it during dinner with the whole team. It was a great and very useful experience.See book: page 242-245
I explain that complexity researcher Dave Snowden says in his keynotes that stories/narratives work better than values or vision statements. And I show with this picture that we used a lego model of metaphors, combined with photos and video, to craft the vision for the ALE network.
The “long tail” and the “strength of weak ties” are both metaphors that suggest that the sum of all small things in a social network can together be more powerful than the few strong things in the network.Likewise, several weak models can be more powerful than one strong model.In social systems we only have weak models (no strong mathematical models).Therefore, we need multiple models to make sense of the world around us.
What worked for you in the past may not work for you in the future.What works for somebody else may not work for you.
The practices you try will influence the system, but the system will also influence the practices you try.
Exploration is often forgotten on Agile teams.They only do (lots of) adaptation and (a bit of) anticipation.
Working models must be developed through their actual use by people, otherwise they won’t make sense to them.
In Scrum the whole team is required to participate in stand-ups and planning/demo meetings. Therefore Scrum wants us to use the complexity of the minds of the whole team to deal with the complexity of the environment.Scrum is just one model. For example, it specifically requires the use of timeboxes and is incompatible with iterationless models (such as Kanban). In fact, the term “ScrumBut” clearly suggests that there is a “proper” way of doing Scrum.Scrum does recognize that it is a framework and that other practices have to be filled in to make it work, but acknowledges that these practices depend on context.Scrum specifically suggests to iterate often because the demo of the product will influence the customer, and this will influence the backlog, and therefore the product.There is only focus on adaptation and anticipation in Scrum. There is no clear suggestion to explore.Scrum requires that the team changes its process model through regular retrospectives.