[crdoconnor]

I've seen many teams claim to have switched from 'waterfall' to 'agile', but the only ones that haven't slipped back into a 'waterfall'-like mode after a few bad releases have been ones that put a strong emphasis on tools - specifically testing tools.

Good interpersonal dynamics are important, but the sheer level of irony that the first rule of the Agile manifesto emphasizes deprioritizing the main thing that will actually get you away from waterfall-like development is pretty staggering, IMHO.

Never mind. Forget the tests. If you have a meeting at 11am every morning where anybody who sits down is shouted at then you've done it. You're "agile".

[edejong]

The manifesto emphasises the importance of sharing the values of a method, before actually applying the method. It's the difference between wisdom and dogma. Take tests for example: blindly going for coverage metrics will be much less effective compared to having a deep, shared understanding of the pro's and con's of testing. To know that your co-workers have a similar understanding of the methodologies, makes the methodology itself of lesser (or no) importance.

Personally, I am of the opinion that a strong emphasis on test-driven development in the long run will cause waterfall-style development. Tests are all about risk-prevention, instead of risk-mitigation. Prevention eventually becomes exceedingly expensive, whereas mitigation is all about building robustness into the running system. Due to that, the scalability of mitigation systems, such as true micro-services or actor-systems, are inherently more dynamic and cause less latency in development.

I don't understand your last statement. It seems to confirm my position: "... anybody who sits down is shouted at ... ". The process (standing up, not sitting down) is less important than good team dynamics (not getting shouted at).

(edit: down-voters, please share why you down-vote! I'd like to know. Also, please don't down-vote based on opinion, but on weakness of argumentation instead.)

[jrs235]

I think you are getting down voted for questioning TDD. TDD seems to be another religion. You're insulting a sacred cow for some.

Anyways, I would really like the avenue of thought you've planted in me to flesh out: risk prevention vs mitigation and how it applies to software development.

[tome]

> edit: down-voters, please share why you down-vote!

The one thing that I religiously downvote on HN is complaints about down votes.

[edejong]

Well, at least I now know why you down-voted :) Sometimes I ask because I feel a comment was properly written, non-offensive and with reasonable argumentation. I put time and effort into finding the right words and thought through my argumentation multiple times before writing it down. Since English is not my mother-tongue, I'd like to know if i caused a possible misunderstanding. Hopefully others share my belief that down-voting should be reserved to punish abusive behaviour.

[tome]

I understand the desire for an explanation but more often than not in my experience a comment that has quickly been downvoted to in a fit of follow-the-leader will soon be voted back up into positive territory. You just have to be patient :)

[jrs235]

I usually only down vote people who begin or include 'i know I'm going to get down voted...' in their original post. If someone edits asking for explanation I usually give them leeway... It tells me they are monitoring the conversation and willing to engage thoughtfully.

[crdoconnor]

>Take tests for example: blindly going for coverage metrics will be much less effective...

I agree. However, this is about tools and processes, so it's not really relevant to my argument, which is that you shouldn't explicitly deprioritize tools and processes.

>I don't understand your last statement.

I'm making fun of people who cargo cult 'agile'. Actually standing up is the least important feature of stand ups. Sitting down during a stand up and seeing people's reactions is is a good litmus test. It highlights those people who put a great emphasis on non-functional rituals.

[edejong]

I was trying to convey that fostering an environment within which tools and methodologies can be understood for their specific merits is more important than the tools and methodologies themselves. Or: a tool shouldn't be a crutch, but a training aid. At least, that's how I interpret it.

Obviously, the true spirit of the agile manifesto is the non-prescriptive, ambiguous wording.

Unfortunately, 'scrum' has come to be known as 'agile', which I think is an unfortunate consequence of all the cargo-culting going on. Rituals are fine, as long as they have any depth and identity to them. The Scrum rituals are shallow, simplistic and feeble. Without identity it is no wonder many participant want them to be over as soon as possible...

[crdoconnor]

I'll agree that the manifesto is vague enough that you could reinterpret it your way. However, its inimical vagueness is hardly a point in its favor, since all that means is that people project whatever meaning that they really want on to it. Meaning that it has very little meaning.

But it still strongly implies that tools basically don't matter, and I've worked on teams where people did choose to interpret it that way, which ironically led to waterfalling...

[edejong]

Yes, I agree with that standpoint. The agile manifesto is too vague to be used prescriptive. It requires a certain amount of intelligence and wisdom to acknowledge that. It's also not able to bootstrap: you need to be grounded in the philosophical underpinnings in order to understand it.

I'd really could go on to talk about those underpinnings, saying that they are mystic and grounded in certain Western cultural ideals (that are deteriorating at a rapid pace at the moment). But, HN is probably not the right place to discuss it and it is 1 AM here.

[jrs235]

> you shouldn't explicitly deprioritize tools and processes

Is it fairly safe to say that the goal of most [software] companies isn't to just make good software or to develop [good] software fast but to find a repeatable process to make good software quickly? And this is why tools and processes are still needed.

[Clubber]

Waterfall hasn't really been used widespread in years (70s, 80s?), well before Agile in the aughts. It's more of a red herring to compare agile to something. It's like saying memory foam is way better than sleeping on the floor (completely ignoring traditional mattresses).

We always used a pseudo waterfall but with much shorter iterations. We called it cinnabun. For example, we would cut 4 CDs a year so our iterations were about 3 months. We would plan what we wanted to do in the 3 months (bugs + features), code it, developer test it and throw it to QA. Once we had a good build, we would distribute it, have a small celebration the start over again.

It's similar to agile, but with the 3 month cycles, you could actually plan and design a lot better because you could see out a little further.

I suspect Agile is so popular because the business doesn't want to think of, make and stick to a decision for 3 months.

[crdoconnor]

You just said that waterfall hasn't been widespread since the 80s and then basically admitted to using it :)

These days it still happens, it's just that few people call it that unless they want to be rude.

IMHO waterfall is a natural state to revert to if you have a test deficit, technical debt and you don't trust releases that haven't gone through a round of manual testing first. The level of faith you have in your code/tests basically dictates the length of the mini-waterfall iterations.

Continuous delivery (the exact opposite of waterfall) comes equally naturally if you have no test deficit. It doesn't require some kind of paradigm shift or a special 'agile mindset', it just requires an automated regression test suite you can trust.

(this usually only happens when you write the tests first, but it's not strictly 100% necessary)

[Clubber]

Well, the definition of waterfall I grew up with was that you plan the entire project end-to-end with MS Project or something similar, including requirements gathering, delivery milestones, timelines and resource allocation. This was mainly done when building massive, in-house mainframe or AS400 apps that were expected to keep running for decades.

Waterfall, as described, carried on through the PC revolution but was falling out of favor to version scoping and planning (iterative). Iterations could be whatever you wanted. There were backlogs, usually a list of tickets in some software system like Start Team or whatever. I think Visual Source Safe had this as well. It's fairly simple, so our UI designer just build one in a week or so.

Agile and it's short sprints (2-3 weeks) fits nicely with SAAS (websites) because their distribution costs (comparatively none) doesn't lend itself to versioning (or isn't encumbered by it). I just find that the short iteration isn't ideal because the short iteration, and lack of long-vision planning doesn't allow designers to develop in a "big-picture" way.

>it just requires an automated regression test suite you can trust.

Testing doesn't really fit anywhere in the equation as a differentiation. There was automated unit testing before Agile, there just weren't any common frameworks and it usually involved custom test harnesses (usually a console/terminal app to run and log stuff).

It also requires automated deployment which can be tricky, especially when there is a single / clustered relational database involved.

In conclusion, I like the Agile methodology, I just think the short 2-3 week iterations don't fit every organization and if you can handle 1-2 month sprints, you'll have better designed software because you can see further into the future.

[crdoconnor]

>I just find that the short iteration isn't ideal because the short iteration, and lack of long-vision planning doesn't allow designers to develop in a "big-picture" way.

I don't think that kind of planning is particularly valuable. I've worked in many really unsuccessful companies that had a long term plan (which never really came to fruition) and some really successful companies which may have had a blurry long term vision about their general direction but mainly just reacted to customer input and market conditions as they saw fit.

The Linux kernel is developed in exactly this way too and it's hardly a model of an unsuccessful software project. It's not just me.

>Testing doesn't really fit anywhere in the equation as a differentiation. There was automated unit testing before Agile

Automated testing was barely used though. XP, the progenitor of agile, did emphasize it though.

It 'fits' because once you do enough of it (and you have automated releases), it just sort of stops making sense having release schedules. Every change to the code base that gets through code review and the test suite is releasable so why not release it?

>It also requires automated deployment which can be tricky

I think 2009 was the last time I worked on a system that didn't have automated deployment.

>I just think the short 2-3 week iterations don't fit every organization and if you can handle 1-2 month sprints, you'll have better designed software because you can see further into the future.

I've always aimed for iterations that are as short and tight as possible because the future - meaning how your software is really going to be used - is by far and away the least predictable thing you'll have to deal with. The most you can do is react to that quickly before veering too far down a dead end.

Hell, even when I develop software for myself I end up being surprised about how I actually end up using it.