50 ms·

You wrote almost exactly the same thing as the other person who replied. I have to ask (both you and jameshart): What makes you so defensive of Agile? What bene

You wrote almost exactly the same thing as the other person who replied. I have to ask (both you and jameshart): What makes you so defensive of Agile? What benefit have you seen it bring? Truly curious, not trying to bait anybody here. My experience with Agile—except when another engineer and I basically stealthed rapid development into a company with 12-month release cycles in the mid-2000s—has been overwhelmingly negative. 45-minute “standups,” major projects given 3 points, every negative stereotype bandied about on HN is something I’ve experienced.

jameshart 5y ago
Why do I 'defend' agile? I guess... for one thing, I have, multiple times in my career, been part of technology organizations that have positively transformed their relationship with business stakeholders by getting the business to buy the underlying truth: building software is a learning exercise; the requirements can and will change. And the frameworks you have to put in place to make that kind of relationship work, to replace the arbitrary deadlines and deathmarches? Turns out 'agile practice' has a bunch of useful ideas for those. Teams have limited capacity for 'work in progress'. The upcoming work can be prioritized on a backlog. Loose sizing estimates can help us make decisions about trading off time and features. You can only have one top priority at a time. It helps to let teams understand what problem they are trying to solve, not just tell them to implement a piece of a solution. That's what I value when I talk about 'agile'. A bunch of useful ideas stolen from scrum and kanban and lean and so on that actually help put developers in a position to solve the right problems in the right way, and get 'management' off their back. I'm also a fan of daily planning meetings to facilitate collaboration inside teams. I like retrospectives as a way to identify ways for teams to improve how they work. I like short fixed-duration iterations which deliver working code. I like pairing on problems. I like continuous integration and deployment and automated tests written alongside the code. Those are good practices that we, as a small team of developers, can use to help one another do good work, and ship working software. And those ideas are all also stolen from things like scrum and XP and TDD and devops, which are also all 'agile' practices. If someone tells me they don't like agile I am confused because... I don't know why you wouldn't want to work on teams that follow those kinds of practices. I do get that plenty of people have been subjected to environments that use things with the same names as these things in ways that aren't remotely agile. But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them is like saying you never want to use a programming language that has strings because PHP's string coercion sucks. I find these practices helpful, and better than not following them. I've been lucky to get to enjoy working in environments that use them, rather than have them badly forced upon me.
- ericbarrett 5y ago
  Thanks for the detailed reply! I have to say, everything you wrote sounds great. We'd probably agree on more than we'd disagree. That said... > But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them It's not that I've been subject to "a bad implementation." It's been multiple, across a decade, ever since Scrum became a thing, really. Disaster after disaster. I'd also add that most of the effective engineering I've seen (aside from the occasional uber-productive solo code artist) had clear priorities, effective intra- and inter-team communication, and certainly a disciplined retrospective process, all without Agile or Scrum. In the best cases it was self-organized, because we wanted to do good things for the sake of doing good things, and management understood we were trying to do the right thing, and got out of our way when we were being effective. When we weren't, it was a conversation, not school-time lockdown. I don't think that environment can be replicated by process or fiat, which is what the formalized Agile/Scrum of today seems to try (leaving aside the more cynical cases).
  - jameshart 5y ago
    So let me put it this way: Most businesses do not know how to manage software projects. That's not entirely special to software - most businesses don't really know how to manage anything. Agile tools offer a framework for technical teams for fighting off and thwarting crappy management that doesn't understand how to make software. But some crappy management organizations are really, really hard to thwart. Worse, some crappy management organizations have figured out how to neutralize agile tools, by co-opting them and trying to use them to continue crappily managing the software project. Sometimes they do this pre-emptively, neutering one of the only tools a technology organization has to fight back. I would love to know what else people have had success with as a way to fix crappy management other than setting up a properly agile 'safe space' for tech to happen in.
    - ericbarrett 5y ago
      This makes sense and puts it in a slightly new light for me—as a way of salvaging some productivity, when run by the developers, Agile/Scrum would certainly be better than many alternatives. I guess that’s what we did in my earlier reference, about 16 years ago. I wish it hadn’t become so coopted by the usual suspects.
Viliam1234 5y ago
I am a Scrum Master, because I decided that if I can't avoid Agile, at least I might learn to do it properly. So I got some training and read some books. And I was confused, because "this sounds nice, but is totally unlike any Agile I have actually seen as a developer". Then I took my role, and tried to implement the first thing they taught us at the training... but the management said "no". So I tried a different thing... but the management said "no" again. I asked what's the point of sending me to an Agile training if they override all my decisions, and the answer was, more or less, "we are doing Agile this way". My options were limited to do "Agile" their way, or to quit my role and be replaced by someone who will do "Agile" their way. So now we are doing Agile the way everyone hates and everyone does, with me in the role of the bad guy. Except our standups are 5 minutes long, because... that's the only part that remained firmly under my control. Otherwise, everything is the opposite of what the Agile trainings and books said. The management made a big announcement where they congratulated themselves for successfully transforming the company to Agile. From my perspective, this answers the question why "true Agile has never been tried". The people who make the decisions, they want the buzzwords and some of the rituals. They do not really want to give up any of their managing power. To try the Agile as intended... you would probably have to start a cooperative. Or be a very enlightened founder who can resist the temptation to use their power.
lmm 5y ago
I've seen Agile be hugely effective when actually done. It results in a much better product that's also more suited to what the customer needs, and therefore much more fulfilling to work on. It cuts through many of the most frustrating and wasteful parts of other kinds of software development at a stroke (e.g. endless architectural arguments). I genuinely think it's the best thing that's happened to my career. So it's frustrating to hear people attack it and especially frustrating when it gets attacked for the opposite of what it actually is. I don't know how to make people stop lying about what they're actually doing (I wish I did), but I don't think it's reasonable to expect any kind of process to work when you do the opposite of what that process actually tells you to do. (And I'm quite prepared to entertain the possibility that an organisation that actually committed to following RUP or Six Sigma or whatever and followed through on it might be better than half-assed non-Agile "Agile". But I haven't found the HN-endorsed "lol no process" to be effective in practice either)

jameshart 5y ago

Why do I 'defend' agile? I guess... for one thing, I have, multiple times in my career, been part of technology organizations that have positively transformed their relationship with business stakeholders by getting the business to buy the underlying truth: building software is a learning exercise; the requirements can and will change. And the frameworks you have to put in place to make that kind of relationship work, to replace the arbitrary deadlines and deathmarches? Turns out 'agile practice' has a bunch of useful ideas for those. Teams have limited capacity for 'work in progress'. The upcoming work can be prioritized on a backlog. Loose sizing estimates can help us make decisions about trading off time and features. You can only have one top priority at a time. It helps to let teams understand what problem they are trying to solve, not just tell them to implement a piece of a solution. That's what I value when I talk about 'agile'. A bunch of useful ideas stolen from scrum and kanban and lean and so on that actually help put developers in a position to solve the right problems in the right way, and get 'management' off their back. I'm also a fan of daily planning meetings to facilitate collaboration inside teams. I like retrospectives as a way to identify ways for teams to improve how they work. I like short fixed-duration iterations which deliver working code. I like pairing on problems. I like continuous integration and deployment and automated tests written alongside the code. Those are good practices that we, as a small team of developers, can use to help one another do good work, and ship working software. And those ideas are all also stolen from things like scrum and XP and TDD and devops, which are also all 'agile' practices. If someone tells me they don't like agile I am confused because... I don't know why you wouldn't want to work on teams that follow those kinds of practices. I do get that plenty of people have been subjected to environments that use things with the same names as these things in ways that aren't remotely agile. But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them is like saying you never want to use a programming language that has strings because PHP's string coercion sucks. I find these practices helpful, and better than not following them. I've been lucky to get to enjoy working in environments that use them, rather than have them badly forced upon me.

ericbarrett 5y ago
Thanks for the detailed reply! I have to say, everything you wrote sounds great. We'd probably agree on more than we'd disagree. That said... > But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them It's not that I've been subject to "a bad implementation." It's been multiple, across a decade, ever since Scrum became a thing, really. Disaster after disaster. I'd also add that most of the effective engineering I've seen (aside from the occasional uber-productive solo code artist) had clear priorities, effective intra- and inter-team communication, and certainly a disciplined retrospective process, all without Agile or Scrum. In the best cases it was self-organized, because we wanted to do good things for the sake of doing good things, and management understood we were trying to do the right thing, and got out of our way when we were being effective. When we weren't, it was a conversation, not school-time lockdown. I don't think that environment can be replicated by process or fiat, which is what the formalized Agile/Scrum of today seems to try (leaving aside the more cynical cases).
- jameshart 5y ago
  So let me put it this way: Most businesses do not know how to manage software projects. That's not entirely special to software - most businesses don't really know how to manage anything. Agile tools offer a framework for technical teams for fighting off and thwarting crappy management that doesn't understand how to make software. But some crappy management organizations are really, really hard to thwart. Worse, some crappy management organizations have figured out how to neutralize agile tools, by co-opting them and trying to use them to continue crappily managing the software project. Sometimes they do this pre-emptively, neutering one of the only tools a technology organization has to fight back. I would love to know what else people have had success with as a way to fix crappy management other than setting up a properly agile 'safe space' for tech to happen in.
  - ericbarrett 5y ago
    This makes sense and puts it in a slightly new light for me—as a way of salvaging some productivity, when run by the developers, Agile/Scrum would certainly be better than many alternatives. I guess that’s what we did in my earlier reference, about 16 years ago. I wish it hadn’t become so coopted by the usual suspects.

Viliam1234 5y ago

I am a Scrum Master, because I decided that if I can't avoid Agile, at least I might learn to do it properly. So I got some training and read some books. And I was confused, because "this sounds nice, but is totally unlike any Agile I have actually seen as a developer". Then I took my role, and tried to implement the first thing they taught us at the training... but the management said "no". So I tried a different thing... but the management said "no" again. I asked what's the point of sending me to an Agile training if they override all my decisions, and the answer was, more or less, "we are doing Agile this way". My options were limited to do "Agile" their way, or to quit my role and be replaced by someone who will do "Agile" their way. So now we are doing Agile the way everyone hates and everyone does, with me in the role of the bad guy. Except our standups are 5 minutes long, because... that's the only part that remained firmly under my control. Otherwise, everything is the opposite of what the Agile trainings and books said. The management made a big announcement where they congratulated themselves for successfully transforming the company to Agile. From my perspective, this answers the question why "true Agile has never been tried". The people who make the decisions, they want the buzzwords and some of the rituals. They do not really want to give up any of their managing power. To try the Agile as intended... you would probably have to start a cooperative. Or be a very enlightened founder who can resist the temptation to use their power.

lmm 5y ago

I've seen Agile be hugely effective when actually done. It results in a much better product that's also more suited to what the customer needs, and therefore much more fulfilling to work on. It cuts through many of the most frustrating and wasteful parts of other kinds of software development at a stroke (e.g. endless architectural arguments). I genuinely think it's the best thing that's happened to my career. So it's frustrating to hear people attack it and especially frustrating when it gets attacked for the opposite of what it actually is. I don't know how to make people stop lying about what they're actually doing (I wish I did), but I don't think it's reasonable to expect any kind of process to work when you do the opposite of what that process actually tells you to do. (And I'm quite prepared to entertain the possibility that an organisation that actually committed to following RUP or Six Sigma or whatever and followed through on it might be better than half-assed non-Agile "Agile". But I haven't found the HN-endorsed "lol no process" to be effective in practice either)