Friday, 13 September 2013

Surface Tension

Some religions consider walking on water to be a sign of divinity, but for bugs such as the
Water Strider it's simply how they live every day. How is that possible when the density of the water strider is greater than the density of water, i.e. it shouldn't float? It's due to a simple physical property of liquids, surface tension, which is the result of how the molecules in a liquid at its outside surface have stronger bonds to one another. This is a very distinct and measurable property of a liquid, and water has one of the highest levels of surface tension.

The water strider also cheats a little. They have several adaptations such as hairs on their legs that increase the area in contact with the surface of the water which reduce the force they're exerting on any given point. These are effectively snowshoes for water!

At some point, though, all the adaptations simply can't avoid physics and the force due to gravity will overcome the resistance due to surface tension.  When this occurs the item in question doesn't sink just a little bit into the water in some proportion to its weight, it simply sinks.

It occurred to me recently that our efforts to scale software development processes experience the same sudden loss of surface tension and related sinking.

When the group building a software product is tiny, for example the classic 1 to 4 person startup, they can simply float on the surface due to the very low weight of the process required to work. The group communicates effortlessly in an informal manner, and they're focused on shipping features quickly to satisfy their customers.

If the market for the product increases and the group grows to accommodate the increased need for features, the process needs increase as well due to increased communication paths. At this point the process has become more dense than the water, but it's still light enough that surface tension is sufficient to keep it above water. This is represented by small teams of 5-20 people using processes such as XP and Crystal Clear. Adaptations analogous to the hairs on the water strider's legs may allow the teams to cheat against surface tension and grow as far as perhaps 50 people. This would encompass Industrial XP and the Crystal Series of processes.

There comes a point, though, where the force exerted by the weight of the process overcomes surface tension, and the team sinks rapidly. The simple adaptations made to allow the simple processes to scale can't be applied anymore because a finite limit of physics has been reached. Cheating with practices like Scrum of Scrums, group iteration & release planning, and group retrospectives doesn't work anymore.

Essentially, you've reached a point where you need to create a vessel that has enough buoyancy to float
on the water to support the size of your group. The larger the group, the larger the vessel and the more effort required to actually operate and maintain the vessel. Scale far enough and you'll require a full-crew!  We saw this with the Rational Unified Process (RUP) and with more recent processes such as Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe) and even Spotify's Agile scaling model.

So what can we learn from this?

First and foremost, I defer to Martin Fowler's decade-old assertion that Scaling XP is the Last Thing You Should Do. Ask the question, do you really and truly need a large team working on a product? If your answer is yes, then ask why. If you still think a large team is needed, ask why again. Can you get away with a group working in startup mode? Does increasing the team size to the point that surface tension still holds you above water also increase the rate at which the team can deliver running, tested features? Are you scaling simply because the problem (or more correctly, the perceived solution) seems large?

What can we learn from the nimble water strider, gliding effortlessly across the surface of a pond? Perhaps we're too quick to jump at the solution of increasing team size and thus increasing the weight of our delivery process. How long does it take before we realize that we aren't gliding on surface anymore, but instead have sunk?

In the end, the trick is to identify when you need a water strider instead of an aircraft carrier, and vice versa. I would suggest that the number of times you need the latter is minuscule compared to the number of times that the former is the more effective approach.

2 comments:

Simon said...

I like the fact you go back in time to compare different approaches.

Jens R. Woinowski said...

I think the most important question is: Do you really need more than 50 people? Above, you may cheat a little (smaller sub-teams per topic). Beyond that, Lean might be more scalable than Agile. What do you think?