5 ms·

>This just indicates a failure to perform a proper Analysis/Specification/Requirements phase, with relevant qualifications steps. It doesn't matter if you're a

>This just indicates a failure to perform a proper Analysis/Specification/Requirements phase, with relevant qualifications steps. It doesn't matter if you're a Manager or a lowly Developer - if you can't adequately qualify the requirements and specifications, the analysis is simply not complete. But that view of requirements is not borne out by the reality for most projects. You're presuming that it's possible to gather the "ideal requirements" when the project first starts, with enough due diligence - and also, that those requirements are fixed. In my current job, we're producing a service that has to court a handful of very large clients. Even if there was a well-defined idea of what the service should eventually look like in 5 years, a lot of feedback is required to discover how it should look now. Which client needs more attention? Where is the biggest opportunity for additional value? How are users actually using the service, ignoring what they said they were going to do with it? That last part is the most important - requirements are in reality a feedback process for which the existing product is one input. You cannot analyse how users will empirically interact with a product that does not yet exist. Abstract analysis is no substitute for data.

boffinAudio 5y ago
If you can't formulate actionable requirements, you're either not the domain expert, or not communicating properly with the domain expert. What your service looks like now and what it looks like in five years are obviously two different questions, but a proper analysis will divide the issue between now and 5 years from now and come up with requirements that fill the gaps. This doesn't mean things get set in stone and aren't adaptable to changing needs - when this condition is identified, the manger/developer need only apply the workflow again, and revise the specifications with the updated data, and a new development plan can be formulated. Maybe this is 'agile', but again - it speaks to the fact that waterfall is a naturally occurring phenomenon in engineering/technical matters, and thus should be applied consistently, completely, in order to provide fruitful results. > You cannot analyse how users will empirically interact with a product that does not yet exist. I don't agree with this, as I believe it is very, very glib. You can of course empirically interact, by wearing the user hat. Too often the developer/manager/user hats are considered adversarial - but when the decision is made to be flexible about which of these hats one is wearing, during analysis, makes all the difference between whether your product is successful or not. Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field. >You're presuming that it's possible to gather the "ideal requirements" when the project first starts, with enough due diligence - and also, that those requirements are fixed. I make the claim that this ideal can be attained, by ensuring that the early steps in the waterfall process are actually applied. You are correct in noting that "when you don't do things right, right things don't happen", however ..
- pjc50 5y ago
  > > You cannot analyse how users will empirically interact with a product that does not yet exist. > I don't agree with this, as I believe it is very, very glib This implies that all A/B testing is worthless, which is .. surprising.
  - boffinAudio 5y ago
    > > You cannot analyse how users will empirically interact with a product that does not yet exist. You can certainly refine the software over time (A/B testing, if you will) to more closely attain the ideal, which you may not have well defined at the beginning of the project if you don't perform an adequate review of the needs of the user. But you can certainly also complete a user analysis that produces requirements, which when fulfilled, solve the problem in its entirety for the user. These two extremes are not absolute - sometimes, if the analysis is incomplete, A/B testing can rescue the project regardless of how poorly the first analysis was performed - but A/B testing, it could be argued, is applying waterfall properly: iteratively, as intended... but by all means, call it 'agile' if that makes the difference to the team involved.
    - Kim_Bruning 5y ago
      Wait a minute, you're a proponent of iterative approaches? In modern parlance most people put <non-iterative approaches> under the heading "waterfall". Can you specify which book/process/document(s) you are using in your day-to-day? This could be very interesting in future discussions with clients, to say the least!
      - Jtsummers 5y ago
        Waterfall is indeed a decidedly non-iterative approach. Anyone calling an iterative approach "Waterfall" is, well, confused about the terms. As soon as you add iteration, you're doing something else. Something intelligent. Often some variation of Iterative & Incremental (of which Scrum is an extreme form), Evolutionary, or perhaps the V-Model.
      - 5y ago

boffinAudio 5y ago

If you can't formulate actionable requirements, you're either not the domain expert, or not communicating properly with the domain expert. What your service looks like now and what it looks like in five years are obviously two different questions, but a proper analysis will divide the issue between now and 5 years from now and come up with requirements that fill the gaps. This doesn't mean things get set in stone and aren't adaptable to changing needs - when this condition is identified, the manger/developer need only apply the workflow again, and revise the specifications with the updated data, and a new development plan can be formulated. Maybe this is 'agile', but again - it speaks to the fact that waterfall is a naturally occurring phenomenon in engineering/technical matters, and thus should be applied consistently, completely, in order to provide fruitful results. > You cannot analyse how users will empirically interact with a product that does not yet exist. I don't agree with this, as I believe it is very, very glib. You can of course empirically interact, by wearing the user hat. Too often the developer/manager/user hats are considered adversarial - but when the decision is made to be flexible about which of these hats one is wearing, during analysis, makes all the difference between whether your product is successful or not. Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field. >You're presuming that it's possible to gather the "ideal requirements" when the project first starts, with enough due diligence - and also, that those requirements are fixed. I make the claim that this ideal can be attained, by ensuring that the early steps in the waterfall process are actually applied. You are correct in noting that "when you don't do things right, right things don't happen", however ..

pjc50 5y ago
> > You cannot analyse how users will empirically interact with a product that does not yet exist. > I don't agree with this, as I believe it is very, very glib This implies that all A/B testing is worthless, which is .. surprising.
- boffinAudio 5y ago
  > > You cannot analyse how users will empirically interact with a product that does not yet exist. You can certainly refine the software over time (A/B testing, if you will) to more closely attain the ideal, which you may not have well defined at the beginning of the project if you don't perform an adequate review of the needs of the user. But you can certainly also complete a user analysis that produces requirements, which when fulfilled, solve the problem in its entirety for the user. These two extremes are not absolute - sometimes, if the analysis is incomplete, A/B testing can rescue the project regardless of how poorly the first analysis was performed - but A/B testing, it could be argued, is applying waterfall properly: iteratively, as intended... but by all means, call it 'agile' if that makes the difference to the team involved.
  - Kim_Bruning 5y ago
    Wait a minute, you're a proponent of iterative approaches? In modern parlance most people put <non-iterative approaches> under the heading "waterfall". Can you specify which book/process/document(s) you are using in your day-to-day? This could be very interesting in future discussions with clients, to say the least!
    - Jtsummers 5y ago
      Waterfall is indeed a decidedly non-iterative approach. Anyone calling an iterative approach "Waterfall" is, well, confused about the terms. As soon as you add iteration, you're doing something else. Something intelligent. Often some variation of Iterative & Incremental (of which Scrum is an extreme form), Evolutionary, or perhaps the V-Model.
    - 5y ago