But now I'm no sure

What should you be doing if you want your sofware development project to a be a success?

Well you should be doing some flavour of Agile, and for me, that would be Scrum meetings (stand-up, show and tell, retrospective, planning) and some XP engineering practices.

But that isn't enough. You need to be doing things all the way through your project which reach out into the oranganisation that wants the sofware and explores their values and needs. You also need to be doing things all the way through the project that explore what the users and their values, wants and needs.

And exactly how that will happen will be different in every project.

Some things that I've seen work.

A weekly meeting with the primary stakeholder, where what's going to happen next in the project is discussed
A fortnightly meeting with representatives of the development team and the stakeholders where all the perceived risks to the project are discussed - and scored! So that a graph of the perceived risk on the project is produced.
A pattern for development of any major piece of functionality which goes as follows
1. Exploratory research with any user group which hasn't previously been contacted, to identify what they do, how they might use the system, what their fears, failures and frustrations are relative to the system.
2. From this identification of some specific needs that the system might address
3. Produce some designs that could address these needs
4. Test these with users
5. Did these designs work with users? If not make changes and go to step 3.
6. Implement the designs as working software.
7. Test with users
8. Report and/or demonstrate each stage of this process at Show and tells.

If you're doing this process right, it will be full of - ahem - tensions.

Exploratory research creates a ton of demand and vocal and effective advocates for the users and the organisation inside the team. Doing research like this throws you smack up against the law of contraints.

Whatever anybody else tells you, if you're doing software development, you have some kind of linear pipeline.

Exploratory research. Prototype design. User testing with protoypes Developing working software

All of those things come with their own capacities, their own timescales and their own preferred batch sizes.

It's tempting to think that there's a right timescale and a right batch size that will move smoothly through this pipeline. But uh oh. These are probably going be different for different projects and also different at different times in a project.

Really what you're looking for all the time as a project manager - and it's hell of a lot easier if the team can see it like this as well - is the signs that a batch is too big (can we make it smaller) or has too long a timeframe (can we make it shorter).

To make thing even more complicated, of course, there are the constraints of size and time on the whole project.

User research generates a wall of demands. The team needs a process and a consensus for limiting the amount of that demand that's addressed.