Dealing with failed sprints and deadlines

Question

Many Scrum books and articles say that a failed sprint (when the team fails to complete some features from the Sprint Backlog) is not something that bad, it happens from time to time, and it can actually be useful if the team learns from their mistakes and improves something in the following sprints. And the team should not be punished for not completing the work they committed to.

This looks great from the developer's point of view, however, let's say we have a software company "Scrum-Addicts LLC" developing something for serious clients ("Money-Bags Corporation"):

Scrum-Addicts managers suggest making a piece of software for Money-Bags
They agree on a list of features, and Money-Bags asks to provide a shipping date
Scrum-Addicts managers consult their scrum team, and the team says it will take 3 week-long sprints to complete all of the features
Scrum-Addicts manager adds 1 week to be safe, promises to ship the software in 1 month and signs a contract with Money-Bags
After 4 sprints (shipping deadline) Scrum team can only deliver 80% of features (because of inexperience with the new system, the need to fix critical bugs in previous features in production environment, etc...)
As Scrum suggests, at this point, the product is potentially shippable, but Money-Bags needs 100% of features, as mentioned in the contract. So they break the contract and pay nothing.
Scrum-Addicts is on the brink of bankruptcy because they got no money from Money-Bags, and the investors were disappointed with the results and are unwilling to help the company any more.

Obviously, no software company wants to be in Scrum-Addicts' shoes. What I fail to understand about Agile and Scrum is how they suggest teams should deal with planning and deadlines to avoid the situation described above. So, to summarize, I have 2 questions:

Who is to Blame?

Managers, because it's their job to do the proper planning
The team, because they committed to doing more work than they could
Someone else

What Is to Be Done?

The managers should move the deadline 2x (or 3x) times later than the original team's estimate.
Team members should be encouraged to do all the work they committed to no matter what (by issuing penalties for failed sprints)
The team should drop Scrum because it doesn't fit the company deadline policy
We should all drop software development and join a monastery
???

You point 3 under "To be done" assumes not using Scrum would have changed anything in having only 80% of the features ready in one month. That is ridiculous. — Doc Brown, Feb 25 '16 at 09:26
@DocBrown, I can't agree it is ridiculous. Dropping some Scrum activities like retrospective and demonstration meetings could speed up the development. And in case of a rock-solid contract this could help achieve the ultimate goal: deliver a fixed amount of features at the end of the deadline. — Andre Borges, Feb 25 '16 at 10:12
@AndreBorges Your suggestion to dropping retrospectives and demonstrations is same as suggesting in removing brakes from a car. Sure, brakes only slow you down. But that is what allows you to go really fast. — Euphoric, Feb 25 '16 at 10:18
@Euphoric yes - to continue the metaphor, no brakes might keep you fast in the short term but will eventually put you in a wall in the long run. In software projects, the wall is the unmaintainable, unusable big ball of mud you end up with because the team weren't stepping back to reflect on what they were doing technically and functionally. — guillaume31, Feb 25 '16 at 10:47
@Euphoric, but in some cases removing brakes is worth the risk. Race cars lack many safety features of a regular car, but it is done deliberately and to achieve a clear goal: increase speed (and in the end win a huge prize). It doesn't mean that everyone should start using race cars (waterfall methods), but can't they be the way to go in certain situations (fixed feature list and clear deadline)? — Andre Borges, Feb 25 '16 at 10:53
the same problem remains under any system - note that you can pretty much replace scrum with an equivalent waterfall one and the company still goes bust — jk., Feb 25 '16 at 12:04
@AndreBorges: in your example, you did not write the Scrum team was late because of too much time for "retrospective" or "demonstration meetings"..However, if those kind of meetings are really what slows your team down unneccessarily, the the agile approach is you identify this and react accordingly, which may mean to reduce the meetings to the minimum. To my experience, non-agile methods suffer much more from avoidable bureaucracy. — Doc Brown, Feb 25 '16 at 12:20
Perhaps if those Scrum-Addicts managers had paid more attention during those pesky "retrospective" meetings, they would have had the chance to hit the brake at week 1 or 2, instead of watching the project steer towards the cliff, and hit the gas pedal. — Dorus, Feb 25 '16 at 15:14
See also http://programmers.stackexchange.com/questions/286297/how-to-handle-50-of-worse-than-average-sprints — Paul Draper, Feb 25 '16 at 18:53
Isn't this exactly how Scrum (and "agile" methodologies in general) are supposed to work? The time and cost were fixed, so you adjusted the scope to make it fit. — user253751, Feb 25 '16 at 19:29
Is a representative from Money Bags taking time every week to see the result of the Sprint (which, being Scrum, was a shipable product minus some features)? Did he relay to his management doubts about making the deadline? — corsiKa, Feb 26 '16 at 00:31
@corsiKa, I cannot speak entirely for Money-Bags, as this example is composed of several different situations I observed in the past. But there are cases when proper communication is hard to achieve, but if you work through it and succeed with the project, rewards could be great (for details, see my comments to [one of the answers](http://programmers.stackexchange.com/a/311048/211802)). One of the points of my question was whether Scrum can help deal with such situations. — Andre Borges, Feb 26 '16 at 07:19
@DocBrown, instead of anything else. To word it differently, "Does Scrum provide any means of meeting fixed deadlines with a fixed feature scope? Do its procedures help get the work done on time? Or do they just slow the team down compared to [some other paradigms](http://programming-motherfucker.com/)?" — Andre Borges, Feb 26 '16 at 10:10
@AndreBorges your statement about race cars' safety features is incorrect; safety features (eg, seat belts or intrusion protection) are typically pioneered in race cars. Your analogy is incorrect. Meanwhile, your conclusion about waterfall is also bad: You need a clear and complete list of features for a successful waterfall project, and the deadline is allowed to slip. In Agile, the deadline is constant and the feature list slips as necessary. — mpez0, Feb 26 '16 at 13:20
Sometimes you can make no estimating mistakes, finish all sprints on time and introduce no bugs and still have an unsatisfied customer. That's just part of life and why you need a good contract and lawyer. You can avoid conflict and play it safe, but the business that plays it safe often won't profit. There is always a balancing going on between profit and risk. — Reactgular, Feb 26 '16 at 13:54
It sounds to me like Scrum-Addicts thought scrum was a miracle pill. It's just a way of doing business. You have the same issue with every other development model out there, they just approach the issues in different ways. See also all those government contracts which are hopelessly behind schedule, even though they are using tools like EVMS, which is a tool *dedicated* to handling contracts like these. If you spec 4 months worth of work in 2 months, you fall behind. The question is what is done to ameiliorate the situation. — Cort Ammon, Feb 26 '16 at 15:35
We should all drop software development and join a monastery - You make my day with this! — Ceylan Mumun Kocabaş, Jun 27 '17 at 13:25

Doc Brown · Accepted Answer · 2016-02-26T10:01:24.923

133

I see several fundamental management issues in your example:

if a Scrum-Addicts manager signs a "hard-deadline" contract, but adds only a safety margin of 33% in a situation where "a new system is involved", that is pretty reckless.
the availability of delivering at least x% of the features after one month could have been used to negotiate a contract where the customers pays the money at least partially when he gets only 80% of the features at the deadline. An all-or-nothing contract is something neither the software vendor nor the customer will benefit from - this means not just 0 money for the vendor, but also 0 features for the customer. And an all-or-nothing development methodology like "Waterfall" will only let you write such contracts, an agile approach offers additional possibilities.
looking at the results of the first one or two sprints should have made obvious to the manager that the team cannot meet the deadline. So he should have taken earlier actions, and re-prioritize the remaining tasks and features, or try to re-negotiate with the customer earlier. For example, the manager could have tried to downsize the scope of some of the remaining features, so the team could have delivered all features mentioned in the contract, but each of them in a reduced scope.

If a task turns out to take longer than you thought, no development methodology will save you from that. But an agile approach like Scrum gives management more opportunities to control what happens in that situation. If they don't make use of those opportunities, it is clearly their fault, not the team's, not the fault of "Scrum", and not the customer's fault because "he does not accept agility".

edited Feb 26 '16 at 10:01

answered Feb 25 '16 at 09:46

Doc Brown

199,015
33
367
565

48

+1 for *"An all-or-nothing contract is something neither the software vendor nor the customer will benefit from"*. It is the key thing about agile contracting. – guillaume31 Feb 25 '16 at 10:37
5

And it's certainly the case that 80% is no good for some kinds of project (ultimately it's *possible*, although unlikely, that agile is too limiting to make provision for those projects). So for example it's no use having 80% of the features for your satellite when you launch it, which is why you don't mess about with the contingency on those projects. If you fail to deliver then your client's mission will fail (or be delayed), there's nothing you can do in the contract to change that. – Steve Jessop Feb 25 '16 at 11:42
6

@SteveJessop: I am pretty sure even when you build such a complex thing like software for a satellite, there are different priorities for different features, and there will be lots of features where the scope can vary to a certain degree. The deadline may be fixed for such a situation, of course, because when you don't get the rocket into space until december next year, you might get no second chance. – Doc Brown Feb 25 '16 at 11:56
6

But for this specific example... ofcourse no one would have sent new horizons out if they failed to finish the cameras hardwaredriver. But even for projects on that scale I would bet one are not going into space with every feature that they were imagine of. – Zaibis Feb 25 '16 at 12:46
6

perhaps paying per milestone or functionality could also be an option. – Bram Feb 25 '16 at 13:10
1

If they were actually following the Agile methodology, then the customer would have been a part of every End of Sprint meeting, and seen immediately that the developers probably wouldn't have met the deadline. – krillgar Feb 26 '16 at 00:43
2

@krillgar: not necessarily. In Scrum, the Product Owner represents the customer's wishes inside the team and has the job to communicate with the customer. And it is not the customer's job to take measures when the deadline is at stake. – Doc Brown Feb 26 '16 at 06:55
@DocBrown True, not necessarily. But you can also have the customer at the demo to try out the product. It is key to get their feedback on the progress in case there are things they haven't thought of about the process, UI, or features. Maybe something doesn't have the "feel" to it that they are looking for. You need the customer's feedback if you want to have something to respond to in an agile fashion. – krillgar Feb 26 '16 at 11:33
@SteveJessop When you say "[...] certainly the case that 80% is no good [...]" you need to define what the 100% are. For a scientific satellite with multiple experiments (I assume each scientists' software may not control the hardware, if only because the fuel for pointing antennas - and stopping rotations - is limited), that would be "everything" anybody could think of and get funding. I'd guess such a satellite would normally start with about 50% requirements done. [...] – Volker Siegel Feb 26 '16 at 16:49
1

But a simple satellite that only relays a signal, without changing his orbit? There are certainly lots of features that could be replaced by downloading some data and sending results - just slower. And - because fuel for correcting orbit fluctuations defines the useful, it worth a lot of software to optimize the use; But it's ok to start with an estimated lifetime of, say, 20 years, and about 80% requirements done. I do not think there is non-trivial software that is not useful at 80% completion. – Volker Siegel Feb 26 '16 at 16:50
2

@Volker - "useful" is vague. The customer wants XYZ and is willing to pay $20 million for it. On many projects I work on, 80% complete really is useless and certainly isn't worth paying $16 million for just because something "useful" can be done. The project has to complete a mission. If it can't complete the ENTIRE mission it is of no value to the customer. For example, being able to detect 80% of the various kind of land-mines is of zero value. They really need to detect 100%. The fact that it finds 80% wouldn't make me as an operator very happy even though finding that 80% is "useful". – Dunk Feb 26 '16 at 17:00
2

@Dunk So detecting 100% of land mines is an essential requirement - that is part of your 80%. Other requirements might involve user interface, or speed of operation. Some of those are optional. – Jonathan Hartley Feb 27 '16 at 18:58
@Dunk yeah Jonathan's point is key there. Detecting all mines is one feature - it's not about getting all features 80% complete, it's getting 80% of features 100% complete. Military and such projects are, if anything, more pragmatic than most about this - it's ideal to succeed and have everyone survive, but if you're going to lose everything then it's enough to just succeed, and there's all shades in between. – Jeff Feb 29 '16 at 05:59
2

@Jeff - No Jonathan missed the boat entirely. It is not like you write one algorithm and you can detect all the mines or some requirements are optional. Good luck testing your app to make sure it detects properly without a decent user interface. Good luck meeting the minimal operator skill level standards without a decent UI. Good luck selling your detector when the soldier has to stand in the open field for minutes waiting to determine if a detection occurs. There are simply applications, and there's many of them, where 80% of functionality is no better than 0%. – Dunk Feb 29 '16 at 22:08

score 67 · Answer 2 · edited Feb 26 '16 at 12:12

67

One of the value statements of the "Manifesto for Agile Software Development" is :

Customer collaboration over contract negotiation

The fact that Scrum-Addicts LLC negotiated a contract instead of establishing a collaboration with a customer makes me question their agility.

One thing is clear : Agility needs to be accepted by EVERYONE. Agility is not only for developers. Managers and customers also need to accept the values of Agile Manifesto. If customers don't accept agility and still require rigid contracts and minimal collaboration, then either don't use agile or find better customers.

It is customer's fault they are locked in their contract bubble with deadline-driven development.

edited Feb 26 '16 at 12:12

Pete

8,916
3
41
53

answered Feb 25 '16 at 08:31

Euphoric

36,735
6
78
110

Possibly not the client's fault, but the legal & sales teams for writing/accepting stupid contracts. – RubberDuck Feb 25 '16 at 08:36
@RubberDuck Basically. I did see people claiming about having contracts that said "At end of each iteration, we present what was agreed at start of the iteration and will get paid if customer accepts." With no mention of deadlines or features needed to be implemented. – Euphoric Feb 25 '16 at 08:48
This. If the project is in no way agile (100% of features mentioned in the contract that was written up front, needed on deadline day) then an agile method shouldn't be used for it. – RemcoGerlich Feb 25 '16 at 08:58
@RemcoGerlich would you really suggest waterfall for it? That would only make the project even later. – RubberDuck Feb 25 '16 at 09:02
9

@RubberDuck There has yet to be a software project management methodology that allows features to be decided up front, deadline set and was not terribly expensive. Scope, Time, Money; Pick two. – Euphoric Feb 25 '16 at 09:05
@Euphoric scope or time, pick *one*. =;)- – RubberDuck Feb 25 '16 at 09:06
8

@RubberDuck: The project is already not-agile, because the requirements are set in stone. And the estimate is only three weeks. There is nothing magically bad about waterfall that makes it always late, it just can't deal with vague requirements and change. Yeah, I would use "waterfall" in this case, or more accurately "let's decide what needs to be done and do it". – RemcoGerlich Feb 25 '16 at 09:25
3

@RemcoGerlich ironically, "let's decide what needs to be done and do it" is remarkably agile itself :-) – gbjbaanb Feb 25 '16 at 09:31
@gbjbaanb: Any 3 week project (that finishes successfully within 5) is going to look like it was remarkably agile. – RemcoGerlich Feb 25 '16 at 09:35
2

@RemcoGerlich ah, I think you misunderstand my point: in that agile is not really about the dev methods, but the ability to get on with the work, using whatever means you like. Its about progress not procedures after all. (eg a team that only does Scrum is not agile, a team that only does waterfall-style but modifies it to suit circumstances is) – gbjbaanb Feb 25 '16 at 09:42
"find better customers" is IMHO the wrong answer, I strongly disagree that you cannot combine "Agile" with deadlines. Quite the opposite - agile approaches give you much more control to adjust scope or money when the time is fixed. – Doc Brown Feb 25 '16 at 10:13
@DocBrown If scope or money are not defined, then I wouldn't consider that a deadline. Deadline says what should be done when. If you can adjust what will be finished by deadline, then that is not really a deadline. – Euphoric Feb 25 '16 at 10:20
@Euphoric: the OP was clearly using the term "deadline" for the time, so were I. And the fact one has the ability to adjust scope or money to some degree does not mean those are not defined. – Doc Brown Feb 25 '16 at 11:45
@DocBrown Wrong : "promises to ship the software in 1 month". Here "ship the software" means "all features are implemented". So yes, here deadline means "promise to implement all features in 1 month". Also, the very definition of [Time limit](https://en.wikipedia.org/wiki/Time_limit) is "particular point in time, by which an objective or task must be accomplished". You cannot have a deadline without clearly defined "objective or task". – Euphoric Feb 25 '16 at 11:48
@Euphoric: yeah; I am clearly wrong, since I did not pick the interpretation you like best ;-) – Doc Brown Feb 25 '16 at 11:52
@DocBrown Clear definitions are important in communication. And you cannot just make up your own to fit your own worldview. Pretty much everyone and their mother defines deadline as "finish X by Y". I have yet to meet a person who only thinks of deadline as "time Y" with no task X associated with it. – Euphoric Feb 25 '16 at 11:54
@Euphoric: of course "deadline" means "finish X by Y", but with a much stronger focus on "time limit" than on everything else. Where I agree to you; if a potential customer wants not only to fix the deadline in time, but also wants to fix scope and money to unrealistic expectations, then it may be better not to sign a contract at all. Nevertheless "deadlines" (=time limits) work IMHO well with "agile". – Doc Brown Feb 25 '16 at 12:10
1

@DocBrown Again, I'm repeating myself. You cannot say "time limit" and don't say "for what". You just CANNOT say just time limit with time. You HAVE to say for what task or objective that time limit applies. You must live in some different universe if you think "time limit" means something different in agile and in waterfall. – Euphoric Feb 25 '16 at 12:28
2

I agree with Doc Brown here. You can absolutely have a "time limit" without saying exactly "for what". It's perfectly reasonable to say, for instance, "Our deadline is . On that date, we'll ship what we have done." The scope of what gets shipped does _not_ have to be set in stone the moment the deadline is created. Agile development is all about managing scope and communicating progress inside time-boxed increments, which are all actually mini-deadlines of their own. – Eric King Feb 26 '16 at 00:45
@EricKing: thanks, that is my understanding of that *term*, in general, too. However. my understanding of the specific "deadline situation" described by the OP is somewhere between what you described and what Euphoric insists to be "the one and only correct interpretation". To my understanding, it is a situation where end date and feature list are fixed into a contract by mismanagement, and not because "the customer does not accept agility". – Doc Brown Feb 26 '16 at 09:42
1

@DocBrown @EricKing What you are talking about is not a time limit but a time box. If the scope is not fixed and instead you are committing to "seeing what you can get done within 3 weeks" then it isn't a deadline but a time-box. The very definition of a deadline is the requirement of having task X done by time Y. The Oxford dictionary defines a deadline as `The latest time or date by which something should be completed`, not as 'The latest time or date by which something should be at least partially comzpleted and the work will be stopped anyway' – Cronax Feb 26 '16 at 11:07
2

the Cambridge dictionary makes this even clearer: "a time or day by which something must be done". Unless your definition of done somehow specifies that tasks don't actually have to be completed to be done and the customer has agreed with that definition of done, you will be expected to deliver 100% of all the features. – Cronax Feb 26 '16 at 11:11
@Cronax: my point is: the situation described in the OPs question is a clear management failure - the so-called "deadline" (including fixed, unrealistic time and scope) is a cause of a bad contract and missed opportunities. Euphoric states something different - he says you cannot work agile when the customer refuses, it is all the customer's fault. and better do not work for such customers. Where I agree to this point is: do not make contracts with customers when they insist on "all-or-nothing", but do not be astonished when after you agreed to such a contract the customer insists on it. – Doc Brown Feb 26 '16 at 12:34
I guess my entire career has been based on "clear management failure". I can't recall ever working on a project where "time or cost" and "scope" weren't explicitly called out in our contracts. I take that back, if we are developing "in-house" applications then it was more of a what you can get done in the specified time-frame. But external customers, I have obviously been working for the wrong management as we agree to deliver exactly what the customer asks for. I guess I have a character flaw because I prefer to deliver all of what the customer wants instead of just some of it:( – Dunk Feb 26 '16 at 17:12
@Dunk: if you have read my answer carefully, you might have noticed that I did not write fixing time, scope and money in a contract would be a management failure on its own. – Doc Brown Feb 26 '16 at 17:19
1

@gbjbaanb - I know people don't believe it but companies that successfully use Waterfall do many of the same things that "Agile" takes credit for doing. And they were doing it many years before "Agile" even existed. Nobody who successfully uses Waterfall does one step at a time like Waterfall implies. There's overlap, iteration, multiple builds etc..Waterfall is just a guide that is loosely followed. There's really not a lot of "new" things that the "agile" movement has brought to the table, unless you want to count adding more useless meetings and unacceptable work conditions. – Dunk Feb 26 '16 at 17:24
@DocBrown - That's fair. I was jumping in on your tit-for-tat comments pointing out "sarcastically" that different domains have different kinds of customers and scope is frequently not negotiable. Normally it is either time or money that is fixed along with scope in my domains. I think you both have different kinds of customers and that is where disagreement lies. I agree that it was management failure to believe that a production worthy product can be delivered in 1 month unless there's already a working product with just a few tweaks needed. Especially if the expertise isn't already in house – Dunk Feb 26 '16 at 17:36
@Dunk: I was not aware where I wrote any sarcastic comments here. And yes, customers will always try to fix, time, scope and money (which is quite understandable from their point of view). But they are not to blame for this. The failure happens when your management agrees to such a contract without big enough safety margins, and without doing an active management of the development activities. – Doc Brown Feb 29 '16 at 13:35
@DocBrown - People love to blame management but in this case, I don't agree. The developers said 3 weeks. Management gave them more time, not much more, but more time. I can't recall the last time I've ever had that happen too me. Usually, management halves my estimates and then the customer halves them again:( Blame management in those cases, but they never get blamed, the developers always take the blame for being too slow or not working long enough hours. Thus, my estimates now take those tendencies into account and everyone ends up happy. – Dunk Feb 29 '16 at 22:23
@Dunk: since your company did not go not bancrupt so far, I guess the situation you experience has nothing much to do with the example of the question. You envision far too much of your own situation into my comments ;-) – Doc Brown Feb 29 '16 at 22:28

score 15 · Answer 3 · answered Feb 25 '16 at 10:23

Who is to blame?

Managers, legal dept, accountants - take your pick...

I know the example is somewhat contrived but the fact that the company could walk away without paying a dime if they weren't 100% satisfied should have rung immediate alarm bells as should mixing waterfall and agile thinking.

Customers want to have their cake and eat it - they're happy to accept waterfall, mini-waterfall, agile, la-la-land as long as they get product X for $Y by date Z.

Agile development absolutely requires the development team and customer to be on the same page from a methodology point of view. Thinking differences in culture will just come out in the wash is wishful thinking.

score 12 · Answer 4 · answered Feb 25 '16 at 21:01

IT projects deal with unknowns; some of these unknowns are even unknown unknowns. What does that mean?

Take for example a toy bridge for your model railroad. There are all parameters known to you:

You know how big the valley is
You know the material of the mountains, their height, stability etc.
You know how much material you need
You know from earlier "projects" how long it took you to build similar things

There are many variables involved which influence your calculation of investing spare time and money. But you could say without a thought, whether it is finished next weekend.

Take the example a step further:

Say you do not build the bridge for your own model railroad, instead you build it for a complete stranger: your job is to build a railroad bridge between two mountains
Say you have near to no information in advance of the model landscape
The information about the landscape is, that is has two mountains, which seem not too big
The consistency of the mountain is between rock and jelly
Total cost has a max of 10$
The workplace is complete dark and there is no chance of light: you only have a box of 8 matches
The deadline is 3 hours

That would be the analogy to an IT project. You have experience in building bridges and it is easy to walk on known terrain. What it makes hard is the darkness. There are many things you can hardly predict: The measures of the mountains are only known after poking some time in the dark. So is the consistency of the mountains. From that you could make estimates on how long it will take you and how much it will cost. Here the unknowns are things, which you do not know on the beginning of the project like the concrete terrain etc. But there are things you can not foresee, even with the most experience and most conservative estimations. These things are the unknown unknowns which bear a bit of chaos.

Every IT company should know that. They have to deal with project risk.

1) There are several ways to minimize the (financial) risk: the deal could include tha the customer pays for every working increment. So after increment 1 is delivered, a partial rate has to be paid. As long as Scrum-Addicts LLC delivers, there is minimal financial risk. The more finegrained sprint goals are planned, the lower the total risk of every sprint. That means, if Money-Bags Corporation received 80% of the contract they should at least paid 80% of the contract value. If they refused to pay after a failed sprint the risk isn't as high as the refuse to pay 100%.

2) Scrum-Addicts LLC has a problem with their developers

Scrum-Addicts managers consult their scrum team, and the team says it will take 3 week-long sprints to complete all of the features Scrum-Addicts manager adds 1 week to be safe, promises to ship the software in 1 month and signs a contract with Money-Bags

That suggests, that a) the developers aren't experienced with scrum or b) they are doing scrum wrong The longer teams work with scrum, the better are their estimates. If the teams makes estimations and the manager adds a "buffer" as "safety", the manager seems to know better than the team, which is a bad sign. If you have an experienced team, there is no need for a "managerbuffer", the team included that already in the estimation. The idea is, the more sprints the team has worked together the more the team knows its strengths and weaknesses and has some metrics to make realistic estimates. Of course there are - as already mentioned - the unknown unknowns which tend to make estimates hard; or at least imprecise. But in the long run, the estimates should get better and better.

Who is to Blame?

1) Management

As said above: there is clearly a failure in risk management. If the company is on the brink of bankruptcy, the company deserves it. If you work at such a company: leave!

2) The Team

Even if management is utterly stupid, the team should have spoken up against such a project. A good manager should know the risks; but a good developer should point out risks. And most of all: The team should report early if something fails.

What Is to Be Done?

Now: Take Money-Bags to court

For the future: Do not make such contracts

Scrum is not to blame for management failure. Scrum was developed based on the experience of many IT projects failing. It can not prevent failure, nor can it cure incompetence of teams or management. The basic idea is:

to structure communication ways (who talks to whom when about what)
to encourage developer reporting failure early
to divide problems in tasks and subtasks
to structure time and capacities (who works when on what)
to distribute the tasks over the time slots
make the unpredictable a bit more predictable (planning poker)

or overall: to minimize risk.

Scrum is a tool as a hammer is. Whether it is a good tool depends on your knowledge how to use it. But sometimes a screwdriver fits better. It's up to you.

There's another aspect of Scrum that is vitally important to understanding why this project failed: scrum *embraces failure*. It is expected that the first couple of sprints of a new team or project will fail. Through the scrum process of retrospectives the team will improve itself and over the long term become accurate in their estimates but only as long as they remain the same team working on the same project. When either of those change you should once again expect some failure since the underlying variables are shifting. — Cronax, Feb 26 '16 at 11:24

score 9 · Answer 5 · answered Feb 25 '16 at 09:08

First off, "Who is to blame?" is the wrong question to ask. Assigning blame is fun and all, and will probably make everyone except the blamed person(s) feel relieved (in a "hey, it's not my fault, the boss said so!" sense), but it's not a productive use of your time, and can actually be counterproductive and cause a drop in employee morale.

A better way to look at it is "What caused the delay?". Was it lack of experience in the technology? Critical bugs which were not detected in testing/QA? Lack of testing/QA? Too optimistic in the estimation? Not taking into account the team's not-so-optimistic estimations? Somebody got hit by a bus? Whatever the cause, the next question is "How do we make sure this doesn't happen again?". In some (hopefully rare) cases, the answer for that might be "get rid of so-and-so", but if you start from "I need to punish whoever's responsible", you're unlikely to see the majority of the cases where it is not the right solution.

Within the project, you're already sunk. Deadline's come and gone, you warned the customer as soon as was apparent it was going to slip (because you did do that, right? If not, that's part of the problem), and now it has to be handled however it was spelled out in the contract (it is actually spelled out in the contract, right?). Generally speaking, that should involve negotiating with the customer how you are going to deliver what is missing. Lots of people like to think of a contract as something that cannot be changed, but faced with either a) dropping the contract and not having what you bought, b) suing the company for breach of contract and spending a lot of money in court, and c) negotiating how to get their product with the least amount of trouble possible, most companies choose c.

Looking forward, before quoting a price/deadline to a customer you should analize the risks involved in a slipped deadline or cost overrun (what are possible causes for such a thing? Which causes can you mitigate somehow, and which you can't and just have to plan for), and use that information to help decide on what you are going to promise. If it is a case where it's 100% or nothing, you'll obviously quote higher prices and longer deadlines, because the risk is higher.

You'll notice I didn't talk about Agile in this whole answer. That's because (I'm going to forget about the customer's involvement in Scrum for a second, although it is very, very important) at this point it doesn't really matter. You'll be faced with this problem in Agile, Waterfall, or whatever development process you use. Yes, Agile is supposed to help you manage risks better, by letting you see if they've become actual problems earlier, and involving the customer in the process itself so they are always informed, but it's not a panacea.

-1 The point of agile is that many of the risks simply cannot be predicted. For example, they added 1 week buffer in case things slip up. You can always triple time needed, but then you loose against competition that doesn't do that. Agile should adopt "Its done when it is done" mentality. Which is simply incompatible with contracts and deadlines as described. — Euphoric, Feb 25 '16 at 09:20
@Euphoric I cannot entirely agree. Yes, the point of Agile is that many risks cannot be predicted, and that's what the buffer is for, I'll grant you that. However, that doesn't mean that all risks are unpredictable, nor does it mean that you should go into a project blind, without considering the risks that you can predict. — Iker, Feb 25 '16 at 10:20
@Iker The one does not preclude the other, but the point of being truly agile in the development process is that "It's done when it's done" mentality for both the customer and the team. Sure, there are always some risks you can predict, but you can never successfully predict all possible risks and exactly what impact they will have on your progress. Unless you can see the future somehow. That's why Agile work requires specific contracting, where you agree that "we'll continue working until the money runs out, or either party is no longer willing or able to, or all the customers needs are met" — Cronax, Feb 26 '16 at 11:19
ok, i upvoted this for the immediate rejection of blame as a concept. I agree that blame is an unproductive component that's a distraction from success. Let's change the question. Maybe we could make it "how could we have handled this"? "how can we turn this into a success for us?" "what changes from every party could have resulted in a positive outcome?" i might be ok with changing "blame" to "responsible", but as every project with a vendor and a customer is a team interaction, isn't the entire global scoped 'team' responsible anyway? the question of who is to blame then becomes rhetorical. — Joshua K, Feb 29 '16 at 23:06

score 4 · Answer 6 · edited Feb 27 '16 at 13:49

4

The development paradigm is out of sync with the contract paradigm. Ideally, the way contracts are written would change, but that's unlikely to actually happen. However, even if you were to drop scrum, you would still have surprises and missed deadlines (only you'd likely be much later because you did all that design up front and it was all wrong!!).

With or without a change to how contracts are written, you ship what you've got working. Then fulfill the contract by eating a cycle of development time in order to finish the features you didn't get done.

Is it good that you failed to deliver everything you promised on the day you promised? No, but your customer will be much happier if you can deliver something that works on time, then deliver the rest of it quickly after than if you're simply running late and don't have anything at all to give them.

edited Feb 27 '16 at 13:49

pqnet

103
2

answered Feb 25 '16 at 08:02

RubberDuck

8,911
5
35
44

3

Yes, sometimes the customer is happier if the team delivers at least some portion working features, but this is not always the case. I'm talking about cases when (1) the product is useless to end-users unless 100% of features are implemented (for example, it requires expensive certification that needs to be done only when everything is finished) or (2) the customer is an old-school company with the "all-or-mothing" approach: if the product is not 100% ready we consider it failed, break the contract and fire everyone responsible. – Andre Borges Feb 25 '16 at 08:26
2

The customer will always be happier to see progress in the way of working software. The expensive certification can wait until the product is up to their satisfaction. Releasing it to the client doesn't mean they have to release it to the public. In case 2, there's really no option but to have your legal/sales teams write better contracts. Honestly though, your problems would be the same, if not worse, with waterfall there. – RubberDuck Feb 25 '16 at 08:34
2

@AndreBorges Surely the customer will be happier to see 80% of features than to see 0% of features? At least that way, the customer knows the product is mostly done. – user253751 Feb 25 '16 at 20:22
@immibis, if you say that, it means you've been happy enough to avoid some 'peculiar' customers in your work. There exist some huge clumsy government-related corporations that enforce not-so-reasonable contract terms, but if you invest all your resources into their task and manage to succeed, they pay serious money that could lift your small company sky-high. However, if you fail, you may find yourself looking for a new job. It's the risk that that some people are willing to take. – Andre Borges Feb 26 '16 at 07:07
@AndreBorges Are you suggesting that even a huge government-related corporation would be happier to see 0% features than 80% features? – user253751 Feb 26 '16 at 07:23
2

Exactly! Due to its internal bureaucracy and lack of experienced management staff, sometimes it's easier for a large company to consider a failed deadline an "unsuccessful experiment" and drop the project altogether, than to put further effort in trying to communicate and renegotiate the scope. Sad, but true :( – Andre Borges Feb 26 '16 at 07:33

score 4 · Answer 7 · answered Feb 25 '16 at 09:25

Firstly, this is a problem with any development methodology. At least with an iterative development system you have something to show the customer at the end of the deadline, which may be enough to get an extension to complete the product (even if the customer doesn't pay any more!).

There are cases where a deadline is a deadline however, imagine you're writing a game and it absolutely has to be released in time for the Christmas holidays. Getting that wrong has bankrupted many a company!

For agile methods that have to complete a certain amount of features by a certain date, scrum is probably not the best method to use (as I've always found that scrum makes dev go slower and does not allow enough agility to alter the process when needed.

What you need, regardless of methodology, is to set up a backlog of required features to give visibility of progress. Progress on a per-sprint basis is not good enough, you will not know if you're meeting the ultimate target. So a kanban-style methodology would be better: set all the features on the left, and work them through the system to to show progress to completion.

That focusses people's minds on what still needs to be done in a way that Scrum doesn't handle, and allows people other than the dev team to see what remains and whether you're likely to meet the target (and thus manage customer's expectations early, or arrange those overtime bonuses before they're needed).

Scrum is a system that potters on forever, continually defining and refining something. Its simply not suitable for this kind of development. Others can manage this sytle and still keep the iterative development concept, Kanban is one like that, Crystal another. But what is essential to understand is that if you're following Scrum religiously, you're not being agile. Any true Agile system should be able to morph to cope with these particular issues, that's why it was called agile in the first place, its about getting done what needs to be done, and if a fixed deadline is part of that, then you should be factoring that into the way you work.

"Game ready for christmas" could be a posterchild for Scrum. Ship the 80% you have finished, sell the remainder as DLC. That's not the hypothetical situation discussed here, where the deadline fixed both time and scope, with a 100% penalty for partial delivery. — MSalters, Feb 25 '16 at 11:38
@MSalters you assume the game works at all, that 80% may not be missing features that can be added later, but breaking functionality or crashing bugs. It doesn't have to be a game, could be any software that needs to be shipped for a definite, and unchanging deadline (as not even Apple can postpone Christmas!) — gbjbaanb, Feb 25 '16 at 11:46
That's the basic premise of Scrum! Broken functionality doesn't count. If you come from a Waterfall background, you'll find that Scrum therefore prioritizes bugfixing over adding new features. "80% done" means that there are missing levels, missing bosses, etc. — MSalters, Feb 25 '16 at 11:52
@gbjbaanb By that reasoning, something could be 99.9% done but still not work because it crashes immediately upon startup. — user253751, Feb 25 '16 at 20:25
@immibis but that is true though. Things like games do not tends to leave features out until the end, most parts of a game have to be implemented for the whole to work - while you can take out some features (and I know games that have done this) they do not add features incrementally. So a missing boss would be a broken game. I only chose games as an example as they do tend (particularly before internet delivery) as examples of hard deadlines. — gbjbaanb, Feb 26 '16 at 08:35
"Scrum is a system that potters on forever". {{Citation needed}} — Seldom 'Where's Monica' Needy, Feb 27 '16 at 08:36

candied_orange · Answer 8 · 2016-02-29T09:18:44.460

Many Scrum books and articles say that a failed sprint (when the team fails to complete some features from the Sprint Backlog) is not something that bad, it happens from time to time, and it can actually be useful if the team learns from their mistakes and improves something in the following sprints. And the team should not be punished for not completing the work they committed to.

The way you "punish" this kind of behavior is by limiting the amount of work the ones who didn't finish can take on next sprint. Chances to work on cool stuff are vanishing. The reward for doing good work is more work.

This looks great from the developer's point of view, however, let's say we have a software company "Scrum-Addicts LLC" developing something for serious clients ("Money-Bags Corporation"):

Scrum-Addicts managers suggest making a piece of software for Money-Bags They agree on a list of features, and Money-Bags asks to provide a shipping date Scrum-Addicts managers consult their scrum team, and the team says it will take 3 week-long sprints to complete all of the features Scrum-Addicts manager adds 1 week to be safe, promises to ship the software in 1 month and signs a contract with Money-Bags After 4 sprints (shipping deadline) Scrum team can only deliver 80% of features (because of inexperience with the new system, the need to fix critical bugs in previous features in production environment, etc...) As Scrum suggests, at this point, the product is potentially shippable, but Money-Bags needs 100% of features, as mentioned in the contract. So they break the contract and pay nothing.

Scrum-Addicts is on the brink of bankruptcy because they got no money from Money-Bags, and the investors were disappointed with the results and are unwilling to help the company any more.

If on Monday I bet you $100 that it will rain on Thursday and it doesn't rain until Friday you'd be right to take my money. If, rather than a chance to gamble, what you want is a weather forecast then we need a contract that lets me give you an updated forecast on Tuesday.

Obviously, no software company wants to be in Scrum-Addicts' shoes. What I fail to understand about Agile and Scrum is how they suggest teams should deal with planning and deadlines to avoid the situation described above.

Think about WHY MB wants to take their ball and go home. MB didn't demand the work be done in a month at the outset. SA promised 100% of critical features in one month and didn't deliver. SA set the deadline not MB. SA even arbitrarily added a week to the deadline. So why is this a deadline?

Occasionally when competing for work software companies give in to the temptation to show off and promise the moon. Professionals carefully establish whether a moon is even required. Which is the more critical need for MoneyBags? 100% of features or a functioning product in a month's time? Do they even know what is truly critical? Is there some upcoming event setting a hard deadline?

If I was Scrum-Addicts negotiating this contract I'd want to know a lot more about Money-Bags business needs and structure the contract to grant as much flexibility as Money-Bags is comfortable with. I'd teach them how the agile process works so they know what to expect from us.

This way rather than expecting everything to be suddenly working perfectly in a month they'd be expecting to be evaluating the first deliverable in 1 to 2 weeks.

So, to summarize, I have 2 questions:

Who is to Blame? Managers, because it's their job to do the proper planning
The team, because they committed to doing more work than they could
Someone else

Anyone could have stopped this travesty before we got a month down the road.

I could go as far as blaming Money-Bags Corp for hiring a team that obviously fraudulently represented a waterfall process as being agile. The contract itself makes it clear this is not agile. Planning to be done in a month doesn't make it agile.

If you insist that it's agile, it's agile with only one sprint that is a month long. Which, yeah, I wouldn't recommend because that's, again, the same thing as waterfall.

What Is to Be Done?

How about agile? Deliver something every sprint? Get feedback before the deadline? Week long sprints? How about renegotiating the draconian contract the very moment you suspect the deadline is in danger rather than hiding and praying? At the very least you can stop wasting time on a doomed project and find a more reasonable customer.

The managers should move the deadline 2x (or 3x) times later than the original team's estimate.

Deadline multipliers are about as useful as setting your watch 15 minutes early so you'll never be late. You can only fool yourself so long before you realize what you're up to.

Early estimates are wrong. Try to capture how wrong. 5 weeks, give or take a few weeks is a simple expression that lets you express how uncertain the completion date really is. Rather than trying to guess accurately, you guess how wild your guess is. Do some real work and get some real data. Then you can start making estimates with a narrower range. One to two weeks is plenty of time to do this.

Team members should be encouraged to do all the work they committed to no matter what (by issuing penalties for failed sprints)

Team members should be encouraged. Failed, committed, or otherwise. Rather than constructing any artificial consequence such as punishments or even bonuses (carrot and stick) studies have shown that people doing creative work such as programming respond best if provided three things: Autonomy, Mastery, and Purpose.

Daniel Pink has a TED talk about this. The talk is about motivation not agile but I easily saw how to map these points to agile:

Autonomy - I want to direct my own life - Let me pick work from the backlog.
Mastery - I want to get better at something that matters - Customer feedback.
Purpose - I want to be part of something larger than myself - A collaborative team.

The team should drop Scrum because it doesn't fit the company deadline policy Scrum can hit a deadline more accurately than waterfall. Given a deadline scrum can meet it. It might meet it with only 1 of 47 features depending on time, feature, and skill but it can meet it.

An agile project can be styled so extremely that every night when the team goes home it's ready to ship. This seems silly unless you think of shipping as asking the customer to test and provide feedback. The sooner that happens the sooner you can make adjustments. This hits every possible deadline. Just not every feature. But it steers you to the features that matter.

We should all drop software development and join a monastery

Right, like locking me up in a room away from real life is gonna make me write LESS code.

I've edited this answer down to size. If you're curious read the edit history.

_I'd like to just assume you meant sprint not backlog_ - I meant exacly what I wrote in the question: [the sprint backlog](https://en.wikipedia.org/wiki/Scrum_%28software_development%29#Sprint_backlog) — Andre Borges, Feb 29 '16 at 06:38
_people doing creative work such as programming respond best if provided three things: Autonomy, Mastery, and Purpose_ - this can be a huge topic for speculation on its own, but the fact is that unfortunately a lot of programming work is becoming less creative and more routine (dull tasks, fixed tech stack and feture sets, strict contracts). Hence, in many cases carrot and stick works just fine. — Andre Borges, Feb 29 '16 at 07:46
@AndreBorges You're right, I was thinking of the product backlog. Recently I've been working with a tool that calls the sprint backlog the sprint and the product backlog the backlog. You caught me losing the fight to keep my vocabulary from becoming proprietary. — candied_orange, Feb 29 '16 at 09:23
@AndreBorges programming will never be envelope stuffing. It is firmly a candle problem. The reason why is because any repetitive problem can be solved with the same code that solved the first problem. Despite this management can get into a mindset where they think creativity is a problem to be stamped out. I've worked for and ran from several of these shops. They don't keep good people. They don't produce good software. Developers are craftsmen. Trying to turn them into assembly line workers only hurts your cause. My job is not to flip eggs. It's to ensure that eggs are flipped. — candied_orange, Feb 29 '16 at 09:45

score 0 · Answer 9 · answered Feb 25 '16 at 15:56

Everyone has to be agile. Whatever you decide that will be, look like, who does what, how, when, where and why by all parties. Agile customers, management and developers.

You cannot give a shipping date too far into the future. You give an estimate.

Someone needed to manage the client's expectations. The reason you don't worry too much about having a couple of sprints fall behind is because you adjust to prevent the entire project from falling behind. If you come to the conclusion after a sprint or two that you're not going to finish meet the "shipping date", that's when you tell the client.

Now what do you want to do? Get rid of features you don't need or move the date. If you could deliver on time, you would. Don't hesitate to bring bad news.

Who knows, on some projects, you may ship sooner.

You can't be agile if the client doesn't want to.

score 0 · Answer 10 · answered Feb 29 '16 at 10:26

Goal

I believe the following two "metrics" should be the basis for any business decision:

is the work profitable (for the client)
are we working as efficient as possible

These are quite universal. Of course it get's more complicated very fast, for example, work being profitable is about the product doing the right thing, the user being able to use the product, the product being marketed correctly etc. - for a lot of these "Scrum-Addicts LLC" is not bearing responsibility.

Issue

The contract is not focusing on the goals outlined above. There's an "all or nothing" clause - get everything done and be paid, or get nothing done and don't be paid. However, this does not directly relate to value being created. Another downside which follows: now we need to spend time & money assure and verify that the contract is being followed. Why on earth would we want to spend this money? How does making sure a contract is fulfilled help when the requirements have changed in the meantime and we've found out that the ordered piece of software is not creating any value? There's just more money going down the drain! Now, of course, there's a reason for this behavior:

Culturally we are used to shop for things like that. We expect shop for software as we would for a car: pick a configuration, be given a price and deadline, and be very unhappy if those two aren't met.
we want to offload risk and accountability
we want stability, it helps with planning and makes us feel better (and also our client, which is an important aspect!)

At the end of the day, we'll have to choose a compromise which will allow us to satisfy our goals as good as possible.

This is how it should work

have a contract for services & work instead of for a product
- needs to be terminable on relatively short notice
work closely together to ensure optimal efficiency
involve all the necessary parties, both from "Scrum-Addits LLC" and "Money-Bags Corporation" - a "single point of contact" tunneling all the information is not going to work here

well i basically just said "be agile". Now here's why:

process & contract are optimized to spend as much money on the Goal as possible
you'll have to trust the contractor to do his job, and not need to invest a lot of money verifying that he's up to the job.
the ability of suing your contractor if your expectations / contract isn't met usually doesn't help, because doing so will cost more than just dropping it. Some of the main concerns here are time-to-market. You most likely will lose way more money/business by going to court than you'll get.
- at the end of the day you'll just have to bear some risks yourself.

Dealing with failed sprints and deadlines

10 Answers10

Goal

Issue

This is how it should work

Linked