I have been reading some similar questions here but they are not the same. The project we have inherited from our partner has fixed scope and a fixed deadline to deliver. We are now thinking about way how to manage and agile seems to be the way (providing the framework). If there is basically nothing left to juggle with, I would say we still could benefit from e.g. Scrum and its processes just to have some management in place. It will not be really agile (in its true meaning) but I cannot see any better way how to that. Waterfall does not make sense as we have cross-functional team where our testers immediately test tasks completed. I would be extremely grateful for suggestions.

EDIT: I will repeat - I am not asking about estimates etc., the project is in its 70%. I am asking whether an agile approach could help to manage the execution - there is a cross-functional team at hand, so waterfall does not make sense (tester could work right away on completed features).

  • 1
  • see also: How to sell Agile development to (waterfall) clients
    – gnat
    Jul 22, 2016 at 14:32
  • 1
    Can you build the scope in time at all? That should be your basic management issue. How you do it comes after that initial question has been answered. Jul 22, 2016 at 14:33
  • Embarrassing question: is it that you've started agile and after 70% you need arguments to justify ? Or you've inherited a desperate project at it's 70% and want to know if you can save it with agile ? By the way: 70% of budget, 70% of schedule or 70% of features implemented ?
    – Christophe
    Jul 22, 2016 at 16:57
  • @Christophe The latter. We inherited a mess and try to save it. People are demotivated, stressed..you can imagine. 70% is done, budget spent (but that is not important for management now, i.e. there is still budget), deadline is fixed and scope must be delivered all.
    – John V
    Jul 22, 2016 at 16:59

4 Answers 4


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.


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.

  • 9
    "But constraints don't kill project[s]": While the concept of the triple constraint is valid, it's wrong to extrapolate that you can always meet two of the constraints by adjusting the third. For example, you can't develop an air-traffic control system in a week by throwing a million developers at it. There is a hard lower bound required for a feature. If the timeline doesn't accommodate the minimum time required to implement the features, it's hopeless and bound to fail. There's no amount of risk management that can make the impossible possible.
    – JimmyJames
    Jul 22, 2016 at 16:18
  • 1
    Constraints don't kill the project, because at the begin, you elaborate scope, schedule and costs. If these wouldn't appear realistic (too expensive , not enough time..) you wouldn't even start the project ! What happens usually is that after a while it appears that it's more complex than expected, or quality issues arise, or original estimations appear biased. All these risks make that initial constraints are no longer feasible. Reread my post: I never claimed that it would be possible to adjust only one constraint. It's just that you won't have to pull t the plug just because of agile.
    – Christophe
    Jul 22, 2016 at 16:46
  • 1
    @Christophe Actually, I think it does make sense to create my own answer here. I didn't think I had enough to add to the other answers initially.
    – JimmyJames
    Jul 22, 2016 at 20:53
  • 1
    @JimmyJames - I can adjust cost to the point where I could just buy an air-traffic control system in a week and wouldn't need to build it. Bill Gates bought DOS from some guy and turned-around and licensed it to IBM. I'm sure they were astonished at how quick it got delivered.
    – JeffO
    Jul 28, 2016 at 12:26
  • 1
    @jimmyjames - any company can be bought.
    – JeffO
    Aug 8, 2016 at 0:42

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.

  • 2
    Exactly. This isn't an aspect of Agile, it's a fundamental aspect of reality. Agile simply tries to address it.
    – JimmyJames
    Jul 22, 2016 at 14:22
  • 4
    Guys you are missing the point of the question - sure its not direct aspect of agile, but it asks whether Scrum or other agile approach can be used to help manage the project..
    – Melioer
    Jul 22, 2016 at 14:45
  • 7
    @Melioer The question asks, "Is it possible to do X in agile", this answer answers how to do X in the general case, whether using agile or not, because the answer isn't affected by whether you're using agile or not.
    – Servy
    Jul 22, 2016 at 14:57
  • @Melioer - the the "Or what else?" leaves a lot of room in answering this question and doesn't limit it to an agile only answer. Sometimes the point of a question becomes moot and the best answer is to consider something else.
    – JeffO
    Jul 28, 2016 at 12:39

Yes, an agile approach could help you get the work done1. 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.

1 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.


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.

  • While I'm not a fan of Scrum either (my first exposure to Agile was via Extreme Programming, and I still prefer that approach to the others), I'd point out that having people who understand the process is the most critical thing. So if anyone on the OP's team has experience working with Scrum, and nobody has experience with XP or Crystal or Kanban or whatever, then Scrum is probably the best bet. All agile methods, in the end, encourage adaptation, and reading about the features of another one and adapting towards it could be a good future goal, but use what you know to get started.
    – Jules
    Jul 23, 2016 at 9:18
  • @Jules I agree with your main point but I don't think scrum is a good choice based on the information given. If you have a bunch of demoralized people on a death march, do or die project and start asking them to provide estimates and 'make commitments' to finish something in the Sprint, you are simply going to make them more cynical. Anyone with brains figures out pretty quickly that if you are being asked to commit to an estimate, you'd better pad the hell out of it. Estimates have value but they don't produce working code. If you are short on time it's better to just get people working.
    – JimmyJames
    Jul 24, 2016 at 0:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.