QA dilemmas in Agile environment

I have heard many times that practicing agile raises some dilemmas when trying to keep the QA standards.
There are few examples mentioned below:

1. Little documentation and lots of changes that are imposed with direct verbal discussion between product manager and developers, makes it hard for QA to write their test documents and keep them updated.

2. The "Team" needs to deliver product in time , yet lots of tasks are completed simultaneously at the last moment. Little consideration for the amount of time QA needs to give a green light. At this stage QA are alone and "Team" is busy with future tasks.

By reading above points, first thing comes in my mind is that it is an execution of a waterfall project disguised as agile. A number of things stood out that are not in alignment with an agile project:

• Little documentation- Agile does not mandate little documentation. It says use the type and amount of documentation you need, but no more. If the documents to which you are referring are critical to the completion of the iteration then the time necessary needs to be accounted for in your iteration planning. The idea though is that documents should be used to capture the results of a discussion, but the discussion is where the team does most of their learning and uses the documents as a reference when necessary. The team should ask themselves what value the documents are adding and are they worth the time they take. Can the detail in the document be reduced? One of the things a team I am working with discovered was their test cases were WAY too detailed. They contained every single step a tester needed to go through for each test case. When they asked the testers why they needed to detail every step for a system they all knew very well they said “we don’t need this detail, we are only doing it because our process said we had to”. The test cases were shrunk to about 20% of their normal size.
• Last point makes brings up a number of items that sound very waterfall like:
o QA left alone and “Team” is busy with future tasks – There is one team on an agile project. Until the iteration is done no one on the team should be working on future tasks. One of the main focuses of agile projects is to get one thing completely done before moving on to the next. What you described sounds like a classic waterfall approach. Why aren’t the other members of the team assisting with the testing to complete the iteration?
o Tasks are completed at the last moment – agile projects are feature focused rather than task focused. If everything being developed is not being tested until the end of the iteration then you are following a sequential process and it will be highly unlikely you will realize the benefits associated with agile. You ideally want to be doing testing on features throughout the entire iteration. This requires planning and good selection of items from the backlog to ensure that you will have flow of feature completion throughout the iteration.
o QA giving the green light – Why is QA giving the green light? There should be a definition of done that defines the criteria of a backlog item being done. The definition of done should be used during the planning to make sure the tasks necessary to cover all the criteria are accounted for.
• Getting teams to work in unison rather than in a sequential manner is hard, but it is critical to achieving the benefits of an agile approach.

~SA