Even in strictly Agile projects, the end user is not very well considered. In fact, the Agile practices don't mention explicitly interaction with end users.
As soon as the application is defined and a team is assigned the User Driven Development can start. Users can participate in the development process since primitive states. Follow what is being developed creates confidence and straights the collaborative relationship. More the users feel their inputs are being considered, more likely they are to continue providing it.
The Product Owner writes down the vision for the application and a statement that summarizes the Minimum Viable Product that was chosen to start with.
Lean UX practices are very well applied to this phase.
An iteration starts with the Improvements Meeting (or Kaisen Meeting).
Each developer writes down a story to work with on the current iteration and reads it loud in the meeting.
The story is open for questions from the participants (Development Team, Stakeholders, Users, Product Owner, etc).
After questions, everyone can assign a thumbs up or a thumbs down, depending if they agree if the story should be prioritized or not.
A discussion session can be opened in case of a thumbs down is assigned.
After a fair amount of discussion, if a consensus doesn't happen, the Product Owner can act as a judge and decide if the story is going to be developed or not in the current iteration.
The developers that didn't have the story prioritized can pair with another programmer in that current iteration.
A long time can be wasted when trying to estimate time and detailing the exact tasks that are going to be developed in an iteration. If the team can trust on the developers skills, each developer can task his/hers own stories just before or while they are actually developing it.
After the task definitions, the developers start developing theirs stories using the eXtreme Programming techniques as TDD, Pair Programming, etc. The status of the tasks should be continuously exposed on the wall, so the developers can follow each others progress all the time (not only on a stand up meeting). The main columns for the Kanban board are To Do, in Progress, Being Used and Wasted. There is no "Done" column, only the concept that the user is using the feature that was developed or not.
When developer finishes the tasks, a quality assurance professional can assign some basic needs for a story and if it passes the minimal quality conditions, the story can be deployed in the end user environment. The team can also assign one specific user to make preliminary tests on the story. If the story passes the first end user test, so it can be finally open for the other users, as soon as possible in the development process.
It is very important that the developer can observe the end users while they are using the new story. Observing real data and real users on a working software inside their own environment is priceless to developers. The psychological atmosphere that is formed in a moment like this provides unique insights to the developer with so much valuable information that no document and no intermediary can possibly describe it. (See: Genchi Genbutsu, "go and see")
"It is unacceptable to take anything for granted or to rely on the reports of others." (Jeffrey K. Liker, The Toyota Way)
"No amount of design can anticipate the many complexities of bringing a product to life in the real world." (Eric Ries, The Lean Startup)
The system must continuously collect metrics from the users. After each new story developed the average of use supposed to be increased or at least maintained.
Looking at the stories that are being used and those not, the analysis of the metrics should support the developers on deciding what they want to improve in the next iteration, ie, in which stories are worth working and what is not worth.