Aucune remarque pour cette diapositive
I tell the students that it is important to understand what systems thinking and complexity thinking are about, in order to understand the rest of the course. Together with the previous part (Agile Development) this is the foundation of the book and the course.Note: I don’t go into details about the difference between systems thinking and complexity thinking. It is too subtle to be important. But I see complexity thinking as a bit more advanced than systems thinking. Others would say that complexity thinking is simply systems thinking “done right”.
I tell my personal story of how I was able to write my book so fast. It was because the credit crisis gave me, quite unexpectedly, a lot of extra time to work at home. This is a nice example of an unexpected pleasant surprise (for me).I think each trainer should think of his/her own personal example of a totally unexpected event (black swan), nonlinear behavior of a project, or some other complex phenomena.
I tell the following story, about the unhappy customers, just like it is on the slides...
I explain that systems thinking and complexity thinking are based on various theories developed in the last century.The first is General Systems Theory. I explain that software teams, like many other systems, satisfy the criteria of identity, homeostasis, etc.See book: page 35
See book: page 36
Note that I left out various other theories (game theory, evolutionary theory, etc.) otherwise this part would become too boring for a course. I do mention chaos theory because the butterfly effect and fractals are referred to again later in the course.See book: page 38-39
All these systems theories together (there are many more) can be seen as the body of knowledge of systems. It is a bit ugly because the parts don’t fit together well. But it works. And we call it complexity theory when applied to complex adaptive systems.See book: page 39-40
The most important thing before we start the course is to have a proper worldview or mindset.The worldview that managers are leading a hierarchy of followers makes little sense from a systems thinking perspective.
In systems thinking we can choose: either we see ourselves as part of the system (for example, a manager as part of an organization. In this case we will try to influence the other parts in the system around us through our relationships with them...
...Or we see ourselves as part of the environment (for example, a manager outside a Scrum team). In this case we will try to modify the boundary around the system so we force the self-organizing system inside it to re-organize.
Both views are valid ways of looking at the world. The most useful one depends on the problem you are trying to solve.
Self-organization has been going on for 13.7 billion years. It’s not a new idea.
But self-organization can lead to anything, and managers want it to lead to something valuable.
No matter if it’s file folder organization, bringing coffee, or celebrating birthdays, teams will always self-organize.
Now I go into a bit more detail about the causal loop diagrams...
Now that we’re talking about the known and unknown it is interesting to see there are two kinds of unknowns.The joker is my own metaphor for known unknowns.
The black swan is the methaphor of Nicholas Nassim Taleb for unknown unknowns.
I explain that the concept of emergence is another well-known word borrowed from systems theories. The culture of a team is a nice example of an emergent property.
Emergent properties and emergent behaviors are also unpredictable. For example, nobody can predict when a whole team will get sick from food poisoning.
Finally, I tell the students I think the difference between complicated and complex is important.“Complicated” says something about the structure of a system.
“Complex” says something about the predictability of a system.You can simplify something that is complicated, but not something that is complex.
See book: page 41-45
Now I start explaining the 7 fallacies...
I tell people they don’t have to remember all the fallacies. What I think is important is to have the right mindset and worldview. As managers we try to work the entire system, not individual people.
I usually give each group a complete set of 7 fallacies and 14 quotes. Sometimes I ask two tables to form one group, when I only have 3 or 4 sets with me. I ask them to self-organize somewhere in the room, and not do this at the table. It’s easier that way.I let them struggle for about 10 minutes. Usually they get about 2, 3 or 4 right. Then I tell each group there’s an extra constraint: the numbers of the quotes should add up to 15 per fallacy. This leads to another flurr of activity after which most of the groups have 4 or 5 of them right.Then I ask everyone to sit and I explain the quotes and why I think they belong to which fallacy.I also point out that there’s plenty of room for debate. People may have other opinions, and even other fallacies!
When there’s enough time I ask the groups to come up with their own examples of fallacies and let the next group guess which fallacies were meant. This often leads to fun at the tables, and I think it really helps them realize the many ways managers have wrong ideas about teams and organizations.
I keep this slide on screen when they play the game.
Some questions to consider:-Which fallacies do you recognize when a manager creates lists of individual ratings of people in a team?- Do the fallacies make sense?- Should there be more or fewer?
It is now probably lunch time, and thus it is time for the feedback door.This is the first time the feedback door is used, so I explain what it is for:Agile is about getting feedback faster. If I get feedback only at the end of the course, it is in some cases too late.I want to know duringthe course any essential feedback that I can respond to immediately.After the break I always make sure that I read out loud any feedback I have received and what I will do about it.