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

Saying goodbye to Agile

lewiscampbell.tech

Post reply on HN
Print view View original

261–270 of 271 posts

Re: Saying goodbye to Agile

#261

Post by bulbar »

AnimalMuppet wrote: post #220
Aurornis wrote: post #47

Earlier quoted context omitted.

My favorite Agile-ism is when Agile is defined as “the process that works for the team”. If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!

My definition of agile is that process is a knob that you can turn. You don't like how the process is working out for your team? Adjust the process. Find the sweet spot for your team. As your team changes size and/or members, keep adjusting. "We're going to do agile by following this rigid process" is an oxymoron.

The problem is that "just do what works" doesn't justify a whole agile industry and not even two days of training.

The real claim of the agile industry is that they know what can work and that you can find it using agile. That also has real value - if true.

Re: Saying goodbye to Agile

#262

Post by SCdF »

bulbar wrote: post #259
SCdF wrote: post #128

Earlier quoted context omitted.

Another way of phrasing this though, is that it's in the team's power to determine process (or the lack thereof). Regardless of success or failure you can say to what degree this is true, and to me this is really that only part of "agile" that is worth locking in.

In the team's power to determine a working process but in the scrum master's responsibility.

If you use scrum, and if you have a scrum master. You categorically don't need to do either of those things though.

Re: Saying goodbye to Agile

#263

Post by duskdozer »

locknitpicker wrote: post #241
duskdozer wrote: post #219

Earlier quoted context omitted.

I originally was writing the post using a nailgun, but decided someone would criticize it for straying too far away from a hammer. Alas.

> I originally was writing the post using a nailgun, but decided someone would criticize it for straying too far away from a hammer. Alas. The point is still unaddressed, isn't it?

Well, no, the examples are basically the same. A wifi nailgun that sometimes shoots a nail straight through the board, doesn't shoot one at all, shoots it randomly to the side, shoots you with it, etc.

Re: Saying goodbye to Agile

#264

Post by zelphirkalt »

0xbadcafebee wrote: post #238
zelphirkalt wrote: post #139

Earlier quoted context omitted.

And that's why agile is not a set in stone process, that imposes tools and process upon the devs, but states: "Individuals and interactions over processes and tools". Basically, it tells you, that you will need to figure out what works for this project and this set of people.

Which means Agile will always be more expensive, time-consuming and difficult than alternatives. Say you're building a boat. Boats require not only lots of skills in woodworking, but a whole 'nother skill of design, to get a boat that does what you want on the water. It is always time-consuming, expensive, and hard. And there's two basic ways to build it: with plans, and without plans. Without plans, you have to desi…

No, that's not at all what it means.

It means, that you need capable engineers, who are willing to talk to users and build understanding, rather than just being Jira task rabbits. It means, that you might not even need all the intermediaries, each having their own personal agenda and incentives, that engineers usually have to put up with. It also means, that certain layers in an organization have to trust their employees a little more.

It means, that what you build it based on user feedback, rather than what someone tells the engineers, what the user feedback supposedly is, without having a clear idea, what the users actually want. I have seen this first hand. When in the beginning of the product I as an engineer interacted with the users and found out their issues with the platform I was developing, later on the organization added hierarchy layers, shielding or preventing engineers from talking to the users, to build their own job moat, and patronization going on in terms of "Your time is better spent developing the actual features.". In the end the product ended up drifting far from what is good for the actual users, and instead people talked more to B2B customers, than the employees at those other businesses and what they actually need or want.

With each additional layer between the user and the developer (which is also people who want to be paid btw.), the business is inflicting significant cost and increases the risk to steer off course.

Re: Saying goodbye to Agile

#265

Post by BobaFloutist »

z3t4 wrote: post #258
BobaFloutist wrote: post #169

Earlier quoted context omitted.

I'm pretty sure a religiously followed meat only diet can't succeed at anything other than achieving scurvy.

Meat have all vitamins. But if you plan to stay on the diet forever you should eat all parts, not just the steak.

Ah, fair enough.

I still doubt that your average person would see any real health benefits from eating only meat, even if they ate enough organ meats to actually get all their vitamins and minerals (the lack of fiber is a particular concern) but I guess you're right that there's a version of an "all meat died" that doesn't promptly kill you through malnutrition, you got me there.

Re: Saying goodbye to Agile

#266

Post by dvfjsdhgfv »

dijit wrote: post #13

There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere. In that: if it fails, it is only considered evidence that you were not doing it enough . The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty. It's also true for Cloud providers; that they're not suited for certain…

This applies to everything. If your coding agent has problems with non-trivial programs, it's your fault, too.

Re: Saying goodbye to Agile

#267

Post by z3t4 »

BobaFloutist wrote: post #265
z3t4 wrote: post #258

Earlier quoted context omitted.

Meat have all vitamins. But if you plan to stay on the diet forever you should eat all parts, not just the steak.

Ah, fair enough. I still doubt that your average person would see any real health benefits from eating only meat, even if they ate enough organ meats to actually get all their vitamins and minerals (the lack of fiber is a particular concern) but I guess you're right that there's a version of an "all meat died" that doesn't promptly kill you through malnutrition, you got me there.

It's really a hard-core diet and not for the average joe, the health benefits however are great: Fat loss, especially around your belly (because belly fat act as a protective barrier, and will go away if you don't eat carbs) and the inflammatory processes in the body will go down a lot. You will look more healthy and feel stronger. Just make sure you get enough calories, so you need to eat a lot of meat. You have to spend hours every day just eating.

Re: Saying goodbye to Agile

#268

Post by apple4ever »

SCdF wrote: post #128
Aurornis wrote: post #47

Earlier quoted context omitted.

My favorite Agile-ism is when Agile is defined as “the process that works for the team”. If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!

Another way of phrasing this though, is that it's in the team's power to determine process (or the lack thereof). Regardless of success or failure you can say to what degree this is true, and to me this is really that only part of "agile" that is worth locking in.

> Another way of phrasing this though, is that it's in the team's power to determine process (or the lack thereof).

Which they almost never have.

Re: Saying goodbye to Agile

#269

Post by apple4ever »

AnimalMuppet wrote: post #220
Aurornis wrote: post #47

Earlier quoted context omitted.

My favorite Agile-ism is when Agile is defined as “the process that works for the team”. If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!

My definition of agile is that process is a knob that you can turn. You don't like how the process is working out for your team? Adjust the process. Find the sweet spot for your team. As your team changes size and/or members, keep adjusting. "We're going to do agile by following this rigid process" is an oxymoron.

That's true, but most people / teams can't actually adjust the process.

Re: Saying goodbye to Agile

#270

Post by apple4ever »

locknitpicker wrote: post #72
Aurornis wrote: post #47

Earlier quoted context omitted.

My favorite Agile-ism is when Agile is defined as “the process that works for the team”. If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!

> My favorite Agile-ism is when Agile is defined as “the process that works for the team”. What compels you to believe it isn't? I mean, read the Agile Manifesto. All it does is basically define a set of values and principles. Things like "customer comes first" or "we welcome changes in requirements" or "software must be delivered frequently". What leads you to believe Agile implies a fixed set of precise, rigid rule…

> What leads you to believe Agile implies a fixed set of precise, rigid rules?

How it's been implemented at every company. They are always a fixed set of precise, rigid rules.

Post reply on HN