Fractals, the solution to all of your scaling problems. Including Scaling Agile

It is no secret that I love planning. I'm not coming out of the closet now, that's been true forever! And at some point in my life I was even "cool" with that.

Additionally, I want you to know (although you will not yet understand why) that I still love planning. That's me :) Now pay attention, I'm about to shoot myself in the foot.

Loading the gun

When I was in college there was a topic that I loved, the topic was Information Theory. There's so much stuff in that area of research that I can't even begin to touch the tip of the proverbial iceberg, so I'll just say - for now - that information theory is an area of research that investigates information and how it is codified. For example: how do I compress a text file? Turns out, text can be very efficiently compressed. Perhaps the blog post you are reading can be codified in a few hundred bytes. The cool thing is why that happens: redundancy. Redundancy is an unappreciated quality of all systems.

So unappreciated in fact, that we all praise it's mirror twin: efficiency. A compressed text file is very efficient (i.e. it codifies a lot of information in a very small amount of disk space - I could probably compress this post into 140 bytes and tweet it out - that would be efficient).

If we can create so efficient representation of information why would we stick the old-skool inefficient representation (for example: language)? I'm glad you ask! The reason is that language with all its redundancy is easy to understand even if you cut parts out or mangle the letters. Try reading the following paragraph (click for a larger version):

Did you understand what that said? Of course you did! Redundancy saves the day! Yay!

Now about software and organizations

In organizations and companies, we also have redundancy - plenty of it! And just as well, because without it most companies and organizations would stop working altogether. Redundancy gives us resilience! Just like in the language example above: even with parts of the words cut out of the phrase you were able to understand it! And this is just how organizations work: through, and thanks to, redundancy. This is the reason why some "downsizing" efforts end up killing whole companies, and the often touted "efficiencies" or "synergies" leaders try to gain from mergers and acquisitions end up destroying economic value more often than they create.

The trick with redundancy is to repeat

By now you probably agree that redundancy is good - and it is. But how do you apply it to your organization and processes?

Before we go there, we have to tackle a very neat concept of mathematics. Fractals. Fractals have a property that is mind-boggling. Fractals are concepts that once explored end up generating infinite (yes, infinite!) information. In fact, a fractal line has infinite length even while fitting in a finite space! I won't bore you with the math details, but check this page on Wikipedia about the length of the British coast line - it has a neat demonstration of how a finite space can hold a line of infinite length.

This means that fractals are generative when it comes to information: they generate infinite amounts of information. And this happens to be a very useful property to have in mind when we explore how organizations work.

Making the case for infinity (and beyond)

In this post I argued that removing rules from your company's process book is actually better for your business and for your teams. The next step is to remove as many rules as you can, so that you end up with a small and simple set of generative rules - just like a fractal. Fractals are very simple equations that have in themselves an infinite number of solutions. And that's exactly what our processes should be: a small set of rules that, once in use, accommodate an infinite amount of possible behaviors - this is what I mean by "complex behavior" in the post on disciplined organizations.

Conclusion

Turns out fractals are perfect (yes, perfect - as in perfectly efficient) compression algorithms: a simple equation can be solved in an infinite number of ways, which when plotted in 2D or even 3D generate an infinite line in a finite space.

This property is extremely useful when applied to processes in your company because you cannot predict how people should behave in the future, but you can create an environment that - just like a fractal - allows every actor / person in the company to act in an infinite (and therefore practically unpredictable) number of ways and adapt to whatever the ever changing reality throws at them.

If you believe that your business environment is constantly changing, and that your organization is akin to a living organism you have to embrace the concept of fractal organizations.

Fractals work for you when they allow your blood vessels to reach every cell of your body (within a few cells distance), and when they allow your brain to store vast quantities of information even if it is small enough to fit in your head. Fractal organizations are organizations that can adapt in an infinite number of ways in response to an unpredictable environment.

If change is the only constant, how do I adapt to that?

Epilogue

Before we can understand how to apply the concept of fractal organizations and benefit from that, a very serious question must be answered: If people can behave in infinitely different ways, how do we prevent organizations from turning into chaos? That's a question we will explore soon - stay tuned! :)

Do you want to know more?

Title image credit: John Hammink, follow him on twitter.

Hire generalists to help your specialists shine!

Imagine you are developing a highly-specialized embedded software product. Like a radio tower for the GSM/UMTS network, or a high-frequency trading back-end for a large New York trading firm. Why would you want to have generalists in that team? After all, these are niche-niche-niche products. Maybe a few thousand people work on these projects in the world. No need, right? Wrong! Here's why.

Forget common-sense

The comment above is designed to sound counter-intuitive. The reason for that is that most of this post is counter-intuitive. I'll argue that one of the basic premises behind software project management are purely and simply wrong. This one specifically, is ultra-wrong: specialists in a software project (even a niche one) should be the majority of the team. The "favor specialists" heuristic says things like: "don't hire a Ruby programmer to a Java project", "hire only people who've done financial systems to that high-frequency trading platform", etc. You get the picture.

What is the reason for this "favor specialists" heuristic? Why did it arise? The most obvious reason is that we want to hire people that "know what they are doing", and in our functional definition of software projects that means: "people who have done that one thing before". And who could argue with that? Right?

What if we looked at projects like systems, complex systems that incorporate technical and social aspects that are very hard to control or manage? In this case we would be compelled to question the "favor specialists" heuristics, because we would look at a project as much more than a technical endeavor. We would look at projects as being social and technical endeavors.

Social is complex

Social systems have many more dynamics in place than "what is the best technical solution? How do we select from competing technical solutions? What skills should we hire for?"
Social systems change rapidly (whether you like it or not), and they require a different set of assumptions about what is the best project team composition and organization. For example - the point of this post - it requires us to question the ratio of generalists to specialists.
In the last post I talked about Emergence. I explained that system behavior is affected by many unpredictable dynamics and that simple rules favor adaptable behavior in projects. I also said that a long list of complicated rules will remove adaptability from the project team. The heuristic I described in that post is: "complex rules emerge stupid behavior."

Emergence is favored by and favors generalists

I believe all projects are social complex systems. Yes, even two people projects (those, probably even more than larger projects. Think of the rule set on a 2 people project!). These social complex systems perform better when there are only a few and simple rules. They benefit from constant change (see here how to do that so that it does not kill you). Social complex systems are environments where generalists excel! Here's why:

• generalists are more likely to think laterally (similar problems in other domains), and therefore come up with innovative solutions that provide business advantages;
• generalists are more likely to establish communication links to other teams and organizations (because they are connected to more interest groups - which is what makes them generalists), and therefore improve the overall communication in the project team;
• and there are many more, let me know which you have found in your experience by leaving a comment.

Improve performance by adding generalists to your project

I propose that we start designing our projects based on a different heuristic: "favor generalists". This means that we will try to seed all teams with generalists, people who know their trade but are not invested in only one particular technical solution or process.

For Developers this means that all developers should be encouraged to learn several programming languages, work in different problems during their employment, and that we don't hire people just because they've solved the same problem in the past.

For Testers this means that we hire people that can do manual and automated testing (maybe more on than the other, but both), that know different technologies, that understand social aspects (users) and technical aspects of software development (e.g. math).

For Product Managers this means that we hire people that have worked in other industries, other types of products or even in non-software only products.

If you believe, like I do, that software projects are social complex systems, then you must not favor specialists. Hire and groom specialists but seed all teams with generalists, sit back and enjoy the higher performance.

Picture credit: John Hammink, follow him on twitter.

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

Conclusion

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

How injecting randomness into your project can help it succeed

Success and failure differ, very often, by very little. Take nature as an example. A small change in our DNA (a few mutated genes) can have catastrophic consequences. On the other hand, without these mutations humans would never have come into existence.

Humans and other species in the planet evolved because of chance (although not totally chaotic) changes in their DNA. As small change after small change happened, the surviving individuals were able to spread the viable, and ultimately the most adequate changes to the next generation - and the process repeats still in our own bodies today. If Nature has taught us something about improvement and evolution is that you must have a little bit of luck involved!

The DNA of a project

In software projects - my domain - I see some similarities to this natural model that are worth exploring. Projects also have a DNA which includes the structure and the communication connections between individuals. Communication being one of the most quoted causes for failure in software projects, and therefore one of its critical success factors.

The More I Practice the Luckier I Get

Once a project gets started, a particular structure is put in place (governance, management, teams, etc.). Very often that structure remains in place, and static until the end of the project. But is this a smart choice?

Another aspect of the project that rarely changes is the network of connections between the individuals. This network is what carries information from individual to individual and eventually "selects" the information that is acted upon by the project team. If a piece of information reaches an individual in the project, and that individual does not consider it relevant, that information will not spread further. In contrast, when a piece of information is perceived as important by an individual, that information will be actively spread by that individual.

The Illusion of Control

The structure that is set for a project strongly influences the communication links that can emerge between individuals. Who talks to whom? What meetings exist where people interact regularly? etc. But the reverse is also true. The existing communication network within an organization is a strong influence on what governance structure is put in place, how teams are formed, etc. These co-dependent processes create a positive (or negative) spiral of events for the project, but because neither (structure, or communication network) is often changed, that spiral is unstoppable. If it is positive, it will help the project succeed. If this co-dependent processes create, instead a negative spiral, that will relentlessly remove the chances of success for that project.

This co-dependent relation between two key processes (structure and communication network) is why we can increase the chances of success in our projects by simply causing random perturbations in the project. Randomness helps us explore different patterns for structure and communication networks.

As we carefully design and inject small - safe-to-fail - changes into the project, we can observe how it reacts and adjusts. Later, we can retrospectively amplify or remove/dampen the changes based on the outcome we see. If something works, keep it and ask how can you make it grow. If something creates a net negative outcome, dampen or remove it completely.

The cycle goes like this:

• Define and implement small, safe-to-fail changes in the structure or communication network for the project
• These changes lead to emergent behavior as the individuals and teams adapt to the changes
• A new project configuration emerges which drives new project results
• Finally, we evaluate the results of these changes and decide which components we will try to amplify or dampen

What Do You Mean Random?

There are many ways in which we can, randomly, explore better configurations for our projects. Below I list only a few to illustrate the concept:

• At the start of a project, let the teams chose their own composition. This establishes new connections between individuals in the project as some will choose to work with new team members. However, these new connections will not eliminate the previous connections between individuals. The net effect should be that your project now has a more connected communication network (more individuals with strong connections to each other). In practice this works just like when we form new neural connections in our brain: more connections leads to different thinking and acting patterns
• Organize common project events where people interact with each other outside the day-to-day routine. Planning events can be organized following a structured approach, but including also some unstructured time (à lá unconference, using e.g. Open Space) where people can interact based on their interests. This will also help form new connections between individuals in the project and spread information that would otherwise be locked down and not accessible
• Have regular project "coffee breaks" that happen at the same time and same place. In these events people can connect with other individuals and ask questions from the project management team or the most connected individuals in the project. This unstructured communication increases the chance that some piece of information will "jump the hierarchical borders" and reach people in decision-making positions, or people with influence that can later act on that information.

Conclusion

These practices are designed to inject randomness (unplanned situations or connections) into the project. The goal is not to create Chaos (a scary word for many project teams), but to generate new pathways for the information to flow within the project team, as well as novel project structures that are more adapted to the current challenges the teams face.

Using these (or other) practices will increase your project's chances for success. They don't eliminate the need for the project to be managed, or to have structure. They do increase the chance of success for the project by exploring new organizations and structures through a process of small (safe-to-fail) changes that can lead to unplanned, but ultimately superior performance.

These were just a few examples. How would you inject randomness into your project? Have you done that in the past? Please share your experiences in the comments for the benefit of others.

Photo credit: John Hammink, follow him on twitter

Why projects fail, is why (we think) they succeed!

When I started my career as a Project Manager, I too was convinced that following a plan was a mandatory requirement for project success. As I tried to manage my first projects, my emphasis was on making sure that the plan was known, understood and then followed by everyone involved.

When I started my career as a Project Manager, I too was convinced that following a plan was a mandatory requirement for project success

I wrote down all the work packages needed, and discussed with the teams involved when those work packages could be worked on, and completed. I checked that all the dependencies were clear, and that we did not have delays in the critical path (the linear path through a project plan that has no buffer).

I made sure that everyone knew what to do, to the point that I even started using daily meetings before I heard of Scrum which would, later on, institutionalize that practice in many software organizations.

As my projects succeeded, I was more and more convinced that the Great Plan was the cause for their success.

As my projects succeeded, I was more and more convinced that the Great Plan was the cause for their success. The better the plan the more likely the project would succeed - I thought. And I was good at planning!

Boy, was I wrong!

It was only later - after several successful, and some failed projects - that I realized that The Plan had little effect on the success of the projects. I could only reach this conclusion through experience. Some of the projects I ran were "rushed", which made it impossible to create a Great Plan, but had to be managed "by the seat of the pants". Many of them were successful nonetheless.

In other cases, I did create a plan that I was happy with. Then I had to change it. And then change it again, and again, and again - to the point that I did little else but change The Plan.

Confusing the chicken with the egg, which came first?

The example above is one where I had confused the final cause (chicken) with the original cause (egg).

When something works well, we will often retrospectively analyze the events that led to success, and create a story/narrative about why that particular approach succeeded. We will assign a "final cause" to the success: in my example I assigned the "final cause" of project success to having a Great Plan, and the events that created the Great Plan.

This is normal, and it is so prevalent in humans that there is a name for it: retrospective coherence. Retrospective coherence is what we create when we evaluate events after-the-fact and create a logical path that leads from the initial state to the final state via logical causality, that can easily be explained to others. These causality relationships are what lead us to create lists of "Best Practices".

Best Practice lists are the result of Retrospective Coherence, and because of that many are useless

When the solution becomes the problem

However, this phenomena of Retrospective Coherence is not necessarily a good thing. In my initial example about Project Management I was convinced that the Great Plan and the related activities were the reason for success because that is what I could "make sense" of when I looked back in time. But as I gained experience I was forced to recognize that my "Best Practice" did not, in fact, help me in other projects. This realization, in turn led me to question the real reasons for success in my previous projects.

After many years of research and reflection I came to realize that many projects are successful purely by random reasons. For example: someone did an heroic effort to come to work during the week-end and recover the Visual SourceSafe database that had been corrupted once again and for the 1000th time!

But there are many other reasons why projects succeed by pure random chance. Here are some:

• In one project we had a few great testers that were not willing to wait to the end of the project to test the product. What they found changed the requirements and made the project a success
• Some projects were started so that we could deliver the "perfect feature set" to our customers. But as time went by and the deadlines were closing in, some managers - sometimes even me - understood that delivering on time was more important, and therefore changed the project significantly by reducing scope.
• Some developers were single handedly able to both, increase product functionality, while reducing the code base by 30%. This feat increased quality massively and made a delivery on time even possible.
• In one project we tried to use Agile. As a result, we started practicing timeboxed iterations and eventually ended up releasing so often that we could never be late

These are only a few of the reasons why projects succeed despite having a Great Plan, rather than because of it.

The Original Cause

The reasons for project success that I listed above are only a few that can be called "original cause" for project success. Original causes are those that actually start a chain of events that lead to success (or failure), but are too detailed or far into the past to be remembered while doing a retrospectively coherent analysis of project success (after-the-fact).

The kicker

But the kicker is this: when we get caught in "Final Cause" assignment through the retrospective coherence lenses or our logical mind, we lose a massive opportunity to actually learn something. By removing the role of "luck" or "randomness" from our success scorecard we miss the opportunity to study the system that we are part of (the teams, the organization, the market). We miss the opportunity to understand how we can influence this system and therefore increase our chances of success in the future.

Many people in the project management community still think - today - that having a Great Plan is a "Best Practice", and that you cannot succeed without one. I would be the first to agree that having a plan will increase your chances of success, but I will also claim that the Great Plan alone (including following that Great Plan) can never deliver success without those random events that you will never recognize because you are blind to the effects of chance in your own success.

In our lives we must, always, strive to separate Original Cause (what actually caused success) from Final Cause (why we think success happened by analysing it after-the-fact).

In a later post I will discuss how to increase the chances of project success by - on purpose - inserting randomness and chance into the project. Stay tuned...

Image credit: John Hammink, follow him on twitter