Survival Rules and the Lamp Lighter

By clinging to practices that “worked” (or at least mitigated risk) in the past, the organization makes it harder to adopt agile by making it more difficult to iterate and deliver incrementally. Why do organizations do this? While it might seem that someone wants to sabotage agile adoption, this usually isn’t the case. Agile approaches require working differently and that the stakeholders trust each other. Change and trust are both hard, especially when you are on the line for meeting a commitment.

Survival
Standards and conventions, or “orders,” can be helpful to working effectively, but it’s important to review those orders from time to time to see if they still apply. When a way of working gives us predictable results, we tend to want to continue to use it, even when the context changes.

For example, detailed specification might give us a certain level of comfort, even though much of the specification is speculative—or even fictional—and won’t represent the final product. Having that specification might give us the security that, even if we can’t meet a goal, we can explain why we missed it in a way that stakeholders will accept. It’s hard not to want to continue to use these survival rules as they are. As Jerry Weinberg writes in Quality Software Management: First-Order Measurement [3]:

Survival rules are not stupid; they are simply over-generalizations of rules we once needed for survival. We don’t want to simply throw them away. Survival rules can be transformed into less powerful forms, so that we can still use their wisdom without becoming incongruent.

“Survival” sounds a bit strong until you consider that the motivation behind working a certain way is often a desire not to fail, and sometimes failing is scarier when you are not following established practices. The context behind an agile approach may be different from the context behind your current approach, and the when the context changes, the rules need to change as well.