Hacker News Reader

Comment by kissgyorgy | Hacker News Reader

A lot of people misunderstand it, but what agile says is basically that "you should talk to each other more often" and "you should make smaller steps". So it's a YES from me.

If you never seen this, you should read this ASAP: https://agilemanifesto.org/

Because that's all there is to know about Agile. Obviously it takes a bit more time to really grasp how can you translate that to lines of code or building a deployment pipeline or shipping features, but if you understand these couple of lines, you already know enough about agile development.

View on HN

I think Agile is best learnt by first failing a 1-million dollars Waterfall project.

“Kids today don’t know” what it feels like, explaining lawyers how you didn’t feel the wind turning after spending 9 months delivering layer 1 and 2 and crossing your fingers that layer 3 will be a wrap-up. Once you have seen that, the “less paperwork, more interactions”, the “add value not layers” become a relief ;)

I know what it feels like to fail a 2 million dollar agile project. Where do I go from there?

In today's culture, you should be a billionaire now.

But more seriously, "agile", what does it even mean? I almost posted this on another comment.

There is no, singular, agile beyond the manifesto. Everything else is a variation either attempting to push the goals and ideas of the manifesto or attempting to capitalize on fads.

Scrum is borderline fad (I'm ok on the concept, but I think employees should be paid not to go to most Scrum classes; most implementations are incredibly badly done like they deliberately misread the guide). SAFe is bullshit (the gov't bought into it though, how's that F-35 coming along again?).

XP had (has?) some seriously dogmatic advocates, but most people have learned it's a toolkit and not a thing to do without consideration.

Lean has always been presented as a philosophy and toolkit, at least as far as everything I've ever been able to find on it. I think there are some moronic certifications out there, skip them.

DevOps is Theory of Constraints for IT. Which is not a set of ceremonies to perform, but a way of viewing and trying to improve the system. Though, like with Lean, many people are apparently illiterate and fuck it up.

So the question becomes: what version of "agile" were you using? And did you do one of the most important thing that, as I noted in another comment, seems to be the most crucial common element of most of these (except SAFe, fuck SAFe): Did you actively set about to improve the way you worked as you worked? Did you frequently ask questions like: Is this working for us? Is this working for our customers? Is this the right process? Are these the right tools? Are we holding it right or should we try something different?

If introspection and reflection and periodic adjustments to not just the product but also the team (structure and dynamics) and processes aren't in play, then it's probably a ritualized version of agile which is only barely better than Waterfall.

Exactly. It's not agile until the process is one of the knobs you're willing to adjust. "Let us be agile according to this rigorously defined, unchangeable process" is self-contradictory.

Stop messing around and go waste 100 times that at on a federal project at Deloitte.

> I think Agile is best learnt by first failing a 1-million dollars Waterfall project.

Very high quality engineering work has been getting done ages before "agile" status-reporting was invented and it was often not waterfall (I've been around the industry since the 80s and have never done "waterfall" - the false dichotomy of agile vs. waterfall is a myth).

I love how "Individuals and interactions over processes and tools" turned into "inscrutable processes and tools that take over individuals and interactions".

You can take anything and do it poorly. That's not the fault of the people who created it.

That site is horrendously dated. Here's a modern version of the same content: https://www.agilesoftwaremanifesto.com/

And here's a website describing how you're likely to see Agile implemented in The Real World (TM): https://www.halfarsedagilemanifesto.org/

Most of the problems seem to be not enough Agile!

Agile, as it’s practiced today is Jira driven disorganized waterfall, and has nothing to do with the OG agile principles.

Much like TDD, which works great when it’s dev driven, agile works great when it’s driven by dev team.

The problem happens when the PMs get involved and they have to schedule meetings to get basic status updates and have to implement their voodoo rituals to make it look like PMs are adding to project velocity. Planning Poker, lol.

It gets much worse on larger scope projects and many devs and PMs are inexperienced.

Oh, man, you haven't seen Jira driven disorganized waterfall until you've seen SAFe -- Scaled Agile Framework. Basically Agile with cement shoes, for organizations that are scared to do anything without getting it countersigned in triplicate.

I love how there is an ongoing war between "the old guards" of agile and SAFe. Look up some of the rants, it's a great read. Certificate peddlers flaming each other.

SAFe has a great, telling name though - it's designed to be safe for corporate control freaks. They might not know waterfall, they just live it in their guts.

Easy to identify, they believe in being a "visionary leader" and "inspiring the lower rank".

The dev team can absolutely never drive a business process. Developers don't work with customers, don't measure revenue, don't do marketing. Scrum exists to facilitate clear communication about requirements in the smallest deliverable increments. Devs should be fully bought in and involved in decision making but product mangers have to be there to do discovery and set priorities. PMs are there to facilitate and measure progress which can mostly be done just by keeping tickets up to date.

If you have an inexperienced team, any process you adopt is going to suck.

As a dev I have spoken directly with customers in multiple projects, but based on mentioning revenue/marketing it seems you're coming from a consumer focus and not b2b implementations? It seems to be a common perspective on this site but it's not the only one.

Talking with a customer was great when we could, usually it's been when I worked in a small team (1-3 developers), speaking with either internal or external customers. We talk through what is needed then the BA/PM documents it in the updated job brief, rather than the other way around which leads to so much back and forth. It gets to the root of any uncertainty about what they want much quicker.

This is not any official brand of Agile. It's just our natural inclination when left alone. Talk, iterate, deliver.

I agree with everything you say. Part of the problem is PMs and the scrum masters with certificates and no technical experience run the show and play presenter/jira manager. Most of the time they have no idea what's going on and are glorified backwatchers.

I'd rather have multiple Sr. Devs be half time management, and half time dev. Or increase Sr. Dev pay by 20-30% and have them pick up management on top of their duties.

Reply on news.ycombinator.com