This blog has moved. Go to for the latest posts.

Tuesday, January 14, 2014

The simple recipe for disciplined organizations

One question puzzles non-Agilists more than any other question. It is the question that uncovers why Agile does not fit their view of the world. A question that makes non-Agilists feel insecure and reject Agile completely or mostly. This question is: how can less structure, and less planning deliver software more reliably, and with higher quality, and faster, and with better usability, and with better customer satisfaction?

Do you know the answer to this question? Many Agilists don't. Here's one attempt at answering that question.

Agile is different

Those of us that have been practicing Agile for a while have learned to "break the rules" - or reach the Ha or Ri levels in the Shu-Ha-Ri model. We've practiced, and practiced, and practiced. We've learned what works (some times) and what does not work (most of the time), and we have been able to hone our practice to a point where Agile just feels "natural". But what is "normal"? How would you, a Ha or Ri level practitioner of Agile define Agile?

This reminds me of a story I heard from Angel Medinilla, a dear friend and fellow Agile journeyman:

In a dojo somewhere in a southern country, the Aikido apprentice reaches out to the sensei to understand the secret of Aikido.

Aikido apprentice: Sensei, what is the secret of Aikido?
Sensei: The secret is to breath, to balance, to connect with your opponent and whole body movement.

The apprentice was frustrated, he was expecting something enlightened and concrete for him to use.
Then, after 40 years of practice the apprentice finally says to his sensei:

Apprentice: Sensei, finally I understand the secret of Aikido
Sensei: Good. So, what is it?
Apprentice: It was simple and in front of my eyes all along. The secret is to breath, to balance, to connect with your opponent and whole body movement.

The sensei in that story knew that the apprentice would eventually come to realize that Aikido was indeed "just" to breath, to balance, connecting with the opponent and whole body movement. So, how about Agile, what is Agile all about? And how does it deliver more discipline, with less rules?

Chaos is very disciplined

While I tried to make sense of Agile, I explored many possible models. One of them was Chaos Theory. As I explored the Theory of Chaos I found a very interesting video about one of the favorite topics in the Agile community: emergence. Emergence is the process by which a system (any system) organizes itself based on real rules and exhibits what we would call complex behavior. For example, in this post I explained how a colony of Ants can exhibit complex behavior by following just a few rules. That complex, adaptive behavior emerges from the rules, and the action of the individuals. The rules are real (there is a benefit in following them), and the resulting behavior is complex and adaptable but also, very very disciplined (because there is a benefit to that discipline, you follow it or you die of hunger).

Going back in time

The counter-intuitive aspect of emergence is that it goes against all accepted "truths" about organizational design. You see, emergence can not be explained by reducing our model of the system to simply modeling of the agents' independent behaviors. Emergence is a result of all the parts interacting in the system. If you remove one of the rules from the ant colony you would get something different (possibly even the break down of the whole colony).

Simple rules lead to complex behavior. Complex rules lead to stupid behavior.
--adapted from original quote by Dee Hock

Reductionism is the most common process for organization design used by humans today. We tend to start by modeling small independent parts, and when we are satisfied with each, we put them together. But there's a problem with that approach. When you try to design an organization, or a process, by first identifying all the necessary steps individually, and then you sequence them orderly you make the system stupid. Or, in other words, you create rules that remove the possibility for complex, adaptive behavior to emerge.

This process or analyzing, ordering, prescribing organizational and process design is labeled analytic, and it is based on the theory that if you break something apart (like the organization), and analyze those parts independently you will understand it sufficiently enough to know how the whole system works. The problem is that an organization, like any system, has dynamics that can only be seen when all the parts are assembled and never when they are analyzed separately.

By contrast, if we define clear and simple rules (think the rules of chess) and nothing else, we are allowing the system to - through emergence - exhibit complex, adaptive behavior. The big question comes next: where do you draw the line between simple rules that allow for complex behavior to emerge, and the analytic process? When do we cross from one to the other?

Drawing a line in the sand

This is not an easy question to answer, and it is highly context dependent. However, I have found that the moment you think of rules that apply to single agents in a system you are approaching that line (and possibly crossing it). For example: when you have specific rules for every type of agent in the system you are designing through a process of Analytic Reduction. Like when you have specific rules for Project Managers to follow; you have specific rules for Developers follow; you have specific rules for Testers to follow; etc. ad infinitum.

A heuristic that I have found useful is to remove rules whenever possible. Scrum, for example, does this by assigning no special role to any team member, but instead giving the team a set of simple rules and boundaries (timeboxed iterations, interaction with PO, Definition of Done, etc.)

This realization led me to understand the critical role that generalists play in facilitating complex adaptive behavior (but that will have to wait for a later post).


Complex adaptive behavior emerges in systems where the rules are simple, and the agents have a high degree of freedom to make decisions. By trying to analyze systems with an reductionist process we are removing the possibility for agents (us, the people) to make intelligent decisions based on their context, and therefore we are reducing the possibility for complex adaptive behavior to emerge. The analytical mindset kills emergence. But more importantly, when it comes to performance Emergence kicks Reductionism in the groin.

If you tell people where to go, but not how to get there, you'll be amazed at the results. - George S. Patton

Next time you are designing a process or an organization take this into account and remove as many rules as you can. That will help you achieve more! Define the goals and let the people surprise you with their results!

Photo credit: John Hammink, follow him on twitter

Labels: , , , , , , , , ,

at 08:00
RSS link

Bookmark and Share


  • Does it mean, that one could be able to grow effective agile teams only after 40 years of practicing? :)

    And what about rules apprentice should follow before he masters agile?

    By Blogger Алексей, at January 14, 2014 10:41 AM  

  • @Alexey
    :) No, you don't need 40 years of practice to start practicing the heuristic I suggest in the post: "remove as many rules as possible and allow people to make decisions on their own".
    In fact this is very much the same that Scrum already says when it focuses on the roles of Team member vs. non-team member, instead of more detailed roles :)

    The apprentices should just start with something that has already this heuristic codified. They should do a Kata of Scrum :) Or the Kata of Kanban :) Then they will start to collect experience and insights they can apply later.

    BTW: what did you think of the heuristic? Have you used it in your own work?

    By Blogger Unknown, at January 14, 2014 11:11 AM  

  • Nice Article!

    I will add that Simple rules not only leads to complex behavior but also creates an auspicious environment for creativity. Also, fewer limits/rules gives to the team the possibility of thinking outside the box and finally, design creative solutions to complex problems.

    By Blogger Unknown, at January 14, 2014 2:58 PM  

  • Well, what really bothers me about removing rules is that thin line that divides creating creating an emergent order from creating a mess.

    I think that if one removes too many rules before team is ready for increased freedom and resposibility, he could really harm performace. It is much like taking care of a child - I constantly have to reasses his readiness for something more challenging, and I don't have strict rules to decide wether he is ready or not. It's all about my intuition.

    About heuristic.
    I find it to be valid. In fact I've recently joined a team that was stuggling to get working. They were trying to use Kanban but were lacking needed discipline to make it work. I've suggested to switch to Scrum and it helped a lot. But as I see team gets more mature I'am begignning to realize that Scrum is becoming more of constraint rather than support. So I think soon it will be optimal to switch back to Kanban-style process.

    The most interesting thig about this case is that these people aren't inexperineced juniors. They have solid background in softwre development. But while each particular person is mature, team is still a child :)

    By Blogger Алексей, at January 15, 2014 9:26 AM  

  • So complex systems emerge from simple rules, yet I can't quite see how you go towards "give simple rules and team will make good products".

    Ant colony that operates on simple yet wrong rules can die faster that it can learn anything I imagine. What if they skip "get home at night" rule? That could help another colony learn though.

    By Anonymous Artem, at March 28, 2014 12:56 AM  

  • @Artem You are reducing the blog post to only one part of it.
    It is not only about having simple rules. It is also about reducing the rules instead of increasing the rules.

    I'm assuming you have a working system already. And asking you to consider reducing the number of rules in that system to let it (the system) act in an emergent way that can (but does not guarantee) deliver unexpected and better results.

    By Blogger Unknown, at March 28, 2014 11:08 AM  

Post a Comment

<< Home

(c) All rights reserved