AnswerBun.com

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

Software Engineering Asked on December 24, 2021

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

4 Answers

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.

Answered by JimmyJames on December 24, 2021

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.

Answered by Bryan Oakley on December 24, 2021

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.

Answered by Christophe on December 24, 2021

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.

Answered by Telastyn on December 24, 2021

Add your own answers!

Related Questions

Ordering of analytical events

1  Asked on February 26, 2021 by toshakins

     

Is gRPC a good choice for my scenario?

0  Asked on February 17, 2021 by leonardo

   

Are noncontiguous arrays performant?

5  Asked on February 14, 2021 by noisecapella

 

Achievement System based on many past records

4  Asked on February 9, 2021 by miguel-stevens

     

Rest API for multiple applications?

1  Asked on February 5, 2021 by programer

   

Ask a Question

Get help from others!

© 2022 AnswerBun.com. All rights reserved. Sites we Love: PCI Database, MenuIva, UKBizDB, Menu Kuliner, Sharing RPP, SolveDir