How to get productive on a project quickly (joining midway)?

One of the things I have been thinking of nowadays, is how does one join and start being productive on a project quickly, i.e. projects that have started sometime back and you join inbetween iterations (maybe after some release(s)).

One way is what I would term as top-down approach, start with understanding how the system works at a high level. This might involve things like understanding what are the various layers in the system, technologies being used in each layer, testing framework being used, Automated Acceptance Tests, build process, understand the various tools used for testing, development and deployment. Once you have some understanding of these stuff, you can move on lower to the implementation details. One disadvantage I see in this approach is sometime has to be spent before you actually start contributing to the project. Also after spending time on this exercise, you do not have the satisfaction of doing something useful for the project.

Another approach might be a bottom-up approach. Basically you start working directly on some Usecases(UC)/Stories. A pair (who is experienced on the project) can be of great help in disemminating the knowledge of the system. So if the UC/Story you are working on involves, say, some EJB Component Implementation, you start off doing construction on this part of the system. While doing this, you observe how the system works/interacts and gain an understanding of that part of the system. Certain degree of criticality helps in bringing out why the system has been built the way it is. A pair ensures that you always have someone to clear any lingering doubts. However, this also means that you understand only the part of the system that you have actually worked on, and may not have the big picture about other things. This can be a great handicap.

I basically prefer a more hybrid approach, in that you start off constructing some UC/Story, but also spend some little time understanding how the total system works. For eg. while you are implementing a UC/Story, you might spend sometime understanding the big picture of the web services part of the system, another day perhaps the data layer and so on. So you start contributing to the application in some small way by actually constructing something, and also understand the system metaphor. The confidence you get by actually contributing to the system building is a big booster (helps more than just understanding the system interaction at a higher level), and puts you on a firm foot in the project.

Though I have primarily been thinking from a developer perspective (short-sighted vision :-) ), I think the same could be extended to business and quality analysts. Any thoughts?