Notes:
Over the last decade it cannot have escaped the notice of software developers that there has been a move towards describing design ideas in “pattern form”.
There are several variations of the form in which the pattern is expressed, but there is also a lot of commonality. A pattern must describe:
The context in which the solution is applicable;
The forces to be resolved;
The plan, and trade-offs between the various forces: and,
The new context that results from applying the plan.
With a small change in terminology this is very like Polya's approach.
Patterns too often form part of a greater whole – a “pattern language” - that relates the resulting context of one pattern to the context of one or more others.
What I want to borrow is the idea that the “solution” (or plan) is only part of a greater whole. And to assess a solution we need to consider both the original context and the resulting context.
While the founders of the Agile movement are hopefully aware of the context in which their solutions are applicable they are often ignored by those in search of a solution. (This happens with design patterns as well, I often find the “Visitor” or “Singleton” solution applied without any reference to the motivating context.)