Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles A Year in Swarm

A Year in Swarm


During the better part of last year I was leading a small team of tightly-knit developers who largely worked on a single screen and keyboard, had no formally defined roles, performed no estimates, seldom worked on more than one task at a time and delivered a quality product to a satisfied customer.

Crisis - an opportunity

After performing some coaching for a support team and initial diagnostics of a recently put into production ERP solution, I was approached by a client to help them bring the system back into a working condition. The system would often stall and needed a reboot and had a number of known bugs - the features mostly copied from a legacy system with no user or business expert input, etc. The initial diagnostics discovered a huge number of runtime exceptions, memory leakage, abysmal performance and other issues. In the meantime, the company that originally developed the system went bankrupt - not least because the client lost patience and decided to part ways.

One of the alternatives was to abandon the system and go with some of the leading ERP solution providers. Aside from the political and financial cost, this would result in another long period of customization and rollout; instead they decided to give the existing solution another try.

Start with WIP of 1

Fixing a huge legacy application with tremendous problems and source code suffering from every known code smell is nothing short of a “hot potato”. Still, we decided to give it a go, as long as the client was ready to do it on our terms. These weren’t many - basically, at all times we were going to work on a single task. We’d do a test run for one month and then, if the client were happy with the result, we would renew the agreement for a longer period of time. To different methodologies proponents, probably more interesting than the experience itself were the things we decided need not to be doing.

No Estimates

A lot of requests we received had to do with fixing defects: a user unable to submit a form, a report displaying different data for the same input parameters or taking too long to run, etc. In most cases, we were able to deliver a solution for the particular issue within the same day. Very often, after a bit of investigation, one bug would unearth a pervasive anti-pattern. This would mean a few additional days spent applying the solution globally and, on more than one occasion, a few weeks dedicated to resolving a memory leak and optimizing performance. But, for the most part, we were able to deliver a solution to the pressing problems in a matter of hours. We have also put into practice a manual, but efficient solution for new version rollouts with the capability of rollback.

For those requests that implied developing a completely new feature, we would choose a small slice of relatively self-contained functionality and deliver it in a day or two. In this way, our client was able to make the projection himself: if this piece took two days, then the whole feature would probably take two or three weeks. This way no time was wasted on estimates. The key was delivering software in small consistently working increments.

Mob Programming

“Mob programming” involves a group of programmers and other team members like product owners or testers discussing solutions and writing code in fast succession, on a single screen and keyboard. For a number of years, I have been using mob programming as the preferred approach to execute my agile development workshops. I have even tested this format on a real project for short periods of time. The results were more than encouraging and this time I decided to execute the whole project in this manner. Hence the “WIP of 1” condition mentioned above. After a while, we started applying the same mob programming dynamics to other kinds of work, for instance, document creation, writing emails, speaking to a client etc.

Collective Intelligence

Every programmer has experienced moments of mental exhaustion where it can take a lot of time to resolve even the most trivial problem. Most programmers (even those that do not practice pair or mob programming) are aware of this and will invite a fellow programmer to take a look at their code in those moments of frustration. In a mob programming session, such moments are practically non-existent.

When dealing with more far-reaching issues like design and architectural questions, mob programming provokes a creative dialogue and exchange of ideas without falling into a trap of long and heated arguments. After a while, the team starts working at the same “wavelength” and collective decisions are based on mutual trust. In cases when significant difference in opinion persists longer than usual, the issue can be settled by conducting experiments.

Three’s a company

A subtle psychological effect of mob programming compared to pair programming is a less involved and less intimate relationship between participants. A larger group fosters a more open discussion. Moreover, it is much more difficult to impose opinions based on authority. There is also a more varied mix of expertise and experience. Mob programming’s practical application has proved that a group environment (as opposed to a pair) overcomes many objections voiced against pair programming. Finally, a recent study suggests that groups of 3 or more are more effective at problem solving than a single person or a pair.

Learning and mentoring

In the knowledge industry, learning and mentoring should be an integral part of everyday work activity. A swarm provides an ideal environment for that, as long it is done in a deliberate manner and at a steady pace.

Swarm Patterns

While most of our time was spent mob-programming, on occasion, we would deliberately turn the “parallel” mode on. The most important difference in this approach compared to traditional or even pair programming team setup is the fact that the team as a whole is always focused on a bringing a single work item to a close, but might focus individually, in pairs or in smaller groups to remove different impediments that stand in the way of completing the current work item. This behavior is the most important characteristic of what I would call the “high performance team”.

Probably the most important benefit of the ability to react and reorganize was the capacity of the main group to continue working on current items in “business as usual” fashion, while a few members would deal with impediments and urgent or unplanned issues. This means that the normal team dynamic remains unaffected, learning continues and all members are still very much aware of the current work in progress. Here are several patterns I was able to identify.

Branch out

Some kind of impediment appears, preventing a team from bringing certain item to a close. A member, pair or a group will break out from the team and work on removing the impediment. After the impediment is removed, those who branched out return to the mob.

Another situation when branching out is warranted is when some routine, low-complexity work needs to be performed. Such work presents only a small opportunity for learning. Performing it in unison does not provide interesting benefits when all team members are already familiarized with the procedure and automation is not warranted.

In those situation a member “branches out” to perform the work and joins the rest of the team once this “solitary” work is done.

A similar approach would take place when some urgent issue was reported: one or two members would branch out to investigate and, if possible, resolve the issue. In the meantime, the rest of the mob would carry on with original work.

Spread out

From time to time a defect was discovered that was uniformly applied across the code base effectively forming an anti-pattern. In such a situation, after resolving the first occurrence as a group, the team would “spread out” to apply the solution to the rest of the defect instances. After the work is done, the team would join to comment on different facets of the defect and how these were resolved, as well as to document the experience.

Keep one in the dark

Some people argue that groups can stifle creativity and lead to irrational decisions, motivated by conformity, a phenomenon known as groupthink. In order to avoid this happening to our team, from time to time one person would purposefully abandon the swarm until a certain task was finished. After completing the task, a code review would be performed where the solution was presented to the team member temporarily excluded from the swarm and where he was able to question the decisions taken. His suggestions would then be incorporated into the solution if warranted.

No Roles

No roles were defined explicitly during the engagement or any form of team hierarchy. As the engagement progressed, the team members interchangeably started performing different kinds of tasks, including negotiating commercial aspects of the engagement with the client, working on marketing, procuring new opportunities etc.

Fluid Leadership

In most cases, teams are formed with a pre-established leadership and other roles. Team roles are often allocated based on an employee’s position in a company, which frequently produces an uneasy relationship between the two. It is not realistic to expect the same person to show superior skills and initiative in each and every situation.

In our swarm, a different team member would show initiative depending on a particular situation. So, if a particular technology was a specific team member’s area of expertise, he would lead the way, while the rest of the team was getting familiar with the technology. If a team member had a closer, pre-established relationship with a client, he would lead the conversation and make sure to involve the others. In time, all team members become capable of autonomously performing a great variety of tasks and are at ease with taking important decisions.

No Decision-Making

Decision-making is one of the most difficult and challenging tasks any team has to perform. Before swarming, my experience was more or less limited to ‘command and control’, or traditional ‘democratic’ teams. However, ‘command and control’ teams can stifle a member’s autonomy and initiative. Those teams often belong to hierarchical organizations where internal politics and bureaucracy can have a significant impact on team performance. On the other hand, traditional ‘democratic’ decision-making can often result in a lengthy process, protracted meetings and heated discussions, where a majority based decision-making, often delivered as a voting exercise, still leaves a number of members dissatisfied.

One of the unplanned effects of the swarm was the way the decision process would play out. Decision-making became a part of everyday work flow, not different from most “grunt work”. A team is already aligned, shares the same vision and most agreement is generated collaboratively and almost instantly - for instance, while writing a certain document or email in a “mobbing” fashion.

No Ceremonies

For a collocated team that is always informed of the current work in progress, many of typical Scrum ceremonies, like daily standups or sprint planning and review, make little sense. They might be appropriate for novice teams, but more mature teams are more likely to feel restrained by them. We would speak to a client often and whenever necessary. In these meetings we would present the finished product to the client and we would agree on the next work item to pull. As a general rule, the whole team would participate in all meeting with the client and the stakeholders.

We would discuss and often implement different and better ways of doing things as a part of a normal daily routine. With other teams, retrospectives were taking place at the end of sprint and we would hope that some of the action items would make it into the next sprint. With swarm, we strived to take any opportunity for improvement immediately.

Playful work

In a healthy and respectful team environment, swarming becomes a playful and enjoyable social experience. While during intermissions there is a lot of humor and laid-back conversation, it is the work itself that becomes an engaging activity and almost never drudgery. As a result, there is much less stress - problems are dealt with in a collective manner and at no point is a single person left on their own to deal with a difficult problem.

Most of us writing code enjoy the mental challenge it entails and derive satisfaction from creating something used by other people. Swarming turns coding into an enjoyable and playful social event, surprisingly revealing that programmers are in fact “social animals” and can greatly enjoy collective problem solving.

Different kind of flow

Programming demands a lot of mental effort, while attaining the best results requires intense concentration that is best achieved in a quiet environment with no interruptions. In literature, this state of high immersion is often referred to as “the flow”. At first glance, it may seem that a swarm-type social environment might prevent reaching this highly productive state.

However, it turns out that “swarming” members are also highly immersed, although probably in a slightly different kind of flow. One member will easily take over after a switch in a mob programming session, since generally everybody is highly focused on the work being performed.

This “social flow” is most visible during the most challenging problem-solving periods. Often, the work will start with one member leading along a certain path, another helping resolve impediments that might crop up, the third suggesting a slightly different direction or a detour and so on, until the problem is solved.

Will it work for my team?

All members on our team have known each other for a number of years and swarming felt like a natural next step for a mature and highly collaborative team. Less mature teams might need to go through an initial process of team gelling, where the rules of the game are first made explicit and then gradually absorbed in the process of swarm creation. Probably the best way for a team to test if this kind of team organization is appropriate for them is to try mob programming during some kind of a programming workshop or a code retreat. If they seem to enjoy it, they might find other abovementioned team organizational patterns equally natural and engaging.

About the Author

Danijel Arsenovski is an author, software craftsman, and agile coach. He is the author of books "Professional Refactoring in Visual Basic" and "Professional Refactoring in C# and ASP.NET" for Wrox. He has pioneered refactoring on the .NET platform and is creator of a Refactoring Dojo. Lately, he has been experimenting with creation of highly collaborative teams - "Human Swarms". His twitter handle is @darsenovski.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p