A funny thing happened to me last week.

As I was driving to work, I was listening to another brilliant podcast from Manager-Tools on Assumptive Goal Settings. The curious name (for me, at least) is actually something we’ve done before. AGS is about reaching a goal, when  you don’t have a clue how to get there. To summarize, you start at the end, assume you’ve already got there, then work out what steps you took in order to get there.

(The main reason behind this, is that if you’re using your current state as a starting point to reach a high goal, you’ll probably not get there, simply because it requires doing things differently than what you’ve done until now. If you start at the end in mind, disregarding where you are right now, you’re more likely to think outside the box, think of new ways to be more productive, get more sales or whatever your goal is.)

Why is that funny? Because that same day, we’ve looked back at the aftermath of such an exact meeting we had a few months back.

Prognosis? Not good. It’s true that you need to plan in the end in mind, but you also need to check if your plan is working out for you. If it’s not, it’s time to re-plan.

For the little agile person in you this may seem obvious: you always look for feedback on your activities, and tune your behavior accordingly. Agile methodologies tell us that in order to be agile, you need to shorten the feedback cycle. That’s how we got retrospectives, demos, automated unit tests, stand ups – practices that make sure that if you’re out of bounds, you’ll know quickly. You can then adjust.

All are still valid. But we need to remember that not all processes are short. That doesn’t not mean they have to suffer from lack of feedback. When you have long processes, fit for a higher goal, plan check points for checking how you’re doing.  And then adjust.

You can be agile over the long haul too.

Are you applying agile practices for long processes?