Hacker News Reader

Comment by mpweiher | Hacker News Reader

> agile has killed the happiness...meetings...rituals...meta-work...not actual productivity.

All of that isn't actual agile. It's Fauxgile and has nothing to do with what agile is about, which is about removing impediments to productivity, removing meetings (why were there standups? Because they shouldn't exist in the first place, and if you absolutely positively can't avoid them then at least make them as short as possible by making everyone as uncomfortable as they should be) and laser-focusing on actual productivity.

> (If agile is done well though it can be amazing but that's another topic to me)

Yes. I would phrase it as: if agile is actually done.

View on HN

Can't upvote this enough times. Time and time again you see this: people say "I hate agile because of X, Y and Z" where X, Y, and Z - at best - are orthogonal to the idea of Agile, and at worst (and perhaps even "ordinarily") are complete anathema to the spirit of Agile.

Sorry, but anybody who thinks Agile is about velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc. has been sold a bill of goods. Now that's not to say that those things don't have (some) value. But they aren't "the thing" about Agile. Not even close.

But if you are joining an Agile shop what do you get on average?

Fauxgile.

And every time communism meets the real world we call the required modifications state capitalism.

I thought it was called the welfare state, or social democracy.

Scrum

Jira

What is actually Agile then, and how does one actually practice it?

agilemanifesto.org

Constant reflection and drive towards faster feedback. XP or if I squint Scrum can be a starting point, but you gotta adapt to the individuals on the team and the characteristics of the type of problem you are solving.

It's a methodology that makes software more resilient to the changing needs of the business. Anything that violates the 12 canonical principles[0] should be thrown out - and this has to be determined by each org. individually.

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

/u/lr4444lr and /u/ajmurmann nailed it. "Agile" is just what the Agile Manifesto says. Strictly speaking, "Agile" in and of itself isn't even a methodology - it's just a set of principles, to which a number of concrete methodologies claim some association. They differ in the degree to which they faithfully represent the spirit of the manifesto.

So really, you're never "doing Agile". You're "doing $X" where $X can be Scrum, XP, Crystal, AgileUP, SAFe, or whatever. At most companies what you get, in my experience, is a bastardized version of Scrum cobbled together by somebody who has never actually developed software, took a couple of Scrum classes (maybe), paid too much money for some "help" from some "Agile coaches", and is hoping some of the resulting shit will stick to the wall.

FWIW, I've actually had the pleasure of working at company that did Scrum and really did it well, and it was honestly a great experience. Actual Scrum, as documented in the Scrum Guide, isn't bad. The problem is when people take base Scrum and start tacking on additional shit (see: "agile coaches" and "agile consultants") and wind up with a bureaucratic / kafka-esque tarpit of interminable meetings, ceremonies, and artifacts. In other words, pretty much exactly what the Agile Manifesto stood against in the first place.

Difference between doing Agile and being agile is the same as education. You can have engineers who are educated well and you can have engineers who get stuff done, well without a high level of ‘education’.

You’re talking about training, not education. A masters in engineering will be an experience in software architecture. An engineering role under one of these management styles will be an experience in training.

No I’m not. You are.

If you have an engineer the whole point of them being able to claim the title is they are educated and expert in their field. Without knowledge and expertise in a field you aren't going to get any engineering done.

Which is different to saying anyone trained to be an engineer will be able to get stuff done. But getting stuff done was always a recnognised requirement of an engineer; i.e. by definition they should be getting stuff done.

Agile is to Lenin as Agile processes are to Stalin.

Read the Agile Manifesto. That’s what Agile is. All else is either: - (good) trying to implement the Agile Manifesto, or - (bad) trying to make current process appear like Agile.

You speak with a client. They say what they want. You build it they test it, and state objections and or request more features. You discuss and then build the agreed thing. And then you do this loop untill you ship

The whole idea is that there is no strictly formal version of the process. It can't be answered with a package. The process itself is agile, ammendable, fluid, mutable, improvable. You do what works for you.

Just stick to the principles of focusing on the product customer value over the processes themselves, with recurring reflection over how your process is working, as per the agile manifesto.

If your company hasn't done this before, Scrum is a good starting point, but it is by no means a goal nor the final destination. This is where most companies fail.

Some companies will just request a ready-made agile process from a certified agile overlord. The process will hinder productivity since only reporting parts and rituals are implemented, and all improvements suggested by individuals participating are dismissed since they are “against the agile process”.

I did leave and the company did crumble shortly afterwards. The main reason wasn’t related to processes, though. It was already too late when the faux-agile was introduced.

You asked about Agile, but I will talk about Scrum instead, because I am more familiar with it.

https://scrumguides.org/scrum-guide.html

Ctrl+F "JIRA" - 0 results

Ctrl+F "velocity" - 0 results

Ctrl+F "on-call" - 0 results

Ctrl+F "manager" - 0 results

Selected quotes:

> Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

> During the Sprint: No changes are made that would endanger the Sprint Goal;

> The Daily Scrum is a 15-minute event

A short version is that you have a small team of intelligent people who are given sufficient autonomy. They split time into intervals called "sprints", each sprint is 2-4 weeks long. (If you have no experience with Scrum, start with 2 weeks. When you get used to it, the team can decide the correct length.)

At the beginning of the sprint, the developers and the representative of the customer agree what gets done. During the sprint, the developers do it. Every day there is a short meeting in the morning, when developers say "I completed this; I am going to work on this; I am blocked by this", nothing more.

At the end of the sprint, developers show the implemented changes to the representative of the customer. Then the developers talk among themselves about what was good during this sprint, what was bad, and what they want to do differently the next time.

The important thing (ignored at almost all companies pretending to do Scrum) is that in this ideal world, managers do not exist. Developers manage themselves. In the daily meetings, developers report their progress to each other. What needs to be done, is decided by the representative of the customer (literally a person from a different company, or from a different department if this is an internal project). How it gets done, that is decided by the developers. When developers talk about what was good and bad, and what needs to be done differently, they actually have the power to do it differently the next time. Developers assign the work between themselves, and make estimates how long something would take.

Shortly: the developers are treated as adults, and their responsibility to the customer is defined on a biweekly or monthly basis.

> Sorry, but anybody who thinks Agile is about velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc. has been sold a bill of goods. Now that's not to say that those things don't have (some) value.

Spot on. You and parent have hit the two points that matter:

1. Agile is about removing impediments to productivity

2. velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc are all, in some way, impediments to productivity (even if they do have some value).

I think the real reason you cannot have real agile is because businesses don't run in a way that is compatible with agile, so over time all processes within a business will evolve to match how the business itself functions.

Strong agree.

Except it's not even really about productivity, it's about outcomes. The productivity is only important insofar as it achieves the outcomes. The ideal agile process would have the team on the golf course or in the spa but still changing the world (any suggestions on achieving this, gratefully accepted, as always).

I think the real reason you cannot have real agile is because businesses don't run in a way that is compatible with agile, so over time all processes within a business will evolve to match how the business itself functions.

Sadly, I think you are correct. It's very hard, at best, to make "the business" operate in a way that's truly compatible with the agile approach on the tech side. :-(

I won't say it's impossible, but it's definitely not easy.

Yes, the business leadership almost always put an impossible waterfall approach ontop - they don't adapt to change at all well and are not really leading.

For me the value in Agile is what we end up NOT doing - we never get to that shit because in the end it's not that important. So we never waste time doing it.

"removing impediments" - just sounds like good managers in any process. Bad managers often are an impediment.

Agile is made up. The vast majority of places “do it wrong”. Coaches come in and make things even worse, with even less understanding. Saying “they are doing it wrong” and having nothing change isn’t doing anything, and it’s not really a great point. (Not specifically calling you out I just hear this all the time)

“Fauxagile” *is* agile, because thats what the majority of places in reality do.

“Agile” needs a complete rebrand.

Productive teams understand that any "way of working" is just a means to an end, and that good teams find a way to work that suits them (and their situation).

"Individuals and interactions over processes and tools" as the Agile Manifesto would call it. Quite different from having a certified scrum master

Certified Scrum Masters are individuals who need jobs.

Then they should get a different job.

“Agile” needs to stop existing.

Agile just means making it up as you go when you have people who don't have the knowledge or experience to define first exactly what is required. If more programmers became managers and could work with the stakeholders, most specifically the clients that are ultimately paying their salaries then there would be fewer problems with waterfall. My experience is that if programmers would read the design document written by people who are knowledgeable instead of wanting to build it on the fly there would be no need for agile (assuming experienced people are writing the design documents. After ~1998-2000 it seems like marketing and sales were the ones that ended up doing that despite having no education or experience in designing software interfaces let alone programming). But that's just my experience, and I learned early on the first thing you do is read the manual and if it doesn't answer all the questions then ask and re-write the manual yourself before doing any budgeting or coding. Instead we got agile, which turned into make it up as you go through constant sprints/iterations and meetings as you design and build it rather than on paper. As comic Dave Smith said, if you say it works on paper but doesn't in practice then it doesn't work on paper either.

Usually you know the least at the start so your plans at that point are rubbish. So you keep refining your plans .....

Who gets to do things that they have experience in all the time? Not me at lest. And what manual do you read ? There's almost never anyone who understands it all quite apart from having written "a manual".

Rebranding wouldn't help. The same people doing Fauxagile will be doing FauxX after. The underlying issues of why Fauxagile exists don't get removed because of rebranding

I've read the original manifesto and principles, and quite frankly I'm not that impressed with them either.

Some of the principles are actively harmful, like welcoming changing requirements late in the process.

Yep.

"Individuals and interactions over processes and tools"

OK, not terrible, but why not "interactions and tools over individuals and processes"? De-emphasize individual's egos and ritualized processes, focus on the things that get work done and communication between entities.

"Working software over comprehensive documentation"

Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.

"Customer collaboration over contract negotiation"

Fine. You'll still need a contract, but it's definitely important have a collaborative rather than adversarial relationship with customers.

"Responding to change over following a plan"

Tends to make sense when gathering requirements, turns into a horrible idea later on in a project. Also fails utterly when working with something like a factory (making a hardware product with embedded software). If your entire view of software is web apps, this one seems like a good idea. If you're making something with a manufacturing deadline, it's a recipe for disaster.

> Working software over comprehensive documentation

This means something a little different. It wasn't talking about "end-user" documentation. Rather, it meant "product specifications." Do you need to design the system upfront in UML before you start writing code? You may still need something like a whiteboard sketch or something similar, but that wouldn't be "comprehensive."

> "Customer collaboration over contract negotiation"

The distinction is more about how granular you need things. Do you need to negotiate every piece of business-logic and get signoffs on mockups up-front, and in the case of paying customer, rather than internal stakeholder potentially including placing them into a legal SOW? Or can you just agree to a bullet-list of high level functionality, and then establish a working arrangement to receive feedback and refinement. Build and MVP and get some use, then make it better. Likely the initial understanding of the requirements was flawed anyway, so being reactive to the change, with buy-in from the customer will be a better plan for success. But yeah, this might not work with physical products.

> "Working software over comprehensive documentation"

> Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.

Another problem:

It makes onboarding new engineers difficult. Without any documentation on what each API endpoint does, or the purpose of every repo, getting an understanding of how the system works ends up requiring scanning through code manually or taking a lot of time from other engineers asking questions.

It's especially bad when microservices are given non-descriptive names like Galactus or Omega Star.

"over" does not mean "to the complete exclusion of".

The point is that documentation by itself doesn't deliver any value, and there are diminishing returns with amount and detail level of documentation.

Agile doesn't say you shouldn't document, it says you shouldn't spend more time documenting your API endpoints than Implementing them.

Rather have a big document for a program that doesn't work?

Yes

You can get there with a big document for a program that doesn't work

You can't get anywhere with a program that works and no document. You might get sales, but that's someone else's job

I certainly would have preferred just a big document instead of the code I was given on my current role

I meant: you'd be happy to hand your stakeholder a document about the code you would have written if you'd had time to?

Note that the AM doesn't say not to create documentation, or use processes and tools, etc. It just says to favor the alternatives with the implication that you have to exercise some judgment and discretion on deciding what to do when. The AM in and of itself isn't a methodology and it isn't terribly prescriptive. It's a high level description of a general notion of how to approach things, which can be (and should be) tailored to your circumstances.

The Agile Manifesto starts with “We have found…”

So that’s the why. You can ask for elaboration, or disagree with the results, but the opinion of the signers of the Agile Manifesto, based on their experience, is that to prefer the former over the latter, while acknowledging that the latter principles have value, they tend to succeed (and enjoy their work more) when deciding between the two (there are always trade offs) to give greater weight to the more lightweight, practical, and less rigid values — hence the use of the word “agile”.

> "Customer collaboration over contract negotiation"

TLDR: Businesses purchase development effort in terms of contracts, and the contract is almost always "You will deliver $X for $Y amount, in $Z months or less". Agile is the opposite of that as far as business is concerned - "We will pay $A per hour until our money runs out or we are satisfied with what we get".

I've never understood this one, to be honest. Business runs on contracts; in any interaction with the outside world (suppliers, customers, employees, etc) the businesses contract is what makes or breaks that interaction.

In 999 out of 1000 cases, no contract == no interaction.

I mean, look at it this way: when you ask a crew to paint your house, you specify the colors upfront. You don't iterate with them on after every room, or every wall.

You certainly will not engage with any crew who wants to paint your house using the guidance of the Agile Manifesto, because then you'd have little to no upfront indication of the cost, you might have a house not gully painted (because you're paying per hour for their time, and once your money runs out they stop working).

Agile works great for teams internal to the business - the money never runs out unless the business shuts down. But for external developers, the business cannot engage without a contract, and that contract will be "You will deliver $X for $Y in $Z months", and not "We will pay you $A hourly until we are satisfied with the result".

The practical result is that the agile way and the business way are entirely opposites of each other. This explains why dev teams within companies constantly complain "This isn't Agile!" ... because business is trying to enforce some sort of "Deliver $X within $Z months" and the agile team is working with "We'll collaborate until the stakeholders are satisfied"

It's like you reached inside my head, pulled out my crudely formulated thoughts and feelings on why it struck me as ill-advised, and refined and explained everything perfectly.

Internal teams! My work these days is directly with people paying for the thing. That's why Agile gives me the shivers.

It's unfortunate that you haven't understood any of the problems of writing software or buying on contract despite having it laid out for you.

In reality people change their minds - especially when they see the software - so there's a lot to be said for building it incrementally and showing it to them.

The fact that contracts don't suit this behavior might explain why contracts are such an awful way to get software and why they so often go wrong.

> It's unfortunate that you haven't understood any of the problems of writing software or buying on contract despite having it laid out for you.

> In reality people change their minds - especially when they see the software - so there's a lot to be said for building it incrementally and showing it to them.

Doesn't matter - the people paying for the software are not the ones that are going to be using it, so showing it to them is pointless (they just want their bullet points/requirements checked off).

Showing the software to the users is equally pointless, because they don't have the authority to request changes (any change is a bill that has to be approved).

See my other reply to you: https://news.ycombinator.com/threads?id=lelanthran#34381865

> The fact that contracts don't suit this behavior might explain why contracts are such an awful way to get software and why they so often go wrong.

Maybe, but unless you have an alternative that addresses the problems in not having contracts, there's little point in telling other people that they don't understand the problem.

A good friend of mine worked for HP Consulting, which at the time was using heavyweight waterfall method. Out of curiosity, I asked her how well they hit their schedules and costs.

"Oh, we hit our schedules and costs 100% of the time", she said.

I was incredulous, so I pressed her on the point.

"Well, compared to the contracted schedules and costs, we run 200% over on average by the time we deliver. But what happens is that customers quickly figure out that what they contracted for isn't anything like what they actually need. And every time a requirement changes, we add time and money. A lot of time and money. More than enough to make up for any actual overruns. So we always hit our schedules and costs exactly, by the time we're done."

In short, "We will deliver $X for $Y amount, in $Z months or less" is a total scam.

> And every time a requirement changes, we add time and money. A lot of time and money. More than enough to make up for any actual overruns.

...

> In short, "We will deliver $X for $Y amount, in $Z months or less" is a total scam.

How is that a scam? "We will deliver $X in $Y months for $Z money" is easily predictable by the client when the client wants to change $X.

If the client doesn't change $X, the client can understand what they will pay and when they will get it.

When the client changes $X to $X+a, they still understand that delivery will be "$x+a in $Y+b months for $Z+c money". In fact, the original contract they signed made it clear to them what the cost and time was for changing requirements.

More to the point, when they want to make a change, they can balance the need for the change against the cost and time. Even better, because they know these things upfront, someone at the client will have to approve the cost and delivery time for the new requirements. That person is not going to give the supplier a blank cheque.

It's a good deal better than "We deliver working parts until you are satisfied or until you run out of money. We cannot tell you in advance how much this will cost and how long it will take."

I mean, if experienced developers are unable to get their software development supplier to deliver with only a small margin of money/time overruns, what hops is there for the procurement person at any company?

This is a great piece. My software engineering training just held the assumption that the world runs on agile processes by now. Waterfall-like processes were a historical reference and a failure.

Since external customers and non-swe stakeholders expect binding contracts and even waterfall, I would consider it essential to learn how to interface agile processes with the said contract-driven stakeholders. Telling them that we are trying our best just doesn’t work.

It's why contracted-for software is so awful - contractors do absolutely anything to meet the conditions and then they're gone and not responsible anymore.

> It's why contracted-for software is so awful - contractors do absolutely anything to meet the conditions and then they're gone and not responsible anymore.

What's the alternative? Never have contracted-for software? Only accept contractors who are prepared to do Agile?

How does the procurer then put out bids, without having requirements up front?

How do they evaluate bids from various suppliers without knowing what the final bill is? How do they shortlist the three "best" bids with no costing information? How do they even know if they can afford it?

How are the suppliers supposed to submit bids without knowing what they are going to bill for?

How does audit make sure that the process was fair?

Once you start supplying/developing software for companies that are large enough to have a procurement department, you better believe that the process all runs on paper[1].

[1] Or the digital equivalent.

> I mean, look at it this way: when you ask a crew to paint your house, you specify the colors upfront. You don't iterate with them on after every room, or every wall.

This isn't a useful analogy - more often, it's like asking a crew how much it would cost and how long it would take to paint your house, except the house isn't built yet, you're not sure what you're going to use it for (or whether you'll actually use it as a house rather than a B&B), plus you reserve the right to change colors at any point in the process.

> Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.

This was written in a time when documentation/spec was often written before the software, without taking into account the difficulties of implementing it.

Agile seems to imply that software comes before documentation in terms of priorities.

Keep in mind the agile manifesto authors were consultants, working as consultants, and the manifesto is largely in the context of software consultancy.

A lot of the points in the manifesto turn out to be slightly redundant. Comprehensive documentation, as entered into a tool, is wasted time when what you need to do is spend time with the customer developing their ideas into good software.

Better to death march irrelevant requirements to bankruptcy than adapt to reality?

Theres a third option - see if you can think of it!

I can't think of anything more actively harmful than implementing requirements that are wrong.

How do you pronounce Fauxgile? I've heard of "Fragile" before.

Agile is like socialism at times.

Agile is like capitalism at times.

> Yes. I would phrase it as: if agile is actually done.

Agile was the best of times, Agile was the worst of times, Agile was the age of wisdom, Agile was the age of foolishness, Agile was the epoch of belief, Agile was the epoch of incredulity, Agile was the season of light, Agile was the season of darkness, Agile was the spring of hope, Agile was the winter of despair. -- Paraphrasing Charles Dickens

I can't tell whether that's supposed to be upper-case or lower-case agile.

I'm not sure what this means.

"'Real' socialism hasn't been tried, so you can't say it doesn't work."

It has been tried, though, and it works fine in e.g. Chiapas. Granted, that's not an industrialized and mostly urban society, but not everything has to be one.

Exactly!

Socialism has a somewhat agreed upon base set of principles and comes in a thousand different flavors, but at the end of the day every large scale attempt has ended up with an authoritarian state and either failed or converted to Capitalism. So whenever you say Socialism is a failure, you end up hearing "Well THAT wasn't really Socialism!" Same with Agile.

Bad idea in the first place, and when implemented horrifying beyond belief?

Except socialism demands rigid control.

Big A agiles is more like capitalism. Tricking the plebs into working to the bone for a promise that never materialises

Well, you probably like paid time off (as American companies like to call it) and that's a socialist thing. Potentially you might enjoy free healthcare if you could get it - at least you get free policing and defense.

Which country implements pure capitalism? What would that even look like? 0 tax? having to pay private police companies? ....

Reply on news.ycombinator.com