5 ms·

The age of agile must end

46 points by arunc 4y ago

taeric 4y ago
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 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.
- Turskarama 4y ago
  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.
  - crgwbr 4y ago
    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.
- flandish 4y ago
  “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.
  - squalo 4y ago
    I need that last line on a tshirt or bumper sticker
- deleted 4y ago
  [deleted]
Swizec 4y ago
Here’s all you need to know about agile: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 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. 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.
- ramesh31 4y ago
  >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.
  - awb 4y ago
    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.
    - Aeolun 4y ago
      For once it would be nice if they figured out those things can adapt to engineering time too, instead of the other way around.
      - awb 4y ago
gleenn 4y ago
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
- swader999 4y ago
  Yep. Problem developers can create larger problems with longer feedback cycles.
  - polotics 4y ago
    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...
Aeolun 4y ago
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.
- mvdwoord 4y ago
  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.
  - breckenedge 4y ago
    A word can have more than one definition.
    - mvdwoord 4y ago
      Sure, and language evolves. It is still misleading and or confusing, and I bet is by design.
  - Aeolun 4y ago
    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.
- HillRat 4y ago
  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.
devmor 4y ago
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.
- keyle 4y ago
  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.
  - l0b0 4y ago
    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.
- l0b0 4y ago
  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.
robertlagrant 4y ago
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 https://www.scrum.org/resources/what-is-a-product-backlog
winddude 4y ago
> 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.
wwarner 4y ago
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.
- rswskg 4y ago
  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.
mgbmtl 4y ago
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.
gerad 4y ago
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.
santoshalper 4y ago
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.
rektide 4y ago
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.
rippercushions 4y ago
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.
rcarr 4y ago
This is always a good read: https://blog.pragmaticengineer.com/project-management-at-big-tech/ https://blog.pragmaticengineer.com/project-management-at-big...
tony-allan 4y ago
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.
dazsnow 4y ago
Agile ≠ Scrum
senko 4y ago
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?!

46 points by arunc 4y ago

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 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.

Turskarama 4y ago
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.
- crgwbr 4y ago
  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.
flandish 4y ago
“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.
- squalo 4y ago
  I need that last line on a tshirt or bumper sticker
deleted 4y ago
[deleted]

Swizec 4y ago

Here’s all you need to know about agile: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 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. 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.

ramesh31 4y ago
>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.
- awb 4y ago
  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.
  - Aeolun 4y ago
    For once it would be nice if they figured out those things can adapt to engineering time too, instead of the other way around.
    - awb 4y ago

gleenn 4y ago

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

swader999 4y ago
Yep. Problem developers can create larger problems with longer feedback cycles.
- polotics 4y ago
  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...

Aeolun 4y ago

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.

mvdwoord 4y ago
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.
- breckenedge 4y ago
  A word can have more than one definition.
  - mvdwoord 4y ago
    Sure, and language evolves. It is still misleading and or confusing, and I bet is by design.
- Aeolun 4y ago
  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.
HillRat 4y ago
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.

devmor 4y ago

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.

keyle 4y ago
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.
- l0b0 4y ago
  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.
l0b0 4y ago
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.

robertlagrant 4y ago

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 https://www.scrum.org/resources/what-is-a-product-backlog

winddude 4y ago

> 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.

wwarner 4y ago

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.

rswskg 4y ago
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.

mgbmtl 4y ago

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.

gerad 4y ago

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.

santoshalper 4y ago

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.

rektide 4y ago

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.

rippercushions 4y ago

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.

rcarr 4y ago

This is always a good read: https://blog.pragmaticengineer.com/project-management-at-big-tech/ https://blog.pragmaticengineer.com/project-management-at-big...

tony-allan 4y ago

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.

dazsnow 4y ago

Agile ≠ Scrum

senko 4y ago

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?!