Skip to main content

Search...

What Bacteria Do Better Than Your Scrum Team

Avoiding bugs is the wrong strategy. What bacteria and moths teach us about trends, hypotheses, and robustness in software projects.

7 min read
Cover for What Bacteria Do Better Than Your Scrum Team

Resilience in software projects means actively working with uncertainty rather than avoiding it. Two strategies help with this: observing trends rather than individual values to identify changes in direction early on, and planning deliberate steps that do not lead directly to the goal but instead generate knowledge. The greater the uncertainty, the more gaining information matters over efficiency.

Key Takeaways

  • Bug trends provide more guidance than individual bugs because they show whether a system is currently deteriorating or recovering, without requiring you to chase down every single case.
  • Stagnation does not work as a robustness strategy: Those who freeze a system instead of adapting it consume their resources on the spot and lose out in the long run.
  • Deliberately deviating from the direct path—for example, taking a 90-degree turn, as moths do when searching for a mate—does not optimize efficiency but rather the quality of information, and leads to the goal more quickly.
  • Hypotheses are only useful if the goal is to falsify them: Those who actively seek to refute them cut off entire decision-making branches instead of working their way through the entire tree.

Why Nature Is the Better Teacher for Complex Projects

Nature is well-practiced at dealing with uncertainty. Animals live in large ecosystems, interact with other species, and their environment is constantly shifting. Volatility isn’t an exception there—it’s the norm.

It is precisely this skill set that is becoming increasingly important in software projects and companies. The geopolitical situation has a direct impact on markets, the range of possible methods and technologies is vast, and many teams are struggling with the question of where to even begin. Anna Melbinger, a physicist with ten years of IT project experience, draws a parallel here: The processes that nature has developed over a long period of time are almost always aimed at remaining robust and coping with change.

It’s important to distinguish this from bionics. Airplane wings modeled after bird wings, the lotus effect, swimsuits inspired by shark skin: this is the mechanistic approach, in which something is replicated that looks like nature. What’s more exciting is the “how.” Not copying the form, but the strategy biological systems use to make decisions when faced with poor signals.

Uncertainty Is a Factor, Not a Flaw

Uncertainty cannot be eliminated through development. In software testing, there’s a notion that good development produces no bugs. That’s nonsense. Systems are too complex; in the end, there’s always some residual uncertainty.

With AI, this is amplified. In addition to real bugs, there are “hallucinations”—that is, malfunctions that are intrinsically embedded in the system. Anyone who wants to avoid this is fighting the wrong battle. It makes more sense to accept uncertainty as a given and adopt methods that work with it.

Agile methods are based precisely on this idea. “Inspect and adapt” is, at its core, an attempt to foster adaptability and a willingness to learn. At the basic level, this works. However, Anna argues that this principle must extend much further—all the way into management decisions—rather than stopping at the team boundary.

Look at changes, not snapshots. Some bacteria want to swim toward a sugar source but can’t measure the difference between front and back—it’s simply too small. Their solution: simply start swimming and measure the change along the way.

If conditions improve—that is, more sugar or fewer pollutants—the bacterium swims longer in that direction. If conditions worsen, it changes direction more quickly. Every now and then, it changes direction deliberately to avoid running into a dead end. What matters isn’t the absolute measurement at a single point, but the direction of the change.

This leads to a simple, often underestimated implication for projects: Trends tell us more than individual values. Those who chase after individual bugs in project management gain little meaningful insight. The bug trend, on the other hand, shows whether the situation is taking a turn for the worse or whether the team is resolving issues faster than new ones arise.

I think that sometimes bug trends are much more valuable than the bugs themselves. — Anna Melbinger

Burndowns already do exactly that. Anna advocates applying this principle more often. A velocity trend is often more meaningful than velocity alone because you can intuitively see right away where things are headed. People process visual trends quickly and can tell at a glance whether something is getting better or worse. Practical advice: Add a few more trends to your dashboards.

A second point lies in the “bacteria strategy.” Standing still does not equal robustness. Anyone who believes that being robust means not moving or changing is heading for trouble. The bacterium that stays put consumes all the sugar in its current location and dies. Movement, in this context, serves to generate information.

How Moths Show That Deliberate Detours Pay Off

Sometimes the fastest way to a goal is a deliberate step to the side. Male moths search for their mates solely through pheromones wafting through the air. Wind and obstacles turn this into an extremely noisy signal.

Unlike the bacteria, moths don’t just follow the direction; they occasionally make a deliberate 90-degree turn and move off to the side. From a mathematical perspective, they are actively optimizing the information they receive. They’re conducting testing to determine how good the current direction really is.

To illustrate: When moving uphill, the bacterium slowly spirals upward; although it notices that conditions are improving, it takes forever. The moth turns 90 degrees, realizes that the path is going down here—so it must go up there—and reaches its destination much faster.

The difference between the two strategies lies in the use case. For the moth, the outcome is binary: if it doesn’t hit the target, there will be no offspring. The environment is extremely noisy, and the risk of missing the target is high. The bacterium is satisfied as long as it finds something to eat and things are getting better.

Applied to our context, this means: Sometimes it’s worth actively doing something that doesn’t lead directly to the goal, just to generate knowledge. We tend to want to increase efficiency at every turn. The deliberate step to the side goes against this reflex and can still lead to the goal more quickly.

Specific examples of this:

  • When faced with conflicting customer feedback, don’t randomly optimize in one direction; instead, build a mini-mock first to analyze the actual problem.
  • When there are conflicting signals in the retrospective, don’t implement either one immediately. Often, both sides mean the same thing, but for very different reasons.

Optimize for Knowledge First, Then for Efficiency

Which strategy is appropriate depends on the level of uncertainty. If uncertainty is high and the risk of missing the target is great, “Moth Mode” is the right approach: gather information before optimizing. Anna calls this “Infotaxis.”

In practice, this means not thinking in terms of milestones and project plans at the beginning, but rather in terms of decision points. What lies beyond a decision point often cannot yet be planned precisely. The goal is to have enough information to make a decision.

Once the team is on track and knows the playing field, it’s time to optimize. Then it’s important to improve sprint velocity and fine-tune the details. Not before. There’s no ready-made template for this. Both modes are real, and you have to actively decide which one you’re in at the moment and consciously switch between them.

Formulate Hypotheses to Disprove Them

Work based on hypotheses, but with the goal of falsifying your hypothesis. Some people shy away from hypotheses because they fear they’ll be biased by them. The point is different: quickly form a hypothesis that explains what you’re currently seeing, and then try to disprove it.

The benefit becomes clear in complex situations with huge decision trees. You don’t go through them all the way. Instead, you ask the questions that will cut off an entire branch if the hypothesis is proven wrong. That saves you time.

This takes courage, because a false hypothesis will quickly be exposed—and that can be briefly uncomfortable. Karl Popper provides the foundation for this approach. Those who set out to fail—in the best-case scenario—end up with what remains and can then optimize that specific area in depth.

Share this page

Related Posts