Just enough up-front thinking and nothing more

 

I happened to run into this discussion thread and the most interesting discussion was on the topic of just “enough up-front thinking” which this poster David Chelimsky, responds:

In regards to enough up-front thinking, there are a series of scopes to which it applies. When you’re in a release planning meeting you want to do enough up-front thinking to be able to start working on the release with confidence. This will likely include considerations like business strategy, marketplace, etc.

In an iteration planning meeting, the scope is narrower. The goal is still to do enough up-front thinking to start working on the iteration with confidence, but the considerations tend to more about the functional details of specific features that we’ve already selected in the release planning meeting. Perhaps you don’t do separate iteration and release planning meetings, and that’s fine, as long as you recognize that even in the context of a single meeting, the concerns for release planning are wider than the concerns of iteration planning.

Within an iteration the scope is narrower yet. You still want to do enough up front thinking, and perhaps you’ve recognized some design challenges that are presented by the features slated for the current iteration. In that case you call a design meeting with your peers. The goal here is stay within the scope of what you’re doing this iteration.

Then, when you get down to the minute to minute practice of doing TDD, the scope is even narrower. The focus is on objects and how they respond to events in given contexts.

At each level, we’re informed by what we know from the wider scopes, and we can’t help but consider the things we know.  We’re human, after all.  The trick is to avoid the temptation of considering the things we don’t know or are not relevant to the task at hand.

I like this idea as it outlines a form of “mental agility” that forms the basis of acting on information that you obtain “just in time” to be able to get work done.  But as the post outlines, it is still driven by the overall goals of the project and the key is to eliminate the fluff while focusing on the meat.  As I’ve critiques in the last couple posts, Agile is too focused on processes and not enough on the thinking and most importantly, the behaviors you need to adopt in order to have true agility.

Look forward to thinking “just enough” about this and posting more about it!