Fixed cost project in agile

Short answer: Don't.

If you absolutely have to, sure you can. Have a look at Money for Nothing and Change for Free.

Yes, it is possible, as long as there is an overall understanding of what "Agile" is.   Ensure that all decisions and processes adhere to or support the Agile Manifesto and at least one of the 12 Agile Principles.

To answer from a Scrum perspective, you can have a fixed duration (target date, time-boxed sprints), fixed quality (meet DoD), and fixed cost (# of Scrum Team(s) members, operational expenses, etc.).   

The main item under typical project constraints that can vary under Scrum is Scope.   By your target date, you will have delivered a certain % of project functionality.   

Ideally, that number will be 100%, but because of the empirical nature of Scrum, and shorter delivery cycles and feedback loops, the scope could very well change throughout the life of the "project".   However, you should be assured of having delivered the most critical pieces of functionality, and if anything remains to be done by the target date, it should only be low-priority items (where they may even be identified as unnecessary).

> Can we work on a fixed cost project in agile?

If a team is happy to proceed iteratively until the money runs out, and the Product Owner is competent to organize the Product Backlog and maximize the value delivered, then yes.

Thank you all for your valuable comments. It is clear that we can work on a fixed cost project but what about the scope of the project? I mean both cost and scope should be fixed?

Let say cost is fixed and scope is variable so I think it will  not be profitable for the organization  and also if we fix scope so I think fixing of scope is not agility.

Your comments please?

Saying that scope is fixed doesn’t necessarily mean a great deal. It could just mean that the features identified so far are mandatory. During refinement, options can emerge.

On the other hand if “fixed” means that no increment will be released until substantial work is completed and batched up, then agility may be compromised accordingly.

In Scrum each Sprint increment must be potentially releasable and of value. In my experience, as long as that condition is satisfied, people can make whatever claims they like about Product Backlog scope being “fixed”. Maybe it is and maybe it isn't. Ongoing refinement will tell. In the mean time work will be delivered, value maximized, and lessons learned.

In agile, we dont have requirement documents ( SRS or FS ), we only have product backlog and this product backlog is a living document. Things can be added and removed from it.

So again my question is that how can we fix scope if we dont have all the requirements in beginning?

or to start a project in agile we should have all the major functionalities in our backlog?

I think before the team starts sprinting, the product owner should come up with a list of PBIs, these are the most important (mandatory) ones - the core of the system (bare minimum). Once this list is available and has been appropriately reordered, release planning can be done at least for the next 3 releases.

The team starts sprinting, picking the most important items first. I think the initial estimates might be little vague (or on the higher side perhaps ) depending on the uncertainty around the requirements and technological challenges if any. So, the initial team velocity might be a bit low. Once the team gets a couple of releases out the door and confidence boosts up they gain momentum; velocity goes up. This should now give everyone a fair idea as to when the project will get over.

As the team delivers and stakeholders get an initial impression about the system; they might share their feedback. Additional PBIs might get added to the backlog.

So, yes scope is little bit difficult to envisage at the beginning but once the core functionalities have been identified I guess job is almost done. Once these have been delivered and system is live, it will enter maintenance mode (with reduced headcount perhaps) and the other features can then be added in regular increments.

Experts hope I got it right.

If scope has to be locked down, a "Discovery Phase" may be the way to go (yes, yes I know it has the word "phase" in it). During that phase, PO and developers collaborate with users and other stakeholders to create an initial Product Backlog.

It is important to note that the Product Backlog is still subject to change! The discovery phase allows you to gain a first overview of what it is you will be building. As the product development moves along and you learn more that Product backlog will change, so your contracts will still need to account for that. That is where the patterns I posted earlier come into play.

Ultimately, I believe that fixed-scope-fixed-price projects are an impediment to agility. However, they are a reality for many of us right now and we need to be equipped to deal with them accordingly.

I agree with IAN. Fixed cost agile project will be a nightmare. If a client is coming in with a fixed budget and looking for an absolute end date my spider sense would tell me to have a sit down with them and set expectations.  OR not even go agile but use the old Waterfall method or something agile like. 

Thanks a lot everyone for your valuable feedback.