Hacker News Reader

Comment by boxed | Hacker News Reader

> "Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout."

I almost laughed out loud. Isn't that agile? :P

View on HN

Probably the originally intended Agile [1]

These days its been devolved into micromanagement musical chairs of pain. The kind that promotes what it professes to prevent and provide.

[1] https://agilemanifesto.org/

Before someone says "No true scottsman", consider that "Agile" is supposed to mean:

> People over processes

and

> Responding to change over plans

And capital-A-agile is literally a textbook process.

Yea, like when people say they are Christians but are against helping the poor. Pretty clearly not Christians in any reasonable definition...

Isn't "Christian" one of those predicates where identifying as such (public profession of faith) is what makes you one? I mean unless you're going for a denomination that requires baptism.

Yea, that's what it has devolved into. At least Catholicism can protect its brand against crazy stuff like that. The agile guys should have done something like that from the start... if they had known what was coming.

Every agile coach always tells me that agile is whatever works for the team.

Conveniently, if something isn’t working they dismiss it as not true agile.

Of course, all of the processes and meetings they push on to the team don’t actually work out, but they’re long gone by then.

> Every agile coach always tells me that agile is whatever works for the team.

Most so called agile coaches are scrum prescriptivists in my experience.

I mean.. "science" is what works too. If something turns out to be false, we throw it out and say it's not science. This is good. I don't see a problem with this at all.

But pushing useless stuff that doesn't work and then leaving, yea that's not agile :P

Science has proven methodologies to it and those are explicitly taught, followed, and reviewed. Agile coaches offer no real guidance if the bulk of the advice is "do what works". No shit...

The methodologies were discovered after the fact though. The only real scientific method is "if you are a winner you are with us". In fact, plenty of scientific methodologies are NOT tested and probably super bad, like the modern peer review system, or grant writing/proposal/reviews.

Neither of those are methodologies for actual science, but rather publication and funding issues. The methodology most closely related to peer reviews would be idea of reproducibility. There are plenty of peer reviewed things that fail reproducibility.

Many people think it's not science if it's not peer reviewed.

"robust requirements engineering process"

I worked on one team that had this and it was amazing. It implicitly helped with burnout too. It was an "Agile" team, but we followed more of a scrumifall model that worked well for that project.

I've been on a bunch of Agile teams (some more than others) since then, but the requirements processes are all garbage. Then the leaders wonder why things take so long, there's so many bugs, burnout is high, etc. It's really not surprising.

Could you expand a little bit on what the "robust requirements engineering process" was like on that one team?

It was an app that was heavily focused on business processes, like routing items between different groups. We had spreadsheets and process maps for each business process. This means the business actually had to think about the possible routes it could take and the data required on each step. So the spreadsheet would tell us all the possible data exposed on the step including how it was treated (R, RW, required, formats/types, etc). It was magical.

Once a process was created the business would have to sell any process changes to the product owner by either showing it was a regulatory/legal issue, or using a cost study to show it would save money. So not back and forth or superfluous changes.

This is the type of engineering method that I try to instill in my teams. It's very dependant on good practices at every level of requirements management.

"prevent developer burnout."

...Frankly I think all the standups & the pressure from constantly asking me if I am contributing (every single day?!) instead of trusting that I am... burns me out.

I don't mind 2-3 standups per week, 15 mins max.

But 5x 30 minute standups... Is exhausting. It feels like a lack of trust from product managers.

Oh yeah... and unqualified, zero engineering experience, diversity-hire product managers. That's super annoying-- being managed by people who did not obtain their role via the route expected of an engineer (having demonstrable engineering skills)

If you read about agile, standups are supposed to be conducted among the dev team members who are working together on something, and primarily for their benefit, not as a status update to or for someone else. The PM or whoever is considered the "product owner" in scrum could listen in and help unblock issues, or report delays to other people, but not demand more information or change things up that have already been planned. Of course, it actually working this way is rare, although I have seen it.

I haven't really seen this, but a poorly performing product manager or product owner completely breaks the scrum or agile model (to the extent it works at all). They are assumed to basically know the domain and know what needs to be built at a high level, and the software requirements originate from them in the scrum model. If they don't know what the requirements should be or how to communicate them or how to collaborate with the engineers on the requirements, it is completely garbage-in-garbage-out. On the other hand, working with a product owner who is a domain expert and happy to help define software to solve their needs can be a joy.

The equation of "agile = standups" has done more harm to agile (and projects using it) than anything else. I run a company and we use a lot of agile project planning methods, but threw out the standup. Especially in the era of remote work and varying timezones, it makes no sense at all.

That's all kinds of wrong. A stand-up is supposed to take 15 minutes max, and if no one is stuck with anything, it shouldn't take more than just a couple of minutes. It's not supposed to be a "status meeting" at all.

Unfortunately, in practice,that doesn't seem to happen very often.

It’s a synchronization primitive, not the only kind available but most popular. It should not be 30min. Maybe 10.

And it’s not a test of your contribution. It’s part of being a team.

"Why is it called a stand-up meeting?"

"So we are incentivized to get it done quickly and go back to our desks."

"Ah, so if we sit down we can make the meeting longer...."

Reply on news.ycombinator.com