DEV Community

Discussion on: Mockery of agile

Collapse
 
codemouse92 profile image
Jason C. McDonald

I agree that Agile has its place, but it has certainly always struck me as the manifest idealism of starry-eyed business majors. It would be amazing, if it weren't for the fundamental problem that destroys every well-meaning methodology in this industry: software is weird.

Collapse
 
rockymm profile image
Rade Martinović

I would disagree on several levels. First of all, people are wierd too. Second of all, agile actually embraces the wierdness of both software and people. With the right mindset it is very functional and sets up very nice environment to work in.

Without dedication and understanding, it sets up a very frustrating and unproductive environment.

Collapse
 
stevenrcfox profile image
Steven Fox

Except Agile Manifest was written by Software developers. They saw the multiple layers of translation by business people as inefficient and error prone compared to speakind directly with the customer

Collapse
 
jones1618 profile image
Stephen Jones • Edited

In fact, the methodology that embodied the "starry-eyed idealism of business majors" was Waterfall/SDLC. Imagine believing that business wonks could sit in a room and define every aspect of a huge, six-month development effort down to the user interface and then predict (with the accuracy of a train schedule) when each component and feature would be delivered. Now that's a fantasy.

By comparison, Agile is a steely-eyed practical acknowledgement that software is weirdly fluid, always in negotiation and what the client wants delivered is not 500 features a year from now but 2 or 3 features that are most important right now with promise of more in the future.

That said, all the sarcastic bits in this article are sadly funny and true. Those really are the many ways that Agile gets corrupted by management and developers. The worst of these (by far) is turning Agile into Waterfall Lite where the six-month or year-long Death Marches of Waterfall are replaced with 3-week-long Death Sprints masquerading as Agile. Forget that noise.

So, please, anyone who wants to run down Agile or has only experienced bad Agile, you simply have no idea how horrible what came before was. By all means, let's criticize and critique Agile if it leads to something better. Until then, I'll continue to believe in the overwhelmingly positive and productive Agile workflow I've seen work in the real world with real developers even in tough environments.

Collapse
 
laughingraven profile image
Laughing Raven

I think that waterfall done right is far better than agile done right. You need to have an architectural design. You need to plan things. Agile is far too seat of the pants to be effective. Especially when it comes to long-lived legacy applications. Nowadays we write software and it's thrown away a few years later to be rewritten or refactored or some other BS and this just hasn't been the case in the past. there's been a lot of really good systems created with the waterfall methodology and as I said by and large I believe it is the better of the two paradigms

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

Well, no, I don't know that I can agree here. Agile and Waterfall are both vulnerable to the strange phenomena that plague software development. There are many effectively implemented Agile projects, whether fully or partially compliant with the standard. There are also a number of effective waterfall projects.

One must remember that Agile attempted to answer real problems with waterfall, and it partly succeeded. Managers have always been fairly obsessed with ROI, so they're not going to repeatedly sink time and money into Agile processes instead of the much cheaper waterfall processes if they're not getting something out of it.

Like I said originally...

I agree that Agile has its place.... It would be amazing, if it weren't for the fundamental problem that destroys every well-meaning methodology in this industry: software is weird. (emphasis added)

I think the bigger mistake is to believe that one methodology is inherently "better" than the other, or somehow less prone to failure. Own what works for you and your projects as your personal experience, but don't map that experience to the rest of the industry.

This is what I meant by "the manifest idealism of starry-eyed business majors"; they assumed that, because they could see it working in their minds, it could never fail. Does it work sometimes? Definitely. Does it work enough to warrant learning it and considering it a viable option? No doubt. Is it the answer to All Things, Even World Peace? Not by a longshot.

Thread Thread
 
jones1618 profile image
Stephen Jones • Edited

Waterfall is never done right, though. It assumes infinite foresight and precision planning that must never fail or falter.

Who says Agile done right includes no planning? As an organization, you still need to do requirements analysis and prioritization, only Agile gives you permission to continually reassess and adapt to changing goals and market conditions without calling that a failure.

Finally, "Nowadays ... we write software and it's thrown away ... rewritten or refactored." Heck, yeah! That's a feature not a bug. Not only do requirements change and new technologies come along but the truest statement I know in software is "Good software is written. Great software is re-written." Once you've used software in production for a while, why wouldn't it make infinite sense to eventually rewrite parts that aren't working well and hone and expand parts that are proving indispensable? Best of all, Agile plus Continuous Integration lets you "improve in-place", A-B test and innovate in a way that Waterfall could never do without shutting down the whole assembly line and waiting for the organization to gear up for the next big push.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

Waterfall is never done right, though.

Once again, I must disagree. If this were the case, we would have never shipped a single usable software project prior to the invention of Agile. In fact, not only was software shipped, but some of that same software is still in use, and sometimes is more stable and reliable than some of its modern equivalents. So, Waterfall cannot be unilaterally altogether incompatible with completing a project.

It assumes infinite foresight and precision planning that must never fail or falter.

The way it is usually done, yes. Waterfall has issues, many of which Agile attempted to address.

That said, I've seen many of the same assumptions and mistakes made with Agile.

In reality: both methods would theoretically work well, but for human folly. I've used both successfully, and (more often), I've cherry-picked from both techniques (and others besides) to tailor the exact methodology needed for a single project.

When it comes to methodologies, anytime anyone says "X always works" or "X never works", that demonstrates they have failed to understand the vast majority of components in the problem they're trying to solve. (That's not a personal attack; I just find that to be universally true.)

Collapse
 
laughingraven profile image
Laughing Raven • Edited

I agree with you 100%. Anytime that process becomes the most important thing there's an issue. Also I think the other problem is that there are far too many people with one two or three years experience that buy into this and become scrum masters or some other BS term and destroy an entire dev team because they are in no way qualified to discuss anything related to it and should remain relatively silent and continue to develop their technical ability