Real Agile Teams Can Flock

People often try to solve problems by introducing rules in an organization, in the form of "When situation X occurs again, you must do Y." I admit that I am sometimes guilty of such behavior myself, though I am convinced that it is not the best approach. It is better to leave rule selection to individual team members, and instead focus on imposing the proper constraints. Agile software development should be about setting constraints, not rules.

It has been discovered that the flocking of birds can easily be modeled on a computer. This behavior, which is also apparent in many other kinds of animals, emerges through the application of a few very simple constraints:

1. Don't leave the group;
2. Don't bump into each other;
3. Fly in the same direction.

Specific implementations of these constraints are often used in the movie industry to create computer animated birds, bats, fish, penguins, you name it. (An example of such a model of flocking behavior is available here.)

Though we usually don't talk about flocking when it concerns humans, the differences between a human team and a flock of birds aren't that big. For a teams of software developers, flocking might roughly translate to these constraints:

1. Don't single yourself out;
2. Don't fight with team members;
3. Agree on the team's direction.

Flocking behavior is often mentioned as an example of how a system can show complex behavior with only a few simple rules. However, I think the term rules here is not correct, or at least imprecise.

Complex Systems, Agents and Rules
Rules in complex systems are the building blocks of stimulus-response mechanisms. An agent receives some input (from other agents), processes it using a number of his own internal rules, and then responds by emitting some output (to other agents). The rules that an agent uses are not much more than a prioritized list of simple If-Then-Else constructs.

Now, I don't know much about modeling computer generated animals, but I'm sure that the three constraints listed above are insufficient in getting the job done. A lot more actual code is needed to make sure that birds, bats, fish and penguins show behavior that conforms to these constraints. The actual rules, hardwired in tiny animal brains, or written in some programming language, might be something like this:

1. Calculate the average position of the birds that I can see;
2. Calculate the average direction of the birds that I can see;
3. If my distance from the average position > constant A, then adjust my direction towards the average by X degrees;
4. If the distance between me and some other bird < constant B, then move away from it by Y degrees;
5. If my direction deviates more than C degrees from the average direction, then adjust my direction by Z degrees towards the average;
6. Etc...
7. Repeat until we've landed.

Rules like this are a better reflection of what each individual in the group actually does. The result is that each individual won't go astray, avoids collisions, and keeps up with the group. Which is exactly what evolution and natural selection required them to do, or they wouldn't survive. But the actual rule selection process, carried out by each individual, is the result of trial-and-error by genetic programming and learning-by-example.

It's Not About Rules, It's About Constraints
The mistake people often make is that they directly try to "program" team members by giving them rules to follow. "IF you receive this type of document THEN you must perform that activity," and "IF the customer wants some new requirement THEN you must start this-or-that procedure." But the power of complex systems is that agents can manage their own rule selection process. People must restrict themselves to setting constraints, and then allow team members to solve their own problems.

Agile software development is the natural approach to manage software projects. It sets constraints like "collaborate with the customer", "allow frequent changes" and "only deliver stuff that works". And then it's up to the team to select and implement rules like "IF the customer cannot travel THEN we do our demo using Skype," or "IF there's change request THEN we create a new branch in source control," and "IF someone breaks the build THEN he must wear the funny rabbit ears."

This also means that agile software development is not in the first place about pair programming, TDD, iterations, and the specific implementations of other rules and practices. (Note: the Agile Manifesto doesn't mention any of these!) Sure, those practices are interesting and important. But as soon as you're imposing them as fixed rules, you're not allowing the agents in your complex system to carry out their own rule selection process.

And then they've lost the ability to be really agile.

via http://agilesoftwaredevelopment.com/blog/jurgenappelo/real-agile-teams-can-flock