6 ms·

Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting t

Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...

13hours 11y ago
I used to as well, until I started to refuse to do it. It truly is in the best interest of the customer to work this way, and I explain it to them. The ones that understand it and buy into this way of working are the ones I work with.
- soft_dev_person 11y ago
  Sounds awesome. Unfortunately I don't work in my own company. Fortunately, I don't work with sales (much).
eterm 11y ago
Absolutely this, clients need to know their costs upfront. Meanwhile, I've been on the other side, working with a shop that insisted they were agile, and so refused to give an upfront cost. That project ended up delivering a substandard project where key parts did not work well. Their answer was to tell us they would of course be happy to be paid for another 2 week sprint to fix those bugs... As a customer it wasn't very satisfying.
- 13hours 11y ago
  I don't think working fixed price quote would have given you a different outcome though? The team produced bad quality product, fixed cost or agile won't change that. Selecting the team to build the product on price is often a bad idea, and that's all fixed cost gives you above agile (the ability to select on price).
  - eterm 11y ago
    A fixed cost makes it easier to turn and around not pay (in whole or part) if the product is really not up to the standard specified. It's harder to do that if the cost is not fixed but overrunning and the response is "well we just need more time". Also fwiw, the team wasn't selected on price.
    - marcus_holmes 11y ago
      In my experience it's easier and less risky doing it the agile way. You give them a 2-week sprint target. If they fail to hit that, then: a. You don't pay them. b. They're probably going to miss every other target. If you paid the agile shop for everything they did no matter how crap, and withheld payment from the waterfall shop because quality control, then that's got nothing to do with agile vs waterfall, it's got to do with your QC.
    - jsprogrammer 11y ago
      Not pay? Heh. For work performed? OK... That is why my contracts require payment up front.
      - SapphireSun 11y ago
        Sounds like they should have negotiated for a base rate with bonus pay out on meeting QC targets. For heavens sake people, align your incentives!
        codeisawesome 11y ago
        Everyone, on both sides of this river, they need to grow up.
      - st3v3r 11y ago
        To be fair, they're talking about subpar, unacceptable work.
        11y ago
- Zigurd 11y ago
  The problem isn't with the requirement for fixed-time, fixed-bid contracts. The problem is that agile methods and tools, and all the advantages they carry, are incompatible with those requirements: You can't start fast with minimal specs. You can't apply what's been learned along the way unless, miraculously, it costs less and takes less time. You can't make changes to suit changing business goals without a major negotiation on change orders. You can't access most of the benefits of agile inside that box. You CAN, however, find contract developers who have mastered the art of faking agile methods and being buzzword compliant while delivering no feedback that prevents you from having bad ideas implemented in bad ways. You will also find contractors that will lead you down the garden path. You could call them "half agile." They won't warn you that you are asking for something dumb, or unworkable. They will treat your mistakes as revenue enhancement opportunities and lay on the agile talk pretty thick. This is why the "no true agile Scotsman" argument is so easy to make: That's not agile. You have the wrong people. You fail at agile. That's an easy case to prove but it isn't very helpful. Real agile is hard to do and doing it with compromised ingredients, like using low-bid contractors that want to minimize their effort and/or enhance their revenue, that you have stuffed into a fixed-bid box, is agile poison.
- ChemicalWarfare 11y ago
  The question is how this shop ended up getting the gig in the first place ;)
- lliamander 11y ago
  I'm curious, did your contractors host regular demos, sprint retrospectives, etc.? If so, was it clear early on that the results were going to be substandard, or was it a surprise fairly late into the process? I'm not going to debate about whether they were doing "true Agile", but it seems like even without settling upfront costs it would still be possible to control risks by tracking value added vs. cost on a sprint-to-sprint basis. Hopefully it should be evident early on if the project isn't worth it[1]. Of course, this requires that the contractors be able to deliver value incrementally, which might not be possible in all projects. In which case, upfront cost estimates (and more thorough planning) will probably be necessary. [1]In fact, this is exactly why Zed Shaw says he uses Scrum on risky projects(http://zedshaw.com/archive/the-c2i2-hypothesis/ http://zedshaw.com/archive/the-c2i2-hypothesis/)
humanrebar 11y ago
> ...customers that require pretty accurate (cost) estimates prior to even getting the contract. If you require that accurate of an estimate, your business model cannot handle the risk of software development. Really, really wanting an accurate estimate does not make risk go away.
- ams6110 11y ago
  That's not exactly true, but it means holding the customer to exactly what they asked for, and having a formal "change request" process for any deviations. The track record of that model of development is not one of successful on-time delivery, but it does seem to make some types of customers more comfortable, even if it shouldn't.
- true_religion 11y ago
  Estimates can be fairly accurate if they're made for software that's a composition of previously iterated work. If someone asks for a login system with X,Y,Z and you've done that 1000 times, you can be fairly accurate in stating what it will take to do it 1001 times. The issue is when a piece of software is custom, and there's no domain expertise available for the custom bit then you cannot accurate estimate how long it will take because the developers will be learning while doing.
  - ams6110 11y ago
    And some developers bring this on themselves. They could use the boring conservative technology that they know inside and out from the last project, or they could use something that's new and hot this month, which they have never done or have much less experience with (but is exciting). Double whammy if it's an unfamiliar domain and a cutting-edge tech stack.
    - Scarblac 11y ago
      And it takes longer, so more billable hours.
- HillRat 11y ago
jameshart 11y ago
Customers don't need to know the cost, they need to know the price. The most important factor in determining that should be the value of the software to the customer, not the time it will take to produce it.
- DougWebb 11y ago
  True, but difficult to sell, especially to repeat customers who can calculate the price/hr on previous work.
  - jameshart 11y ago
    Let's say they figure out you only spent 100 hours to deliver them $50,000 of value. It's your job to persuade them that that guy on the internet who says they would sell them 100 hours of dev time for just $5,000 will only give them $5,000 of value (if that). If I have a choice between getting someone who delivers value at a rate of $500/hour versus someone who delivers value at $50/hour, and I need $50,000-worth of software, I should choose the more efficient developer, not the cheapest one.
    - DougWebb 11y ago
      For the kinds of projects my company tends to do, when we're getting into repeat business we're generally not competing with other contractors. Our clients know that the other contractors would have a ramp-up cost that we don't, and an unknown working relationship vs our good working relationship. Instead, they look for per-hour discounts and ways to 'cut costs' while delivering the same value. They also typically have their own development team who don't get paid nearly as much per-hour as my company charges, so they look to share more of the work with their internal team. Since we do product, services, and support, including training, it's hard to argue that the internal team can't or shouldn't do the work. It gets complicated, but in the end we mostly come out alright. Our clients are well aware that taking on additional work reduces our likely development cost but increases overhead costs and raises project/schedule risks. It's a tradeoff they accept, and we work with them to ensure the project is successful. My point is, in the real world you can't just charge by the value you provide rather than by the cost of providing that value. That's a simplistic point of view.
kentt 11y ago
I'd love to know more.

Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...

13hours 11y ago

I used to as well, until I started to refuse to do it. It truly is in the best interest of the customer to work this way, and I explain it to them. The ones that understand it and buy into this way of working are the ones I work with.

soft_dev_person 11y ago
Sounds awesome. Unfortunately I don't work in my own company. Fortunately, I don't work with sales (much).

eterm 11y ago

Absolutely this, clients need to know their costs upfront. Meanwhile, I've been on the other side, working with a shop that insisted they were agile, and so refused to give an upfront cost. That project ended up delivering a substandard project where key parts did not work well. Their answer was to tell us they would of course be happy to be paid for another 2 week sprint to fix those bugs... As a customer it wasn't very satisfying.

13hours 11y ago
I don't think working fixed price quote would have given you a different outcome though? The team produced bad quality product, fixed cost or agile won't change that. Selecting the team to build the product on price is often a bad idea, and that's all fixed cost gives you above agile (the ability to select on price).
- eterm 11y ago
  A fixed cost makes it easier to turn and around not pay (in whole or part) if the product is really not up to the standard specified. It's harder to do that if the cost is not fixed but overrunning and the response is "well we just need more time". Also fwiw, the team wasn't selected on price.
  - marcus_holmes 11y ago
    In my experience it's easier and less risky doing it the agile way. You give them a 2-week sprint target. If they fail to hit that, then: a. You don't pay them. b. They're probably going to miss every other target. If you paid the agile shop for everything they did no matter how crap, and withheld payment from the waterfall shop because quality control, then that's got nothing to do with agile vs waterfall, it's got to do with your QC.
  - jsprogrammer 11y ago
    Not pay? Heh. For work performed? OK... That is why my contracts require payment up front.
    - SapphireSun 11y ago
      Sounds like they should have negotiated for a base rate with bonus pay out on meeting QC targets. For heavens sake people, align your incentives!
      - codeisawesome 11y ago
        Everyone, on both sides of this river, they need to grow up.
    - st3v3r 11y ago
      To be fair, they're talking about subpar, unacceptable work.
      - 11y ago
Zigurd 11y ago
The problem isn't with the requirement for fixed-time, fixed-bid contracts. The problem is that agile methods and tools, and all the advantages they carry, are incompatible with those requirements: You can't start fast with minimal specs. You can't apply what's been learned along the way unless, miraculously, it costs less and takes less time. You can't make changes to suit changing business goals without a major negotiation on change orders. You can't access most of the benefits of agile inside that box. You CAN, however, find contract developers who have mastered the art of faking agile methods and being buzzword compliant while delivering no feedback that prevents you from having bad ideas implemented in bad ways. You will also find contractors that will lead you down the garden path. You could call them "half agile." They won't warn you that you are asking for something dumb, or unworkable. They will treat your mistakes as revenue enhancement opportunities and lay on the agile talk pretty thick. This is why the "no true agile Scotsman" argument is so easy to make: That's not agile. You have the wrong people. You fail at agile. That's an easy case to prove but it isn't very helpful. Real agile is hard to do and doing it with compromised ingredients, like using low-bid contractors that want to minimize their effort and/or enhance their revenue, that you have stuffed into a fixed-bid box, is agile poison.
ChemicalWarfare 11y ago
The question is how this shop ended up getting the gig in the first place ;)
lliamander 11y ago
I'm curious, did your contractors host regular demos, sprint retrospectives, etc.? If so, was it clear early on that the results were going to be substandard, or was it a surprise fairly late into the process? I'm not going to debate about whether they were doing "true Agile", but it seems like even without settling upfront costs it would still be possible to control risks by tracking value added vs. cost on a sprint-to-sprint basis. Hopefully it should be evident early on if the project isn't worth it[1]. Of course, this requires that the contractors be able to deliver value incrementally, which might not be possible in all projects. In which case, upfront cost estimates (and more thorough planning) will probably be necessary. [1]In fact, this is exactly why Zed Shaw says he uses Scrum on risky projects(http://zedshaw.com/archive/the-c2i2-hypothesis/ http://zedshaw.com/archive/the-c2i2-hypothesis/)

humanrebar 11y ago

> ...customers that require pretty accurate (cost) estimates prior to even getting the contract. If you require that accurate of an estimate, your business model cannot handle the risk of software development. Really, really wanting an accurate estimate does not make risk go away.

ams6110 11y ago
That's not exactly true, but it means holding the customer to exactly what they asked for, and having a formal "change request" process for any deviations. The track record of that model of development is not one of successful on-time delivery, but it does seem to make some types of customers more comfortable, even if it shouldn't.
true_religion 11y ago
Estimates can be fairly accurate if they're made for software that's a composition of previously iterated work. If someone asks for a login system with X,Y,Z and you've done that 1000 times, you can be fairly accurate in stating what it will take to do it 1001 times. The issue is when a piece of software is custom, and there's no domain expertise available for the custom bit then you cannot accurate estimate how long it will take because the developers will be learning while doing.
- ams6110 11y ago
  And some developers bring this on themselves. They could use the boring conservative technology that they know inside and out from the last project, or they could use something that's new and hot this month, which they have never done or have much less experience with (but is exciting). Double whammy if it's an unfamiliar domain and a cutting-edge tech stack.
  - Scarblac 11y ago
    And it takes longer, so more billable hours.
HillRat 11y ago

jameshart 11y ago

Customers don't need to know the cost, they need to know the price. The most important factor in determining that should be the value of the software to the customer, not the time it will take to produce it.

DougWebb 11y ago
True, but difficult to sell, especially to repeat customers who can calculate the price/hr on previous work.
- jameshart 11y ago
  Let's say they figure out you only spent 100 hours to deliver them $50,000 of value. It's your job to persuade them that that guy on the internet who says they would sell them 100 hours of dev time for just $5,000 will only give them $5,000 of value (if that). If I have a choice between getting someone who delivers value at a rate of $500/hour versus someone who delivers value at $50/hour, and I need $50,000-worth of software, I should choose the more efficient developer, not the cheapest one.
  - DougWebb 11y ago
    For the kinds of projects my company tends to do, when we're getting into repeat business we're generally not competing with other contractors. Our clients know that the other contractors would have a ramp-up cost that we don't, and an unknown working relationship vs our good working relationship. Instead, they look for per-hour discounts and ways to 'cut costs' while delivering the same value. They also typically have their own development team who don't get paid nearly as much per-hour as my company charges, so they look to share more of the work with their internal team. Since we do product, services, and support, including training, it's hard to argue that the internal team can't or shouldn't do the work. It gets complicated, but in the end we mostly come out alright. Our clients are well aware that taking on additional work reduces our likely development cost but increases overhead costs and raises project/schedule risks. It's a tradeoff they accept, and we work with them to ensure the project is successful. My point is, in the real world you can't just charge by the value you provide rather than by the cost of providing that value. That's a simplistic point of view.

kentt 11y ago

I'd love to know more.