The age of agile must end(uxdesign.cc)
uxdesign.cc
The age of agile must end
https://uxdesign.cc/the-age-of-agile-must-end-bc89c0f084b7
49 comments
“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.
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
The problem with this is that agile when done well is actually the best way to build software. Just because people misuse it (the name OR the method) doesn't actually make it bad.
And whatever you try to replace it with, you can expect middle management to do that wrong as well.
And whatever you try to replace it with, you can expect middle management to do that wrong as well.
Eh, at best agile done well is the best way _we know of now_ to build _some kinds of_ software. I certainly don’t think it’s the best for mission critical software (e.g. someone dies if there’s a bug in this). And even for lower stakes things I’d find it incredibly hard to believe that we’ll never find anything better.
[deleted]
> It has to be timeboxed into a Sprint to make sure software can be released into the market in an “iterative” cycle.
No it doesn't, you just want to be able to get feedback from stakeholders at each iteration.
There also exists the idea of spikes, where the whole purpose is you throw it away at the end.
No it doesn't, you just want to be able to get feedback from stakeholders at each iteration.
There also exists the idea of spikes, where the whole purpose is you throw it away at the end.
Here’s all you need to know about agile:
Agile works. But you have to actually do agile.
Yes, it’s hard. You have to hire good people and get out of their way. Trust is key. Let them do the work however they want, it’s gonna be okay. Focus on the outcome, not on feeling in control.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile works. But you have to actually do agile.
Yes, it’s hard. You have to hire good people and get out of their way. Trust is key. Let them do the work however they want, it’s gonna be okay. Focus on the outcome, not on feeling in control.
>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 that would be super helpful to have all of these tickets, and track the progress of our burndown chart, and what's our velocity this sprint compared to last?".
It's just a game to play with the company folks put in charge of watching over us doing our thing.
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 that would be super helpful to have all of these tickets, and track the progress of our burndown chart, and what's our velocity this sprint compared to last?".
It's just a game to play with the company folks put in charge of watching over us doing our thing.
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.
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.
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.
Wow, thx for those insights! Mostly worked in research and this manifests my darkest nightmares about working for corporations.
These deliverables are usually tied to external events with lead times of their own like an ad campaign, new hire, funding, etc.
Engineering teams that can more accurately estimate their delivery dates add tangible value to their company.
Engineering teams that can more accurately estimate their delivery dates add tangible value to their company.
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.
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.
And in case of hard/real deadlines, there is usually opportunity to say “We can’t do X, but can Y be good enough?”. Those are important conversations to have.
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.
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.
So far I’m at 3 out of 5. It’s a bit sad that all the good experiences were with companies <200 employees.
> all the good experiences were with companies <200 employees
My best experience has been at a hyper growth company that roughly 10x’d in 2 years. The extreme focus on keeping up with demand meant that all manner of bullshit just melted away because nobody had time for that.
My best experience has been at a hyper growth company that roughly 10x’d in 2 years. The extreme focus on keeping up with demand meant that all manner of bullshit just melted away because nobody had time for that.
Agile = the team who’s working to solve the problem should work together to figure out the best process for solving it.
That’s really all that there is to it. The point of it is that the process shouldn’t be handed from the top down and those folks who are in the trenches should be the ones who are choosing, evaluating and improving the process.
Stuff changes a lot in software, so the team needs to be able to adapt and change with it.
That’s really all that there is to it. The point of it is that the process shouldn’t be handed from the top down and those folks who are in the trenches should be the ones who are choosing, evaluating and improving the process.
Stuff changes a lot in software, so the team needs to be able to adapt and change with it.
Coming from big corp, I definitely miss my days at smaller shops that did Agile. I feel like so much of this has little to do with the development methodology and more to do with the people though. Smart people can make any methodology. Even at big corp, more waterfall-y processes are not terrible because I think my coworkers make it alright. The author seems to be unhappy about empowered developers being problematic, which I've seen, but a few of those people probably would have been as big a pain as in waterfall land. In general, I think Agile is good because it emphasizes smaller iterations and adapting processes, amongst many other connotations. I think the core of those ideas are miles ahead of whatever was produced decades ago by more rigorous engineering processes. Building a bridge is not the same as building a big piece of software. Developing software is hard in general. I think we're just slowly iterating as an industry towards better practices and we aren't there-there yet. As always, YMMV
Yep. Problem developers can create larger problems with longer feedback cycles.
The main difference between Some-planning-up-front and big-A Agile IMHO is that responsibility for failure of delivering on the plan can be shunted away from the leadership to a slow-burn failure of delivering on quality after many iterations. A product will have been built, but it is too costly, low quality, expensive to maintain. Lack of qualified software design can be papered over for several years with the big A...
I've worked in one (1) effective agile team in my entire career, and that one had an end user fully integrated into the team, providing near-realtime feedback and prioritizing bugs and feature development.
But this would leave the product manager out of a job, so I've never seen any other company even try it.
But this would leave the product manager out of a job, so I've never seen any other company even try it.
I hate "agile".
Would love to try agile some day. Never worked anywhere that actually did agile though - lots of places with bits and pieces. So many scrum masters, standup meetings, T-shirt sizing, kanban boards... but never full agile.
Starting to think it's a myth.
Would love to try agile some day. Never worked anywhere that actually did agile though - lots of places with bits and pieces. So many scrum masters, standup meetings, T-shirt sizing, kanban boards... but never full agile.
Starting to think it's a myth.
It is not a myth but it is quite rare. Either you have incompetent management, or incompetent development, or both, which will make it impossible.
Agile only works with trust, trust that every level of the organisation is experienced, focused and aligned. Most organisations end up bastardising it because that's not the case.
Agile only works with trust, trust that every level of the organisation is experienced, focused and aligned. Most organisations end up bastardising it because that's not the case.
Trust is absolutely core to an agile workplace. If everyone's busy covering their own ass nothing impactful really gets done, and "feedback" is just everybody saying nothing because they don't dare disagree.
It's not a myth, but I don't think there's any easy way to tell whether you'll be working with someone who actually knows it within the interview cycle. I got my first real taste of both TDD and Agile from a tiny startup, and it was the fastest and most impactful learning period of my career.
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 through the first sprint.
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 through the first sprint.
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. (I have had to explain this to multiple managers.
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. (I have had to explain this to multiple managers.
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.
A word can have more than one definition.
Sure, and language evolves. It is still misleading and or confusing, and I bet is by design.
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 sometimes months, of calendar time ahead of encumbering the full dev team (and you better not roll all your devs into sprint zero in a big bang for the same reason), but it doesn't mean doing a full waterfall, either. It's just that if you have a must-deliver project, you need to have an atlas ready to go, even though the turn-by-turn directions will emerge through the project.
Even when designers go into refined visual design mode, the solutions plan should have them running at least one, ideally two sprints ahead of development to prevent starvation. My suspicion is that he's been a victim of the "let's throw everyone into the same timebox" scenario that projects default to in the absence of real solutioning and project governance. When "agile" is used as an excuse for a lack of planning, everyone suffers.
Even when designers go into refined visual design mode, the solutions plan should have them running at least one, ideally two sprints ahead of development to prevent starvation. My suspicion is that he's been a victim of the "let's throw everyone into the same timebox" scenario that projects default to in the absence of real solutioning and project governance. When "agile" is used as an excuse for a lack of planning, everyone suffers.
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.
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.
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.
Somehow an author with an MBA background fails to interrogate the business impact of their advice and various interpretations of agile.
I’m also slightly incredulous that they got through an MBA program without the reading comprehension needed to tackle the agile manifesto…
I think this is actually a blogspam article meant to drive outrage. Shame on HN for falling for it.
I’m also slightly incredulous that they got through an MBA program without the reading comprehension needed to tackle the agile manifesto…
I think this is actually a blogspam article meant to drive outrage. Shame on HN for falling for it.
I’m not. When you meet a good manager with an MBA, chances are they’d have been (or were) a good manager without one, too. But in my experience, no bad manager has ever improved by getting an MBA. All they get is an indication they’re upper class enough to get into a program and possibly to take time off of work to do it.
This is always a good read:
https://blog.pragmaticengineer.com/project-management-at-big...
https://blog.pragmaticengineer.com/project-management-at-big...
I'm not a particular fan of agile but the article goes a bit far and appears to be a critique of a poorly implemented agile methodology with inadequate resources.
Having a smooth and well organised release cadence is a good idea. Obviously skipping strategy and UI work is a bad idea. These tasks need to be done in parallel and inform each well thought-out sprint.
Having a smooth and well organised release cadence is a good idea. Obviously skipping strategy and UI work is a bad idea. These tasks need to be done in parallel and inform each well thought-out sprint.
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?!
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?!
You know, I'm definitely skeptical of the Agile Industrial Complex, but man, this article is doing us skeptics no favors. This is not a Software Person.
There's valid criticism as always (no process is perfect), but I'm pretty uncomfortable with how the intro starts with a series of false assertions, as if no one ever has questioned agile.
The tl;dr is that, as a UX designer, this person is frustrated by corners being cut.
As a dev, I get frustrated if I need to develop something that I know won't be used. I like being in contact with the customer and I like receiving quick feedback.
Obviously, as anyone, I don't like having pressure to deliver and silly metrics. So I'm my own boss and I negotiate with the client. If the client doesn't like it, they can quickly realize that and they won't have lost a lot of money.
The tl;dr is that, as a UX designer, this person is frustrated by corners being cut.
As a dev, I get frustrated if I need to develop something that I know won't be used. I like being in contact with the customer and I like receiving quick feedback.
Obviously, as anyone, I don't like having pressure to deliver and silly metrics. So I'm my own boss and I negotiate with the client. If the client doesn't like it, they can quickly realize that and they won't have lost a lot of money.
It's agile forever and ever man. We are totally path dependent on this. It seems impossible to have any other idea of what we might do that might take off.
Agile is ironically one of the best indicators of fixedness on the planet. It was a simple idea that has taken root, & will never ever ever be removed.
Agile is ironically one of the best indicators of fixedness on the planet. It was a simple idea that has taken root, & will never ever ever be removed.
False. Hey, early and frequent releases, cicd, unit testing, small teams with courage and responsibility, all of those come out of agile. Yes, it come with a lot of hot air, and yes, not every project should be agile, but show some respect man.
The hot air came later when the project manager gods realised they had to rebrand if they were going to continue telling coders what to do.
I feel like that journalist who wrote an article called "Stop making me defend Donald Trump". I don't particularly like Scrum, but articles like this just give not liking Scrum a bad name. I wouldn't trust anything it says, really.
Here's a sample:
> It has to be timeboxed into a Sprint to make sure software can be released into the market in an “iterative” cycle.
The key is "potentially shippable increment". You don't have to ship it. The point is that if you don't have that mentality then you start to forget all the 50 steps needed to actually release, and also that small changes are more reliable than big changes.
> Sprint Planning happens right before the sprint because that’s when you’ll have the latest insights on what to focus on, just in time.
Yes, true.
> There’s a Daily Standup to have on-the-fly “operational improvements.” (Only developers are allowed to speak and discussion is not allowed because that leaves the machinery idle.)
"Developers" being anyone in the team, including UX. It's not about "leaving the machinery idle" - working a bit of a silly metaphor from the article back into the "why" of Scrum seems pointless - it's about having quick meetings. You can have conversations elsewhere, and regular meetings elsewhere; they just aren't for the daily standup. Unless you have a retro and decide to change it.
> At the end of the sprint there’s a Review to view working software and to determine what was not completed or what needs improvement.
That's sort of right, but an odd emphasis. It's to get feedback from the people you're building for.
> There’s also supposed to be a Retrospective to discuss what went well and what didn’t go well, in the interest of increasing the quantity of output.
No, not necessarily. It could be spotting that quality is low, or the team is taking on too much and burning out, or that things external to the team are really slowing something down (e.g. Todd still doesn't have a new laptop and he can't run the latest XCode), or anything else that would be an improvement. Again, why try working the silly metaphor back into reality?
> The Backlog isn’t core to the Scrum practice, it’s an artifact of the collateral damage and detritus of everything jettisoned during the sprint.
I don't think the author knows what the backlog is (or backlogs are). They are part of Scrum[0].
[0] https://www.scrum.org/resources/what-is-a-product-backlog
Here's a sample:
> It has to be timeboxed into a Sprint to make sure software can be released into the market in an “iterative” cycle.
The key is "potentially shippable increment". You don't have to ship it. The point is that if you don't have that mentality then you start to forget all the 50 steps needed to actually release, and also that small changes are more reliable than big changes.
> Sprint Planning happens right before the sprint because that’s when you’ll have the latest insights on what to focus on, just in time.
Yes, true.
> There’s a Daily Standup to have on-the-fly “operational improvements.” (Only developers are allowed to speak and discussion is not allowed because that leaves the machinery idle.)
"Developers" being anyone in the team, including UX. It's not about "leaving the machinery idle" - working a bit of a silly metaphor from the article back into the "why" of Scrum seems pointless - it's about having quick meetings. You can have conversations elsewhere, and regular meetings elsewhere; they just aren't for the daily standup. Unless you have a retro and decide to change it.
> At the end of the sprint there’s a Review to view working software and to determine what was not completed or what needs improvement.
That's sort of right, but an odd emphasis. It's to get feedback from the people you're building for.
> There’s also supposed to be a Retrospective to discuss what went well and what didn’t go well, in the interest of increasing the quantity of output.
No, not necessarily. It could be spotting that quality is low, or the team is taking on too much and burning out, or that things external to the team are really slowing something down (e.g. Todd still doesn't have a new laptop and he can't run the latest XCode), or anything else that would be an improvement. Again, why try working the silly metaphor back into reality?
> The Backlog isn’t core to the Scrum practice, it’s an artifact of the collateral damage and detritus of everything jettisoned during the sprint.
I don't think the author knows what the backlog is (or backlogs are). They are part of Scrum[0].
[0] https://www.scrum.org/resources/what-is-a-product-backlog
Agile ≠ Scrum
However, I do find the excessive snark against wanting to empower the developers kind of off putting. In particular, zero charity in reading is given to looking at how it was taken up. And there is practically no way that is accurate, either.
My personal view is that treating the entire "software" industry as a homogeneous one is the mistake here. From type of product being delivered to capabilities of team doing the delivery, there is a lot of variance out there in what one would expect to work. Worse, thinking that any given other field has "figured it out" is doing a major disservice to the hard work that goes into every field.