Is it possible to work in a fixed-time and fixed-price project?

1. Is it possible to work in a fixed-time and fixed-price project?

I'd say yes, however, there are a few things I feel would need to be true for it to have a higher chance of success. There should be little uncertainty in the scope and requirements of the project and there should be a low/no chance of changing requirements as time progresses. Is the work something that has been done many times before with another implementation that is largely unchanged from previous? 

2. Is it common in an agile project?

If you're considering an agile project my assumption is it's because what I've listed in the answer to number 1 are not true. Frameworks like Scrum will ultimately add overhead due to the constant feedback loops and create space for change in scope and direction based on emergent learning which may not lend itself well to a fixed time and price approach.

1. Is it possible to work in a fixed-time and fixed-price project?

Yes. Agility does not restrict this.

2. Is it common in an agile project?

I would say Yes. In fact, when you look at it from the perspective of Scrum, you are aiming to create a potentially releasable and "Done" Increment atleast by the end of the Sprint.

3. Does anyone have a link of reference?

I don't have a direct link, but you can research about the concept of the inverted iron-triangle of Agility. Basically, it talks about how cost and time are fixed but scope is variable.

So, to summarize, Yes, you can work in a fixed-price, fixed-time project as long as the people doing the work have the courage to forecast the scope of the work that can actually be completed within those constraints.

The time of a sprint is fixed (unless it is cancelled). The price should also be known in advance and will often be fixed.

A sprint can be seen as a single project, and arrangements can be made to invest in just one (or more) sprints.

1. Is it possible to work in a fixed-time and fixed-price project?

2. Is it common in an agile project?

3. Does anyone have a link of reference?

In Scrum, each Sprint may be regarded as a project. Focusing on the completion of work every Sprint helps empirical process control to be established. Sprints are always fixed-time and might reasonably be fixed-price.

If you're thinking of a project in a more traditional sense, see "Fixed Price bids. An open invitation to bribe, cajole, lie and cheat" by Gunther Verheyen: https://www.google.com/amp/s/guntherverheyen.com/2012/10/07/fixed-price-bids-an-open-invitation-to-bribe-cajole-lie-and-cheat/amp/

Agile or not, most organizations have fixed budgets, fixed delivery timelines, fixed resources and fixed scope. This is why many organizations who say they DO Agile, are just chasing the dream.

All companies have limited amount of money to invest. They all want to deliver soon, or at least before an end date. They have "just" to accept uncertainty and to welcome change in scope, as they learn about the product and its context as they build it.

You could start with a fixed price project to establish communication and collaboration as well as trust. This could be the base for future, not fixed price projects.

Thank you guys for your valuable thoughts.