5 ms·

I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this

I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. My other pet annoyance is management still seems to think that adding more resource to a project makes it faster. Especially "cheaper" resources working in a different country.

lmm 8y ago
> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. I'd say that the biggest failures I've seen have been due to having a specification, and the bigger the project the more important it is not to have one. As the quote goes: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. You can, and should, have specifications for the next ~two weeks of changes that you want to do. These should be verifiable at a user-facing level. But after that you iterate. Trying to specify further in advance or at more detail than what's user-visible is a recipe for disaster.
- andy_ppp 8y ago
  > You can, and should, have specifications for the next ~two weeks of changes that you want to do. We completely agree here - are you saying you've never encountered the "we're agile, no need for specs" mindset?
  - lmm 8y ago
    I've encountered it and not found it to be a problem - if you have good access to someone who can answer questions during development then that's better than a spec. Even without that, as long as you're keeping your iterations short and demoing at the end of them then the worst case is you get things wrong for two weeks and then correct them after. I've found the "we're "agile" but going to have a huge up-front spec" mindset far far more damaging.
- shadowtree 8y ago
  "A complex system designed from scratch never works". And yet we flew to the moon. And have airplanes, and and and. A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through the same, software has freemasons now. But no engineering whatsoever. Example: People still write their own date conversions (and fuck it up).
  - lmm 8y ago
    > And yet we flew to the moon. And have airplanes, and and and. We do, but not by designing from scratch. We achieved those things by incrementally extending existing designs and verifying that the newer, more complex designs had the desired properties. > A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through the same, software has freemasons now. But no engineering whatsoever. The constraints that apply to software are very different from those that apply to construction. What if "throw shit at the wall and see what sticks" really is a better way of making software than "engineering"? > Example: People still write their own date conversions (and fuck it up). Indeed they do. Do you find this is more common in projects that specify and design up front or in projects that don't?
    - igouy 8y ago
      > What if "throw shit at the wall and see what sticks" really is a better way of making software than "engineering"? What if it isn't.
      - lmm 8y ago
        If it isn't, then maybe agile is a bad idea and we should expect to see agile projects fail more often/expensively than non-agile projects. But that's not what we see (at least not what I've seen).
    - andy_ppp 8y ago
      The people making the planes made meticulous changes to the design before anything was built so I really don't think your point is supported by aeroplane manufacturers. The builders weren't just told make it faster and more fuel efficient and to get on with building it.
dragonwriter 8y ago
> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. Backlog items in most processes called agile are specs, and most variations include an activity of assuring that they meet whatever quality standards are in place prior to being eligible for development. It's more common for places claiming to be agile to not have any integrated spec for what has been built than to not have specs of each to-be-built unit, AFAICT.
oldboyFX 8y ago
Speaking from first hand experience, it is possible to build efficiently without detailed specifications. The key is to put boundaries between different parts of the application and allow each developer to take full responsibility for delivering their part. I've had some horrific experiences where multiple developers worked on the same features (without specs) while stepping on each others toes.
- thanatropism 8y ago
  Ha. This depends on developers being able to stand each other during the MVP slog. I've seen launches derailed because nerd #3 didn't like to be told how to do something by nerd #5. Technical talent is a the-odds-are-good-but-the-goods-are-odd kind of deal - at least outside Silly Valley in the developing world. You can hire a huge sum-total-IQ but you can't hire people who can work independently and collaborate.
avinium 8y ago
> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. It depends. With certain projects, the overriding risk is that you're building something that nobody wants. In this case, Agile makes a lot of sense, and specifications are a waste of time until you've validated customer demand. For other projects, you're very confident that demand exists for the product you're building, and specifications start to make a lot of sense. Big caveat though - you can get this assessment very very wrong. "Demand" can be a very open-ended concept (e.g. in the entertainment industry), but that doesn't necessarily translate to user satisfaction. No Man's Sky, for example, probably should have been put in front of players a lot earlier. That means building to a looser spec in shorter cycles with more iteration (more "Agile", for want of a better term). This is why product managers are so important - they need to make this judgment. It's a difficult balancing act to juggle "minimum features and user testing", "grand product vision" and "efficient and manageable development cycles".

lmm 8y ago

> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. I'd say that the biggest failures I've seen have been due to having a specification, and the bigger the project the more important it is not to have one. As the quote goes: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. You can, and should, have specifications for the next ~two weeks of changes that you want to do. These should be verifiable at a user-facing level. But after that you iterate. Trying to specify further in advance or at more detail than what's user-visible is a recipe for disaster.

andy_ppp 8y ago
> You can, and should, have specifications for the next ~two weeks of changes that you want to do. We completely agree here - are you saying you've never encountered the "we're agile, no need for specs" mindset?
- lmm 8y ago
  I've encountered it and not found it to be a problem - if you have good access to someone who can answer questions during development then that's better than a spec. Even without that, as long as you're keeping your iterations short and demoing at the end of them then the worst case is you get things wrong for two weeks and then correct them after. I've found the "we're "agile" but going to have a huge up-front spec" mindset far far more damaging.
shadowtree 8y ago
"A complex system designed from scratch never works". And yet we flew to the moon. And have airplanes, and and and. A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through the same, software has freemasons now. But no engineering whatsoever. Example: People still write their own date conversions (and fuck it up).
- lmm 8y ago
  > And yet we flew to the moon. And have airplanes, and and and. We do, but not by designing from scratch. We achieved those things by incrementally extending existing designs and verifying that the newer, more complex designs had the desired properties. > A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through the same, software has freemasons now. But no engineering whatsoever. The constraints that apply to software are very different from those that apply to construction. What if "throw shit at the wall and see what sticks" really is a better way of making software than "engineering"? > Example: People still write their own date conversions (and fuck it up). Indeed they do. Do you find this is more common in projects that specify and design up front or in projects that don't?
  - igouy 8y ago
    > What if "throw shit at the wall and see what sticks" really is a better way of making software than "engineering"? What if it isn't.
    - lmm 8y ago
      If it isn't, then maybe agile is a bad idea and we should expect to see agile projects fail more often/expensively than non-agile projects. But that's not what we see (at least not what I've seen).
  - andy_ppp 8y ago
    The people making the planes made meticulous changes to the design before anything was built so I really don't think your point is supported by aeroplane manufacturers. The builders weren't just told make it faster and more fuel efficient and to get on with building it.

dragonwriter 8y ago

> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. Backlog items in most processes called agile are specs, and most variations include an activity of assuring that they meet whatever quality standards are in place prior to being eligible for development. It's more common for places claiming to be agile to not have any integrated spec for what has been built than to not have specs of each to-be-built unit, AFAICT.

oldboyFX 8y ago

Speaking from first hand experience, it is possible to build efficiently without detailed specifications. The key is to put boundaries between different parts of the application and allow each developer to take full responsibility for delivering their part. I've had some horrific experiences where multiple developers worked on the same features (without specs) while stepping on each others toes.

thanatropism 8y ago
Ha. This depends on developers being able to stand each other during the MVP slog. I've seen launches derailed because nerd #3 didn't like to be told how to do something by nerd #5. Technical talent is a the-odds-are-good-but-the-goods-are-odd kind of deal - at least outside Silly Valley in the developing world. You can hire a huge sum-total-IQ but you can't hire people who can work independently and collaborate.

avinium 8y ago

> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. It depends. With certain projects, the overriding risk is that you're building something that nobody wants. In this case, Agile makes a lot of sense, and specifications are a waste of time until you've validated customer demand. For other projects, you're very confident that demand exists for the product you're building, and specifications start to make a lot of sense. Big caveat though - you can get this assessment very very wrong. "Demand" can be a very open-ended concept (e.g. in the entertainment industry), but that doesn't necessarily translate to user satisfaction. No Man's Sky, for example, probably should have been put in front of players a lot earlier. That means building to a looser spec in shorter cycles with more iteration (more "Agile", for want of a better term). This is why product managers are so important - they need to make this judgment. It's a difficult balancing act to juggle "minimum features and user testing", "grand product vision" and "efficient and manageable development cycles".