I don't think you even need PMs and UX to be involved here. Let the eng get a little bored and they'll find stuff to fix. The way it actually works though is we set some arbitrary impossible deadline, rush to meet it, creating a wake of tech debt, launch, and then straight on to the next thing.
The best way to build products I've found is to
1. hire passionate engineers.
2. give engineers enough room to breath and collaborate on the product.
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.
Even better, let the devs just watch the users use the product.
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.
> Let the eng get a little bored and they'll find stuff to fix.
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.
Where deviance is normalized, sure. If that dev didn't have to rely on 52 "weird tricks" and half-assed hacks just to keep their local environment running, they might care more about the quality of the product. But when everything around you has the grime of "just do enough to get it barely working", that's the game.
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.
sure but in some of the cases we were scaling products to millions of users. And it would work great but don't expect engineers to create good UI/UX paying attention to the "small" details. That won't happen naturally.
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.
Agile isn't entirely irrelevant, it's also not the main issue.
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.
Business is trying to maximize money. It seems like quality has much less of an impact on sales than many of us would wish. I am not sure why it is like that, but as long as it is... it is a financially rational decision to throw unpolished products on the market as fast as possible.
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 wish users more aggressive about their software. At least once a week I hear something along the lines of:
> 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.
I think you are on the right track, but realistically I think the answer is even more cynical: the last 20 years in software has been all about refining business models that remove choice and disempower customers. Quality doesn’t matter. Privacy doesn’t matter. Price matters a little, but only in the sense that you need to make your monthly SaaS fee low enough to avoid sticker shock- you don’t need to provide real value though. Just keep milking those monthly fees and make the UI a little worse every year or so.
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.
> It seems like quality has much less of an impact on sales than many of us would wish.
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.
It's the balance between staying in business, going out of business, reducing employee count, increasing employee count, etc. Also how much unpaid overtime is the dev willing to put into the project. That seems to be what causes most of us to not be allowed to put in the required time for properly sanding the UI.
Agile is relevant here because it has been adopted almost universally as a shovel to push more things on the programmer's back without much care to the quality of the changes being done.
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.
> Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto?
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.
Agree, we have some time in sprints to do whatever we want, and then you finally can fix those minor annoyances that are probably the users annoyance too.
But in general I think more time should be there reserved for it. It's now once in x sprints.
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.
He is not speaking for me but all enterprise projects I worked was like that. When devs (me included) run out of high priority tasks we ask or are directed to more high priority tasks, not fix the minor label/input issue, or the border of the disabled button in resolutions smaller than 400px, or whatever the PM/Scrum master didn't prioritize. Tired of bad management, developers just do what master Jira tell us to do.
I do my best to fix all open bugs in my own software, tho.
I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made.
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.
> I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made.
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.
I’m not sure if you meant this to be sarcastic but I think you’re on to something. In both cases: a rebellion against a soul crushing authoritarian system by writing a manifesto describing a decentralized utopia… which then gets implemented in an authoritarian context and undermined along the way until all that remains is the name and some window dressing from the manifesto. Orwell’s Animal Farm still resonates because of this.
If somebody says “be agile; do A, B, and C for better software engineering”, and you do not A, not B, and not C then complain about how terrible agile is, the problem is not with agile. You did something different to agile and got different results, so why are you blaming agile for your own failure?
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.
If somebody says “be communist; do A, B, and C for better society”, and you do not A, not B, and not C then complain about how terrible communism is, the problem is not with communism. You did something different to communism and got different results, so why are you blaming communism for your own failure?
It is, in fact, possible to implement communism wrong – by doing the exact opposite of communism. This is not a rhetorical trick you are catching people out on
"Waterfall" is not a development process. But plenty of the processes that give space for planning, also give space for QA. So surely agile, in the broad sense of development processes, is relevant to the comparison.
Being an actual process and being slow and bad are not opposites of each other. Literally, every recent software engineering book has a section on the "Waterfall Process". Nobody claims waterfall is good, but it is a software development process.
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.