8 ms·

Agile isn’t about speed, it’s about direction

45 points by michalhosna 4y ago

jfdi 4y ago
Well it’s both imo - i.e., agile is about velocity.
- jcutrell 4y ago
  Any good process should care about both the vector and the magnitude. The saddest state of affairs, and most common, is when highly capable people have a high magnitude with an incorrect (or inconsistent) vector, leading them nowhere.
dec0dedab0de 4y ago
I thought agile was an elaborate scheme divised by energy vampires to drain the enthusiasm of developers through the use of rituals.
- pan69 4y ago
  That's scrum. Scrum uses agile but agile is not scrum.
  - SpeedilyDamage 4y ago
    I think of scrum as a way to get work done under little to no established trust between leadership and ICs. Isn’t that what the name supposed to evoke? Two groups locked in a push in opposite directions.
  - expazl 4y ago
    Your comment strikes me as a bit odd, let me explain why. Yes you're correct in saying that op was talking about scrum not agile, but "scrum uses agile" is a very confusing phrase. Scrum predates agile by 8 years, so how could it use something that wasn't invented when i was created. Also agile isn't something "to use" since it's not a framework. Scrum is something that you use, since it is an actual framework, and often people who implement agile use Scrum, because scrum was very much in the minds of the creators of the agile manifesto. And this should not surprise anyone as the creators of scrum where also part of the group that created the agile manifesto.
    - jesuscript 4y ago
      Damn, didn't even know Agile and Scrum had such deep lore.
      - slowmovintarget 4y ago
        Agile is not a noun. You develop with agility. Your team is agile. The largest problem with so many of these discussions is that people talking about them have pinned themselves to the noun of capital "A" Agile instead of recalling that the point is to curate and practice an empirical process instead of a defined process like in manufacturing. Scrum became one of the more popular process tool kits because it was a lot simpler to use than the entirety of eXtreme Programming (for example). Later a lot of consultant artifacts got piled on including a mishmash of other practices like Kanban, planning poker... etc. You won't find any of those in the original book on Scrum. The point was always frequent course examination and correction. Ken Schwaber, author of the Scrum book, was also one of the original signatories to the manifesto: https://agilemanifesto.org/ https://agilemanifesto.org/
jraph 4y ago
or its lack thereof
- Avshalom 4y ago
  Right. I mean half the pitch of the ol manifesto was "don't plan on finishing software because it's impossible to actually get requirements out of a customer ahead of time" And it was sold as a good thing.
  - AnimalMuppet 4y ago
    Well, if that's the world you actually live in, then you'd better be able to live in that world. (I mean, sure, ideally one should fix it. But your development approach has to work in the world you're trying to apply it in.)
julienreszka 4y ago
Give a break Agile is just an adjective. It's the antonym of clumsy/ungraceful.
- expazl 4y ago
  Yes, an Apple is just a fruit. But a fruit didn't create the iPhone. So perhaps when people talk about Apples upcoming phone, they probably mean the company not the fruit. And when people talk about Agile in relation to software development they likely mean to refer to Agile software development not just the word agile.
  - julienreszka 4y ago
    Apple has a very clear brand whereas the agile practices are convoluted and meaningless
oceanplexian 4y ago
I guess the “No True Agile” crowd is as alive and well as they were 10 years ago. When it’s a failure, they always come out of the woodwork to let you know you weren’t doing it according to the orthodoxy. When you point out that it isn’t faster in practice, they gaslight you and claim that was never the point in the first place. In a way it reminds me of a cult. You do a series arcane rituals that have no scientific evidence behind them, none of the process is data-driven or statistically proven. Frankly, it can’t die soon enough but as we all know some new hype will simply take its place to give busybody managers a reason to exist.
- ebiester 4y ago
  Fine. Let's assume that Agile is worse than the alternative. I am willing to accept that. However, which process are you arguing for, in its stead? "Programming, Motherfucker?" Shapeup? (Shapeup gets pretty close to agile in spirit.) Spiral Model? (I am assuming you're not arguing for RUP or others.) Conceptually, I like shapeup. I think spiral model is fine - I'd argue that a lot of "agile" shops are closer to spiral. Now, there are tools in agile that I'll vehemently defend, such as continuous integration and retrospectives. I'm a fan of most of the principles, such as "Continuous attention to technical excellence and good design enhances agility." But we are now at a point that if we're going to argue that "agile doesn't work," we've had enough time as an industry to gather around an alternative.
  - makeitdouble 4y ago
    Does it need to have a fancy name and can’t be some frankenstein process you set as you look at the team and address the part where they needs structure ?
  - righttoolforjob 4y ago
    The alternative is to just do what makes sense, without calling it anything. Junk shit like what scrum has become, for example not discussing technical stuff during standup (why the fuck not? that's what our job is about), artificially splitting stories into 2 week boxes (why the fuck should I break down something that isn't naturally breakable?), why create a card for every thing I'm working on (fucking control freak heaven), etc. It's completely juvenile, gaslighting, cargo cult scientology. Continuous integration => of course, for me, never worked at a place where it didn't happen and that was before agile was even a thing. If I hopped on a project where it didn't make sense though, I should be free to ditch it. There is no one way to write software that works for every project and there is no one process that works for every project. Just let the experienced folks decide what to use instead of leaning on some bullshit fixed crap process.
Jtsummers 4y ago
It's about both, it's just that ritualized Big-A Agile isn't about either. It's about the appearance of speed and selling certifications to companies and management that don't know better. I think "velocity" (from Scrum) actually evoked the correct idea, but most people seem to forget that velocity != speed. Velocity is a pair, speed and direction. Raw speed is useless if you're heading the wrong way (e.g., towards a solution for the wrong problem because you didn't bother validating along the way).
- AnimalMuppet 4y ago
  But if you can adjust the direction fast enough, you can quickly recover from the wrong direction. That is, it's about speed of adjusting, not just speed. (In sports, it's the difference between speed and quickness.)
  - marcosdumay 4y ago
    Only if you adjust into the right direction, and keep it after the adjustment. Theoretically, scrum was aimed at adjusting faster. But if the adjustments just keep coming, you won't go anywhere.
    - darreninthenet 4y ago
      But equally you don't burn on for months in the wrong direction
    - majormajor 4y ago
      If the adjustments just keep coming you have a business problem and no "process" will save you.
      - righttoolforjob 4y ago
        Where I currently work it's absolutely a process problem (of Scrum). The version of scrum they're running wants you to just get the committed stuff done, and it's irrelevant what it leads to. There is no room for understanding the end goal and making sure you reach it, with a set deadline as well. You might as always happens attack them for not doing Scrum right, and I'll tell you that's the age-old cry of the agile-folks: you're not doing it right, and nobody ever was. Fuck scrum, it's not agile, never was and never will be.
bsder 4y ago
Your semi-annual reminder that the promulgators of XP/Agile all came from the Chrysler Comprehensive Compensation System which failed miserably: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... Beck, Jeffries, Fowler, Hendrickson, and Wells are examples of Failing Upward(tm) rather than any example of good programming to be emulated.
oxfordmale 4y ago
This quote summarises everything that is wrong with Agile. >> rarely well implemented. The Agile Manifesto was published in 2001, over two decades ago. After all this time, and the involvement of a lot of clever people, even Agile advocates are stating it is rarely well implemented. Doesn't that suggest that Agile, as a management technique, has failed? True Agile is appears to be as elusive as the holy grail.
- baby 4y ago
  Isn’t agile just like 5 sentences that are pretty vague? If so what does it mean that it’s badly implemented? That sounds like the “they are not interpreting the bible correctly” type of argument.
  - agumonkey 4y ago
    I think it was Ward Cunningham who discussed that on a video. People in his group would interpret with nuances and good sense. But the thing became a fad and enterprise world turned it into an accounting exercise.
- jesuscript 4y ago
  Well, who is in the position to change an Agile process in any company? If we have 20 years of using this system, we should have enough feedback from developers and the business to refine what Agile is. I can tell you very few developers have input on the overall process in most places. It's not evolving into a better system because it's under the new bureaucratic regime of project managers. They are an institution now within the tech industry and are a self preserving entity. It's idiosyncratic for them to change this bureaucracy. If a developer were to say, "here is what I think about the process that governs me", the governors will laugh you out of the room with a delicate smile and sweet fuck you along the lines of "woah, that's great feedback!".
sakesun 4y ago
For me, Agile is about risk migitation by early knowledge building.
- nsxwolf 4y ago
  That could apply to waterfall also. You build all specifications and understanding up front, then you implement it to the specification.
  - majormajor 4y ago
    My opposition to waterfall is that building understanding through investigation and specifications is inferior as a way to get the finished product you need in the time you want, generally much inferior than building understanding through implementation. But I've always seen that somewhat orthogonal to team-level processes. You can "Agile™" or "Scrum™" the shit out of waterfall, after all. Create a ton of tickets for spec writing, etc.
    - ProfMeowsworth 4y ago
      The whole point of Scrum, in my opinion, is to create a working increment in the sprint. That’s the mechanism for managing risk. Finishing tickets for writing specs don’t achieve that. Unfortunately, it’s a common practice though.
      - majormajor 4y ago
        Yeah, having running software forces you to prove a certain level of correctness and lets people test against it. You can call a spec done arbitrarily and it's much harder to test that spec against any number of edge cases; and harder to visibly inspect "do these two specs get along" than "did this API call to this other place succeed?" "It doesn't compile" or "it throws an error" or "it doesn't do what it should" are all much more concrete and force you to confront "we might not understand the problem as well as we thought."
rco8786 4y ago
Can we just be done with “agile”? As far as I can tell it’s like communism. Seems to make sense on paper. Every time teams try and follow it things fall apart, and the crowd points and says they just weren’t doing it right. How about we just get the requirements and write the code, however that is best achieved in your org.
FpUser 4y ago
You are holding it wrong.
nineteen999 4y ago
It's about whatever some commentator thinks its about this week in order to get blog hits, sell more books, or to appear influential or as a thought leader etc etc etc. Most of us with a brain have looked at it and taken the best parts of what is there and incorporated into our workflow for ourselves and our teams, and dumped the rest. The rest just parrot on the same talking points with a different angle every week.
- cassianoleal 4y ago
  The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be. Every time I see something not quite working the way it should in an agile environment, I refer back to the manifesto. Anything that feels like it's going more towards "the things on the right", I point it out. Good managers are willing to listen. Most other engineers either already understand what's wrong or dislike the current processes anyway so are open to trying a bit less of them. When all else fails or when something feels off, get back to first principles.
  - majormajor 4y ago
    It's a similar version of "build vs buy" discussions that happen at every level, from "do we even build an engineering team vs outsource to contractors" to "do we include leftpad or write our own method," and everything in between. There are people out there with high amounts of resistance to using something someone else hasn't recommended or appeared to vet, at every level. It's often about trying to manage downside risk vs trying to maximize upside. Orgs where people are more afraid of having someone they can blame than they are motivated to truly excel are going to lean towards things they can pay other people to decide for them.
    - cassianoleal 4y ago
      https://www.forbes.com/sites/duenablomstrom1/2018/11/30/nobody-gets-fired-for-buying-ibm-but-they-should/ https://www.forbes.com/sites/duenablomstrom1/2018/11/30/nobo...
throwing_away 4y ago
Anyone remember this? https://agilemanifesto.org/ https://agilemanifesto.org/
unethical_ban 4y ago
It's about speed of changing direction. Duh. The entire supposed premise of agile is defining goals and constructing a product iteratively, so misunderstandings and changes in design can happen more quickly. The "quick" part being a change in direction. Given a perfect definition of a program and skilled ciders and unified vision from the beginning, agile would be meaningless.
Kon-Peki 4y ago
Nobody seriously measures "speed" in terms of how many words you type per minute. HN is pretty much in agreement that lines of code per day is a bad measurement of progress/accomplishment, right? We've seen so many bad variations on this concept: * Butts in seats means work is being done * Movement is progress etc. It's all bunk, of course, and here we are with agile. Corporate types are collecting some metric and the larger the value the higher the developer speed. Or so they think. Ideally, "speed" in this context is about direction. They are almost interchangeable. If you are going in the right direction, you have some amount of positive speed. Otherwise, it is negative or zero.
eezing 4y ago
Was the article created by a bot?
happytiger 4y ago
It’s actually about getting management out of the way of letting engineers do their jobs. There has never been a better strategy for letting engineers steer the ship and make decisions that ship code instead of getting micromanaged by non-experts that generally bungle things up and insert a bunch of external priorities without reconciling them with reality. The reality in my mind is that agile is the reaction to excess management, which is a massive problem in technology organizations. I’m sure there are other things too. Some of the other comments are gold. But that’s my 2c.
drewcoo 4y ago
No, compasses are about direction. Next. Seriously, there's very little substance to the article. It effectively says "agile doesn't work without customers." I'm pretty sure "customer collaboration" mattered back when it was a developer movement and not some kind of training sold to management. https://agilemanifesto.org https://agilemanifesto.org

45 points by michalhosna 4y ago

jfdi 4y ago

Well it’s both imo - i.e., agile is about velocity.

jcutrell 4y ago
Any good process should care about both the vector and the magnitude. The saddest state of affairs, and most common, is when highly capable people have a high magnitude with an incorrect (or inconsistent) vector, leading them nowhere.

dec0dedab0de 4y ago

I thought agile was an elaborate scheme divised by energy vampires to drain the enthusiasm of developers through the use of rituals.

pan69 4y ago
That's scrum. Scrum uses agile but agile is not scrum.
- SpeedilyDamage 4y ago
  I think of scrum as a way to get work done under little to no established trust between leadership and ICs. Isn’t that what the name supposed to evoke? Two groups locked in a push in opposite directions.
- expazl 4y ago
  Your comment strikes me as a bit odd, let me explain why. Yes you're correct in saying that op was talking about scrum not agile, but "scrum uses agile" is a very confusing phrase. Scrum predates agile by 8 years, so how could it use something that wasn't invented when i was created. Also agile isn't something "to use" since it's not a framework. Scrum is something that you use, since it is an actual framework, and often people who implement agile use Scrum, because scrum was very much in the minds of the creators of the agile manifesto. And this should not surprise anyone as the creators of scrum where also part of the group that created the agile manifesto.
  - jesuscript 4y ago
    Damn, didn't even know Agile and Scrum had such deep lore.
    - slowmovintarget 4y ago
      Agile is not a noun. You develop with agility. Your team is agile. The largest problem with so many of these discussions is that people talking about them have pinned themselves to the noun of capital "A" Agile instead of recalling that the point is to curate and practice an empirical process instead of a defined process like in manufacturing. Scrum became one of the more popular process tool kits because it was a lot simpler to use than the entirety of eXtreme Programming (for example). Later a lot of consultant artifacts got piled on including a mishmash of other practices like Kanban, planning poker... etc. You won't find any of those in the original book on Scrum. The point was always frequent course examination and correction. Ken Schwaber, author of the Scrum book, was also one of the original signatories to the manifesto: https://agilemanifesto.org/ https://agilemanifesto.org/

jraph 4y ago

or its lack thereof

Avshalom 4y ago
Right. I mean half the pitch of the ol manifesto was "don't plan on finishing software because it's impossible to actually get requirements out of a customer ahead of time" And it was sold as a good thing.
- AnimalMuppet 4y ago
  Well, if that's the world you actually live in, then you'd better be able to live in that world. (I mean, sure, ideally one should fix it. But your development approach has to work in the world you're trying to apply it in.)

julienreszka 4y ago

Give a break Agile is just an adjective. It's the antonym of clumsy/ungraceful.

expazl 4y ago
Yes, an Apple is just a fruit. But a fruit didn't create the iPhone. So perhaps when people talk about Apples upcoming phone, they probably mean the company not the fruit. And when people talk about Agile in relation to software development they likely mean to refer to Agile software development not just the word agile.
- julienreszka 4y ago
  Apple has a very clear brand whereas the agile practices are convoluted and meaningless

oceanplexian 4y ago

I guess the “No True Agile” crowd is as alive and well as they were 10 years ago. When it’s a failure, they always come out of the woodwork to let you know you weren’t doing it according to the orthodoxy. When you point out that it isn’t faster in practice, they gaslight you and claim that was never the point in the first place. In a way it reminds me of a cult. You do a series arcane rituals that have no scientific evidence behind them, none of the process is data-driven or statistically proven. Frankly, it can’t die soon enough but as we all know some new hype will simply take its place to give busybody managers a reason to exist.

ebiester 4y ago
Fine. Let's assume that Agile is worse than the alternative. I am willing to accept that. However, which process are you arguing for, in its stead? "Programming, Motherfucker?" Shapeup? (Shapeup gets pretty close to agile in spirit.) Spiral Model? (I am assuming you're not arguing for RUP or others.) Conceptually, I like shapeup. I think spiral model is fine - I'd argue that a lot of "agile" shops are closer to spiral. Now, there are tools in agile that I'll vehemently defend, such as continuous integration and retrospectives. I'm a fan of most of the principles, such as "Continuous attention to technical excellence and good design enhances agility." But we are now at a point that if we're going to argue that "agile doesn't work," we've had enough time as an industry to gather around an alternative.
- makeitdouble 4y ago
  Does it need to have a fancy name and can’t be some frankenstein process you set as you look at the team and address the part where they needs structure ?
- righttoolforjob 4y ago
  The alternative is to just do what makes sense, without calling it anything. Junk shit like what scrum has become, for example not discussing technical stuff during standup (why the fuck not? that's what our job is about), artificially splitting stories into 2 week boxes (why the fuck should I break down something that isn't naturally breakable?), why create a card for every thing I'm working on (fucking control freak heaven), etc. It's completely juvenile, gaslighting, cargo cult scientology. Continuous integration => of course, for me, never worked at a place where it didn't happen and that was before agile was even a thing. If I hopped on a project where it didn't make sense though, I should be free to ditch it. There is no one way to write software that works for every project and there is no one process that works for every project. Just let the experienced folks decide what to use instead of leaning on some bullshit fixed crap process.

Jtsummers 4y ago

It's about both, it's just that ritualized Big-A Agile isn't about either. It's about the appearance of speed and selling certifications to companies and management that don't know better. I think "velocity" (from Scrum) actually evoked the correct idea, but most people seem to forget that velocity != speed. Velocity is a pair, speed and direction. Raw speed is useless if you're heading the wrong way (e.g., towards a solution for the wrong problem because you didn't bother validating along the way).

AnimalMuppet 4y ago
But if you can adjust the direction fast enough, you can quickly recover from the wrong direction. That is, it's about speed of adjusting, not just speed. (In sports, it's the difference between speed and quickness.)
- marcosdumay 4y ago
  Only if you adjust into the right direction, and keep it after the adjustment. Theoretically, scrum was aimed at adjusting faster. But if the adjustments just keep coming, you won't go anywhere.
  - darreninthenet 4y ago
    But equally you don't burn on for months in the wrong direction
  - majormajor 4y ago
    If the adjustments just keep coming you have a business problem and no "process" will save you.
    - righttoolforjob 4y ago
      Where I currently work it's absolutely a process problem (of Scrum). The version of scrum they're running wants you to just get the committed stuff done, and it's irrelevant what it leads to. There is no room for understanding the end goal and making sure you reach it, with a set deadline as well. You might as always happens attack them for not doing Scrum right, and I'll tell you that's the age-old cry of the agile-folks: you're not doing it right, and nobody ever was. Fuck scrum, it's not agile, never was and never will be.

bsder 4y ago

Your semi-annual reminder that the promulgators of XP/Agile all came from the Chrysler Comprehensive Compensation System which failed miserably: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... Beck, Jeffries, Fowler, Hendrickson, and Wells are examples of Failing Upward(tm) rather than any example of good programming to be emulated.

oxfordmale 4y ago

This quote summarises everything that is wrong with Agile. >> rarely well implemented. The Agile Manifesto was published in 2001, over two decades ago. After all this time, and the involvement of a lot of clever people, even Agile advocates are stating it is rarely well implemented. Doesn't that suggest that Agile, as a management technique, has failed? True Agile is appears to be as elusive as the holy grail.

baby 4y ago
Isn’t agile just like 5 sentences that are pretty vague? If so what does it mean that it’s badly implemented? That sounds like the “they are not interpreting the bible correctly” type of argument.
- agumonkey 4y ago
  I think it was Ward Cunningham who discussed that on a video. People in his group would interpret with nuances and good sense. But the thing became a fad and enterprise world turned it into an accounting exercise.
jesuscript 4y ago
Well, who is in the position to change an Agile process in any company? If we have 20 years of using this system, we should have enough feedback from developers and the business to refine what Agile is. I can tell you very few developers have input on the overall process in most places. It's not evolving into a better system because it's under the new bureaucratic regime of project managers. They are an institution now within the tech industry and are a self preserving entity. It's idiosyncratic for them to change this bureaucracy. If a developer were to say, "here is what I think about the process that governs me", the governors will laugh you out of the room with a delicate smile and sweet fuck you along the lines of "woah, that's great feedback!".

sakesun 4y ago

For me, Agile is about risk migitation by early knowledge building.

nsxwolf 4y ago
That could apply to waterfall also. You build all specifications and understanding up front, then you implement it to the specification.
- majormajor 4y ago
  My opposition to waterfall is that building understanding through investigation and specifications is inferior as a way to get the finished product you need in the time you want, generally much inferior than building understanding through implementation. But I've always seen that somewhat orthogonal to team-level processes. You can "Agile™" or "Scrum™" the shit out of waterfall, after all. Create a ton of tickets for spec writing, etc.
  - ProfMeowsworth 4y ago
    The whole point of Scrum, in my opinion, is to create a working increment in the sprint. That’s the mechanism for managing risk. Finishing tickets for writing specs don’t achieve that. Unfortunately, it’s a common practice though.
    - majormajor 4y ago
      Yeah, having running software forces you to prove a certain level of correctness and lets people test against it. You can call a spec done arbitrarily and it's much harder to test that spec against any number of edge cases; and harder to visibly inspect "do these two specs get along" than "did this API call to this other place succeed?" "It doesn't compile" or "it throws an error" or "it doesn't do what it should" are all much more concrete and force you to confront "we might not understand the problem as well as we thought."

rco8786 4y ago

Can we just be done with “agile”? As far as I can tell it’s like communism. Seems to make sense on paper. Every time teams try and follow it things fall apart, and the crowd points and says they just weren’t doing it right. How about we just get the requirements and write the code, however that is best achieved in your org.

FpUser 4y ago

You are holding it wrong.

nineteen999 4y ago

It's about whatever some commentator thinks its about this week in order to get blog hits, sell more books, or to appear influential or as a thought leader etc etc etc. Most of us with a brain have looked at it and taken the best parts of what is there and incorporated into our workflow for ourselves and our teams, and dumped the rest. The rest just parrot on the same talking points with a different angle every week.

cassianoleal 4y ago
The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be. Every time I see something not quite working the way it should in an agile environment, I refer back to the manifesto. Anything that feels like it's going more towards "the things on the right", I point it out. Good managers are willing to listen. Most other engineers either already understand what's wrong or dislike the current processes anyway so are open to trying a bit less of them. When all else fails or when something feels off, get back to first principles.
- majormajor 4y ago
  It's a similar version of "build vs buy" discussions that happen at every level, from "do we even build an engineering team vs outsource to contractors" to "do we include leftpad or write our own method," and everything in between. There are people out there with high amounts of resistance to using something someone else hasn't recommended or appeared to vet, at every level. It's often about trying to manage downside risk vs trying to maximize upside. Orgs where people are more afraid of having someone they can blame than they are motivated to truly excel are going to lean towards things they can pay other people to decide for them.
  - cassianoleal 4y ago
    https://www.forbes.com/sites/duenablomstrom1/2018/11/30/nobody-gets-fired-for-buying-ibm-but-they-should/ https://www.forbes.com/sites/duenablomstrom1/2018/11/30/nobo...

throwing_away 4y ago

Anyone remember this? https://agilemanifesto.org/ https://agilemanifesto.org/

unethical_ban 4y ago

It's about speed of changing direction. Duh. The entire supposed premise of agile is defining goals and constructing a product iteratively, so misunderstandings and changes in design can happen more quickly. The "quick" part being a change in direction. Given a perfect definition of a program and skilled ciders and unified vision from the beginning, agile would be meaningless.

Kon-Peki 4y ago

Nobody seriously measures "speed" in terms of how many words you type per minute. HN is pretty much in agreement that lines of code per day is a bad measurement of progress/accomplishment, right? We've seen so many bad variations on this concept: * Butts in seats means work is being done * Movement is progress etc. It's all bunk, of course, and here we are with agile. Corporate types are collecting some metric and the larger the value the higher the developer speed. Or so they think. Ideally, "speed" in this context is about direction. They are almost interchangeable. If you are going in the right direction, you have some amount of positive speed. Otherwise, it is negative or zero.

eezing 4y ago

Was the article created by a bot?

happytiger 4y ago

It’s actually about getting management out of the way of letting engineers do their jobs. There has never been a better strategy for letting engineers steer the ship and make decisions that ship code instead of getting micromanaged by non-experts that generally bungle things up and insert a bunch of external priorities without reconciling them with reality. The reality in my mind is that agile is the reaction to excess management, which is a massive problem in technology organizations. I’m sure there are other things too. Some of the other comments are gold. But that’s my 2c.

drewcoo 4y ago

No, compasses are about direction. Next. Seriously, there's very little substance to the article. It effectively says "agile doesn't work without customers." I'm pretty sure "customer collaboration" mattered back when it was a developer movement and not some kind of training sold to management. https://agilemanifesto.org https://agilemanifesto.org