3 ms·

You are ignoring what I am saying – these are guidelines and principles to follow in development processes, not absolute requirements. If a requirement for the

You are ignoring what I am saying – these are guidelines and principles to follow in development processes, not absolute requirements. If a requirement for the system you are delivering is comprehensive, complete documentation, then you can deliver that. The point is that "comprehensive documentation" without "working software" is useless.

kuschku 11y ago
No, it is not. Your software might be working later on – and at the same time, someone else can write software depending on yours, based on just the documentation. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones.
- matthewmacleod 11y ago
  No, it is not. Your software might be working later on It might be, but it almost certainly won't be. See the errata to any set of documentation. But this is a digression – if the acceptance of your product or feature requires documentation of interfaces in advance, then that's a requirement that can be met regardless of the development process that you use. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones. No, that's what incorrectly designed, implemented or tested software leads to. But again – if documentation is required, using an agile process in no way restricts your ability to meet that requirement
  - kuschku 11y ago
    But when you have to document and plan everything you write before you do so, isn’t that again waterfall? Are you just telling me that waterfall is also agile?
    - matthewmacleod 11y ago
      Are you just telling me that waterfall is also agile? No, I'm obviously not communicating effectively. Documentation is a deliverable component of a software system. As a result, it can be tracked and managed just like any other deliverable component. In any real software system, the initial documentation will not reflect the finished system. That's inevitable – it's why we have errata. The difference between 'agile' and 'waterfall' in this case will be whether those changes to documentation are delivered at the end of development, or as they are required by changes to other parts of the system.
      - kuschku 11y ago
        The issue is when other software is built upon those initial documentation of your system. Third party services depending on you having a stable API, for example. You can’t just break support for them, so what do you do in agile?
        gnoway 11y ago
        Don't break support for them? There are still requirements, there is still design. If you have a customer depending on your API, that is a requirement. Agile doesn't mean requirements go away.
        kuschku 11y ago
        And if your implementation never changes, but you just do minor changes – isn’t that the maintenance phase of Waterfall again?
        gnoway 11y ago
        I don't like trying to make direct comparisons between Agile and Waterfall as if they are two separate mutually-exclusive approaches to development. A product developed in an Agile process still has a 'maintenance phase'; the idea of software maintenance is not a Waterfall concept, it's a Software Development concept. One thing I think you're having trouble with (maybe) is that this article was about Scrum, but you're attacking Agile. Scrum is an implementation of Agile, or maybe better characterized as a process facilitating Agile development, but it is not uniquely Agile. There are other Agile implementations/processes (Kanban, XP, etc.). Agile is more about attitude than implementation. What Scrum is attempting to do is break down big ideas into small workable units, and help teams organize, assign, track and complete those work units efficiently. It separates the development cycle into several sprints: a team works a selected amount of items per sprint based on their capacity vs. the 'weight' of those items. If the development process using Scrum incorporates accepting changes to requirements or the design along the way, it's Agile. If it doesn't, Scrum can look a lot like a series of tiny waterfalls; you can absolutely have a Waterfall process where your teams organize and execute work like Scrum. The most important thing to keep in mind is that neither Agile nor Scrum dictate what you consider to be a finished product, or a successful product. The standard of quality you added to one of your earlier comments is absolutely achievable using Scrum or another Agile process - in fact, it is the stated goal of Agile to turn out a high quality product which meets stated requirements.

kuschku 11y ago

No, it is not. Your software might be working later on – and at the same time, someone else can write software depending on yours, based on just the documentation. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones.

matthewmacleod 11y ago
No, it is not. Your software might be working later on It might be, but it almost certainly won't be. See the errata to any set of documentation. But this is a digression – if the acceptance of your product or feature requires documentation of interfaces in advance, then that's a requirement that can be met regardless of the development process that you use. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones. No, that's what incorrectly designed, implemented or tested software leads to. But again – if documentation is required, using an agile process in no way restricts your ability to meet that requirement
- kuschku 11y ago
  But when you have to document and plan everything you write before you do so, isn’t that again waterfall? Are you just telling me that waterfall is also agile?
  - matthewmacleod 11y ago
    Are you just telling me that waterfall is also agile? No, I'm obviously not communicating effectively. Documentation is a deliverable component of a software system. As a result, it can be tracked and managed just like any other deliverable component. In any real software system, the initial documentation will not reflect the finished system. That's inevitable – it's why we have errata. The difference between 'agile' and 'waterfall' in this case will be whether those changes to documentation are delivered at the end of development, or as they are required by changes to other parts of the system.
    - kuschku 11y ago
      The issue is when other software is built upon those initial documentation of your system. Third party services depending on you having a stable API, for example. You can’t just break support for them, so what do you do in agile?
      - gnoway 11y ago
        Don't break support for them? There are still requirements, there is still design. If you have a customer depending on your API, that is a requirement. Agile doesn't mean requirements go away.
        kuschku 11y ago
        And if your implementation never changes, but you just do minor changes – isn’t that the maintenance phase of Waterfall again?
        gnoway 11y ago
        I don't like trying to make direct comparisons between Agile and Waterfall as if they are two separate mutually-exclusive approaches to development. A product developed in an Agile process still has a 'maintenance phase'; the idea of software maintenance is not a Waterfall concept, it's a Software Development concept. One thing I think you're having trouble with (maybe) is that this article was about Scrum, but you're attacking Agile. Scrum is an implementation of Agile, or maybe better characterized as a process facilitating Agile development, but it is not uniquely Agile. There are other Agile implementations/processes (Kanban, XP, etc.). Agile is more about attitude than implementation. What Scrum is attempting to do is break down big ideas into small workable units, and help teams organize, assign, track and complete those work units efficiently. It separates the development cycle into several sprints: a team works a selected amount of items per sprint based on their capacity vs. the 'weight' of those items. If the development process using Scrum incorporates accepting changes to requirements or the design along the way, it's Agile. If it doesn't, Scrum can look a lot like a series of tiny waterfalls; you can absolutely have a Waterfall process where your teams organize and execute work like Scrum. The most important thing to keep in mind is that neither Agile nor Scrum dictate what you consider to be a finished product, or a successful product. The standard of quality you added to one of your earlier comments is absolutely achievable using Scrum or another Agile process - in fact, it is the stated goal of Agile to turn out a high quality product which meets stated requirements.