To get a clearer understanding of what emergence is, consider the following particle system (based on this):
Here, each particle follows its own course, ignorant of its fellow particles. The rules are simple, a particle starts with an initial random speed and direction, travels in given direction with given speed, and bounces off the wall when it hits it. There is nothing complex or surprising about this, and if you knew the rules you could easily imagine the outcome.
However, in 1986 Craig Reynolds created a simulation of flocking behaviour in birds and fishes. By adding his 3 simple rules to the system above, we can create something much more intricate. Crucially, the particles, now called boids (from bird androids), takes each other's position into account when determining where to move. This interaction is the root of complexity.
- The first rule is Alignment; steer towards the average heading of local flockmates
- The second rule is Cohesion: steer towards the average position of local flockmates
- The third rule is Separation: steer to avoid crowding of local flockmates.
In addition, to simulate vision, each boid only sees its neigbours within a certain radius and angle, the boids within this zone is the local flockmates referenced in the rules above.
What we get, with a little bit of tuning of the weight of each rule is something like this:
The boids are now actually flocking, and the flock seems to have taken on a mind of its own. This behaviour is an example of emergent behaviour, not easily imagined from knowledge of the rules alone.
Connection to teamwork?
The idea of emergence is an interesting one. In software, we have had the idea of emergent design for some time, where by following 4 simple rules about code, hopefully a good global design emerges. In agile, the concept of self-organizing teams rests on the notion that a suitable work-process will emerge if the team is given a task and the proper responsibility. Additionally, Alistair Cockburn identified 3 principles agile teams that he observed seemed to follow: Sit together (i.e Communicate), deliver often (i.e Get Feedback) and reflect upon the process (i.e Improve Consioucsly). It is tempting to view these principles as rules for 'agileness' to emerge. Of course, these simple rules do not guarantee success alone. Especially when a system consists of complex agents such as humans, the results are hard to predict.
It could also be interesting to think along the lines of emergence for example when introducing actions in retrospectives. How about "rules" like "for each negative comment in crucible, add one positive", "we do pair-programming with rotation every 25 minutes" or "we start each meeting with 2 minutes of laughter yoga". They all focus on how individuals in a team interact. And with complex systems involving humans, there is plenty of room for experiment!