6 ms·

I think the author misses what the purpose of deadlines is. They are contracts between organizations for when software will be available, which are used for oth

I think the author misses what the purpose of deadlines is. They are contracts between organizations for when software will be available, which are used for other organizations to make informed decisions without needing very tight and constant communication. They're analogous to SLAs in service-oriented designs. In a moderately large (say, 500+ employee) organization, deadlines are essential to get anything done. Suppose, for example, you're overhauling a billing system, making international tax calculations simpler. The finance team is making a hiring decision: they need to get tax stuff calculated before the end of the year; do they need to find consultants to help them with this, or is the software going to be ready in time? If your answer to them is "I can't tell you, we just do stuff on the kanban board and don't think about deadlines," they're (1) going to be less than thrilled with you, decreasing trust, and (2) unable to make their decision effectively. I don't think "there's only "stuff" to be done" is an adequate alternative to deadlines and sprints if it doesn't address the reason organizations use those tools. They're primarily tools for predictability and scaling outbound communication about progress; I think the author mistakenly believes they're supposed to be motivational tools. They're sometimes misused that way, for sure, but that's not the whole picture.

mpweiher 8y ago
> If your answer to them is "I can't tell you, we just do stuff on the kanban board and don't think about deadlines," they're (1) going to be less than thrilled with you, decreasing trust, and (2) unable to make their decision effectively. I think the point is that if you do make those commitments you are just making things up, in reality those commitments are worth pretty much exactly as much as not making the commitments. Where with reality I mean the actual physical reality. I realise that social reality can be different, and even a commitment that you make despite everyone knowing that you don't actually have any basis for making that commitment (no track record, no reasoning, no nothing...) can be valuable.
- falcor84 8y ago
  >I think the point is that if you do make those commitments you are just making things up, in reality those commitments are worth pretty much exactly as much as not making the commitments. Well, reality is not that harsh and there is a middle ground. It definitely is possible to complete things on schedule. Assuming "cost, time and scope - choose two" as a reasonable model, there are trade-offs you can make to get the thing out in time. What the OP argues, and I fully agree, is that it's unsustainable for people to work with deadlines all the time. But I think that discarding deadlines entirely can be competitive suicide. There is a way to put in place deadlines in particular strategic circumstances, assuming (again as the OP implies) you have some control of either scope or cost.
  - admax88q 8y ago
    That's not a reasonable model though. You cannot pick "time+scope". As has been well documented in software adding money to a project does not necessarily make it move any faster.
lima 8y ago
No, the idea is that you don't set hard deadlines for the team - they're pointless. It results in unnecessary stress and work won't get done any faster (maybe in the short term, but it's unsustainable). Either the deadline is too short and your team has to work overtime, or it was too generous and you lose efficiency. The project manager, of course, still needs to be able to make an estimate according the his team's velocity, which he can then communicate to other business divisions. See: https://apenwarr.ca/log/?m=201712 https://apenwarr.ca/log/?m=201712
- Terretta 8y ago
  In fact, Scrum changed the word “commitment” to “forecast”. https://www.scrum.org/resources/commitment-vs-forecast https://www.scrum.org/resources/commitment-vs-forecast “One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it.” Pretty sure the Scrum folks are aware of needs of enterprises and their deadline addiction.
  - lima 8y ago
    Yes - sprints can be a great estimation tool as long as they aren't mistaken for a deadline or performance measurement. In my opinion, it needs be more like drawing a (rough) "this is how far we will get at the current velocity" line somewhere in the sorted backlog, rather than a fixed set of tickets that you expect to get done. Popular tool-driven "agile" workflows where you move tickets into a particular sprint, followed by the admission of defeat at the next sprint planning meeting when you failed to complete all of them, reinforce the idea of "commitments" rather than "forecasts".
- deleted 8y ago
  [deleted]
- brmgb 8y ago
rch 8y ago
I'd simply say that if something isn't ready, then as a general rule, don't make decisions as though it will be ready at a particular time in the future. For instance, buying a home thinking that a new highway will be done around the time you move in could lead to multiple years of disappointment. Voting to allow your city to provide substantial financial incentives could enable the builder to go to extraordinary lengths to get the project done at the appointed time.... but even then, only within reason.
- Lewton 8y ago
  If you run your businsss like this you will be outcompeted by people who make reasonable guesses on when things will be completed
  - rch 8y ago
    Survival bias: companies that guess poorly aren't around to explain why they believed they were being reasonable. ...to expand a bit: you're more likely to benefit from correct forward looking estimates if you have sound alternatives available when those estimates to be less than completely accurate.
  - deleted 8y ago
    [deleted]
  - sporkland 8y ago
    Is there evidence for this? There are some very real examples of software companies that thrive by not providing estimates, valve, blizzard, google, apple, etc. I would assume the dominant factor in software delivery is actually ability solve user problems and not being able to time when those problems will be solved.
cuspycode 8y ago
There are two kinds of deadlines: the ones imposed by objective facts (like for example the Y2K deadline), and the ones imposed by arbitrary decisions (like for example a milestone in a project plan). I think it is important to distinguish the two.
- badfrog 8y ago
  Usually when you set an arbitrary deadline, it quickly becomes less arbitrary. See OP's example of the finance team depending on a certain timing that they were promised.
- laumars 8y ago
  There's also a 3rd kind of deadline and they're the worst kind. It's the "our sales team have already told the customer it will be ready by then so you need to tell me how you're going to achieve that" deadline. I can deal with hard technical deadlines and project milestones - the former is a fact of life and the latter is often required to help focus larger projects. What I emphatically dislike is sales guys making business decisions before checking with the engineering teams to determine how much effort is required to deliver a project.
  - koonsolo 8y ago
    I used to dislike this too, mainly because they put the problem in your bucket. The solution is to not let this problem end up on your side. "We will see what we can do, but since we didn't make any estimate on this, the risk of failing the deadline is on you. If you want to set a proper deadline next time for my team, consult me first so we can do a proper estimation. I hope it works out for you this time." I also had plenty of cases where we had to reach an imposed deadline. Then 2 weeks later you ask "did they find issues?". "No, they didn't deploy it yet"
    - laumars 8y ago
      This isn't something you can get away with in many businesses (at least not in terms of the kind of businesses that would put you in that position to begin with) - and the few you can do this, it's not something you'd want to do frequently because you can end up being seen as an obstruction and that ultimately works against your interests. I've found it's better to work with them on a compromised phased released / MVP so the customer still gets what they asked for and you are still seen a miracle worker albeit without actually having to do anything unrealistic in the end. Unfortunately though, there are some businesses that place their sales team too far ahead of the health of their engineers for any compromise to happen and there isn't really much you can do aside taking the overtime pay and move on shortly afterwards.
jacques_chester 8y ago
An estimate is not a deadline. A deadline is not an estimate. Mixing them up leads to unhappiness. Giving an estimate should not come with the whiff of punishment for probabilistic inaccuracy, potentially due to factors out of one's control. That's what deadlines do. That's why they distort behaviour.
Justsignedup 8y ago
An even simpler way to put it: I have $1,000,000 in the bank. I have 10 engineers. If we don't make at least a break-even income in 6 months I have to fire 10 engineers. So you have 2 months to build something so I can spend 4 months hyping people up to buy a bunch of it or we close down. And I know your engineer asses ain't gonna write bug-free code.
- ThomPete 8y ago
  This is the only deadline which matters.
- andrei_says_ 8y ago
  Given that the amount of communication grows exponentially with the number of people working on the project maybe you could rent out 5 of the engineers and make the project go faster :)
everdev 8y ago
Also, there's a theory that projects take the time you give them. There are some deadlines that are too short that can't be hit, but if you have a project your team has done before in 4 weeks and give them 8 weeks, it'll take 8 weeks. The reason is it can always be improved. There are always more edge cases and more automation that can be added. Plus, many people would gladly work at half speed rather than full speed if the outcome was the same (daily compensation, praise, success, etc.).
- CrLf 8y ago
  If something needs 8 weeks to be done and you give the team 4 weeks to do it, chances are it's going to take 12 weeks.

mpweiher 8y ago

> If your answer to them is "I can't tell you, we just do stuff on the kanban board and don't think about deadlines," they're (1) going to be less than thrilled with you, decreasing trust, and (2) unable to make their decision effectively. I think the point is that if you do make those commitments you are just making things up, in reality those commitments are worth pretty much exactly as much as not making the commitments. Where with reality I mean the actual physical reality. I realise that social reality can be different, and even a commitment that you make despite everyone knowing that you don't actually have any basis for making that commitment (no track record, no reasoning, no nothing...) can be valuable.

falcor84 8y ago
>I think the point is that if you do make those commitments you are just making things up, in reality those commitments are worth pretty much exactly as much as not making the commitments. Well, reality is not that harsh and there is a middle ground. It definitely is possible to complete things on schedule. Assuming "cost, time and scope - choose two" as a reasonable model, there are trade-offs you can make to get the thing out in time. What the OP argues, and I fully agree, is that it's unsustainable for people to work with deadlines all the time. But I think that discarding deadlines entirely can be competitive suicide. There is a way to put in place deadlines in particular strategic circumstances, assuming (again as the OP implies) you have some control of either scope or cost.
- admax88q 8y ago
  That's not a reasonable model though. You cannot pick "time+scope". As has been well documented in software adding money to a project does not necessarily make it move any faster.

lima 8y ago

No, the idea is that you don't set hard deadlines for the team - they're pointless. It results in unnecessary stress and work won't get done any faster (maybe in the short term, but it's unsustainable). Either the deadline is too short and your team has to work overtime, or it was too generous and you lose efficiency. The project manager, of course, still needs to be able to make an estimate according the his team's velocity, which he can then communicate to other business divisions. See: https://apenwarr.ca/log/?m=201712 https://apenwarr.ca/log/?m=201712

Terretta 8y ago
In fact, Scrum changed the word “commitment” to “forecast”. https://www.scrum.org/resources/commitment-vs-forecast https://www.scrum.org/resources/commitment-vs-forecast “One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it.” Pretty sure the Scrum folks are aware of needs of enterprises and their deadline addiction.
- lima 8y ago
  Yes - sprints can be a great estimation tool as long as they aren't mistaken for a deadline or performance measurement. In my opinion, it needs be more like drawing a (rough) "this is how far we will get at the current velocity" line somewhere in the sorted backlog, rather than a fixed set of tickets that you expect to get done. Popular tool-driven "agile" workflows where you move tickets into a particular sprint, followed by the admission of defeat at the next sprint planning meeting when you failed to complete all of them, reinforce the idea of "commitments" rather than "forecasts".
deleted 8y ago
[deleted]
brmgb 8y ago

rch 8y ago

I'd simply say that if something isn't ready, then as a general rule, don't make decisions as though it will be ready at a particular time in the future. For instance, buying a home thinking that a new highway will be done around the time you move in could lead to multiple years of disappointment. Voting to allow your city to provide substantial financial incentives could enable the builder to go to extraordinary lengths to get the project done at the appointed time.... but even then, only within reason.

Lewton 8y ago
If you run your businsss like this you will be outcompeted by people who make reasonable guesses on when things will be completed
- rch 8y ago
  Survival bias: companies that guess poorly aren't around to explain why they believed they were being reasonable. ...to expand a bit: you're more likely to benefit from correct forward looking estimates if you have sound alternatives available when those estimates to be less than completely accurate.
- deleted 8y ago
  [deleted]
- sporkland 8y ago
  Is there evidence for this? There are some very real examples of software companies that thrive by not providing estimates, valve, blizzard, google, apple, etc. I would assume the dominant factor in software delivery is actually ability solve user problems and not being able to time when those problems will be solved.

cuspycode 8y ago

There are two kinds of deadlines: the ones imposed by objective facts (like for example the Y2K deadline), and the ones imposed by arbitrary decisions (like for example a milestone in a project plan). I think it is important to distinguish the two.

badfrog 8y ago
Usually when you set an arbitrary deadline, it quickly becomes less arbitrary. See OP's example of the finance team depending on a certain timing that they were promised.
laumars 8y ago
There's also a 3rd kind of deadline and they're the worst kind. It's the "our sales team have already told the customer it will be ready by then so you need to tell me how you're going to achieve that" deadline. I can deal with hard technical deadlines and project milestones - the former is a fact of life and the latter is often required to help focus larger projects. What I emphatically dislike is sales guys making business decisions before checking with the engineering teams to determine how much effort is required to deliver a project.
- koonsolo 8y ago
  I used to dislike this too, mainly because they put the problem in your bucket. The solution is to not let this problem end up on your side. "We will see what we can do, but since we didn't make any estimate on this, the risk of failing the deadline is on you. If you want to set a proper deadline next time for my team, consult me first so we can do a proper estimation. I hope it works out for you this time." I also had plenty of cases where we had to reach an imposed deadline. Then 2 weeks later you ask "did they find issues?". "No, they didn't deploy it yet"
  - laumars 8y ago
    This isn't something you can get away with in many businesses (at least not in terms of the kind of businesses that would put you in that position to begin with) - and the few you can do this, it's not something you'd want to do frequently because you can end up being seen as an obstruction and that ultimately works against your interests. I've found it's better to work with them on a compromised phased released / MVP so the customer still gets what they asked for and you are still seen a miracle worker albeit without actually having to do anything unrealistic in the end. Unfortunately though, there are some businesses that place their sales team too far ahead of the health of their engineers for any compromise to happen and there isn't really much you can do aside taking the overtime pay and move on shortly afterwards.

jacques_chester 8y ago

An estimate is not a deadline. A deadline is not an estimate. Mixing them up leads to unhappiness. Giving an estimate should not come with the whiff of punishment for probabilistic inaccuracy, potentially due to factors out of one's control. That's what deadlines do. That's why they distort behaviour.

Justsignedup 8y ago

An even simpler way to put it: I have $1,000,000 in the bank. I have 10 engineers. If we don't make at least a break-even income in 6 months I have to fire 10 engineers. So you have 2 months to build something so I can spend 4 months hyping people up to buy a bunch of it or we close down. And I know your engineer asses ain't gonna write bug-free code.

ThomPete 8y ago
This is the only deadline which matters.
andrei_says_ 8y ago
Given that the amount of communication grows exponentially with the number of people working on the project maybe you could rent out 5 of the engineers and make the project go faster :)

everdev 8y ago

Also, there's a theory that projects take the time you give them. There are some deadlines that are too short that can't be hit, but if you have a project your team has done before in 4 weeks and give them 8 weeks, it'll take 8 weeks. The reason is it can always be improved. There are always more edge cases and more automation that can be added. Plus, many people would gladly work at half speed rather than full speed if the outcome was the same (daily compensation, praise, success, etc.).

CrLf 8y ago
If something needs 8 weeks to be done and you give the team 4 weeks to do it, chances are it's going to take 12 weeks.