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

201–210 of 320 posts

Re: Agile at 20: The Failed Rebellion

#201

Post by MauranKilom »

forgotmypw17 wrote: post #188
MauranKilom wrote: post #181

Earlier quoted context omitted.

How did this approach deal with difficult technical/algorithmic problems where someone needs to investigate something before further decisions can be made? Example: You want to improve performance. Somebody will have to fire up a profiler and measure things, and then figure out which hotspots are worth optimizing. I totally get breaking it down to "set up profiling tool", "do profiling runs for workflow X/Y/Z", and "…

Research and algo design was where most of the 3- and 5-point tickets came from. I think I remember a couple with more points, but not many. Given the "about one hour of work, give or take" target point value we used, there weren't many tasks which had more points than that.

I see. But that's still only the first, "plannable" part. If the research (or algo design) led to the conclusion that component X needed a rewrite, would it require waiting half a month to get started? Maybe that makes sense if it's a larger thing (so that detailed planning would be worthwhile), but would you be required to drop it and do something else in the meantime even for smaller ones (say, a man-day of work)?

Re: Agile at 20: The Failed Rebellion

#202

Post by tkiolp4 »

ipaddr wrote: post #39
emptysongglass wrote: post #23

Earlier quoted context omitted.

> And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about. If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement…

That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks. In the end if you are difficult you become easy to replace.

Everyone is easy to replace.

Re: Agile at 20: The Failed Rebellion

#203

Post by g051051 »

> They were developers, programmers, scientists, and engineers. They were still slingin’ code* and working with their stakeholders to solve problems. This is important.

Utter nonsense. They were consultants looking to sell consulting services. Just in the next paragraph:

> Many of these people already had a methodology they had created and/or were proselytizing.

Re: Agile at 20: The Failed Rebellion

#204

Post by g051051 »

pydry wrote: post #192
dirkt wrote: post #57

Earlier quoted context omitted.

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…

The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are,…

> those hallowed commandments are, frankly, ill-defined bollocks.

I wish I could upvote this more.

Re: Agile at 20: The Failed Rebellion

#205

Post by ratww »

avereveard wrote: post #148
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?

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.

If anything, frontend is kinda boring, and it can be argued that some of those tools above need some disruption.

Re: Agile at 20: The Failed Rebellion

#206

Post by teamonkey »

pantalaimon wrote: post #118
TedDoesntTalk wrote: post #77

Earlier quoted context omitted.

> negative emotions involved Because the daily standup can only be X minutes, someone always gets cut off, causing negative emotions.

I'd say the much more common negative emotion is when you didn't manage to get the work done you had planned to do/spending way too long on a task and having to justify that in front of the team.

This smacks of a dysfunctional work environment, to be honest, and I don't think scrums are the problem.

Re: Agile at 20: The Failed Rebellion

#207

Post by chiefalchemist »

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…

> Also, Agile methodologies tend to assume you are in close contact with the customer, who can tell you what they actually want and decide how things should work.

Yes. Kinda :) But the issue isn't want. The friction is actual make-an-impact business needs.

It's easy to sit around a conference table and spitball wants. But trying to bin that person or group down to specifics as well as resolve disconnect and inconsistencies between the ideas and faces go blank.

Customers want the luxury to spit out wants without having to take the time to knuckle down and do the hard work of defining needs. They have a "you figure it out" attitude. That leads to assumptions. And assumptions lead to dysfunctional product / features, for which the engineers get blamed. Again.

Agile is a worthy solution to this problem, but when IT is treated as a service provider and not an equal partner the tool (i.e., agile) gets mutated to a point it's not truly agile anymore.

Re: Agile at 20: The Failed Rebellion

#208

Post by johan_larson »

loki49152 wrote: post #199
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…

The fundamental insight behind what became agile is that it isn't actually possible to have both a guaranteed delivery date and a guaranteed set of delivered features. The reality of software development just doesn't allow it. Businesses don't "get things done" by operating as if they can have both. That's why projects fail, businesses cut corners, and then inevitably ship broken products or don't ship at all. Most o…

I agree with you that it is not possible to both fix the feature set and fix the delivery date and expect to consistently succeed. But it is also not possibly to tell upper management, who are dealing with a whole other set of difficulties, that they have to pick a feature set or a delivery date and that's all there is to it. If you do that, they'll reject your advice, and find someone else who'll give them a more palatable message.

The best I can come up with is the notion of a double contingency plan. Engineering agrees to a set of functionality to be delivered and a delivery date. This is inevitably going to be a bit optimistic, because people consistently overestimate themselves.

To deal with that, the first contingency plan addresses the question of what should be done if things are not converging to the ship date. The plan here is to keep the ship date, but ask hard questions about what bits of functionality actually need to be kept. What are the actual P0 - MUST HAVE features?

The second contingency plan addresses what is to be done if the first one fails. At this point engineering has already done all they can. They have pushed as hard as they can, and they have deferred every feature that is deferrable. They are down to the actual MUST HAVEs. Now the rest of the organization has to figure out what to do with a product that is inevitably going to be late. What is the alternate ship date? What customers are going to be really unhappy. And so on.

It seems to me any large engineering project should think out these contingency plans in advance. What will they do if making the deadline starts to look daunting? And what will they do if making the deadline turns out to be impossible?

Re: Agile at 20: The Failed Rebellion

#209

Post by Aeolun »

AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

> Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion.

The only thing that is less likely to have the building team and customer come to the same conclusion is to add many more layers in between.

I’ve seen where that ends. It’s not a good place.

Re: Agile at 20: The Failed Rebellion

#210

Post by Aeolun »

mmarq wrote: post #154
baxtr wrote: post #97

Earlier quoted context omitted.

It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.

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…

> I don’t think that people who don't write or never wrote software should have a place in a software development team

This is no guarantee any more. Newly minted managers coming from a development position that have only ever worked in dysfunctional organisations (and got promoted from within) will only reinforce the existing bad practices.

Post reply on HN