Is fixed-scope, fixed-time really impossible to deliver in agile? Or what else use?

Given the details you have provided:

• Fixed scope
• Fixed deadline
• Demotivated team
• Project is a mess

I think agile makes sense, but not scrum. You probably want to do something more lightweight like Crystal Clear. This is briefly described as:

The lead designer and two to seven other developers … in a large room or adjacent rooms, ... using such as whiteboards and flip charts, ... having easy access to expert users, ... distractions kept away, deliver running, tested, usable code to the users … every month or two (quarterly at worst), ... reflecting and adjusting their working conventions periodically.

The scrum methodologies are designed around being able to project delivery timelines based on prior experience. That is, once you start producing real working solutions, you use the data generated by that in order to predict the time it takes to produce more. You keep doing this and you get more data and use it to measure trends.

Based on what you are saying, it doesn't seem that predicting outcomes is very important for your project. What's important is getting it done. You say it's 70% complete which in Agile terms means 70% of the features are in production or production ready (the former is more reliable than the latter.) If the deadline is a long way off (a year or more), you might want to begin doing scrum. Otherwise do something much more lightweight.

This is all presuming that you have no room to negotiate scope or delivery. If you can, it's a completely different story. Usually, in these situations, delivery is going to slip and ultimately that will force some sort of discussion. Usually the client prefers to get something rather than litigate and more time will be given.

Yes, an agile approach could help you get the work done¹. At its core, scrum provides a way for a group of motivated individuals working together to deliver a product. Scrum provides a framework for breaking a larger body of work into smaller pieces (epics, stories, tasks) and then working on those smaller pieces.

Scrum also provides a framework for the team to constantly improve, which may also help get the work done. Finally, it makes the process visible, so that stakeholders can see how the project is progressing.

¹ An agile approach will help you organize and do the work, but it can't guarantee you'll finish on time or on budget. Agile is less focused on budgets and deadlines, and more on delivering the right product. That being said, even with a fixed scope and fixed deadlines, as a tool for organizing your team to do the work, it can definitely help.

Time, budget and scope

Every project, whatever life cycle approach it uses, has to cope with the triple constraint of cost, time and scope. In your case time and scope are fixed. You say nothing about cost, but as you've inherited this project from your partner, I fear that there might be a fixed (or at least capped) cost as well.

The unexpected risks

These constraints can make project difficult and your life miserable. But constraints by themselves don't kill project. It's risks that kill projects : risks that were not taken into account when budget, schedule and scope were defined, or risks that occur and make the constraints unsuitable.

Following risks lead frequently to failure:

• risk of quality: If you find out at the end of a project that there was a fundamental misunderstanding about the requirements or the customer's expectations, the cost and time needed to correct such errors can lead to an expensive total failure!
• tunnel effect without feedback: If you enter in a longer activity, it might be like a tunnel: you might find out at its exit that you're in the wrong place and that the project was completely underestimated. The more time past in the tunnel, the higher the risk, and the unhappier the customer when you'll tell him the uncomfortable situation.
• self-fulfilling prophecy: with longer timeframes, there is a risk that tasks take all the planned time including margins that you've added in the schedule. For example people might take time to draft and redraft a perfect design document. But this precious time might lack in the end. In traditional project management, the critical chain (not path!) methodology could address this issue. But short time-boxed goals used in agile methods reduce such effects in a much more efficient way.

Conclusion

An agile approach is in my view the best approach to anticipate and master the biggest project risks. It allows to address uncertainty early, to get constant feedback and tangible progress, and to react as fast as possible in case of any issue.

So agile is not the problem, it's part of the solution.

Additional remarks (sum up of comments)

For your project at 70% of completion, I believe that techniques such as a precise and transparent backlog, frequent short terms objectives with a weekly iteration cycle, and daily short standups should help to keep focus and get back on track. And transparency about achievements and work to do could restore trust.

At this stage of progress, it's difficult to add many new resources. It might also be counterproductive to start to learn a fully new approach with completely new tools. Adopt the agile core principles with pragmatism.

Final remark: it would be worth to get an understanding of what would happen in event of late delivery: will the company fail some legal obligations and go bankrupt ? Will there be penalties ? And same for scope: among all your features/user stories, are there some that are less critical that could in worst case be delivered after the go-live of the core functions ? All these could be useful for negotiation and damage control if in the end it would be required.

If you have fixed scope, and a fixed deadline, then the only thing you have left to play with is cost. You can throw more people at the problem (which doesn't really work), you can buy premade software, or you can sacrifice quality. ...Or you can change peoples' minds about the fixed scope or fixed deadline thing.

That's not an agile problem, that's a problem for all projects. Changing how you go about executing the project doesn't change the inherent constraints.