Agile & Optimal Foraging

Honey Bees are oft cited as a biological example of Emergent Behavior and Self-Organization (see my post Self-Organization: Flocks, Schools & Colonies). These examples provide analogies that help us understand team behavior.

Optimal Foraging Theory is derived from modeling organisms achieving the ultimate goals of survival and reproduction. Continually optimizing organisms forage to maximize their energy intake per unit time.

Surviving organisms search for, capture and consume food containing the most calories while spending the least amount of time. Mathematically, organisms adapt to maximize the ratio

E / (s + h)

Where E is the average caloric energy intake, s is the average search time, and h is the average handling time.

A presumed advantage of Agile over the Waterfall Model is the compression of the requirements gathering and Big Design Up Front phases into concise story creation, iteration planning, and time-boxed spikes. In the optimization equation, the focus then is on decreasing the denominator. The advantages of agile over waterfall degrade somewhat as the quality of story creation and planning decreases. This is because search and handling time typically go up (denominator) as story quality goes down.

In the honey bee analogy, the Product Owner is the Queen bee. She holds the group knowledge. The Developers are Worker Bees who perform tasks for the survival of the community. The Subject Matter Experts are male drones (essential but expendable after their duty is performed).

Role	Honey-Bee
Product Owner	Queen
Developer	Worker Bee
Subject Matter Expert	Drone

One of the biggest honey clumps in agile is how stories are conceived, fleshed out, and distributed to the developers. Applying the honey bee analogy to the reality of many agile projects, the queen either has defective DNA or too many responsibilities and, as a consequence, the worker bees are left idling.

The queen has too many responsibilities - After all, she's the collective consciousness of the team and she might not understand her role.

The worker bees are left idling - On many agile projects, developers spend too much time foraging (e.g., searching for digestible stories and handling project artifacts). This occurs due to poorly written stories (e.g., a story title with the word Placeholder -- and nothing else) and when stories lack a bullet list of what constitutes done - acceptance criteria.

Iterating Toward Improvement

To survive and reproduce as teams and as Agilists we must, in a sustainable way, continue to adapt so that we maximize the value ratio.

Caloric energy intake, E in the optimization equation above, being replaced with the third agile principle

Deliver working software frequently

Average search time s and average handling time h, being replaced with second half of the third agile principle

. . . from a couple of weeks to a couple of months, with a

preference to the shorter timescale.

Time-saving gains are still to be made in the denominator of the optimization equation. Teams need better tools, better techniques, and a few tweaks to realize those gains.

Tools: The first generation of agile software tools are a collective hindrance (see Is Version One a Software Chindōgu?) Software teams need better collaborative tools. Improved automation of story creation is needed. For example, software that generate test methods for developers (e.g., Fit). Product owners need better idea aggregators (i.e., a glorified mobile To-Do app for the iPhone or for Android). Developers and Product Owners need software tools that encourage good habits and don't bog down progress with usability issues. The good news is that the software only needs to be better than index cards and Post-It notes. Why can't we do that? I am excited about the potential for the Google Wave platform to grow such collaborative tools (see Google Wave and Collaborative Projects).

Techniques: Several Agilists I respect, pooh-pooh the prescriptive language of Behavior Driven Development (BDD) because it is formulaic or because it is unnatural and not how product owners work. I find the formulaic language to be a helpful foothold for floundering Product Owners (the queen bees with faulty DNA or too many responsibilities) and certaintly more scrutable on a story card than the title Placeholder (I have seen this story title more than once). But BDD is another step toward automation. BDD encourages Product Owners to talk in terms of Roles or Personas and to talk in tests (acceptance criteria). Software automation of such standardizations - if done right - decreases forage time for those hungry worker bees, the developers.

Tweaks: Two rules derived from foraging decision-making that apply to story creation, tasking, and distribution:

Rule #1:

Never eat anything bigger than your head.

Rule #2:

Consume items that lead to the highest gain in Energy/Time.

That is, make sure stories are properly tasked and sized in bite-sized chunks. And, make sure stories are properly staged and prioritized.

Do you have tools, techniques, or tweaks that have helped you?