Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The age of agile must end

uxdesign.cc

Post reply on HN
Print view View original

41–50 of 50 posts

Re: The age of agile must end

#41

Post by jermaustin1 »

Aeolun wrote: post #9
ramesh31 wrote: post #6

Earlier quoted context omitted.

>Unfortunately in my 10+ years in the industry, I’ve seen few teams do it that way. More often it’s a top-down series of waterfalls masquerading as agile. Ask any software developer how they work (or would like to work): "Yeah I just do the thing until it's done, then I do the next thing" But this doesn't work for management, so we end up with all of these charades, and we have to play along and talk about how "yeah…

The big problem is that it doesn’t fundamentally change the way you work, which is exactly “Do the thing until it’s done, then do the next thing”. What happens is that you get yanked off the thing halfway through, only to have the same thing happen with a few other things. Then folks ask why there’s 4 unfinished things lying around.

Only 4? I have an order of magnitude higher of unfinished tasks since December 2022 in my queue, and about 150 still assigned to me from all time. This is the life of a boring corporate developer in a highly hub & spoke software company where everyone lives in a vertical that is only allowed to speak to their direct manager.

Any time I try to just update the branch to bring it rebase onto current master, I'm pulled into another task that is the highest of high priorities, so high, it can't even be added to TFS, and I must drop everything I'm doing to handle.

I will usually get 4-10 phone calls during the task (most take me under a 2 hours) asking for my status, and after the PR is submitted, it will get ignored for a couple of weeks until inevitably there is a merge conflict, so I then need to drop everything I'm doing to handle it.

I very rarely get to finish a task in my job without being spirited away for hours, days, weeks, months, or even years before being allowed back on that task.

Re: The age of agile must end

#42

Post by Aeolun »

awb wrote: post #16
Aeolun wrote: post #10

Earlier quoted context omitted.

For once it would be nice if they figured out those things can adapt to engineering time too, instead of the other way around.

At good companies they do adapt to engineering timelines. But marketing (reasonably) wants to know if an app launch is 4 weeks away or 8 weeks away and what features will be included so they can plan their campaign accordingly. And then there are things that are immovable like a holiday or a legal deadline, where it’s helpful to know the progress and ETA as accurately as possible as early as possible.

I realize that, and I’m happy to give estimates. It’s when they expect me to estimate something that fits in the schedule they’ve already decided on that it gets iffy.

Re: The age of agile must end

#43

Post by Aeolun »

mvdwoord wrote: post #14
Aeolun wrote: post #5

Who is this guy, and what kind of credentials does he have to sprout such drivel? It seems that like whatever sector he’s in, he has a big beef with developers. If he’s a designer like I assume from the fact it’s published in something related to UX, I suppose he wants a few months to design a whole application up front (because it’s fun!), only to then throw away 80% of it because the requirements changed halfway th…

If 80% of your design is invalidated halfway through the first Sprint, perhaps you are not developing software but rather you are chasing some dynamic business logic (or chasing trends), disguised as software. The fact that stints are being referred to as sprints, is also indicative of something being out of balance. By definition not everything can be a sprint, just like not everything can have the highest priority.…

If everything that was nonsense never happened the world would be a nice place. Just because you want it to be doesn’t make it so.

Re: The age of agile must end

#44

Post by Aeolun »

HillRat wrote: post #24
Aeolun wrote: post #5

Who is this guy, and what kind of credentials does he have to sprout such drivel? It seems that like whatever sector he’s in, he has a big beef with developers. If he’s a designer like I assume from the fact it’s published in something related to UX, I suppose he wants a few months to design a whole application up front (because it’s fun!), only to then throw away 80% of it because the requirements changed halfway th…

Designers should have enough time up front to interview users, define the product and services, build a business plan, and design the application; just as architects need enough time to plan the project, analyze risk, and determine the systems design; IT needs enough time to figure out the server and network plan; and operations needs enough time to forecast staffing and define processes. This means weeks, and someti…

I completely agree with everything you say.

But it somehow bothers me. To me it sounds like a fairytale, but also like you are speaking from experience, at the same time.

Re: The age of agile must end

#45

Post by [deleted] »

taeric wrote: post #2

I share the current disdain for "agile" workflows. In particular, I have grown very weary of every example of failure getting met with "they did agile wrong." After enough encounters with it being done in a way that does not bode well, I am forced to start questioning the general ideas. However, I do find the excessive snark against wanting to empower the developers kind of off putting. In particular, zero charity in…

[deleted]

Re: The age of agile must end

#46

Post by HillRat »

Aeolun wrote: post #44
HillRat wrote: post #24

Earlier quoted context omitted.

Designers should have enough time up front to interview users, define the product and services, build a business plan, and design the application; just as architects need enough time to plan the project, analyze risk, and determine the systems design; IT needs enough time to figure out the server and network plan; and operations needs enough time to forecast staffing and define processes. This means weeks, and someti…

I completely agree with everything you say. But it somehow bothers me. To me it sounds like a fairytale, but also like you are speaking from experience, at the same time.

One thing my old BigCo does right is put a solution level between sales and execution that has veto authority on any project -- our job was to manage everything from scope to risk to staffing and timelines going into the deal, just to ensure that projects would run as cleanly as possible.

If a client balked at the time or price of a project, then we'd step in and renegotiate scope, risk mitigation, expectations, and responsibility until a balance was struck. If, after all that, we felt that a project was too high-risk, we (or any partner tasked with oversight) could pocket-veto the sale by refusing to sign off on it. (It's a testament to the sales teams that I rarely had to exercise that veto; out of those times, twice I had a veto overridden by partners higher up the food chain, and both times the projects failed along the load-bearing lines we identified.)

It doesn't always work out as planned, of course, but, in my experience (over a couple hundred million dollars' worth of work), we stuck the landing much more often than we failed. Trying to do this inside a company is a significantly different and more difficult experience, certainly, and it only works if the c-suite puts their muscle behind a disciplined innovation process that can exercise those same kinds of authority across internal silos.

I'll also point out that BigCo aligned on this overall approach because we, like most strategy/tech consultancies, experienced a lot of failures to launch, and burned out a lot of developers and designers along the way. When half the firm is coming out of massive waterfall-style projects that often fail because they're brittle and push risks to the very end, and the other half is used to just throwing devs at two-week timeblocks until something ships or everyone quits, you've got to find an approach that gives you as much knowledge and shape up front as possible, while still letting the development efforts come together flexibly through the dev process. Kudos to them for getting that done.

Re: The age of agile must end

#47

Post by squalo »

flandish wrote: post #37
taeric wrote: post #2

I share the current disdain for "agile" workflows. In particular, I have grown very weary of every example of failure getting met with "they did agile wrong." After enough encounters with it being done in a way that does not bode well, I am forced to start questioning the general ideas. However, I do find the excessive snark against wanting to empower the developers kind of off putting. In particular, zero charity in…

“They did agile wrong” always, when I hear it, makes me chuckle as if someone said “russia did communism wrong, it wasn’t the real …” Agile is middle / project managers doing cultish makework for themselves, to codependent-ly distract from feelings of life-cycle imposter syndrome.

I need that last line on a tshirt or bumper sticker

Re: The age of agile must end

#48

Post by awb »

Aeolun wrote: post #42
awb wrote: post #16

Earlier quoted context omitted.

At good companies they do adapt to engineering timelines. But marketing (reasonably) wants to know if an app launch is 4 weeks away or 8 weeks away and what features will be included so they can plan their campaign accordingly. And then there are things that are immovable like a holiday or a legal deadline, where it’s helpful to know the progress and ETA as accurately as possible as early as possible.

I realize that, and I’m happy to give estimates. It’s when they expect me to estimate something that fits in the schedule they’ve already decided on that it gets iffy.

For sure. Time and deliverables are the two concerns. Management can define one and engineering should define the other.

If time is defined by management (ex. a Christmas sale), then engineering should estimate which features can be done by then.

But I’ve definitely seen clients try to define both the timeline and the scope of work and that’s not a successful outcome for anyone.

Re: The age of agile must end

#49

Post by senko »

Kettle, pot.

In recent decades, UX has been coopted and corrupted to the point it's no longer about the user experience, it's about how best to manipulate users into doing things that will improve our growth metrics.

I agree in principle with the article, and have seen first-hand what agile[tm] can look like.

However, the tone comes off as condescending (the snarky agile manifestion translations don't help) and the conclusions come off as incredibly naive:

"Determine what to build, determine how best to build it, invest in foundations and do operations the right way"?

Gosh darn, that sounds so simple, why didn't I think of that earlier?!

Re: The age of agile must end

#50

Post by tensionheadx »

jermaustin1 wrote: post #41
Aeolun wrote: post #9

Earlier quoted context omitted.

The big problem is that it doesn’t fundamentally change the way you work, which is exactly “Do the thing until it’s done, then do the next thing”. What happens is that you get yanked off the thing halfway through, only to have the same thing happen with a few other things. Then folks ask why there’s 4 unfinished things lying around.

Only 4? I have an order of magnitude higher of unfinished tasks since December 2022 in my queue, and about 150 still assigned to me from all time. This is the life of a boring corporate developer in a highly hub & spoke software company where everyone lives in a vertical that is only allowed to speak to their direct manager. Any time I try to just update the branch to bring it rebase onto current master, I'm pulled i…

Wow, thx for those insights! Mostly worked in research and this manifests my darkest nightmares about working for corporations.
Post reply on HN