Achieving Swarming In Agile Teams – Part One

On May 23rd I gave a talk about Achieving Swarming In Agile Teams at Project Society Conference (PMI). Slides are available on SlideShare. And here is the full transcript, organized in three posts…

Part One

Dictionary defines swarming as a large group of insects or other animals moving around together.

We generally think of swarms and swarming in context of insects. We perceive swarms as entities capable of much complex behavior and having much higher abilities than those of an individual insect.

In humans, however, swarming has a slightly different meaning. It is generally understood as a collaborative behavior of a group. In such meaning, swarming comes naturally to humans, especially in very young age, in preschool children (i.e. before such behavior is inhibited by social norms or school system).

If we present a group of preschool children with a complex problem (as in complexity defined by Cynefin framework), they will almost always try to approach it individually. And they will compete with each-other until they realize that they don’t have abilities needed to find a solution. Once coming to that realization, they will seek for help from others – from their peers, effectively engaging in exchange and building on each-other’s ideas. This behavior depends on particular child’s personality, of course. However, building on each-other’s ideas almost always emerges.

Once the school system is done with us, our mindset is so dramatically changed, that when we engage in professional work, we seek comfort zones in which we can work individually. Most of the companies, sadly, support and favor such behavior.

When individually approaching complex problems however, attained knowledge up to that point and best practices alone are not enough for solving them. We need to hypothesize and experiment a lot. We have to make assumptions. And to make other assumptions based on them, effectively chaining them together.

Take a software developer for example. A typical software developer makes dozens of assumptions and decisions and actions based on them every day. Those assumptions range from trivial to really complex ones. Every subsequent assumption depends on validity of previous ones, effectively forming a chain of assumptions. If the initial one is proven wrong at some point, all subsequent assumptions are most likely wrong and actions based on them are most probably wasted effort.

Consider a space of all possible solutions to a particular problem, ranging from the poorest to the optimal one. Each individual is capable of coming up with just a handful of solutions from that space of all possible solutions, depending on his past experience, knowledge and environmental factors (such as timeframe). In pursuit for optimal solution, he dismisses potential solutions from his solution set one by one, based on (again) his past experience, knowledge and environmental factors, and additionally, personal preference. Proposed solutions are dismissed one by one until he is left with one solution which is most likely optimal solution from his perspective.

Different individuals have different starting points and different perspectives, thus their proposed solution sets will be different and they will most likely decide on different solutions as optimal ones. If their perspectives are not combined, they will end up with suboptimal solutions.

If their perspectives are combined, however, they will engage in feedback, giving and receiving feedback, effectively challenging and validating each-other’s assumptions. The shorter the feedback loop, greater the chance that the amount of wasted effort is minimized.

Remember our typical software developer with long assumption chain? If he has his original assumption validated really quick, he will have minimal amount of effort wasted.

Significance of short feedback loops is really nicely summed up in the following quote – “The best time to discover bugs is within about 3 minutes of introducing them”. This originates from software development, but is valid for all other contexts as well.

So, what does Agile have to offer in terms of feedback and different feedback loop mechanisms?

The most popular Agile framework by far is Scrum. Scrum provides feedback loop opportunities on different scale: weekly scale of Sprints and daily scale of Daily Scrums.

Sprints are fixed-length iterations, one to four weeks long, which guarantee client feedback and feedback about the process at the end of sprint. So, for team having two-week sprint, it is guaranteed to have feedbacks every other week. That might be to long for most assumptions team makes, so Scrum provides Daily Scrums.

Daily Scrum provides 24-hour feedback loop. It guarantees team engaging in feedback session at least once a day. For our software developer (who makes dozens of decisions every day) this might be too long. However, Scrum does not provide any shorter feedback loops.

On the other hand, co-founder of Scrum, Jeff Sutherland said that for software development Scrum best works if combined with Extreme Programming (XP) practices. So if we use them, we have:

  • Continuous Integration (CI) – integrating one’s work with work of others, verifying that his increment will not break the product and will fit nicely in it. It typically happens several times a day, but at least will be executed daily (when developer checks his code in when leaving office).
  • Unit Testing – writing unit tests while and before writing application code (TDD) guarantees verification of one’s code validity even after refactoring or applying other changes. It will be executed several times per continuous integration cycle, but at least once per CI cycle – when the code is checked in.

And that is really short feedback loop occurring lots of times a day. However, XP proposes another, much shorter feedback loop – continuous feedback loop! It is provided by engaging in Pair Programming (or Pairing).

So, why is now a pair important for this context? It is the smallest possible form of human swarm – it has only two members (so, technically, it is really stretching the swarming definition).

Consider distribution of one’s ability over the course of problem solving progress, related to particular point of that very progress. It varies for each person. And if we combine two individuals by pairing them together, it is reasonable to expect to have their combined maximum at all times. However, pairing does not work that way. If they engage in pairing, they will engage in continual brainstorming, thus effectively continually building on each-other’s ideas and validating them. They will come up with induced knowledge, which surpasses their individual knowledge and it is not likely that they would come up with it working on their own in isolation.

If we keep adding individuals to the team, effect will only grow, but only to a certain point – we cannot grow the team indefinitely and keep it performing. There is a sweet-spot depending on context and organization, which defines perfect team size, and it varies with different companies and teams in them.

However, such grouping is real, exists and has a name – Mob Programming (or Mobbing) and is particularly popular in Scandinavian countries with increasing popularity throughout the world.

Continue to the second part – Scrum Example.

Here is a bonus video of one day in team engaging in mob programming.