6 ms·

Surprised to see this post so far up on HN. Not only is Agile still very valuable with lots of good lessons to teach us - this guy's complaints are technically

Surprised to see this post so far up on HN. Not only is Agile still very valuable with lots of good lessons to teach us - this guy's complaints are technically wrong - his examples pertain to the use of the word as a verb or an adjective - not as a noun. And, to be fair, in the context of software, turning Agile into a verb is perfectly fair. "Agile Master Alliance" - Adjective - it modifies "Master" "How to Agile" - Verb. "Agile Certificate" - Adjective. You could argue that it is a nominalization, but that is truly splitting hairs. Let's put it another way: if this guy doesn't know what a [gerund](https://en.wikipedia.org/wiki/Gerund https://en.wikipedia.org/wiki/Gerund) is, or what [nominalization](https://en.wikipedia.org/wiki/Nominalization https://en.wikipedia.org/wiki/Nominalization) is, that is not Agile's problem. So, in the end, what is this guy's point, other than "get off my lawn"? Edit/update: Magdoub's point is this: >You don’t need velocity, daily stand ups, points estimations, spikes, scrum masters to deliver high quality software. You just need good people. That is so catastrophically false that I don't even know where to start. I mean, really sanity-blasting. Sure, maybe cargo-cult adherence to agile tenets is not going to help anyone, but throwing management methodology out the window and hoping that "good people" just somehow summon good software into being is comically naive.

joslin01 10y ago
> but throwing management methodology out the window and hoping that "good people" just somehow summon good software into being is comically naive. Maybe so, but to play devil's advocate, it's Valve's entire business model.
- 15charlimit 10y ago
  Which caused SteamOS to be DOA and made "HL3/Episode 3 never" into an internet-wide inside joke. Not the best example you could have chosen.
  - Mindstormy 10y ago
    I would say that their business goals have just changed over time, they went from being a company that spits out games, to a company that spits out money. While the end results have changed there is still underlying software that powers all of these things. Look at the in game cosmetics economy that has sprung up around dota2 and cs:go. If anything this is the definition of being Agile.
  - awesomerobot 10y ago
    "Spits out money" isn't a business strategy. They've simply found distribution to be more profitable than production.
  - joslin01 10y ago
    Forgive me, but I'm not making a stance. I'm just pointing out this is generally Valve's game-plan.
- awesomerobot 10y ago
  To further your advocacy... how many successful examples can you point to outside of Valve? How does that compare to the number of groups that are using some form of agile methodology to produce a successful product?
  - joslin01 10y ago
    None. Like I said below, I'm not taking a stance. I practice "agile" at my company, but Valve's existence does refute the claim that it's comically naive. Now, if I had to offer my 2 cents why it works at Valve and not others -- games are deeply creative. You actually want your engineers to go off in their own little world and somehow capture the sparks that fly. It's nearly impossible to do this with some sprint model ("OK guys, creative thinking sprint! let's go!"). To re-iterate, the reason why it doesn't work with games is sprints are output-driven yet the creative output is not so easy to capture in this manner. Its origin is mysterious and subject to "ah ha!" moments whenever/wherever. This is why games must instead focus on process (hire the best, let them do whatever) and take a hit on strict output-driven management. Yet, the big dogs have been pushing one game out after another. For example, WoW got bought by Activision and they couldn't get new expansions out soon enough. One of the most popular MMOs, Ultima Online, was bought by EA and they immediately started their expansion line of junk and ruined the game. This wears down on the overall brand of the game. Ultimately, output-driven management of games is a sure way to lose the creativity and balance necessary to create a gem.
- elthran 10y ago
  To be picky, it's valve's management model, their business model is just to be a marketplace/hat vendor, allowing transactions on other people's work. I'm long past the point of viewing them as a company selling software.
  - swampthinker 10y ago
    And given their poor history in putting out new games and content, I'm honestly not too impressed by Valve as of late.
  - joslin01 10y ago
    Thanks, you're right.
  - deleted 10y ago
    [deleted]
- rubiquity 10y ago
  When I worked at certain top software companies the people I worked with were often so talented and, most importantly, cared enough about the work they did that we could have produced great software with any form of process. In fact, we often started with "base Scrum" and about 6 or so months in we would have a completely modified version of Scrum. My point is, I don't think Valve is hiring average or below average people. Their process works for them because great people make any process work. Or maybe great people just make their own process, which is the most Agile-y of Agile things you can possibly do.
awesomerobot 10y ago
"You just need good people" is a solution like telling the homeless to "stop being poor"
wmeredith 10y ago
I agree, the failure to grasp the basics of english grammar around which the author has declared his/her thesis is cringeworthy.
at-fates-hands 10y ago
>>> and hoping that "good people" just somehow summon good software into being is comically naive You have no idea how true this statement is. I was on a small project about a year ago, using Agile. Both mangers and a director quit within weeks. Our team basically became self sustaining. No PM's, no managers. Our team had no oversight and no captain to steer the ship. We were left to finish the project ourselves. We had a team of 5 developers. We sat at lunch one day, bound and determined to show management we could do this without all the daily standups, agile tracking, burn down rates and stupid PM oversight. I wanted to quit inside of two weeks. 3 developers were advocating a total rewrite and a pivot to a different stack. Myself and another developer just wanted to finish the app and get it shipped. Egos, a tight timeline and several rash decisions doomed us. Instead of showing management we could do this ourselves, it became blatantly obvious this project would not get completed without a ton of oversight and guidance from an experienced project manager. It's all rainbows and unicorns when you think about it. "Just get some good developers together and they can get it done!" sounds so romantic, but in reality, it always ends up in a total shit show, as I experienced first hand. It was a tough lesson to learn that management actually do have a job to do and they understand a lot of stuff developers never have to worry about.
- ktRolster 10y ago
  3 developers were advocating a total rewrite and a pivot to a different stack. Those were not good developers; ie, there are some skills they were clearly lacking. I've lived through the opposite situation as you: management left the company, and we continued to release for the next few months without any management at all. The key, I think, was that the managers had pushed the decision making down. Everyone took turns being scrum master......so when the next sprint came, we elected a new scrum master and carried on. Fred Brooks pointed out that with a group of competent programmers, any development methodology can work. The best development methodologies help programmers become self-sufficient (teaching them the skills if they don't have them), instead of trying to micro-manage.
  - mikejholly 10y ago
    > Those were not good developers Nailed it.
mikejholly 10y ago
Lemme guess, Scrum Master? Although those faux titles may be technically wrong, the use of capital-A Agile usually implies association with Agile the brand (the noun), not "agile as in agility". > That is so catastrophically false that I don't even know where to start. Doesn't sound like a great argument. The highest performing teams I've worked with were small groups of highly skilled, talented (IQ and EQ) and passionate people. These groups are usually familiar with various development methodologies and able to come to agreement on which processes to adopt and which are cargo-culty and should be thrown out. I don't think OP is arguing for zero process. In fact the opposite is clearly stated in the Agile Manifesto list: "They figure out the process that works for them and for the current problem they are working on." Here's a much better articulated criticism on Agile that I enjoyed: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/?utm_campaign=Pivot%2BProduct%2BHits&utm_medium=rss&utm_source=Pivot_Product_Hits_24 https://michaelochurch.wordpress.com/2015/06/06/why-agile-an...
- libertymcateer 10y ago
  Corporate lawyer, actually. However, before I was a lawyer I was a dev, and I try to stay current. Like any methodology, Agile has its time and its place. However, I have found that the vast majority of people who categorically write-off agile don't actually do it right - and I am not talking "no true scotsman" here. I am saying that they actually do fall into cargo-cult behavior. This aside, small groups of highly skilled and talented people can develop and ship products - sure. Maintaining them is a different thing altogether. Adding features, adding localizations, porting to new OSes - let's be serious, these require formalized practices, especially as (now very financially successful) developers move up and out onto other things. Software is a business. Businesses are alive. Like any living thing, they must continually adapt or they will die. As a result, Software itself is also a process. Unless there are some formalisms in that process, you don't have a sustainable business - you have a business that lives and dies with its core team. That is not an investment-grade business. Nor is it a long-term sustainable business. The link you sent has interesting points and valuable criticisms, to be sure - but this section: >1. Business-driven engineering. Nearly everything in it is wrong. Seriously. All businesses are business driven - and if you want your engineering teams to be purely engineering driven - go into academia. This is not to say that business goals must ignore engineering concerns - they must address them and take them seriously - this is what talented business people do. But software, like any other business, is business-driven tautologically. Even when an engineering decision is so categorically important that it becomes its own goal - it has now become a business goal. To put it another way: a purely engineering decision has results that are pari passu with regard to business impacts. When an engineering decision is no longer pari passu with regard to its business impacts - meaning that the decision will have disparate impacts on the business depending on the route that is followed - it is no longer a purely engineering decision - it is a business decision. In order to be a good business, then, you must have someone technically competent to understand the impacts making these calls. Accordingly, I strongly belief people complaint the avalid criticism -- having non-technical people calling the shots on engineering decisions that have business impacts when they do not have the ability to understand how the technical decisions have externalities and other impacts -- has been utterly conflated with criticisms of management methodology. Just because your PM is a chump doesn't mean we shouldn't have PMs. It means you should get a better PM. It is an unfortunate reality that, for whatever reason (and there are several clear ones in my mind) software - which is a technical discipline, make no mistake - has so, so many technically unqualified people in management. Compare this to any other technical business discipline - medicine, structural engineering, energy, mining - and the people at the top are typically also technically qualified. Software as an industry has to stop acting like it is privileged beyond these other technical disciplines and realize that its problem is not that "decisions must be engineering driven" it is that business people must be technically competent - which is a wholly different assertion, and one that I stand by fully. I.e. - we don't do away with the managers. We make sure the managers are competent. This is so, so different. Which, by the way, is why I am a lawyer who codes. I wouldn't hire me to be on a dev team, but I can tell you with all honesty that I can sit down with your team and understand at a non-theoretical level the engineering problems you are having and their impacts into parts of the business that are not purely engineering based. This is what allows me to be - I hope - good at my job. If you have a legal problem that relates to software - I am your guy. At least, I'd like to think so. I care about software deeply, and can tell you from experience that if you think that the lack of technical competence among PMs and scrum masters is bad - you have obviously never worked in law.
geebee 10y ago
It happens when people use the mod system to vote their position on a topic. I'm guilty of this, and I do think "agile", as a noun in quotation marks, has gone badly wrong. A lot of us have just gotten really burned. It's immensely fair of people who do stand behind agile methods to object to the mischaracterization of agile as a set of micromanagement techniques. But to a lot of us, that is now our experience with "agile." A daily "standup" where a team lead (who often doesn't write code) asks for a progress report and follows it up questions about whether this means we'll still meet our deadlines, followed perhaps by questions about what we can do to make sure we still meet them. You're welcome to say that this isn't what agile intended, that it is a corruption. I'd agree, completely. The real disagreement here will be whether "agile" methods are inherently unstable enough to invite this sort of corruption. The notion of daily standup is just so tempting for people who wish to micromanage, deny developers autonomy that can't be measured in daily increments, and apply deadline pressures. In many ways, they may be scratching their heads that the developers themselves proposed this arrangement, but ok, sure! I just finished watching a game of thrones episode, evidently the plan here is to invite an outside army in, order your own army to stand down, have the outside army to put down a rebellion, ask them to leave, then reassume power? What could possibly go wrong?
dev360 10y ago
RE: >> catastrophically false I think if you are a small, close knit team, then having great people and no process works great. If you are trying to scale developer productivity as your team grows in size, then you need more structure, so yeah - I agree 100% with your point.

joslin01 10y ago

> but throwing management methodology out the window and hoping that "good people" just somehow summon good software into being is comically naive. Maybe so, but to play devil's advocate, it's Valve's entire business model.

15charlimit 10y ago
Which caused SteamOS to be DOA and made "HL3/Episode 3 never" into an internet-wide inside joke. Not the best example you could have chosen.
- Mindstormy 10y ago
  I would say that their business goals have just changed over time, they went from being a company that spits out games, to a company that spits out money. While the end results have changed there is still underlying software that powers all of these things. Look at the in game cosmetics economy that has sprung up around dota2 and cs:go. If anything this is the definition of being Agile.
- awesomerobot 10y ago
  "Spits out money" isn't a business strategy. They've simply found distribution to be more profitable than production.
- joslin01 10y ago
  Forgive me, but I'm not making a stance. I'm just pointing out this is generally Valve's game-plan.
awesomerobot 10y ago
To further your advocacy... how many successful examples can you point to outside of Valve? How does that compare to the number of groups that are using some form of agile methodology to produce a successful product?
- joslin01 10y ago
  None. Like I said below, I'm not taking a stance. I practice "agile" at my company, but Valve's existence does refute the claim that it's comically naive. Now, if I had to offer my 2 cents why it works at Valve and not others -- games are deeply creative. You actually want your engineers to go off in their own little world and somehow capture the sparks that fly. It's nearly impossible to do this with some sprint model ("OK guys, creative thinking sprint! let's go!"). To re-iterate, the reason why it doesn't work with games is sprints are output-driven yet the creative output is not so easy to capture in this manner. Its origin is mysterious and subject to "ah ha!" moments whenever/wherever. This is why games must instead focus on process (hire the best, let them do whatever) and take a hit on strict output-driven management. Yet, the big dogs have been pushing one game out after another. For example, WoW got bought by Activision and they couldn't get new expansions out soon enough. One of the most popular MMOs, Ultima Online, was bought by EA and they immediately started their expansion line of junk and ruined the game. This wears down on the overall brand of the game. Ultimately, output-driven management of games is a sure way to lose the creativity and balance necessary to create a gem.
elthran 10y ago
To be picky, it's valve's management model, their business model is just to be a marketplace/hat vendor, allowing transactions on other people's work. I'm long past the point of viewing them as a company selling software.
- swampthinker 10y ago
  And given their poor history in putting out new games and content, I'm honestly not too impressed by Valve as of late.
- joslin01 10y ago
  Thanks, you're right.
- deleted 10y ago
  [deleted]
rubiquity 10y ago
When I worked at certain top software companies the people I worked with were often so talented and, most importantly, cared enough about the work they did that we could have produced great software with any form of process. In fact, we often started with "base Scrum" and about 6 or so months in we would have a completely modified version of Scrum. My point is, I don't think Valve is hiring average or below average people. Their process works for them because great people make any process work. Or maybe great people just make their own process, which is the most Agile-y of Agile things you can possibly do.

awesomerobot 10y ago

"You just need good people" is a solution like telling the homeless to "stop being poor"

wmeredith 10y ago

I agree, the failure to grasp the basics of english grammar around which the author has declared his/her thesis is cringeworthy.

at-fates-hands 10y ago

>>> and hoping that "good people" just somehow summon good software into being is comically naive You have no idea how true this statement is. I was on a small project about a year ago, using Agile. Both mangers and a director quit within weeks. Our team basically became self sustaining. No PM's, no managers. Our team had no oversight and no captain to steer the ship. We were left to finish the project ourselves. We had a team of 5 developers. We sat at lunch one day, bound and determined to show management we could do this without all the daily standups, agile tracking, burn down rates and stupid PM oversight. I wanted to quit inside of two weeks. 3 developers were advocating a total rewrite and a pivot to a different stack. Myself and another developer just wanted to finish the app and get it shipped. Egos, a tight timeline and several rash decisions doomed us. Instead of showing management we could do this ourselves, it became blatantly obvious this project would not get completed without a ton of oversight and guidance from an experienced project manager. It's all rainbows and unicorns when you think about it. "Just get some good developers together and they can get it done!" sounds so romantic, but in reality, it always ends up in a total shit show, as I experienced first hand. It was a tough lesson to learn that management actually do have a job to do and they understand a lot of stuff developers never have to worry about.

ktRolster 10y ago
3 developers were advocating a total rewrite and a pivot to a different stack. Those were not good developers; ie, there are some skills they were clearly lacking. I've lived through the opposite situation as you: management left the company, and we continued to release for the next few months without any management at all. The key, I think, was that the managers had pushed the decision making down. Everyone took turns being scrum master......so when the next sprint came, we elected a new scrum master and carried on. Fred Brooks pointed out that with a group of competent programmers, any development methodology can work. The best development methodologies help programmers become self-sufficient (teaching them the skills if they don't have them), instead of trying to micro-manage.
- mikejholly 10y ago
  > Those were not good developers Nailed it.

mikejholly 10y ago

Lemme guess, Scrum Master? Although those faux titles may be technically wrong, the use of capital-A Agile usually implies association with Agile the brand (the noun), not "agile as in agility". > That is so catastrophically false that I don't even know where to start. Doesn't sound like a great argument. The highest performing teams I've worked with were small groups of highly skilled, talented (IQ and EQ) and passionate people. These groups are usually familiar with various development methodologies and able to come to agreement on which processes to adopt and which are cargo-culty and should be thrown out. I don't think OP is arguing for zero process. In fact the opposite is clearly stated in the Agile Manifesto list: "They figure out the process that works for them and for the current problem they are working on." Here's a much better articulated criticism on Agile that I enjoyed: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/?utm_campaign=Pivot%2BProduct%2BHits&utm_medium=rss&utm_source=Pivot_Product_Hits_24 https://michaelochurch.wordpress.com/2015/06/06/why-agile-an...

libertymcateer 10y ago
Corporate lawyer, actually. However, before I was a lawyer I was a dev, and I try to stay current. Like any methodology, Agile has its time and its place. However, I have found that the vast majority of people who categorically write-off agile don't actually do it right - and I am not talking "no true scotsman" here. I am saying that they actually do fall into cargo-cult behavior. This aside, small groups of highly skilled and talented people can develop and ship products - sure. Maintaining them is a different thing altogether. Adding features, adding localizations, porting to new OSes - let's be serious, these require formalized practices, especially as (now very financially successful) developers move up and out onto other things. Software is a business. Businesses are alive. Like any living thing, they must continually adapt or they will die. As a result, Software itself is also a process. Unless there are some formalisms in that process, you don't have a sustainable business - you have a business that lives and dies with its core team. That is not an investment-grade business. Nor is it a long-term sustainable business. The link you sent has interesting points and valuable criticisms, to be sure - but this section: >1. Business-driven engineering. Nearly everything in it is wrong. Seriously. All businesses are business driven - and if you want your engineering teams to be purely engineering driven - go into academia. This is not to say that business goals must ignore engineering concerns - they must address them and take them seriously - this is what talented business people do. But software, like any other business, is business-driven tautologically. Even when an engineering decision is so categorically important that it becomes its own goal - it has now become a business goal. To put it another way: a purely engineering decision has results that are pari passu with regard to business impacts. When an engineering decision is no longer pari passu with regard to its business impacts - meaning that the decision will have disparate impacts on the business depending on the route that is followed - it is no longer a purely engineering decision - it is a business decision. In order to be a good business, then, you must have someone technically competent to understand the impacts making these calls. Accordingly, I strongly belief people complaint the avalid criticism -- having non-technical people calling the shots on engineering decisions that have business impacts when they do not have the ability to understand how the technical decisions have externalities and other impacts -- has been utterly conflated with criticisms of management methodology. Just because your PM is a chump doesn't mean we shouldn't have PMs. It means you should get a better PM. It is an unfortunate reality that, for whatever reason (and there are several clear ones in my mind) software - which is a technical discipline, make no mistake - has so, so many technically unqualified people in management. Compare this to any other technical business discipline - medicine, structural engineering, energy, mining - and the people at the top are typically also technically qualified. Software as an industry has to stop acting like it is privileged beyond these other technical disciplines and realize that its problem is not that "decisions must be engineering driven" it is that business people must be technically competent - which is a wholly different assertion, and one that I stand by fully. I.e. - we don't do away with the managers. We make sure the managers are competent. This is so, so different. Which, by the way, is why I am a lawyer who codes. I wouldn't hire me to be on a dev team, but I can tell you with all honesty that I can sit down with your team and understand at a non-theoretical level the engineering problems you are having and their impacts into parts of the business that are not purely engineering based. This is what allows me to be - I hope - good at my job. If you have a legal problem that relates to software - I am your guy. At least, I'd like to think so. I care about software deeply, and can tell you from experience that if you think that the lack of technical competence among PMs and scrum masters is bad - you have obviously never worked in law.

geebee 10y ago

It happens when people use the mod system to vote their position on a topic. I'm guilty of this, and I do think "agile", as a noun in quotation marks, has gone badly wrong. A lot of us have just gotten really burned. It's immensely fair of people who do stand behind agile methods to object to the mischaracterization of agile as a set of micromanagement techniques. But to a lot of us, that is now our experience with "agile." A daily "standup" where a team lead (who often doesn't write code) asks for a progress report and follows it up questions about whether this means we'll still meet our deadlines, followed perhaps by questions about what we can do to make sure we still meet them. You're welcome to say that this isn't what agile intended, that it is a corruption. I'd agree, completely. The real disagreement here will be whether "agile" methods are inherently unstable enough to invite this sort of corruption. The notion of daily standup is just so tempting for people who wish to micromanage, deny developers autonomy that can't be measured in daily increments, and apply deadline pressures. In many ways, they may be scratching their heads that the developers themselves proposed this arrangement, but ok, sure! I just finished watching a game of thrones episode, evidently the plan here is to invite an outside army in, order your own army to stand down, have the outside army to put down a rebellion, ask them to leave, then reassume power? What could possibly go wrong?

dev360 10y ago

RE: >> catastrophically false I think if you are a small, close knit team, then having great people and no process works great. If you are trying to scale developer productivity as your team grows in size, then you need more structure, so yeah - I agree 100% with your point.