Emergent Requirements

Dec 7th, 2002 by Tony in Questioning XP

Extreme Programming projects do not try to produce a detailed requirements document and then freeze it. Instead, the Onsite Customer is actively encouraged to steer the project by changing his mind about what exactly it is that the team is supposed to deliver.

By freezing requirements, a team is choosing to delay when it recognizes that the requirements have changed. The longer the period of the requirements freeze, the more likely that when the application is eventually delivered it will not match what the users really need. It may, however, still be a reasonable fit, allowing a new project to start to delivery additional functionality while the users happily work with the first version. For most purposes, however, if an application does not meet current requirements it is effectively a buggy application.

Slow-moving environments lend themselves to requirements freezes; fast-moving environments do not. The difference is that between efficiency and effective adaptation. In a nearly static environment, it makes sense to optimize for efficiency, so requirements can be carefully documented and baselined. In a fast-moving, dynamic environment, optimized for efficiency is completely the wrong strategy; effective
adaptation is a much better option. Rather than try to control the changes, we must instead strive to respond rapidly to each change as it occurs.

— Pete McBreen, Questioning Extreme Programming, Chapter 16


  • This is akin to adaption to environmental changes in biological systems. If the changes are sufficiently slow then an organism can optimize to conserve energy and “optimize for efficiency”; however, in a rapidly changing environment, such overly “specialized” organisms fail to adapt and thus are ill suited to survive.

    However, a rapidly changing environment should not be looked on as some sort of virtue as it (as in biological systems) inherently is a destructive and often energy wasteful system that stresses the biological systems to the point often of temporary collapse.

    Too often rapid change is lauded by those who think it is more desirable than the other extreme, bureaucracy, standards, and process. The truth is such extremes are just that, extremes of the pendulum of what is perceived is “best practice”.

  • […] rather than specifiable. I think this is a very good way to see it, but please also consider that agile methods often practice a freezing of requirements. So, when you use agile methods you would normally not allow changes to the requirements during an […]