Live data from Hacker News

Agile Is a Tainted Term

pcloadletter.dev

31–40 of 108 posts

Re: Agile Is a Tainted Term

#31
post #20

Earlier quoted context omitted.

Having clear requirements, good communications with key stakeholders and empower the enginees.

What if the requirements are super clear but they change? When do you find out and what happens then? I've personally never had a project where the requirements were 100% clear and stayed exactly the same. Even when writing a v2 of an existing project from the ground up things tended to be unclear and subject to change.

The point is to use what ever works best for your team, not blindly follow some process that may or may not necessarily work for you.

Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.

Re: Agile Is a Tainted Term

#32
post #12

Earlier quoted context omitted.

I’ve seen agile done well once. Yes it does happen. The process was not described, spoken of or even considered. It just existed between a few like minded decent engineers. Their manager got an “agile PM” forced on them and it broke. The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.

The charlatans are a serious problem in software engineering today.

The good news is that it is easy for engineers to start their own companies and keep these people out at first at least.

You will still get cold emails and LinkedIn messages from these people but you don't have to respond

Re: Agile Is a Tainted Term

#33
post #17

Earlier quoted context omitted.

By focusing on the product rather than the process.

How does that work? So you've already went through the steps of figuring out a process, or do you just pick one and stick with it - accepting shitty parts? What's the process?

You should start with the developing of the product as is happens, then use Continuous Improvement process to improve the development process.

You can use SCRUM/Kanban/SaFE/LeSS, hybrid or other Agile methodology, or no process at all, but it will not help when people are not trained to be proper part of the process.

For example, a PM may replace SCRUM meeting with a status meeting, because it makes his job easier, while PM or other M should not attend a SCRUM meeting at all, unless called in by engineers. The proper moment for interaction between PM and engineer are beginning/end of a ticket, sprint review, and sprint planning.

Re: Agile Is a Tainted Term

#34
post #21

Earlier quoted context omitted.

The problem is that it's a neverending treadmill of naming if you do that. Every good idea will be taken over by fraudsters. A lot of good ideas are already tainted by this, and while you have to pick your battles, there's something to be said for standing your ground on naming.

The thing that made agile ripe for fraudsters/cargo cultists was how vaguely it was defined. That can be fixed by defining something new, more precisely.

Is it really vaguely defined?

I find it perfectly precise in what it tells you what you need to optimize for. It just doesn't tell you how because it couldn't possibly know. But finding out is hard work.

What the fraudsters are telling you is that you don't need to do any of the things in the manifesto because they know everything already. A general lack of industriousness on the part of software companies is really what makes not just Agile, but the consulting space in general, ripe for fraud.

Re: Agile Is a Tainted Term

#35
Another problem is that the Agile OGs keep overselling their methodology.

They keep saying that waterfall just doesn't work, yet almost all commercially successful (and unsuccessful) software is produced that way, whether they claim to use Agile or not. Would it be better if they used "real Agile"? Of course! But you only ever have to be just good enough.

Re: Agile Is a Tainted Term

#36

Yes. What I have said before, for the same reasons, is that when the average office that says "we do the Agile", what they mean is that they have top-down, upfront planned micromanagement via tools such as Jira. * This has nothing in common with the values of the Agile Manifesto. In fact it's more like the opposite of them. * I hate Jira. Jira is not the cause of the problem. People's desire for a tool like that is c…

We’re going to be officially moving to Agile! Soon.

By which I mean the project planning committee has created a multi-hundred page document with precise BPM-style workflow charts (based on Jira, obviously), and non-technical managers have started being sent on multi-day training courses to learn how to follow them.

It’s going to be a shitshow!

Re: Agile Is a Tainted Term

#37
post #17

Earlier quoted context omitted.

By focusing on the product rather than the process.

How does that work? So you've already went through the steps of figuring out a process, or do you just pick one and stick with it - accepting shitty parts? What's the process?

1) Come to work.

2) Look at the current state.

3) Decide what the product needs from you.

4) Do that.

5) Use git.

Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).

This is how my current job works and we are unbelievably productive.

Re: Agile Is a Tainted Term

#38
post #7

Earlier quoted context omitted.

The problem is that it's a neverending treadmill of naming if you do that. Every good idea will be taken over by fraudsters. A lot of good ideas are already tainted by this, and while you have to pick your battles, there's something to be said for standing your ground on naming.

> The problem is that it's a neverending treadmill of naming if you do that. OKRs (Objectives and Key Results) have replaced KPIs (Key Performance Indicators) due to some kind of contrived negative connotation that became associated with KPIs over time But they're the exact same thing. Something else will replace OKR in a few years so that management can sound as if they're more in tune with the sensitivities of thei…

OKR is an Objective + KPIs.

Re: Agile Is a Tainted Term

#39
post #31
post #20

Earlier quoted context omitted.

What if the requirements are super clear but they change? When do you find out and what happens then? I've personally never had a project where the requirements were 100% clear and stayed exactly the same. Even when writing a v2 of an existing project from the ground up things tended to be unclear and subject to change.

The point is to use what ever works best for your team, not blindly follow some process that may or may not necessarily work for you. Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.

Sounds like you need a process that can be flexible, able to respond to change, some might say… agile ;-)

I kid, but I think the early proponents of Scrum and similar were trying to achieve a loose framework to do exactly what you’re talking about. The modern incarnations of these can be horrific, but the original intent was always to empower teams to make their own process. Ahh well.

Like so many good ideas (democracy, constitutions), you only really know how well they function once people are actively trying to subvert them. Scrum et.al. have failed in the face of corporatocracy. I honestly don’t know if decentralised structures (i.e. teams empowered to run themselves), can ever survive in large corporates. Which is a pity. Cities grow, but companies die. You have to jump off the dying colossus to find the new company that hasn’t yet succumbed.

Re: Agile Is a Tainted Term

#40
post #21

Earlier quoted context omitted.

The thing that made agile ripe for fraudsters/cargo cultists was how vaguely it was defined. That can be fixed by defining something new, more precisely.

Is it really vaguely defined? I find it perfectly precise in what it tells you what you need to optimize for. It just doesn't tell you how because it couldn't possibly know. But finding out is hard work. What the fraudsters are telling you is that you don't need to do any of the things in the manifesto because they know everything already. A general lack of industriousness on the part of software companies is really…

A customer of the software product need to know that after spending of $X dollars for Y days he will receive Z. In a working Agile project, PM must calculate team velocity and then use it to predict arrival time and expenses, then add/remove developers or features to meet budget and/or dead line. Agile manifesto says nothing about that.
Post reply on HN