3 ms·

One comment - the article mentions that Waterfall was basically the only approach used prior to agile. This is false. In some industries waterfall was used, but

One comment - the article mentions that Waterfall was basically the only approach used prior to agile. This is false. In some industries waterfall was used, but in others software was designed and driven incrementally just as with core agile. The work I did in fixed income brokerages in the early 90s was largely ad hoc agile.

Zigurd 3y ago
Scrum is just one offshoot of Agile. It has become laden with jargon, Scrum-specific job titles, and rapidly trained Scrum Masters. This obscures the fact that a competent team can start with traditional jobs and roles and use The Manifesto for Agile Software Development as their guide, with some modifications for a remote, Slack/Zoom world. Don't be afraid to dump Scrum.
- cylinder714 3y ago
  It seems like scrum is the very antithesis of "Individuals and interactions over processes and tools."
- Scubabear68 3y ago
  Agreed. This is more or less what we did in the 90s, deliver quickly and incrementally with right-sized processes. Scrum adds so much complexity, heavy processes and endless meetings it is truly incredible.
  - switchbak 3y ago
    The XP folks crystallized what a lot of people were doing (in ad-hoc ways) and documented it so others could reuse the learnings more easily. [There's more to it than that, but that's the core of it] I think that's in-line with what you described above. I also think it captured what a lot of folks were trying to do at the time: shorten feedback cycles with RAD, etc. Scrum - or whatever it is that we see in the wild that's called Scrum - is exactly how you (and the article) describe. The way I see it, the corporate types were scared of the devs actually being self-managing/self-optimizing teams, and decided to turn to an Agile-Lite that they could sell as being new and shiney, but it's still the same command-and-control distrustful crap under the hood. (Non-Scrum) Agile did a great job at the lower layers (devs, facilitators), but nothing can change that much if you don't affect the management and exec levels.
nottorp 3y ago
Every piece of work I've ever done was done in the spirit of agile. Just without the religion.
SAI_Peregrinus 3y ago
[Waterfall](https://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf https://leadinganswers.typepad.com/leading_answers/files/ori...) was an incremental design process directly in opposition to the hirearchial process that it's commonly conflated with. That's the paper that coined the term Waterfall, note the contrast between the final Waterfall process from the traditional process (figure 10). "Documentation Driven Development" is basically Royce's Waterfall under a different name. Waterfall has the following 5 requirements/steps: 1. Design first. It'll get replaced (see step 3), but is needed for requirement 2. 2. Document the design. This defines what you're building (this time around) and the tests. 3. Do it twice (build a MVP, test, refactor & replace it as requirements become clear based on customer feedback, update the design & docs & tests, use those tests for the improved version). 4. Plan, control, and monitor testing. 5. Involve the customer. Requirement 3 is what makes Waterfall inherently an incremental iterative process.
- rawgabbit 3y ago
  18F basically follows the process you just described and calls it the agile with a straight face. https://guides.18f.gov/agile/18f-agile-approach/ https://guides.18f.gov/agile/18f-agile-approach/
  - SAI_Peregrinus 3y ago
    Most "Agile" proponents think of Waterfall as diagram 1 from the Waterfall paper, when in fact diagram 1 was the process Waterfall aimed to replace. It mostly gets used as a straw man process to oppose, few people seem to have ever read the Waterfall paper to begin with.
RaftPeople 3y ago
> but in others software was designed and driven incrementally just as with core agile That's my experience also. Since the early 80's, every project I've been involved in was managed with a semi-flexible, pragmatic approach that involved breaking down the problem into smaller chunks, regular communication with the customer, etc.

Zigurd 3y ago

Scrum is just one offshoot of Agile. It has become laden with jargon, Scrum-specific job titles, and rapidly trained Scrum Masters. This obscures the fact that a competent team can start with traditional jobs and roles and use The Manifesto for Agile Software Development as their guide, with some modifications for a remote, Slack/Zoom world. Don't be afraid to dump Scrum.

cylinder714 3y ago
It seems like scrum is the very antithesis of "Individuals and interactions over processes and tools."
Scubabear68 3y ago
Agreed. This is more or less what we did in the 90s, deliver quickly and incrementally with right-sized processes. Scrum adds so much complexity, heavy processes and endless meetings it is truly incredible.
- switchbak 3y ago
  The XP folks crystallized what a lot of people were doing (in ad-hoc ways) and documented it so others could reuse the learnings more easily. [There's more to it than that, but that's the core of it] I think that's in-line with what you described above. I also think it captured what a lot of folks were trying to do at the time: shorten feedback cycles with RAD, etc. Scrum - or whatever it is that we see in the wild that's called Scrum - is exactly how you (and the article) describe. The way I see it, the corporate types were scared of the devs actually being self-managing/self-optimizing teams, and decided to turn to an Agile-Lite that they could sell as being new and shiney, but it's still the same command-and-control distrustful crap under the hood. (Non-Scrum) Agile did a great job at the lower layers (devs, facilitators), but nothing can change that much if you don't affect the management and exec levels.

nottorp 3y ago

Every piece of work I've ever done was done in the spirit of agile. Just without the religion.

SAI_Peregrinus 3y ago

[Waterfall](https://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf https://leadinganswers.typepad.com/leading_answers/files/ori...) was an incremental design process directly in opposition to the hirearchial process that it's commonly conflated with. That's the paper that coined the term Waterfall, note the contrast between the final Waterfall process from the traditional process (figure 10). "Documentation Driven Development" is basically Royce's Waterfall under a different name. Waterfall has the following 5 requirements/steps: 1. Design first. It'll get replaced (see step 3), but is needed for requirement 2. 2. Document the design. This defines what you're building (this time around) and the tests. 3. Do it twice (build a MVP, test, refactor & replace it as requirements become clear based on customer feedback, update the design & docs & tests, use those tests for the improved version). 4. Plan, control, and monitor testing. 5. Involve the customer. Requirement 3 is what makes Waterfall inherently an incremental iterative process.

rawgabbit 3y ago
18F basically follows the process you just described and calls it the agile with a straight face. https://guides.18f.gov/agile/18f-agile-approach/ https://guides.18f.gov/agile/18f-agile-approach/
- SAI_Peregrinus 3y ago
  Most "Agile" proponents think of Waterfall as diagram 1 from the Waterfall paper, when in fact diagram 1 was the process Waterfall aimed to replace. It mostly gets used as a straw man process to oppose, few people seem to have ever read the Waterfall paper to begin with.

RaftPeople 3y ago

> but in others software was designed and driven incrementally just as with core agile That's my experience also. Since the early 80's, every project I've been involved in was managed with a semi-flexible, pragmatic approach that involved breaking down the problem into smaller chunks, regular communication with the customer, etc.