This is a process that generally requires a product manager to choose to prioritize, together with a capable UX engineer and/or designer.
That prioritization can be inserted into any development methodology if you want it.
Agile is irrelevant here.
Every project that uses Agile defeats 2. I'm not saying that Agile is the reason for this but after 15 years of seeing this repeatedly I'm very wary of places which place Agile as a component of their culture.
https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-...
That is the opposite of all engineers I worked with. Engineers easily learn that they should click in the specific part of the element and will forget it is an issue and use it like that for 5 years if nobody point that the issue is making the UX terrible for most users.
I can't help thinking that the "fungible engineer" concept has done a lot of harm to tech hiring and team structure - of course if you take a guy who most is excited about database optimisation and put him on UI work he won't be passionate about it.
The will to have nice things is a cultural value that some companies just don't have, and if they don't have it for themselves, they won't have it for their customers.
I often join support when they have a call with a customer demonstrating an issue. I also sometimes get to join support when they're on-site for training or similar.
Every time I watch users use our product, I learn so much about what to do and what not to do.
It's a cultural one. If someone tells me they work on an 'Agile Development' team my immediate perception is that they are a culture of cargo culting and bike shedding, without putting a ton of thought or care into their product, process, or users. These systems are designed to maximize output, not the quality of the output.
Management is likely out of touch with the demands of creating a high quality product. This leads to misalignment with the development team and probably the business needs. Most businesses need a higher quality product than they have. Some don't, though. In those circumstances it doesn't really matter - I recommend avoiding these places like the plague.
It would be easy to blame the customers. But let's look in the mirror -- how do I make purchase decisions as a customer?
Actually, not a good example, because I usually don't buy software. OK, I buy Windows, but... I don't feel like I have a choice between more polished and less polished versions of Windows. Other than that, I use free software. When I use software at work, someone else made the decision and I had zero input. And that kind of software usually sucks (now I am thinking of Confluence, Jira, and other user-hostile monstrosities).
So I guess a part of the answer is that if you sell software to business, there is no need to make it nice, because the people who decide whether the company buys it are not the ones who will be stuck with using it.
> I'm not a technology person, so I can't make X do Y
It would be so much better if the go to response was:
> This technology sucks, so I can't make X do Y. And if it can't even manage to make Y easy, then I'm sure not going to trust it with Z, and I'm going to tell my friends that they shouldn't either.
If the business types need to be reminded that the quality problem is hurting them, then we should coordinate among ourselves to ensure that it hurts even more until they notice.
This is the unpleasant truth of the matter. As people who hone our craft and want to take pride in our work, a competent developer’s ethos is at odds with maximizing profit.
Lack of interoperability and vendor lock-in, the move toward SaaS software that you run on behalf of your customers, making network effects fundamental to your value prop, bundling, and the enterprise sales tactics you pointed out are all ways that quality of software has been removed from the conversation entirely.
Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto? It is how it is used, not what it was used for.
Increasingly, I am also blaming the Agile Manifesto for causing the mess we are all in.
Given current business tendencies, the authors should have probably foreseen the future consequences of their wishy-washy manifesto declarations. I think "true Agile has never been implemented" should not absolve them from assuming some responsibility.
When working on my own apps it's really obvious that non focused time leads to lots of improvements. Instead of only the business wishes. In that regard it seems that the potential of a dev is a bit diminished when you don't have time to do things according to your own priorities.
Window dressing in the virtual space! Spending too much time/effort worrying about this nears sabotage, IMO
No we don't.
I do my best to fix all open bugs in my own software, tho.
I think in a company like Steve Job's Apple, where it needs to look perfect (within his tastes), you'd have the time to polish the UI even with agile/scrum - one of the acceptance criteria will be "I spent 5 minutes kicking it and I didn't get any splinters". and then later on when Steve gets a splinter, he'd yell at you for a bit and then create a ticket.
This is the exact opposite of agile. Direct from the Agile Manifesto:
> Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
> Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
> The best architectures, requirements, and designs emerge from self-organizing teams.
It is, in fact, possible to implement agile wrong – by doing the exact opposite of agile. This is not a rhetorical trick you are catching people out on.