Agile methodologies are designed to cope with changing business realities. Not as commonly stated changing requirements.

Its a subtle difference but one which it sounds to me is important in your case.

A waterfall approach would be to collect read all the documents (make a plan) before begining work (implementing the plan).

The risk in business with that approach which agile addresses is that during the implementation or later stages of planning, something happens in the real world which invalidates the plan. Say a deal falls through, or a new market opens up, and hence the whole project fails.

Agile addresses this by doing small bits fast. But each bit delivers value because the state of the world is known at that time. You can clearly see if the bit of work is correct or not. If something changes later the work might lose value, but the pace of change is set by real world events. Events which cant be planned for.

In your situation though the changes happen at the pace at which you read and understand the documents. A known task that will be finished prior to the end of the project.

So a small bit of work delivers no value for you if it is wrong, you wont know if it is right untill the end and potentially has NEGATIVE value!

For you, Agile is a high risk approach. essentially gambling that more bits will luckily turn out right than the time you spend fixing the wrong ones.

I would suggest you read all the documentation first and then do the work.

Agile methodologies are designed to cope with changing business realities. Not as commonly stated changing requirements.

It's a subtle difference but one which it sounds to me is important in your case.

A waterfall approach would be to collect read all the documents (make a plan) before beginning work (implementing the plan).

The risk in business with that approach which agile addresses is that during the implementation or later stages of planning, something happens in the real world which invalidates the plan. Say a deal falls through, or a new market opens up, and hence the whole project fails.

Agile addresses this by doing small bits fast. But each bit delivers value because the state of the world is known at that time. You can clearly see if the bit of work is correct or not. If something changes later the work might lose value, but the pace of change is set by real world events. Events which can't be planned for.

In your situation though the changes happen at the pace at which you read and understand the documents. A known task that will be finished prior to the end of the project.

So a small bit of work delivers no value for you if it is wrong, you won't know if it is right until the end and potentially has NEGATIVE value!

For you, Agile is a high risk approach. Essentially gambling that more bits will luckily turn out right than the time you spend fixing the wrong ones.

I would suggest you read all the documentation first and then do the work.