Announcing The Swarming Development Method

October 6, 2014


By now, you’ve probably figured out that I’m laying out all the guidance for using Swarming as a legitimate, full-fledged, Agile method. It looks like this:


There you have it. A complete method for swarming. Wrap it up and ship it.

“But wait!” you say, “You’re not a real methodologist, your just some guy with a blog!” You are absolutely right. What gives me the right to propose a new agile methodology? What kind of egomaniac thinks he can just pop up with a completely new method of team development? Well, actually, it’s not that new. I pulled a lot of the material from a variety of existing sources. I copied the format for the Values and the principles from the Agile Manifesto. Nothing here is all that original. After all, if I’m right, bugs have been doing this stuff without the benefit of my genius for millions of years. Why would I do this?

First, I’d like to state this as emphatically as I can: ANYBODY CAN DO THIS! We can all be copying methods and tweaking them – and we should. No real experience is required. After all, that’s how the guys who came up with Scrum, and Kanban, and XP did it. They copied ideas from Takeuchi and Nonaka, Ohno, Demming, Goldratt, and a whole bunch of others. We need to keep doing that – copying and stealing and mixing and removing bits until we find methods that work even better. Take this opportunity to make a methodology that is an expression of your beliefs. Heck, maybe it expresses the vision of your entire team…or company.

Secondly, there just aren’t enough methodologies out there. Having scrum taking over 80% of the agile project management ecosystem is really, really…boring. Ken Schwaber, one of the creators of Scrum, has always maintained that something better will come along one day. I’m sure that’s true, but it won’t happen unless we are creating a vibrant ecosystem of competing methods. Just having Scrum and Kanban isn’t enough.

So feel free to take this methodology – it’s yours. Run with it (careful, it’s pointy), copy it, break it, fix it, and for God’s sake, make something wonderful.

Swarming Resources

October 4, 2014


Here are some of the books and web sites that researched as part of my investigations into swarming. There are a few that I should probably re-read too. That said, if you are interested in swarming, you could use some of these references for starting points.


The Wisdom of Crowds – James Suroweicki

Suroweicki’s book was my introduction to the power of self-organizing groups. He is a very engaging writer. It’s a fun read and serves as a good starting point for further research.

Bioteams – Ken Thompson

The Thompson book is the first that I found that attempts to apply the theory of swarming to teams of people. It’s oriented to the use of mobile devices and does a good job of positing the simple rules that might be used by swarming teams.

Emergence – Steven Johnson

Steven Johnson’s book is similar to Suroweiki’s, but Johnson’s work is more thorough and academic in tone. He does a great job of explaining some very complicated ideas well.

Micromotives and Macro Behavior – Thomas Schelling

 This guy is a nobel laureate in economics, so I guess he knows what  he’s talking about. I loved the introductory chapters, but after that he lost me. It gets really dense really fast.

The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations – Ori Brafman and Rod Beckstrom

I really loved this book. Brafman and Beckstrom did a fabulous job of writing a very engaging book about self-organizing…organizations. This book does the best job of giving you real examples of groups of people swarming.

Swarm Creativity – Peter Gloor

Peter Gloor’s book is mostly focused on swarming as a way of driving innovation in teams. He also examines ways that we can find collaborative networks (COINS) within existing organizations.

Swarm Intelligence: A Whole New Way to Think about Business – Eric Bonabeau and Christopher Meyer

Bonabeau and Meyer have made the transition from academics to business. They take the principles of swarming and apply them to business problems.

Web sites

BioTeams – Companion to the book

Systems Thinking – A catalog of systems theory and emergent behavior links

CalResCo Complexity Writings – a collection of academic papers on emergent and complex behavior

Swarm Theory –  a great Nat Geo article about swarming

Wikipedia article on swarms

Rules for Flocking Behavior

Boids – If you want to play with simulations of swarming behavior, this is a great start

The Science of Biological Swarms

Swarm Creativity – companion site to Peter Gloor’s book

Research Project from the MIT Center for Collective Intelligence

Links on Complexity, Self-Organization and Artificial Life

Swarm Intelligence – more links

NY Times article on swarming

Project Anarchy

October 3, 2014


Recently I’ve been writing a series of posts on a rather radical methodology that I call Swarming. I describe it as a method that enables individuals to become part of whatever team they like and work on whatever they want. They can follow their passions wherever they choose (in fact they must) without interference or even guidance from a hierarchy (managers, coaches – nobody). I’m quite keen on the ideas, but it occurred to me that what I’m advocating might be indistinguishable from anarchy!

So I hustled over to wikipedia to look up anarchy. Here’s what I found:

The word anarchy comes from the ancient Greek ἀναρχία, anarchia, from ἀνan, “not, without” + ἀρχόςarkhos, “ruler”, meaning “absence of a ruler”, “without rulers”).

Oh my. That is what I’m talking about! One of the fundamental rules of swarming is there is no single controlling entity or “ruler”. So swarming could indeed be described as a form of anarchy by this definition. Now it turns out that anarchy has more than one definition, and in common parlance, the word seems to be mostly associated with the political definition:

Proponents of anarchism (known as “anarchists”) advocate stateless societies based on what are sometimes defined as non-hierarchical organizations, and at other times defined as voluntary associations.

That’s interesting. That is pretty much what I have been advocating. Maybe I am an anarchist after all. But I’m from Seattle, and here in the Northwest we know what anarchists are. We have a bunch of them around here. Anarchists are gangs of masked hooligans that roam the streets and break shop windows whenever the WTO comes to town. They’re a real pain in the ass. I’m not one of those clowns.

However, strangely enough, as I become more experienced with software development projects, the less I find myself trusting traditional management institutions. I yearn for a place that is free of hierarchy (non-hierarchical organizations), where we have the opportunity to pursue whatever tickles our fancy.

But allow me to make this argument: Swarming does have very simple rules. I don’t think of anarchy as having rules, so I don’t believe that Swarming can be called anarchy. Actually there is a variant of anarchism that fits my notion of Swarming rather well: anarcho-syndicalism.

Syndicalists consider their economic theories a strategy for facilitating worker self-activity and as an alternative co-operative economic system with democratic values and production centered on meeting human needs.

Ooh! That’s much more like it! What a mouthful. I especially like the “meeting human needs” part. Wow. So that’s what I am. Damn, I guess Brian Marick was right.


Starting Swarming

October 1, 2014


“prattle without practice”
― William Shakespeare, Othello

Enough prattle! All this theory is great, but how do we actually set the conditions for swarming to occur? How can we make it work?

Initiating the Swarm

The problem with a good swarming team is that you can’t control team membership. Swarming requires a dynamic and egalitarian approach where everyone can decide what they want to do with whomever they please. Management has no role in this at all (other than perhaps creating the space). I suppose you could try and provide a few seed ideas to attract people, but you go into it with no assurance that those ideas will be what the groups coalesce around.

There should be some orientation to the values and principles to start with. We need to find a group that is interested in using the process and understands from the start that there are no explicitly defined leaders or followers. Anyone can come up with an idea, and if the idea is a good one, perhaps others will join you.

So the key ingredients to start swarming:

  • People who have been introduced to and understand the swarming values and principles
  • Some ideas
  • A place for the swarming to take place – preferably a place dedicated to swarming
  • Passion

One more note on the people: radical diversity is required. It’s not sufficient to just toss a bunch of developers and QA into a room and tell them to swarm. It must be open to everyone. ABSOLUTELY everyone. That’s right, toss that cute receptionist from the front desk in there too. Customer Service, the guy from the help desk, and the janitor. Throw them all in. And a customer or two – don’t forget them. Oh, and for God’s sake, whatever you do, don’t toss an agile coach in there, they’ll tell everyone how to do it and just screw everything up.

That should get them started. It could be structured like the marketplace in open space. Everyone with an idea goes to the center of the room and writes their idea on a sheet of paper. They stand up and announce the idea, then go to some agreed upon area and wait to see who shows up. Simple. Then let people go wherever their interest takes them. They can be butterflies, bumble bees, whatever makes them happy. If you come up with a new idea (and hopefully people will) then you just write it down and announce it to the group. If there are no takers, no problem: you can decide to continue on your own and develop the idea to the point where it attracts more interest or you can dump it and look at someone else’s idea.

That’s really all there is to it. From here on out you just stand back and let it go. The teams that form will decide how to work together. If someone doesn’t like it, they can move on, make their own team or join another one. No managers. No scrum masters. Just:

Water frequently…

Place in direct sunlight…

And let it grow…

Swarming Context

September 29, 2014

The application of Swarming as a method can be broken down into four main contexts. For each context the process of swarming is different. Allowing for different contexts makes sense, because we really can’t expect the same process to work equally well in every situation. Even the simplest animals are able to exhibit variations in behavior based on the context, so why shouldn’t our processes? We change our behavior to match the circumstances. That is, unless we are using fixed methods like Scrum or Kanban. If you are using fixed methods, the proscription is to treat the process in a fractal fashion, repeating it everywhere. Practically speaking, by having only one process these methods ignore the context.

So what are the four contexts of Swarming? Here they are in no particular order:

  • Emergencies
  • Shifting Gears
  • Innovation
  • Building

Emergencies represent the simplest context for swarming. When a crisis occurs, it’ all hands on deck. Everyone joins the conversation and brings whatever specific expertise they have to the party. The group self-organizes to enable those present to contribute to solving the problem. You see this a lot in production operations environments when a “P1” defect occurs or, heaven forbid, the production system goes down. When this happens, everyone swarms on the problem. Some are gathering information, some are listening and integrating the information, and some are taking action to try and remedy the situation. All of this is happening dynamically in the moment without central organization. All of these activities are critical to the success of the swarm. During a crisis, nobody is going to stop what they are doing for a standup meeting, and they sure as hell aren’t interested in seeing your Kanban board.

Shifting gears refers to when the system is in transition. The corporate ecosystems that we are all a part of are changing faster with every passing day. New products are coming to market and disrupting the old ones. It’s not enough to simply work within the existing system. You can’t keep up that way. These days corporations have to match their structure to the complexity of the environment. That’s hard, and that’s where swarming comes in. Like when honey bees form a swarm, the corporation reaches a critical mass where a new structure is necessary. Up until this point, the hive has been a stable and reliable structure, but with the presence of a new queen everything changes. A cascade of events takes place where the hive moves on. This can also happen with companies. When they reach a certain size, they can spin off subsidiaries, divisions, and even teams. We see this when teams reach critical mass and split into two teams (meiosis). On swarming teams, we use simple rules to enable groups to decide on their own when division should take place (Team size of 7 plus or minus 2). We use the swarming values and principles to help guide who works on each team – always leaning toward letting individuals decide based on where their own passions take them.

In swarming, Innovation is treated as foraging. We are foraging for new information and new ideas. In this context we are actively using our social networks to recruit new people and new ideas to our cause. This can be initiated as part of a special state (shifting gears) or it can be part of the ongoing activities of the team. When ants are foraging, they tend to follow the strongest pheromone trails to a food source. However this rule is not universal. There are ants who wander off the pheromone trail from time to time. These solitary explorers are the ones who have the unique opportunity to wander off the beaten path and potentially find rich new sources of food. So too, we want people on our team not to follow the team too closely. It’s best if they can wander off and explore side avenues and blind alleys. This isn’t something that is dictated, it’s a natural part of teams with rich diversity. People make these decisions on their own and either bring them back to the original team or they form a new team.

Building takes place when we are trying to strengthen our networks. As a team is growing it uses it’s social networks to strengthen bonds both within and without the team. This can be as simple as increasing the number of social “touches” on a team. Social touches are things like: greeting each other, going out to lunch together, supporting each other’s work. There are some people who are stronger at this than others. Some people tend to form many lightweight social contacts (which is very useful). On the other hand, there are those who only have a few deep, strong relationships. A good swarming team is composed of a healthy balance of both types of people.

In summary, swarming is used differently based on the context you are in. Understand the context, and you are prepared to take advantage of the power of swarming.


Broadcast Communication

September 27, 2014


In the agile development community, we are all hip to the notion of two way communication. It can be via any mechanism you choose: email, instant messaging, smoke signals or the hands-down, all-time winner – face to face. That’s fantastic, but there is another form of communication that we can develop: one-way communication.

What’s the value of that, you ask? Isn’t two way communication a lot better? The answer is yes, two way communication is great and has it’s place, but one way communication has a different purpose – one that agile teams should learn to develop as well. In fact, most agile teams don’t do very well at the one way communication beyond the team at all.

Let me explain: One way, or broadcast communication doesn’t require any response. You just shout out the news and go about your business. Now of course if there is no one to hear the news, then it really doesn’t make much difference (if a tree falls in the forest…). However in the case of working on a team, there is usually someone around. Broadcasting simply shares information with absolutely no expectation of any information or reply in return. It’s all giving and no receiving. Others can get the information and then act accordingly without ever engaging in dialog.

Some examples of one way communication include: status reports, information radiators: including burndown charts, kanban boards, etcetera. There are tools that promote one way communication such as Twitter and Yammer. I suppose even a wiki or blog qualifies too.

There is one other thing about broadcast communication that I like, especially when it comes to swarming. One way communication removes any expectation of compliance. When you broadcast information, the receivers get to decide what they want to do with it. There is no expectation of any sort of action. Commands are weakened or non-existent with this type of communication. That’s a good thing if you are swarming.

A few sentences back, I made the claim that Agile teams aren’t very good at broadcasting information beyond the team. Many of the teams that I work with tend to be very inward facing. The communication is rich between team members, but it’s very sparse if you are outside the team. This may also be a reflection of the hierarchical nature of many of the companies I’ve worked with. Teams need to take advantage of every mechanism they can find to radiate information outside the team. Some opportunities include:

  • The Scrum of Scrums or other program or portfolio meetings
  • Information radiators OUTSIDE the team. Broadcast doesn’t work if everyone has to come to you to get the message.
  • Attending other forums, other teams status meetings
  • Status reporting – yes, status reports are the root of all evil, but they are a form of one way communication.

If you aren’t using one way broadcast, give it at try. It’s a powerful communication tool – and essential to promote swarming.

Swarming Roles

September 26, 2014


So far in this series I have covered the values and principles of the swarming methodology. Now let’s talk about roles on swarming teams. In nature, when you look at swarms, flocks and schools there are all kinds of specialization. The nature of the roles can be fixed (i.e. workers and queens) or they can be dynamic (foraging, nursing, etc.). So there are a very broad range of roles that we can find in the animal world. Given those models, there are a few things we can identify as critical to swarming teams:

  • Swarms don’t have Managers, Masters or Owners
  • Swarms have radical diversity
  • Membership is not fixed

There are none of the typical command and control structures to be found on a swarming team. There is no manager. There is no owner. There is no one person making any of the decisions for the group. Swarming doesn’t work without complete equality. That doesn’t mean there can’t be leaders, they are still necessary, but it is only leadership by virtue of their ideas, not any sort of hierarchy or power relationship.

Swarms require diversity. Swarm based decision making is enabled by diversity in the group. Without that diversity, the swarm is likely to have too narrow a perspective and come up with poor answers. This comes from the wisdom of crowds – it doesn’t work without diversity. True diversity is rare in our business. I’m not talking about just race and sex (although more diversity there is necessary), I’m actually talking about a diversity of knowledge and interests. We need people who aren’t software engineers on our teams. Anyone can play: the admin, the fisherman, the librarian, the doctor and the engineer. I think of this as radical diversity.

Finally, the membership of the team doesn’t stay the same. It ebbs and flows with the popularity of the project and the ideas that are being worked on. Anyone can come or go on any given day. They are able to follow their passions where ever they may go. Swarm teams can recruit, sell, and dissipate completely. Nothing about the membership on swarming team is mandatory.