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 Principles

September 25, 2014


In an earlier post I introduced a set of values that might be used to guide swarming teams. Values are a good start. They provide very broad guidelines to give teams guidance when making big picture decisions. Principles help give more specific guidance. So here are a few principles that are aimed at guiding teams practicing swarming as a discipline.

Swarming Principles

  • The most important thing I can do is whatever I am most passionate about today
  • Prefer one way broadcast over two way communication
  • Using agreed upon protocols enhances the effectiveness of our communication and decision making

The first principle tells us that we need to be fully engaged in whatever we care most about. That means that people move to where ever they have the most interest. Teams are spontaneously formed dynamic entities that are composed of people who share a common passion.

The second principle tells us that we not only need to communicate, we need to radiate. Information needs to be broadcast exuberantly without reservation or hesitation.

The third principle tells us that one of the foundations for emergent behavior is in simple protocols. We need to be explicit and disciplined in how they are applied and we need to be always seeking new protocols to add to the mix.

How to Fail Without Really Trying

July 28, 2009


Having been working on software projects now for more than a few years I feel as though I have explored many of the most common (and a few of the not-so-common) ways of failing on a project. The good news is that you can do it with any project. It really doesn’t matter which methodology you choose to use: waterfall, scrum, XP, Kanban – you can fail spectacularly with them all. It’s deceptively easy to do and in fact, in my experience teams do it all the time. According to the people who measure these things, like in the 2004 Standish CHAOS report, we seem to be getting better at failing projects over time. I like to think that somehow, in my own small way, I’ve helped to contribute to those statistics. The good news is that you too can contribute to our long and not-so-distinguished history of software project failures. For those who are just starting out at failing software projects I have a few tips to help you along.

First things first, you have to pick or become part of a project that you really don’t have much passion or interest in. Nothing beats raw, unadulterated apathy to guarantee the failure of a project. There are all sorts of clever ways to justify our presence on projects that we really don’t care much about:

  1. It’s a down economy and I’ll do whatever it takes to keep a job. No, really – anything.
  2. It’s too hard to do the work required to find something we’re really passionate about that pays the bills
  3. Let someone else make the decisions about what we work on. This has the added benefit of enabling us to point the finger of blame for our situation at someone else!
  4. Adopt a strategy of learned helplessness. This isn’t as easy as it sounds – it takes literally years of really hard work to completely stifle a person’s initiative and will to fight. But hang in there, I’m here to tell you it can be done. Persistence matters.
  5. Join a team of people you really don’t particularly like or admire. If you have trouble with this, try taking on a superior attitude. That way they won’t like you even if you don’t find them particularly offensive.

If you are unfortunate enough to come across a project that perhaps your team does have some interest in, don’t despair – there are some things you can do to fix it so that nobody will want to be a part of the project in short order. First, you need to cultivate a very selfish attitude. Try the following:

  1. Just go through the motions. Show up at the daily team meeting and avoid sharing anything of any use to others on the team. Make it all about you. Just like show and tell in first grade. As far as I can tell, this seems to be the natural state of affairs for most standup meetings, so it should be easy to manage.
  2. Avoid the elephant in the room. Elephant dodging is truly an art form. I’ve witnessed teams go through contortions similar to dancing the “Limbo dance” in order to avoid tangling with the team pachyderm.
  3. When in meetings, be sure that you attend without making any significant contribution or preparation. I find sitting quietly with my arms crossed and occasionally nodding off during a meeting tends to discourage people from inviting me to more meetings – and that’s generally a good thing – for me.
  4. If someone solicits your input, give it grudgingly if at all. If people have a hard time getting your contribution, they’ll see it as a rare commodity and value it more highly.
  5. Whatever you do, don’t make the classic mistake of getting frustrated and asking more of others – otherwise they’ll start to do it too, and then eventually they might do it to you!
  6. Be very quiet. Don’t speak up unless asked, and when that happens, be sure to answer using monosyllables. “No” is always a good start. Even better – just shake your head.
  7. Don’t *ever* rock the boat.

Oh, one more thing: I know people are going to need help with some of this, so I want to offer my services as a consultant. If you really want to fail the easy way, give me a call – my services are available for a very high price. In fact the steep price alone may be enough to guarantee project failure. Of course as far as I can tell the competition is pretty fierce these days. There are a lot of people out there who will cheerfully escort you down the well trodden path to failure while taking your money and spouting meaningless managerial advice.