Understanding the reasoning behind the four agile values

by rchaves • 5 years ago

56 89 5 years ago

necovek2• 5 years ago

While I like the basic premise of embracing the uncertainty, I disagree that "nature" (evolutionary model) is the approach to follow: while it has produced marvelous results, "experiments" took way too long to learn from if they were progress/success or not.

I think we should embrace experimentation, but we should improve on natural processes because we are smart, sentient beings, and there are things we can predict and measure much faster, and thus pivot much faster too (as an example, all genetic diseases that are commonly terminal after the early reproductive age in humans are likely to be carried on into descendants because, well, reproduction has already happened — it would take many generations for "nature" to weed out those diseases, but luckily, we've got medicine that helps us not even having to weed them all out, and does stop some altogether).

cuillevel3• 5 years ago

Responding to change over following a plan

Agile manifesto: "That is, while there is value in the items on the right, we value the items on the left more."

necovek2• 5 years ago

Whether nature follows a plan is up for debate. I am personally in the camp that it doesn't, but I understand if someone isn't.

I am guessing that was not your point though, but that you simply missed that I was only complaining about strictly adhering to "natural" process which the OP seems to hold in very high regard (rightfully so, but they fail to mention that we can and should improve on them, which was the point I was making).

dang• 5 years ago

I edited the title because agile is one of those words that cause commenters to immediately react reflexively (yay agile or boo agile...but mostly boo) and this is a more thoughtful article that deserves better.

(Side note - when we do this, we try always to use representative language from the article itself)

g05105116• 5 years ago

Those four sentences are now an unchallenged way to better develop software in general

Pure garbage. Those 4 "values" are incredibly destructive and have led to far more problems than they ever potentially might have solved. You'll get plenty of challenge here, I'll wager.

after over 20 years they proved their value empirically - but why is it that they make so much sense?

They don't. They certainly haven't proved their value empirically. For every "agile" success, there are countless failures, because "agile" isn't a magic bullet.

indymike• 5 years ago

Pure garbage. Those 4 "values" are incredibly destructive and have led to far more problems than they ever potentially might have solved.

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

I'm not sure which of these four you believe has led to far more problems that they potentially may have solved. Maybe the contract negotiation part. In my experience the core values of agile were fine. Where agile often went off the rails is when people implemented agile in a way that contradicts the four values. Definitely not pure garbage.

You'll get plenty of challenge here, I'll wager.

Please don't speak for me, thank you. I've done well with agile, and continue to do so.

krona• 5 years ago

Where agile often went off the rails is when people implemented agile in a way that contradicts the four values

I can't remember a discussion about Agile in which the No true Scotsman fallacy wasn't mentioned at least once.

g05105116• 5 years ago

In my experience the core values of agile were fine. Where agile often went off the rails is when people implemented agile in a way that contradicts the four values. Definitely not pure garbage.

In my experience, "agile" went off the rails the day it was conceived. I've yet to see a legitimate implementation of "agile" that wasn't a cheat in some way. Specifically, any organization I've encountered that claimed to be successful as an "agile" organization wasn't actually being "agile"...they were saying they were "agile", but would abandon it where it conflicted with actually getting work done.

Please don't speak for me, thank you. I've done well with agile, and continue to do so.

How could anything I wrote be construed as "speaking for you"? Pretty egotistical on your part to assume I was. Based on past "agile" posts, I expect that there will be considerable pushback on what OP presents as empirically proven truth.

watwut6• 5 years ago

Agile never valued individuals. It does kinda values interactions, because it turns literally everything into formalized negotiation between multiple people. Which leads to social issues, but who cares, because agile dont actually value people.

Working software over comprehensive documentation

We have no idea what our software should do nor whether it works. There is no place where you can learn how it works. It theoretically makes it easier to pretend it "works", because no one can tell whether it works. Practically, it never really works.

Customer collaboration over contract negotiation

You mean constant negotiation all the time.

codr72• 5 years ago

Nothing is, but this is simply common sense.

But anything threatening to rock the boat will be embraced and corrupted until it's worse than what came before, hence Scrum etc.

g05105116• 5 years ago

How is it common sense?

mobjack2• 5 years ago

My issue is that much of Agile in practice ignores the first value and puts process over people.

This is especially true with Scrum.

DarknessFalls• 5 years ago

Well how many points would you assign to that story?

mobjack2• 5 years ago

What is the definition of done?

jrootabega• 5 years ago

It puts the process people over the producing people. It's a great vector for graft and jobs programs. Once that has taken hold it's fatal.

rramadass7• 5 years ago

This right here is the essence of everything that is wrong with Agile. I sometimes think the term "Bullshit Job" was made to describe Agile/Scrum specific positions :-)

heian0224• 5 years ago

Agree with this,many people think that the right process is agile. In fact, many times they don't consider the practical significance of these processes at all,but just learn from others' processes. This has no significance for agile practice

greatgib• 5 years ago

The worst is that it is like enslaving:

Management will tell you that it is not the case, because it is agile so it is you that decided the process even if it was imposed to you...

And that you are negative to complain, because it cost nothing for you "to try"...

throwaway984393• 5 years ago

Why the Four Agile Values don't work:

1. Nobody applies rigor to anything complicated anymore. The only way you can produce anything that works without rigor is to only produce very small things that you can prove work. So you can produce a lot of very small work and say "I'm developing so fast!", and meanwhile all the components connected together can be a tire fire. Short-term wins and long-term pain. This applies to a lot of the Agile process, but also the avoidance of processes and tools. Processes and tools can help or hurt, depending on how you use them. Even Agile is a process.

2. Working "software" is completely meaningless. What is actually valuable is a working solution to a user problem. I can make a program that very reliably spins in a loop forever, doing nothing. Who the fuck wants that? Not a user. And a large system, which is what a lot of software today is written for, cannot be connected together, operated, troubleshooted, etc without documentation. Nobody's going to be able to run your software or fix it when it breaks if they have no documentation, because they didn't write your software, so they have no fucking idea what to do with it. So we end up with a lot of unmaintainable widgets that don't solve user problems.

3. No software developer actually collaborates with a customer, because software developers have never cared about a customer. They care about their precious code, their algorithms, their design, their bugs, their tests. They don't care if the customer hates the software. I have literally never heard a developer utter the words "so how does the customer like the software?" This whole rule of customer collaboration is just an excuse not to have to think about a contract.

4. 'Responding to change' pretty much just means 'push out shit software and wait for bug reports'. For the first year of operation, Agile software is garbage. Because there was no coherent plan, it doesn't work for the customer, it isn't maintainable, and the other parts of a complex system that it operates as a part of will constantly break in weird ways. We don't need to make a plan, so we don't need to figure out how this thing is supposed to work, so in 6 months when we finally get around to a customer use case, we'll realize this architecture never would have worked within the constraints they're running it in.

Software development is not 'too damn complex'. Software developers are just lazy. We know that, because developers brag about being lazy all the time (I do too). They have these huge egos, and they believe that they're intelligent or talented because they can design an efficient algorithm or create 'beautiful code'. But the end result of all that code is what matters, not the code itself.

Agile is simply a 180-degree reaction to decades of work in developing processes that result in reliable solutions. The processes got complicated, so the software developers said, "fuck it, i'm just going to wing it". And as a result, most modern software is less reliable and more complicated than decades-old systems that are both simpler and solve more problems.

Swizec• 5 years ago

No software developer actually collaborates with a customer, because software developers have never cared about a customer. They care about their precious code, their algorithms, their design, their bugs, their tests. They don't care if the customer hates the software. I have literally never heard a developer utter the words "so how does the customer like the software?" This whole rule of customer collaboration is just an excuse not to have to think about a contract.

You need to start working with better developers. Where I’ve worked, developers consistently and often push back on Product Manager requests when it feels like they aren’t solving the user’s actual problem.

andrewingram• 5 years ago

Yeah. I’ve worked with developers with varying degrees of interest in the overall user problem, but that level of interest has never been less than “some”, and usually they fight just as hard as designers and product managers for solutions that truly solve the user’s problems.

marcinzm• 5 years ago

I think you should look into why you keep ending up with such a-hole indifferent developers as coworkers. The ones I've worked with have in vast majority of cases cared about the problem being solved and didn't have large egos (too much imposter syndrome if anything).

jboy559• 5 years ago

My response;

Nobody applies rigor to anything complicated anymore.

No one ever did. There was no golden period before Agile, where rigor was applied but now we've gone all soft. Before Agile, tire fires were bigger and found much later. That's why they developed Agile. Process and tools can indeed help, but the point of what we are doing in development, is to build working software, not to just follow the process or use the tools. That may seem obvious, but it wasn't and it still isn't, you see many leaders, even in "Agile" environments, who are more comfortable being able to report the process is working, than to challenge a customer to build a better product.

What is actually valuable is a working solution to a user problem

That is obviously what they are talking about. You are creating straw men. The root of this sentence comes somewhat from Gall's law, "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system"

3. You don't have a very extensive work history if you've never found engineers who care about customers. I would look at successful companies and successful startups.

"Agile is simply a 180-degree reaction to decades of work in developing processes that result in reliable solutions."

Its not, its the gradual evolution of software processes, its over 20 years old at this point, its predated by other Agile processes. It came from study of project failures.

The more I re-read your rant, the more I realize either you are intentionally trying to create a stereotypical reaction to Agile or you are deeply disturbed. If you are a software engineer, you should just quit, why are you doing something that makes you so unhappy?

This is so beyond reality its absurd. Agile is not some "giving everyone a trophy" bs.

dominotw• 5 years ago

software developers have never cared about a customer.

umm I am not sure if this is true. To me ultimate thrill in my job is customers solving their real life problems with the software i built.

almeria2• 5 years ago

I have literally never heard a developer utter the words "so how does the customer like the software?"

I'm not surprised, given how many lousy places to work there are out there. But there are plenty of shops where this isn't the case. And where developers do in fact care what the customer thinks, because this obviously (if only slightly indirectly) correlates with the organization's chances for long-term success and revenue, and all that stuff.

None of which has anything to do with Agile of course (because the same issues existed and were dealt with thousands of years before the AM descended to earth, accompanied by angles).

But just saying - yes, actually giving a shit about what the customer thing is a thing, and always has been a thing (at better shops at least).

bitwize• 5 years ago

The one true takeaway of agile is measurement, metrics, and accountability. Your boss was sold on agile on the premise that it lets him keep continuous, precise tabs on you and the entire team, to ensure that y'all are hitting the OKRs for this quarter and so that when something goes wrong, the guilty party and what they did can be identified; or when the schedule slips, the laggard can be identified. This is the reason why shops are so gung ho about agile development. And this, I am forced to conclude, is agile. A game of Mornington Crescent in which the shop pretends to care about the stuff in the left column when the actual goal is to create a work environment so precisely measured, controlled, and optimized it makes Fred Taylor cum in his grave.

dirkt• 5 years ago

Your boss was sold on agile on the premise that it lets him keep continuous, precise tabs on you and the entire team, to ensure that y'all are hitting the OKRs for this quarter and so that when something goes wrong, the guilty party and what they did can be identified; or when the schedule slips, the laggard can be identified.

Which is exactly what agile NOT is, according to the core values...

erikerikson2• 5 years ago

Agile, in a nutshell, says "let's stop being counterproductive (and miserable), it's better for everyone (except maybe sadists and masochists)".

Most of us really want to get things done and sometimes it devolves into self serving tripe but I've been forced to spend 50% of a project planning and then get ridden and harried because that vicious choice that no engineer wanted (but each was forced to do) puts off delivery.

g05105116• 5 years ago

Agile, in a nutshell, says "let's stop being counterproductive (and miserable), it's better for everyone (except maybe sadists and masochists)".

Where does "agile" say any of that?

erikerikson2• 5 years ago

You're right that agile is more positively stated and this declaration violates the more productive tone of the manifesto [0].

Agile processes promote sustainable development

Did I take license? I did. Yet, I was present for some of the unpleasant and ineffective abuses and waste that "agile" was a counteraction to. Although the same types of leaders continue to act against my interpretation's goal, the industry is broadly improved (though physics continues to allow for localized terribleness). There are those who act as though talent retention isn't an important factor in delivery but they can't talk to us because they're busy trying to mend their velocity.

[0] https://agilemanifesto.org/principles.html

deviation• 5 years ago

Great article.

In my experience using agile, I haven't observed any failures- just failures from teams implementing it incorrectly.

There are many billion dollar consulting companies that have completely committed to agile and are flourishing. If it were as garbage as many people in this thread are saying, I feel like we would see more concrete evidence of it.

Source: Worked in agile teams on-and-off for ~5 years now, not at my current company.

riffraff2• 5 years ago

my experience matches yours, but there's something to be scrutinized if a lot of people do something wrong. We can't keep telling people "you're holding it wrong".

For agile, I believe what needs to be stressed is always: adapt the process to your team.

A lot of the frustration is not with the agile manifesto, but with some externally enforced scrum/whatever.

jaybrendansmith• 5 years ago

Such negativity. It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. A total nightmare. Scrum and agile are absolutely wonderful in comparison. Yes, it provides for measurement and close management oversight, but it also does not impose impossible schedules with locked requirements. Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach. But where agile really shines is when the problem is poorly understood and the solution not well defined. In these cases agile can provide for project successes that would have led to certain failure in a waterfall world. It's likely not an overstatement that agile and iterative development has been the recipe behind web 2.0 and so much else in recent years.

clumsysmurf• 5 years ago

Projects were doing iterative development in the 50s, way before scrum or agile.

“All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities.” — Weinberg G. M. (Project Mercury)

I think many of the agile principles remain largely unpalatable to your typical command & control org structure.

One of the main premises of Agile, is letting people closest to the work decide how they want to work.

Instead, in many companies, the org co-opted the meaning of Agile for its own agenda. The PMO got what it wanted, putting heavily gated process on top of Scrum. Why Scrum? Because its push, of course (instead of pull).

At the moment, my org is adopting SAFe, and PI planning, which has devolved into quarter long waterfalls for projects. We just use Scrum as 2 week waterfalls in the quarter waterfall.

rramadass7• 5 years ago

Oh, Jeez; not this again.

See Barry Boehm's https://en.wikipedia.org/wiki/Spiral_model for what has already been done correctly.

watwut6• 5 years ago

I lived before agile came around. And bad the old days of waterfall are to large extend carricature. Maybe it existed in the horrible form agile advocates pretend, but I have no seen that. And for me, work was in fact more motivating before agile. Agile turned the work I really liked a lot into something you do for money. Agile at it best is tolerable.

Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach.

It does not. It is micromanagement ritualized and it somehow leaves both customer and workers unhappy.

rchaves8• 5 years ago

I'm really curious, could you expand on why do you think it was more motivating? Were there less micromanagement before agile?

rramadass7• 5 years ago

And the bad old days of waterfall are to a large extent caricature

Very right! They were never true; mere blame-game when they screwed up something else.

It is micromanagement ritualized and it somehow leaves both customer and workers unhappy

Well Said! Even stronger : A Ego/Power trip for people who can cut it as neither Developers nor actual Managers :-)

almeria2• 5 years ago

It seems many on this thread did not live through the bad old days of waterfall and .mil standard development.

Probably because for most of us they never existed - and yes, of course I mean "pre-agile".

This whole "before Agile it was all waterfall and no one could conceive of anything differently and oh my brothers, let me tell you what a nightmare it was" cant is just that - a cant, something people like to repeat without thinking about whether it has any actual validity in, you know, actual reality. In other words, a myth.

There have always been good shops and bad shops; but like the sibling commenter said, (in the better shops) people have been working iteratively for decades and decades before the Agile Manifesto descended to earth on a ray of light, accompanied by angels.

But where agile really shines is when the problem is poorly understood and the solution not well defined.

Which problems people, again, had already been solving for decades and decades before the AM.

Such negativity

"Negativity" is not only an appropriate, but a healthy and necessary response to the never-ending stream of cargo-cult tripe and talking point nonsense that is Agile.

g05105116• 5 years ago

It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. A total nightmare. Scrum and agile are absolutely wonderful in comparison.

I did. Scrum and "agile" are far, far worse, based on what I've seen and experienced. Those "bad old days" were heaven compared to the bizarre approach currently in vogue. I will be very happy when this fad passes as well.

But where agile really shines is when the problem is poorly understood and the solution not well defined.

That's the problem...people think that you can just use "agile" and not worry about understanding the problem and developing a solid solution. You just start slamming out code and checking back with the customer, wasting huge amounts of time and effort.

Zigurd• 5 years ago

Waterfall planning + critical path analysis was too brittle for software projects. The choices were: 1. Frequent replanning, every 2-6 weeks 2. Stop replanning and try to meet an unrealistic schedule

Agile introduced tactical planning and dropped precise schedule estimates, which did not hold up anyway.

If more Agile proponents would start with that instead of leading with the collaborative aspects of Agile, and drop the Scrum jargon, they would be better understood.

Making software is not like most other projects. Many more new problems to solve because if you already solved it, just reuse the code. That has practical consequences in project management, specifically: iterating toward the goal.

Collaborative task assignment for each iteration is important. But that's not why iterating toward a goal is how to do software.

rramadass7• 5 years ago

I wholeheartedly agree with trying to learn lessons from Taleb's writings and applying it to Software Project/Risk Management.

OTOH, trying to interpret Agile/Scrum methodology in terms of the above is nothing more than Putting Lipstick on a Pig i.e. a valueless/useless endeavour.

rchaves8• 5 years ago

If nothing, it was valuable for me already. My goal was not to preach agile (much less scrum), but to actually try to find a common rationale behind the good and bad experiences that people do feel they had coming from agile. And for me (maybe for other devs too), finding an explanation that makes sense, a more general theory, is very rewarding in itself, it allows contradictory ideas to fit together in my head

rramadass7• 5 years ago

If you are trying to figure out and model something in your mind, then i am fully there with you.

The problem is your marrying it to Agile and its Manifesto. They are a bunch of platitudes, there is no exact definition far less a process/methodology, it can mean anything, everything and nothing in a given context and thus have nothing concrete to recommend themselves. As you can see in this thread, the words Agile/Scrum invoke rather strong feelings amongst the HN crowd and hence your message has gotten lost.

Instead, if you were to do a article on what/how you feel Taleb's ideas can be applied to Software Project/Risk Management, that would be an interesting and welcome read.

rchaves8• 5 years ago

My first experience with agile was not with Scrum but XP, and it was a very good one. There are so many people here conflating Agile with Scrum, and I shouldn’t be surprised I guess, but my goal was not to invoke the “No true Scotsman fallacy”, I don’t care about pointing who is agile and who is not, or what names you use for what, but I do care about the principles behind it, they can give us very good ideas on how to balance certainty vs uncertainty, upfront design vs feedback cycles, in whatever environment you are. Some environments you will need to balance more to one side, some more to the other.

cudgy2• 5 years ago

What did you get out of XP? Didn’t XP promote pair programming? Personally hate the idea of pair programming and would never work for a company that requires it.

rchaves8• 5 years ago

Do you hate the idea of pair programming or the actual act? Have you tried it? It was indeed weird at first but then I had lots of fun from pairing, I really miss it since the whole corona started

cudgy2• 5 years ago

Now that agile has been preached for over a decade, has software actually gotten “better” for end users?

So much focus seems to be on anti-patterns like mining users of their information or minimizing costs by outsourcing development to cheap, unskilled contractor mills and churning out widgets to meet the mad march toward unicorn status along with all the other identical unicorny startups.

The agile crowd talks about pleasing and providing the customers with a product that meets their needs, but is that what we are doing and has agile made this worse, not better?

Understanding the reasoning behind the four agile values

Related Stories