Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile at 20: The Failed Rebellion

simplethread.com

Post reply on HN
Print view View original

211–220 of 320 posts

Re: Agile at 20: The Failed Rebellion

#211

Post by tarcon »

johan_larson wrote: post #196

The problem I see with various flavors of Agile is that they don't fit in particularly well with how things actually get done at companies. For example, teams running Agile are very reluctant to give both a delivery date and a fixed set of features. They're willing to promise one or the other, but not both. And that's a problem, because the whole rest of the organization really wants to know when they can announce th…

Long Term Deadlines that are conjured up from thin air make no sense. That's why tools like a burn up charts exist.

Extreme Programming suggests having a customer on site. In Scrum the Product Owner is merely a substitute for the Customer.

The agile manifesto values working software more than comprehensive documentation, but does not forbid documentation.

So why do companies and their devs misunderstand this?

Re: Agile at 20: The Failed Rebellion

#212

Post by Aeolun »

Ma8ee wrote: post #138
yobbo wrote: post #125

Earlier quoted context omitted.

> As much as devs try to disagree, technology is not a goal in of itself Can you find one dev that has ever disagreed with this?

I’ve seen countless systems built where technology choices where more exciting than economical. Why build something in c# on top of SQL-server in six months when it can be done in three years with micro services, Kotlin, Cassandra, Kafka, mongoDb etc…

To be fair, this can also be because one random developer suggests this, management hears a fancy new term for their buzzword bingo, and they decree that that tech shall henceforth be used.

Re: Agile at 20: The Failed Rebellion

#213

Post by avereveard »

ratww wrote: post #205
avereveard wrote: post #148

Earlier quoted context omitted.

The whole JavaScript ecosystem

I'm all for shitting on the JS ecosystem, but honestly there haven't been any noticeable shifts whatsoever in its ecosystem for at least 6 or 7 years now. Both React and Vue.js are now older than jQuery was when both were released. Same for Babel and Webpack. Typescript is older than all of these. SASS/SCSS also older than Typescript. Those are the only things you see in 99% of the frontend job descriptions out there…

They keep releasing versions that break backward compatibility forcing whole app rewrite left and right, that counts too

Re: Agile at 20: The Failed Rebellion

#214

Post by schwurb »

xorcist wrote: post #180
mmarq wrote: post #154

Earlier quoted context omitted.

The existence of coaches and scrum masters is the result of decisions of management, that see agile as a way of getting daily reports from the team through the daily standup. I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “im…

> We don’t allow scrum masters and agile coaches in hospitals They're not called scrum masters but the healthcare industry is absolutely full of them. One peculiar thing about the covid crisis was, at least around this particular corner of the planet, in the all-hands-on-deck situation where everyone on the floor in healthcare had to help out, these people suddenly found other things to do. It was impressive to see w…

> I'm sure there's a lesson there somewhere. There sure is: Having one goal and being able to allocate all/most resources towards that goal. The problem is that this is not sustainable. Times of crisis usually ends and then what? Then we are back at square one with "How do we allocate our scarse resources between these really important 4-5 goals?"

Concluding: It is certainly refreshing how efficient groups can be once a crisis forces all attention towards one single goal. (Perhaps unfortuntately) that is not a reliable (crisises are usually not predictable) nor sustainable (other goals tend to get neglected in crisis mode).

Re: Agile at 20: The Failed Rebellion

#215

Post by Aeolun »

bosie wrote: post #33
zorpner wrote: post #27

Earlier quoted context omitted.

> I earn the respect every day I come in How much of each dollar you make for the company with your hard work do you take home?

Any advice on how to calculate the first?

A very simple one is to improve the performance of your app by some degree and see if you get the savings on AWS cost on your bank account.

Re: Agile at 20: The Failed Rebellion

#216

Post by jq-r »

rualca wrote: post #38
lalos wrote: post #13

Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. It's a slippery slope, way to easy to over do. The risk is it starts something to be gamed/incentivized instead of actual progress.

> Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. I would put things differently: micromanagers leveraged the agile and scrum buzzwords to justify and convey an aura of legitimacy to micromanaging. I mean, how many orgs forced daily meetings where workers are forced to enumerate what they did and delivered in a short time frame, but mysteriously left out t…

Agreed completely. I was (and still are) on couple of different companies and teams practicing "Agile" and those daily standups are more like daily blamefests. God forbid you get stuck somewhere and need someone's help. Then you have to apologize because everyone thinks that you're lazy or incompetent and holding everyone down. Also if people wanted to know what I did yesterday, they could have a peek at the tickets they want us to keep up to date but no, they want us to say it anyway. Also that stupid "do you have any blockers" question. No I don't have any blockers, it is this bullshit technology/service everyone wants to use today, and discard tomorrow which I somehow need to be an expert of with 30 min of looking at some incoherent manuals.

It seems to me, that all these buzzwords and meetings are just a way to always keep you "busy" (or at least looking busy), to always have some kind of fire below your feet so you don't "slack off" (or have a bit of free time to actually gain or sharpen the skills you need for the same company...). I'm just tired of this. In a way, good teams will be good, and bad teams will be bad, doesn't really depend on whatever process they have.

Re: Agile at 20: The Failed Rebellion

#217

Post by pydry »

2sk21 wrote: post #173
nicoburns wrote: post #139

Earlier quoted context omitted.

One key part of this that a lot of businesses miss is that this means that every member of the team shoul have direct contact with thw customer, not just a "point of contact"

This is a good point. However in practice we wind up with a number of gatekeepers between the developer and the actual users. These gatekeepers are both on the customer side and the developer side. For example on the developer side, sales people typically do not like being disintermediated since it reduces their relevance. On the customer side, managers often do not want outside developers bothering their workers.

As a developer I've had plenty of pointless and unpleasant customer interactions thrust upon me. It's not a good thing.

I have always appreciated product managers who effectively intermediated customers, had deep domain knowledge, managed stakeholder expectations, learned how to interpret what they said (and ignore what isnt relevant), asked the right questions, prioritize effectively and output to me a nice set of, de-noised, ordered, precise answers to the question "what do I do next?"

It's a rare skill. It boosts my productivity immensely when done right. It removes cognitive load from the developer.

Even when POs make mistakes and misinterpret requirements I still appreciate that being somebody else's problem. It quells my anxiety immensely and lets me focus on developing the thing right without having to worry about whether Im developing the right thing.

Re: Agile at 20: The Failed Rebellion

#218

Post by brnt »

jim-jim-jim wrote: post #159
mmarq wrote: post #154

Earlier quoted context omitted.

The existence of coaches and scrum masters is the result of decisions of management, that see agile as a way of getting daily reports from the team through the daily standup. I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “im…

> We don’t allow scrum masters and agile coaches in hospitals Give it a few years.

My hospital had them 10 years ago. Leaving is, second to marrying my wife, the best decision I ever made. Hospitals are, much to my sincere regret, not able to attract much talent in IT. Mediocrity is the best you can hope for, and I wouldn't even count on that.

Re: Agile at 20: The Failed Rebellion

#219

Post by hamstergene »

Agile taught me about refactoring but in reality I get less opportunity to refactor bad code than I've had under Waterfall-type process. My understanding of our evolution into Agile has always been like:

1. Big Ball of Mud: work without a plan

2. Waterfall and alike: make a very elaborate plan and stick to it

3. Agile: work without a plan, but promptly refactor issues caused by lack of foresight

Waterfall worked well but is too slow to respond to change, so Agile replaces one-off planning with iterative refining. So far, great idea.

However, if the backlog is never short of business requests, and business requests are always higher priority than refactoring, then when will refactoring ever be done?

If we don't have architects anymore, but also don't designate time to refactor, we are de-facto doing Big Ball of Mud with stand-ups.

Re: Agile at 20: The Failed Rebellion

#220

Post by lz400 »

forgotmypw17 wrote: post #52

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFEREN…

The best version of Agile I've ever been part of didn't start great, started like what you describe. And everyone hated the day long retro and planning. So we iterated over it until we got people to come to those meetings with their homework done and tasks reasonably thought out and split instead of having to waste everyone's time for it. And in the end it worked quite well. Retro and planning down to ~1 hour.

I will fight, in any team I'm a part from now on, to avoid the interminable scrum rituals. They are soul crushing for most good engineers I know. I never ever want to do them again.

Post reply on HN