Live data from Hacker News

Dear Agile, I’m Tired of Pretending (2018)

medium.com

31–40 of 420 posts

Re: Dear Agile, I’m Tired of Pretending (2018)

#31

Earlier quoted context omitted.

What's stupid in wanting to get an idea of how much a project costs in order to decide if it's a good idea to pursue, let alonr allocate resources?

Nothing, inherently, except perhaps the fallacy of comparing a pair of jeans to the rather chaotic and unpredictable world of bespoke systems development. One is inherently known (a pair of jeans you've presumably already manufactured), the other is one big unknown, basically.

Right. You can imagine a conversation something like:

"Ok, how long is this project going to take?"

"Well, it's still being defined..."

"What do you mean you refuse to tell me how long this project is going to take?"

The analogy is so ridiculous that the person making it clearly doesn't even comprehend the domain he's discussing.

Re: Dear Agile, I’m Tired of Pretending (2018)

#32
Organizations have to find their own way of working. It's going to change based on the size of the organization, its goals, and its people. With the exception of 1.5 years in a software company, most of my organizations have been internal IT. What I find is that user areas, who initiate projects with us, often don't have a clear view of what they want but think it's going to help the organization. Our job is to build models quickly so that they can validate an idea. Only after iterating through a few models can they reliably say the benefit/cost of the idea.

A very good engineer within my organization said to me, "Our job is to get something in front of them quickly so they can figure out what they don't want." Our successful projects have been ones in which we kept to this maxim.

I think this is what the author was trying to say but I had a hard time following his writing style.

Re: Dear Agile, I’m Tired of Pretending (2018)

#33
"Thou shalt not be negative" (HN) - well I'm sorry. Just some example text:

> both Agile and Waterfall are focused on building. Design is about validating.

or

> So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value.

Satire? Enough words to fill a hot air balloon or two. "Smart" focus, "clear" outcomes, "outcomes" vs. "milestones"(?), "trusted" product teams (as opposed to... what?), "empowered" etc.?

Far more interesting than the contents of many links that make it to the HN homepage is discovering the fact that they do so.

Re: Dear Agile, I’m Tired of Pretending (2018)

#35

You don’t hear the name Joel Spolsky much any more, but he was pretty influential in software process thinking in the 90’s - not really for being particularly insightful or original, but more because he was one of the first people who thought of writing a blog about software design. One of his early “observations” about software project management was that “you wouldn’t buy a pair of jeans without knowing how much th…

That's one of the big reasons that I've become a proponent of Donald G. Reinertsen's approach to product development.

He emphasizes a variation of the cost benefit formula + urgency, called Cost of Delay for prioritizing that basically boils down to "Value / Time Remaining" because your cost is the time remaining. It naturally prioritizes work based on shortest time to value because, unless the value proposition is enormous, dividing by estimated time is almost always going to favor the shorter tasks.

This will of course vary by team, but in general it puts a focus on responsiveness and getting the little stuff out of the way first (including tech debt). When you have a formula that doesn't let the little stuff build up, it gets easier to focus on the big stuff too. It's also make it easy to pivot because it totally disregards prior time investments.

It meshes better with what agile is supposed to be better than any other methodology that I've encountered to this point.

Re: Dear Agile, I’m Tired of Pretending (2018)

#36
post #26

Earlier quoted context omitted.

What's stupid in wanting to get an idea of how much a project costs in order to decide if it's a good idea to pursue, let alonr allocate resources?

Writing software is design, not manufacturing [1]. Do companies know accurately in advance how much it will cost to design a new nuclear power plant, aircraft carrier, or jet engine? [1] http://www.bleading-edge.com/Publications/C++Journal/Cpjour2...

There are times when something truly original is being built and it's a valid argument for estimate uncertainty. But a significant portion of the industry is engaged in building CRUD app #237 or Ho-Hum SaaS #17, and a significant percentage of estimates end up wrong because some developer who was bored with his job decided to use a blingy new Javascript framework he had no experience with because he wanted a challenge. Money gets lit on fire again and again this way and it's frankly selfish and irresponsible.

Re: Dear Agile, I’m Tired of Pretending (2018)

#37
post #2

I agree that almost all of the orgs I encountered that were Doing Agile were pretty horrible. On the other hand, I've also been in orgs that were very successful in developing software in a way that we would recognise as being agile. We just didn't make a big deal out of it. And we didn't do standups (most of the time), or 2 week sprints, or retrospectives. We didn't even pair consistently: we split up on trivial stu…

Good advice for an experienced team. Couple it with good reporting (who's job is that?) and management could be good with it. Green teams may need more structure. But the structure should not take over; it should be a tutorial and get rethought as the team matures.

You also need to give people the chance to make mistakes and learn from them. I don’t envy a lot of the young developers who get micromanaged all the time and never have a chance to try something.

Re: Dear Agile, I’m Tired of Pretending (2018)

#39
I have a theory that commercially successful software development methodologies are like diets: they have to be almost impossible to follow. This ensures that when you fail to lose weight/achieve bug free software, you blame yourself for not following the rules exactly, rather than the rules for not working.

Re: Dear Agile, I’m Tired of Pretending (2018)

#40
post #22

Earlier quoted context omitted.

Nothing, inherently, except perhaps the fallacy of comparing a pair of jeans to the rather chaotic and unpredictable world of bespoke systems development. One is inherently known (a pair of jeans you've presumably already manufactured), the other is one big unknown, basically.

Aircraft, hospitals, hotels — a million complex bespoke things are built every day. Cost and time projections are inevitable.

> Cost and time projections are inevitable.

As inevitable as blowing through the projections.

Post reply on HN