For years, working in a bottom-up manner has been seen as the ugly step-brother of the exemplary top-down approach. Going bottom-up was greedy, lacking direction, trying to achieve things now without thinking about the future (sounds like someone you know?). Instead the right way was orderly defining your goals, laying out a plan, refining the plan until you reached the state of simple steps.
Nowadays the bottom-up approach is rehabilitated. And this was a parallel development in different domains:
- GTD is a bottom-up-driven methodology (see the wired-article).
- Agile Processes value responding to change over following a plan
One of the reasons is that the pure top-down-approach relies on two things:
- You have to be good at planning (what people usually aren't, see Why Your Plans Fail)
- The target has to stay constant (which it usually does not - requirements change by a few percent each month)
Change happens. And it happens more frequently than you think and in another direction than you think. But change does not have to be a bad thing. Change can be an opportunity. And the "new" methodologies prepare you to grab those opportunities.
GTD gives you a "mind like water" to be ready for anything that comes up. You do not have to reorganize everything, you just create new projects and a few new "next actions" and weave them into the "stuff" you already had on your lists before the change. Your weekly review will help you to eliminate anything obsolete.
In Agile Software Development, you have working software that delivers as much business value as possible. You didn't allow technical debt into the project (constant refactoring). The continuing contact to your customers makes you aware of changes in their priorities as soon as possible. The technical base helps you to react as soon as possible, you don't have to go "all the way back" to the early waterfall phases. Instead your next iteration or scrum or whathaveyou will focus on the new features your client needs.
The theme is the same. Being well-organized in your smaller steps allows you to shift direction when needed. I think it was "Pragmatic Programmers" where I first read the comparison that developing software is a lot like driving a car: you don't determine an exact direction, set your wheel precisely and drive for miles with the steering wheel in this direction. Instead you point the wheel in an approximate direction, start driving and continue to adjust the direction very often in very small amounts. Obviously this involves frequently looking at the discrepancy between where you are going and where you should go.
But remember (teacher-mode on): this doesn't mean you can be unorganized and just label it "bottom-up"!