Survival Rules and the Lamp Lighter

Agile Values
As listed in the Agile Manifesto [2], agile teams value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Processes and tools, documentation, contract negotiation, and plans are part of the agile process, but they only important to the extent that they aid the things that help teams be agile: interactions and collaborations that help teams deliver working software that meets customers’ changing needs.

The Neo-agile Lamp Lighters
Many teams new to agile resemble the lamp lighter in that they try to follow standards and practices that no longer make sense in the context of an agile process. For example, the team may use good technical practices, but the requirements management policies are too heavyweight to keep the backlog populated or the release management policies discourage frequent deployments, leading to code-line policies that place a drag on the team. In addition to organizational resistance to change, some team members might also use development tools and practices that make it hard for other agile practice to work as well as they could.

While it’s possible to use some agile practices without fully embracing agile values, agile is really a system-wide change. Agile development practices work best in the context of agile planning practices, and applying agile methods successfully in one part of the lifecycle will highlight roadblocks in another. The improved visibility of problems and roadblocks can be a challenge, causing some to revert to practices that support documentation and justification rather than embracing the failures as an opportunity to improve. But, the basic context and values of agile methods are different. In agile projects, the working software and the degree to which the software meets customers’ needs matters. Documentation and specification matters only to the extent that it helps to deliver software. So, those old practices that have a sole goal of traceability no longer make sense.

Traditional software development practices focus on reducing uncertainty early. Often, this isn’t possible, so agile practices manage uncertainty by embracing the inevitability of change. Rather than requiring detailed specifications that will guide teams, agile teams err on the side of lightweight requirements and frequent iterations where product managers review the working software. Rather than extensive integration cycles, agile teams spread testing and integration throughout the development process so that problems are detected early.