Posted On: Thursday, 11 December 2008 by Rajiv Popat

In one of my earlier posts I basically advised that team members liking each other is the secret sauce of successful teams. Hand picking team members and creating a culture that is open, transparent and where most team members like and truly respect each other is a dream come true for most managers consulting around the planet. In reality most of us have to move from one client to another or one organization to another as we consult and work with multiple teams and deliver projects or products.

If you lead work with a team, and if you’re not as lucky as I was thrice in my career, chances are that you probably inherited a part of or the whole of your team from their previous manager when you joined your organization.

When I first worked with an inherited team at Multiplitaxion Inc, I realized how different it is from hand-picking every single individual in your team based on your core values and your very own selection criteria. Internal frictions, ego issues and complexities within the team were way too high to get anything done.  It almost felt like having walked into a fifth grade class room with students fighting with each other.

While it is tempting to setup a strong hierarchy of rules, Jurgen Appelo in his post Real Agile Teams can Flocking, makes a valid point that Agile Development is more about setting constraints than it is about setting rules. He explains:

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. 

Jurgeon believes that modeling flocking of birds on a computer is much harder when done through a set of if-then rules than it is done by constraints and so is setting up an organization or a team. According to Jurgeon, it’s not about rules, it’s about the constraints:

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." 

It’s rare to find teams you genuinely and truly like working with; so much so that you see them as a part of your life rather than just colleagues. In order to land up with a team like that stars have to align and you genuinely have to be really lucky. If you’re not that lucky however, or if you’ve inherited a team that has a little bit of friction, don’t lose heart. Setup the basic constraints in place first; then give the team the basic freedom, flexibility and trust to form their own rules. Chances are that things might work out.

Who knows, you might even end up finding a few colleagues you genuinely start liking to work with over time. While Jurgeon, in his post, re-words the constraints for agile teams and considers them slightly different from the constraints of a flock of birds, I personally think the that original constraints for the flock of birds work for Agile teams as well. Team dynamics are stupid simple, you don’t exactly require the IQ of a genius to get it. You can literally be as half witted as a humming bird and still get it all right. The only thing you have to know well is flocking together.

Remember; Don’t Leave the group. Don’t bump into each other. Fly in the same direction.

Everything else, including all your process and rules, is just details.

Flock on people. Flock on.

Comment Section

Comments are closed.