5

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

John V
  • 4,928
  • 1
    Possible duplicate of Is it possible to take a flexible agile approach to projects that require estimates of both time taken and time saved? – gnat Jul 22 '16 at 14:31
  • see also: How to sell Agile development to (waterfall) clients – gnat Jul 22 '16 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. – Luc Franken Jul 22 '16 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 '16 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 '16 at 16:59
  • Sounds like changing the culture is something that may help. Even if Agile weren't any better than anything else, for he sake of morale, it might just work. Happy people work faster. – Guy Schalnat Jul 22 '16 at 19:14
  • Fixed time, fixed scope (with fixed resources) is impossible to reliably deliver using any management methodology. The only real difference agile brings to this is that it discourages you from even attempting it; other methods will pad estimates with safety margins and so on so that failures are less common (but you end up paying more on average because you're paying for the safety margin which, if done correctly, doesn't all get used in >50% of cases), but agile methods provide transparency so that both the team and the stake holders know what the real estimate is. – Jules Jul 23 '16 at 09:08
  • @Jules that is not true. I have done tens of projects with both deadline and scope..its simple waterfall. – Melioer Jul 23 '16 at 16:03
  • @Melioer - the problem is that you might succeed a few times, but sooner or later the problem will be much harder than you estimated and will fail spectacularly. That's why I say reliably deliver. Waterfall style management of a project fails in about 18% of cases according to this survey, while Agile methods only 8%; the fact that Waterfall management often leads to attempts to fix time, scope and resources at the same time is probably one of the main contributors to that failure rate, IMO. – Jules Jul 23 '16 at 16:50
  • In waterfall, proving (unit testing is one way to go) and integration fall under coding, so when you say testers test completed tasks, what does that mean ? https://en.wikipedia.org/wiki/Waterfall_model – JeffO Jul 28 '16 at 12:45
  • 70% complete? Does that mean that 70% of the features are passing acceptance tests? The only measure of progress is completed features. – kevin cline Jul 24 '20 at 08:09
  • @kevincline That is rather a thing in an ideal world. In the typical project delivery, you need to measure completeness during the whole lifecycle. Unless you have the liberty while developing your own product, there is vast difference between everything developed but not tested and nothing developed at all. Yet from "Done" perspective, both are 0. – John V Jul 24 '20 at 13:10
  • @JohnV Zero is the right answer. The known value of unimplemented design is zero. The known value of untested code is also zero. It's not uncommon for a new developer to take over code said to be "almost done" and then to realize that the best thing to do is start over. Code that passes no tests is rarely the effort to understand it. This is why waterfall projects often fail so completely. There are no measurable deliverables until the end. – kevin cline Jul 30 '20 at 04:19
  • @kevincline Only in theory but we are talking about progress measurement, e.g. because of invoicing, resource burn etc. Reporting you have done 0 is just not accurate, the correct and accurate answer is e.g. 80 of stories are developed but not tested. I have witnessed many projects in top notch IT companies being managed in a hybrid mode, because this silly binary reporting is not suitable outside of product development, where you are free to do pretty much anything. But try that in a service delivery with a signed contract, fixed scope, deadline, and a customer. – John V Jul 30 '20 at 05:42

4 Answers4

24

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.

Telastyn
  • 109,398
  • 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 '16 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 '16 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 '16 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 '16 at 12:39
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.

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.

legoscia
  • 103
Christophe
  • 77,139
  • 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 '16 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 '16 at 16:46
  • So in your view, it does make sense to adopt e.g. SCRUM or at least Kanban to manage the risks, increase transparency etc. That is what I think - sure it wont be really agile (juggling with scope so that value is delivered) but at least some principles and management will be in place – John V Jul 22 '16 at 16:56
  • @user970696 I think that agility can help even in a mixed mode. It will bring you a focused team, measurable progress and -- thanks to transparency-- reinstall trust from your boss. How is the scope defined: is it something you can build a backlog on ? Is it cut in independent pieces so that pipeline development and test wold be possible (to save schedule) or is it a bunch of highly interrelated items that can only be addressed in larger chunks ? – Christophe Jul 22 '16 at 17:14
  • @Christophe We have now created the backlog in Jira and the tasks are somehow atomic - e.g. 5 tasks are being developed at the same time, those finished are immediately fixed. – John V Jul 22 '16 at 17:21
  • @user970696 sounds promising. Do you have a weekly meeting to agree on which one should be finished in the week ? And do you somehow ensure integration of the concurrent parts ? And have yo started to collect some burndown stats on the closed issues ? – Christophe Jul 22 '16 at 17:28
  • @Christophe yes, we somehow do a planning, daily standup to synchronize etc. Estimates...I have to convince those unmotivated people that it is still worth trying... – John V Jul 22 '16 at 17:40
  • "because at the begin, you elaborate scope, schedule and costs" absolutely but that's not the scenario described here. The project scope and timeline has been defined already. It's implied that there is a contractual requirement to meet. If this scope and schedule is not attainable there's no recourse, from what I can tell. – JimmyJames Jul 22 '16 at 19:09
  • @user970696 Based on what you describe, I think you need to go into full execution mode. Are you spending much time coming up with estimates? If so, for what purpose? If you are running late to catch a flight, how much time should you spend on estimating how long it will take you to get to the gate? In this situation, you might want to spike and figure out what other frictions are slowing progress. That will help with morale. So does providing meals. – JimmyJames Jul 22 '16 at 19:15
  • @JimmyJames I have the impression that you express here a lot of opinions that are not directly related to my answer but more with your personal opinion with schedules and estimates. It's of course your right, but I'd suggest that you write your own answer to develop your arguments with all the details they merit. – Christophe Jul 22 '16 at 20:36
  • @Christophe Not sure where you are getting that from. I quoted the section of your answer I was commenting on. If you don't understand how my comment relates to that or my logic, I'm willing to try again and/or elaborate. In a nutshell, you asserted 'constraints don't kill projects' and I asserted 'they can' and explained how. You then replied that they don't because of reasons that don't apply to the specifics of the scenario being discussed. If you don't agree with my logic, OK but please don't make it personal. – JimmyJames Jul 22 '16 at 20:44
  • 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 '16 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 '16 at 12:26
  • @JeffO Really? You honestly think there's an air-traffic-control system that is already coded and ready to deploy? That there's a company that's spent millions on developing this and sitting around, not telling anyone so that you can come along and buy it from them and turn around and resell it? – JimmyJames Jul 28 '16 at 13:33
  • 1
    @jimmyjames - any company can be bought. – JeffO Aug 08 '16 at 00:42
  • @JeffO Not ones that don't exist. – JimmyJames Aug 08 '16 at 15:05
2

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.

Bryan Oakley
  • 25,332
0

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.

JimmyJames
  • 27,287
  • 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 '16 at 09: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 '16 at 00:34