Mushroom Management

This one is not exactly about development, but the consequences are felt in the code too. There's a story called "mushroom management", when instead of a task you get requirements. And they come in pieces.

The name refers to how mushrooms are grown: kept in the dark and fed manure. Likewise, a team deprived of context is figuratively "kept in the dark", with information doled out in doses.

Symptoms

  • Instead of a task and a goal — a stream of raw "as-it-comes" requirements.
  • Context is revealed in pieces, "when the time comes".
  • The team learns about the real goals at acceptance tests.
  • Integrations break because interfaces were agreed on the fly.

Why it happens

Most often — from the wish to "not overload" the team, mistaken secrecy, or a poorly set-up requirements-gathering process. Sometimes because the customer doesn't know what they want and "doles it out in pieces".

Example

The "bad" version: the team builds the interface from an incomplete spec, and the contract changes at final acceptance:

# requirements arrive in pieces:
# 1) "make an application form"
# 2) "add an amount field"
# 3) "the amount must be in kopecks, not rubles"

The "good" version: the goal, context and acceptance criteria are known in advance:

# goal: accept a loan application
# criterion: the application is validated, lands in a queue, its status is tracked
# the API contract is fixed before development starts

How to fix it

  • Push for tasks defined with a goal and acceptance criteria, not "requirements in pieces".
  • Fix API contracts and interfaces before development.
  • Run acceptance tests and integrations against scenarios agreed in advance.