Iterations: An iteration is one feedback cycle we use, and one of the larger-grained ones. At the end of the iteration, we demonstrate the results to the customer and get feedback about what we did right/wrong and what to focus on next.

Stand-up Meetings: This is another feedback cycle to hear from the workers in the trenches what problems and impediments there are. This typically is setup to happen daily.

Continuous Integration: This is a feedback cycle that gives developers feedback on not just whether or not what they just coded works, but how well it does/doesn’t fit with what everyone else just implemented. It happens at least a couple times per day per developer (if they are practicing CI properly, and not just doing daily/nightly builds)

Test-Driven Development: This feedback cycle forces one to first validate their thinking about the test (even watching it fail first) before trying to write the code that passes it. As far as knowing what you’re supposed to be trying to do, this forces that to happen at the front of the programming task, in terms of understanding the requirements very precisely, and designing for testability. It also forces the granularity of this feedback cycle to be pretty darn small (often just hours, or less).

Pair Programming: This is the most fine-grained of all the feedback loops mentioned above. It gives that second pair of eyes whose purpose is not to try and co-author the code so much as to ask questions about the clarity, correctness, necessity of what the programmer is writing, and maintain the strategic direction of that effort.

Every single one of the above are feedback loops that are set-up to “sense” a problem/opportunity. Each one of them goes thru the agility cycle at its own level-of-scale. And each one of them requires being able to “make sense” of the problem/opportunity after you’ve sensed it.

That’s the second step of the agility cycle, the part I called “seeing the problem in the context of the whole”. Because, youre right, it’s not enough to just have have a regular knowledge-validation indicator of feedback that something needs to be addressed, you have to remember to “keep your eyes on the prize” when considering what the heck to do about it. That’s why we have to think strategically, about the end-goal before adding that unneeded abstraction or anticipating that not yet high-priority requirements, or solving that seeming urgent build-breaker with a band-aid that actually makes things harder for the next “consumer” downstream in the process.