9 ms·

Agile Is Dead: The Angry Developer Version

125 points by rubiquity 13y ago

pnathan 13y ago
I've seen this cycle a few times. Let me handwave how it goes: * Agile Critisism: The snake oil is all over and getting worse! * Agilista: It's not done properly! * Agile Criticism: No True Scotsman! I think the NTS is where things usually leave the line and end up in a lot of splutters and anecdotes. Sometimes I wonder if the great flamewars and their arguments should be canonized into standard textfiles and passed around. Much like the old story of joking by only using numbers. :-)
- 0xdeadbeefbabe 13y ago
  1
- rubiquity 13y ago
  It doesn't have to be that way. Agile has a ton of advocacy, it just needs the right advocates that really understand it to help guide teams in the right direction. Agile has been entirely too driven by salesmen the last few years.
  - dragonwriter 13y ago
    The Agile Manifesto is a great starting point, but beyond that I think Agile is too poorly defined; I think the values of the Agile Manifesto are best made concrete in terms of a high level meta-methodological framework in Lean methodologies with (under various names) the PDCA cycle wherein teams have ownership of their own specific processes, strictly follow the processes they define, have clear success metrics, propose process changes from within the team when there is an observed problem with the existing process in meeting desired results, and do empirical tests of the proposed changes using the success metrics. Outside of this kind of concrete instantiation, "Agile" seems to diverge into, on the one side, a combination of empty buzzwords and arbitrary churn where no one knows who is responsible for what or what standards are because there is no process, or externally-defined prescriptive processes of exactly the sort that the Agile Manifesto was a reaction against. People over processes has to mean processes are tools that serve the people on the team, not "no process" or "process taken as received wisdom because of respect for the person or institution originating it".
- area51org 13y ago
  In this guy's defense, there is a lot of Fake Agile out there. People (business people, project managers, mostly) seem to think that Agile means using a new set of buzzwords. Standups? They're daily status reports to management, right?
  - untog 13y ago
    Standups? They're daily status reports to management, right? More importantly, they're daily status reports to each others, internally to your team.
    - Glide 13y ago
      Right. So one of the main smells of an ineffective methodology is going through the same motions but not realizing the intent of each action. Some examples: standups becoming daily status reports, the customer demo becoming it's own production, and let's not get started on retrospectives.
  - steve-howard 13y ago
    It was in my organization that I first heard the word "Scrummerfall." People learn the tools (stand-up meetings! Stories! Sprints!) but not everyone bothers to grok the purpose (I haven't seen "good agile" yet so neither have I). Agile certainly isn't unique in this regard. I've seen an MVC project with only one action on only one controller which had a ton of parameters to control its behavior. There's a balance between "I need to thoroughly understand how to use this concept idiomatically" and "I don't have time to read up on another buzzword."
- mildtrepidation 13y ago
  This seems illogically dismissive, unless you're criticizing the lack of actual discourse instead of the critics as a group, which I'm not really clear on. It comes off as "The Other Side has nothing to go on but insults and logical fallacies."
  - mcguire 13y ago
    Um, which "side" of that conversation do you think is being dismissive?
  - pnathan 13y ago
    If someone wants to intelligently go after the Agilist community or intelligently defend it, they are my guest. But frankly, both sides throw anecdata, insults, fallacies, and feelgoodisms out there by the truckload. Further remark: I figured I'd just bypass the otherwise-upcoming NTS yell and just clear the air so we could all go for the random anecdata and general arguments about Waterfall! Bad Agile! Scrum Masters! and how they caused problems.
greatsuccess 13y ago
Agile is the Waterfall-aholics meeting of software engineers. I personally could give a shit about chanting mantras that say this -over- that and I think anyone who spews them in a blog post or otherwise is a nutjob. I dont "believe" in any of this crap. I have work to do.
edabobojr 13y ago
Agile is something that others call you, not something you call yourself.
timbuktwelve 13y ago
When I get constant messages from recruiters regurgitating phrases like "We're a bleeding edge Agile shop with Angel investor funds looking to disrupt the marketplace," I want to kill myself a little bit. I get so sick of all the buzz words and hype in our industry. Goes with the territory I suppose.
Killah911 13y ago
the notion that developers somehow intuitively know agile and management is ruining it is straight up BS. I know plenty of developers who jump on bandwagon x and then without any understanding proceed to screw the pooch for all of us. The drive to look smart is so important to some(maybe most) people that they'll gladly throw the whole team under the bus so they don't have to appear to not know. Believe it or not, I've seen waterfall work, I've seen waterfall fail. I've seen agile work and unfortunately I've seen agile fail more often as people who don't understand what they're supposed to do create a clusterfuck of a process that just gets in the way. there was an article on HN not too long ago by an old school developer about development methodologies and how he didn't really think it made a difference. What he saw made a difference was how well the team communicated. People over processes, the very discussion of "Agile" ad nauseam violates that very rule. For crying out loud the process will not save you! try to find a process that will not get in people's way while allowing people to communicate effectively. I'm sure that some social scientist might have a better idea on how to solve it than another random developer who thinks he's God's gift to mankind.
- kabdib 13y ago
  > the notion that developers somehow intuitively know agile and management is ruining it is straight up BS Not in my experience. If there are a bunch of PMs and managers, you're going to find that they keep right on doing management and PM stuff, no matter what Agile Manifesto they think they latched onto. Management: "This project is going to take you 13 sprints." Right away, you're in trouble. Management: "What's with your burn-down rate? We're four days into this sprint and we don't see any progress." What replaces management is micromanagement. Manager in the middle of the daily scrum: "Okay, let's go around and get status from everyone." Yup. Status. For management. Management: "You need to drop what you're doing and work on feature X for next week." "But we're in the middle of the sprint." "Oh, that." To make it really work, you have to start nuking job positions. And at a big company that is hard.
  - michaelochurch 13y ago
    To make it really work, you have to start nuking job positions. And at a big company that is hard. Bingo. You know the MacLeod Pyramid (Losers, Clueless, and Sociopaths)? Most of "Agile" methodology is Revenge of the Clueless. It's a great way to replace a company with one long meeting that never ends.
jarrett 13y ago
In the trenches, methodologies don't get projects done. Dave Thomas's original description of agility seems an accurate description of how code actually gets made--and that description is deliberately not a description of a methodology. I ship working code every day, and my clients are happy, despite the fact that I'm not following any definable methodology. Coding is a messy process. Codebases evolve in many ways: They advance by leaps and bounds, they stagnate, they regress, they sputter along, they bloat--often all at the same time. Sometimes you write tests first, sometimes you code first. Sometimes you whiteboard first, sometimes you write up a detailed spec. How do you know what strategy to adopt at any given moment? You can try to formalize it all you want, but in reality, the choice is usually made on intuition. That last point--the key role of intuition--is one of the biggest reasons you can't package up effective coding as a book, a manifesto, or a training session. Which implies something managers may find distressing: There is no silver bullet; a coding team's only salvation is smart coders.
- lmm 13y ago
  What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that. 80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done.
  - jarrett 13y ago
    > What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that. Good question. If you mean: "Why do you choose to ship code?" then I suppose it's my desire to please my clients and stay employed. If you mean: "How do you manage it?" then it's what I hinted at earlier: Good intuition, experience, a precise and logical mind, and thoughtful use of tools. About tools: My tools are important to me, but I don't see them as a silver bullet. It's like if you asked a carpenter about a "hammer-centric methodology." She would laugh. She'd say yeah, she uses a hammer all the time, but her hammer use doesn't amount to a methodology or a philosophy. Hammer use just comes about naturally as a consequence of recognizing nails that must be driven in. Similarly for software: I don't use to-do lists because they're "agile." I use them because I need to remember the 20 different requests my client made yesterday. Could I live without Asana, Basecamp, or what have you? Sure. I'd just write my tasks in a text file. What if I couldn't use a text file? Then I'd put sticky notes on my wall. I need tools (everyone does), but I don't deify them. > 80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done. I agree with all of the above except for the statement that "methodologies do, in fact, get projects done." I think the reason we disagree is that we mean different things by "methodology." I take "methodology" to mean a formalized process, like a recipe, that you can follow mechanically. By that definition, agility is the explicit rejection of methodologies. But then, I'm not the god of word definitions. I don't get to say my definition of "methodology" is right and yours is wrong. So perhaps it's fair to say that we're each right insofar as we're permitted our respective definitions of "methodology."
erazor42 13y ago
Yea it's sad Agile method is now a marketing word, a marketing trend. Same goes for Big Data, any marketing guy with a 100k row DB think they are doing big Data, sell it as big data...
korzun 13y ago
Heh, from my experience if the company has 'Certified Scrum Masters' they will try to apply everything they learned (while pinning their certificate to the wall for everybody to see) into development process. They are usually so clueless that the concept of thinking outside the box and adjusting what they 'learned' from book/seminar is unknown to them. So if company you want to work for has a 'SCRUM MASTER', do your self a favor and run.
lgleason 13y ago
Purr Programming is much more fulfilling :) http://purrprogramming.com/?page_id=2 http://purrprogramming.com/?page_id=2
jbondeson 13y ago
Repeat after me: "Scrum is Agile, but Agile is not Scrum" The Agile Manifesto is a simple set of 4 values and 12 principles to aid in building software, that's it. The different signers of the manifesto had different visions of implementing it, Schwaber's was Scrum, Beck's was XP. Saying that a particular methodology isn't a silver bullet therefore it's Agile's fault is a bit like saying science is dead when we disprove a theory.
- MartinCron 13y ago
  I don't even agree that Scrum is agile. It's a one-size-fits-all prescriptive methodology with rigidly defined schedules, rituals, and roles. If I had the memory erasing device from the Men In Black movies, I would use it on people who advocate for by-the-book scrum.
  - paulhauggis 13y ago
    I'm contracting for a small company that uses by-the-book scrum. I like the idea of it and it allows us to easily see what needs to be done. But, I feel like the boss is more interested in the methodology than actually finishing our project, which is frustrating. He came from big corporate, went to all the seminars on scrum, and things it's the answer to everything.
    - MartinCron 13y ago
      It's probably just a phase, he'll outgrow it :)
  - gutnor 13y ago
    Scrum is agile. You are not supposed to implement everything that's in it - even better, you are supposed to pick one stuff at a time if you face the specific problem the new stuff is supposed to solve. Adding/Removing stuff is the whole purpose of the retrospective, the last feedback loop of scrum, feedback on the process itself. That should be the first thing you add and the last thing you remove. "By-the-book" scrum is like applying all the GoF Patterns in your project. But yeah, I'm nitpicking, I know what you mean: I see around me plenty of positions for "Scrum master, good at removing impediments, x years line management experience, expert with Microsoft Project, no development experience necessary ..." and I'm thinking WTF ...
geebee 13y ago
Zed Shaw had a very entertaining semi-satirical bit on this, involving a pulp-fiction cultural reference.
- chris_mahan 13y ago
  that would be programming-motherfucker.com (don't forget the hyphen or you'll get NSFW)
mavdi 13y ago
Well said. Agile isn't your collection of software toys, and yeah, fuck your long term self-assuring development plans too.
agotterer 13y ago
I've been saying the same thing for quite some time. What I have no found the answer for is how to respond to managers that claim the "agile" process exists to measure developer productivity and accountability. Thoughts?
- gutnor 13y ago
  "Measure developer productivity and accountability" is already looking at the problem the wrong way. A bit like saying a GPS exists to measure car speed and facilitate insurance paperwork. Agile is about a team and how to make it deliver a product as fast as possible. (that wording can be misinterpreted, but that is for HN audience not PHB) The key tenet of agile is that people just can't estimate - so sure fine, use magic PM formula - experience, whatever, anything to have a budget approved, but as soon as the real work start, don't bother your developers with it, just get it done ASAP. Agile can help you to estimate better on the long run but not really because of agile directly, but because agile facilitates creating a consistent more uniform development team. As for developer productivity, at best it will because more apparent who is slacking in a agile team, but if management listen to metric rather than their team lead or the developer themselves all they are measuring is people successful at producing the right metric. Accountability, that's a corporate issue. When accountability is an issue in a company, it means that somewhere along the line it lost the ability to stay focused on the end product. Your teams are not working together toward the same goal so you need to find "people to blame". Not quite sure how that is related to agile, you do not make people working together by having them stand up everyday 15 minutes with others or fill a whiteboard with stickers. The problem is that following a methodology like SCRUM, it is possible to produce a shit-ton of metrics, and that's what make managers wet. Those metrics are useful feedback for the team, but if you use it for anything else, you have just recreated the old 90's LOC stupid productivity metrics with fancy looking new terminology.
FollowSteph3 13y ago
For me agile is a way of making bringing what's wrong with your development painful and front and center, forcing you to address it. As such many people don't like this and as a result agile tends to get warped into whatever process it is they had before, but now it's just called agile. And this is why almost everyone can say they are agile, even thogh they aren't.
vyala 13y ago
When you see Waterfall, Agile as a process, yes they are dead in the software industries. If you see them as a practice, it vary team to team, project to project, time to time. Agile is NOT dead. It was not there at all.
jggkffkfjfjfjfj 13y ago
the problem was the ruby crows who took the pragmatic art of agile, amd mandated a wanky set of slow bloated tools and dogmatic agile. They killed it.
exelius 13y ago
All this Agile purism is great. I'm glad we're having the discussion, because that's how we can breed some understanding. The only problem with "pure" Agile is that it doesn't scale past 10 or so developers. If you're developing a sufficiently complex product, you need process. You need specs that can be distributed to other teams so they can build around the planned changes your team is making to its module. This can be done in a pseudo-Agile way and coupled with a continuous integration process, which is what most companies call "Agile". Releases get cut every few sprints, so the product guys are happy. Developers hate it because all process that interferes with coding is bad, but it's still better than a traditional 6 month waterfall cycle. It's not really Agile if you're being a purist, but it's a good compromise that keeps the business happy with the visibility they get while still releasing code on a relatively short cycle. There will always be process in any sufficiently large organization, since we all have different opinions on how to do things but we need to be on the same page.
michaelochurch 13y ago
I don't care to compare XP vs. Scrum vs. Kanban vs. Lean. That's just an array of banners for MacLeod Clueless, a way for them to form initiatives and conflicts that don't really matter. The top-down closed-allocation organization cannot hit technical high notes. At that, it is unfixable. The best solution (see: large companies) is to let your best people work in an effectively open-allocation setting (while the peons toil under closed allocation) but, as has been discussed in other threads, that becomes politically difficult. Rather than trying to fix closed allocation, which we can't, we should be throwing it out. It might work for a hedge fund that can afford to pay $5 million per year to a mediocre trader. It doesn't work for tech. Never did, never will.
Communitivity 13y ago
I think it is important to note that the Agile manifesto does not say we don't need the things on the right. Instead it says value the things on the left over the things on the right. For example it doesn't say you only need people, no process - that would be ridiculous. What it does say is that people are more important than process. In other words, make your processes fit your people not your people fit your process. Processes and tools are a good thing...if you use them as aids rather than straightjackets. As a final thought, consider the quote 'Justice, tempered by Mercy'. I hope that we can all agree that all justice, no mercy would be very bad. I hope we can all also agree all mercy, no justice would be very bad. We need both, one tempered by the other, just as we need both sides of the Agile manifesto list -- as long as we value the items on the left more.
AnimalMuppet 13y ago
Agile's great. But somewhere up the chain of command, it runs into somebody who views the world through 17-page PERT charts. At that point, there's an impedance mismatch. The "agile" tools help the boss feel better, even if they're a complete misunderstanding of agile. (This is not a trivial problem, by the way. A boss several layers up who doesn't get the expected reports can decide that your project is floundering, no matter how well things are going in reality.) But you can hit an impedance mismatch before that. You can hit it within your team, if you have developers who think in terms of following procedures instead of in terms of working code that creates value for the user.
makabee 13y ago
In my opinion the problem with Agile is that developers are focusing too much on the process and not enough on the product: http://effectivesoftwaredesign.com/2014/01/20/attention-agile-programmers-project-management-is-not-software-engineering/ http://effectivesoftwaredesign.com/2014/01/20/attention-agil...
nathansadia 13y ago
I agree with everything you say. Good simple idea become a source of money with all the classes and certification that just kill the idea.
PeterMerel 13y ago
The choice of syllables is irrelevant. The choice of values is what matters. As Dave says, there are a whole bunch of people selling heavy tools and frameworks and calling them "Agile" where they are anything but. Safety, to pick the obvious example, is not an Agile value, and numerous commentators have called SAFe nothing but RUP in Agile clothing. Declaring Agile dead seems a bit naff, but obviously the manifesto lacks values and principles to address Dave and Richard's concerns. So I've kicked off an initiative to do exactly that. Agile: The Next Generation or A:TNG for short, augments but does not replace the Manifesto values with four new ones specific to Agile at scale. It offers pattern languages (not frameworks or methodologies) based on Kurosawa's The Seven Samurai" and the thousand year Iroquois Confederacy. Most importantly it rebases the whole Agile Alliance shtick on github, where it can be properly open and we can properly self-organise and evolve it without some clique of middle aged white guys dictating to the community at conferences. Details and some starter patterns are up at http://agiletng.org http://agiletng.org . So, yes, Agile is dead. And long live Agile! -- Peter Merel.

125 points by rubiquity 13y ago

I've seen this cycle a few times. Let me handwave how it goes: * Agile Critisism: The snake oil is all over and getting worse! * Agilista: It's not done properly! * Agile Criticism: No True Scotsman! I think the NTS is where things usually leave the line and end up in a lot of splutters and anecdotes. Sometimes I wonder if the great flamewars and their arguments should be canonized into standard textfiles and passed around. Much like the old story of joking by only using numbers. :-)

0xdeadbeefbabe 13y ago
1
rubiquity 13y ago
It doesn't have to be that way. Agile has a ton of advocacy, it just needs the right advocates that really understand it to help guide teams in the right direction. Agile has been entirely too driven by salesmen the last few years.
- dragonwriter 13y ago
  The Agile Manifesto is a great starting point, but beyond that I think Agile is too poorly defined; I think the values of the Agile Manifesto are best made concrete in terms of a high level meta-methodological framework in Lean methodologies with (under various names) the PDCA cycle wherein teams have ownership of their own specific processes, strictly follow the processes they define, have clear success metrics, propose process changes from within the team when there is an observed problem with the existing process in meeting desired results, and do empirical tests of the proposed changes using the success metrics. Outside of this kind of concrete instantiation, "Agile" seems to diverge into, on the one side, a combination of empty buzzwords and arbitrary churn where no one knows who is responsible for what or what standards are because there is no process, or externally-defined prescriptive processes of exactly the sort that the Agile Manifesto was a reaction against. People over processes has to mean processes are tools that serve the people on the team, not "no process" or "process taken as received wisdom because of respect for the person or institution originating it".
area51org 13y ago
In this guy's defense, there is a lot of Fake Agile out there. People (business people, project managers, mostly) seem to think that Agile means using a new set of buzzwords. Standups? They're daily status reports to management, right?
- untog 13y ago
  Standups? They're daily status reports to management, right? More importantly, they're daily status reports to each others, internally to your team.
  - Glide 13y ago
    Right. So one of the main smells of an ineffective methodology is going through the same motions but not realizing the intent of each action. Some examples: standups becoming daily status reports, the customer demo becoming it's own production, and let's not get started on retrospectives.
- steve-howard 13y ago
  It was in my organization that I first heard the word "Scrummerfall." People learn the tools (stand-up meetings! Stories! Sprints!) but not everyone bothers to grok the purpose (I haven't seen "good agile" yet so neither have I). Agile certainly isn't unique in this regard. I've seen an MVC project with only one action on only one controller which had a ton of parameters to control its behavior. There's a balance between "I need to thoroughly understand how to use this concept idiomatically" and "I don't have time to read up on another buzzword."
mildtrepidation 13y ago
This seems illogically dismissive, unless you're criticizing the lack of actual discourse instead of the critics as a group, which I'm not really clear on. It comes off as "The Other Side has nothing to go on but insults and logical fallacies."
- mcguire 13y ago
  Um, which "side" of that conversation do you think is being dismissive?
- pnathan 13y ago
  If someone wants to intelligently go after the Agilist community or intelligently defend it, they are my guest. But frankly, both sides throw anecdata, insults, fallacies, and feelgoodisms out there by the truckload. Further remark: I figured I'd just bypass the otherwise-upcoming NTS yell and just clear the air so we could all go for the random anecdata and general arguments about Waterfall! Bad Agile! Scrum Masters! and how they caused problems.

greatsuccess 13y ago

Agile is the Waterfall-aholics meeting of software engineers. I personally could give a shit about chanting mantras that say this -over- that and I think anyone who spews them in a blog post or otherwise is a nutjob. I dont "believe" in any of this crap. I have work to do.

edabobojr 13y ago

Agile is something that others call you, not something you call yourself.

timbuktwelve 13y ago

When I get constant messages from recruiters regurgitating phrases like "We're a bleeding edge Agile shop with Angel investor funds looking to disrupt the marketplace," I want to kill myself a little bit. I get so sick of all the buzz words and hype in our industry. Goes with the territory I suppose.

Killah911 13y ago

the notion that developers somehow intuitively know agile and management is ruining it is straight up BS. I know plenty of developers who jump on bandwagon x and then without any understanding proceed to screw the pooch for all of us. The drive to look smart is so important to some(maybe most) people that they'll gladly throw the whole team under the bus so they don't have to appear to not know. Believe it or not, I've seen waterfall work, I've seen waterfall fail. I've seen agile work and unfortunately I've seen agile fail more often as people who don't understand what they're supposed to do create a clusterfuck of a process that just gets in the way. there was an article on HN not too long ago by an old school developer about development methodologies and how he didn't really think it made a difference. What he saw made a difference was how well the team communicated. People over processes, the very discussion of "Agile" ad nauseam violates that very rule. For crying out loud the process will not save you! try to find a process that will not get in people's way while allowing people to communicate effectively. I'm sure that some social scientist might have a better idea on how to solve it than another random developer who thinks he's God's gift to mankind.

kabdib 13y ago
> the notion that developers somehow intuitively know agile and management is ruining it is straight up BS Not in my experience. If there are a bunch of PMs and managers, you're going to find that they keep right on doing management and PM stuff, no matter what Agile Manifesto they think they latched onto. Management: "This project is going to take you 13 sprints." Right away, you're in trouble. Management: "What's with your burn-down rate? We're four days into this sprint and we don't see any progress." What replaces management is micromanagement. Manager in the middle of the daily scrum: "Okay, let's go around and get status from everyone." Yup. Status. For management. Management: "You need to drop what you're doing and work on feature X for next week." "But we're in the middle of the sprint." "Oh, that." To make it really work, you have to start nuking job positions. And at a big company that is hard.
- michaelochurch 13y ago
  To make it really work, you have to start nuking job positions. And at a big company that is hard. Bingo. You know the MacLeod Pyramid (Losers, Clueless, and Sociopaths)? Most of "Agile" methodology is Revenge of the Clueless. It's a great way to replace a company with one long meeting that never ends.

jarrett 13y ago

In the trenches, methodologies don't get projects done. Dave Thomas's original description of agility seems an accurate description of how code actually gets made--and that description is deliberately not a description of a methodology. I ship working code every day, and my clients are happy, despite the fact that I'm not following any definable methodology. Coding is a messy process. Codebases evolve in many ways: They advance by leaps and bounds, they stagnate, they regress, they sputter along, they bloat--often all at the same time. Sometimes you write tests first, sometimes you code first. Sometimes you whiteboard first, sometimes you write up a detailed spec. How do you know what strategy to adopt at any given moment? You can try to formalize it all you want, but in reality, the choice is usually made on intuition. That last point--the key role of intuition--is one of the biggest reasons you can't package up effective coding as a book, a manifesto, or a training session. Which implies something managers may find distressing: There is no silver bullet; a coding team's only salvation is smart coders.

lmm 13y ago
What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that. 80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done.
- jarrett 13y ago
  > What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that. Good question. If you mean: "Why do you choose to ship code?" then I suppose it's my desire to please my clients and stay employed. If you mean: "How do you manage it?" then it's what I hinted at earlier: Good intuition, experience, a precise and logical mind, and thoughtful use of tools. About tools: My tools are important to me, but I don't see them as a silver bullet. It's like if you asked a carpenter about a "hammer-centric methodology." She would laugh. She'd say yeah, she uses a hammer all the time, but her hammer use doesn't amount to a methodology or a philosophy. Hammer use just comes about naturally as a consequence of recognizing nails that must be driven in. Similarly for software: I don't use to-do lists because they're "agile." I use them because I need to remember the 20 different requests my client made yesterday. Could I live without Asana, Basecamp, or what have you? Sure. I'd just write my tasks in a text file. What if I couldn't use a text file? Then I'd put sticky notes on my wall. I need tools (everyone does), but I don't deify them. > 80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done. I agree with all of the above except for the statement that "methodologies do, in fact, get projects done." I think the reason we disagree is that we mean different things by "methodology." I take "methodology" to mean a formalized process, like a recipe, that you can follow mechanically. By that definition, agility is the explicit rejection of methodologies. But then, I'm not the god of word definitions. I don't get to say my definition of "methodology" is right and yours is wrong. So perhaps it's fair to say that we're each right insofar as we're permitted our respective definitions of "methodology."

erazor42 13y ago

Yea it's sad Agile method is now a marketing word, a marketing trend. Same goes for Big Data, any marketing guy with a 100k row DB think they are doing big Data, sell it as big data...

korzun 13y ago

Heh, from my experience if the company has 'Certified Scrum Masters' they will try to apply everything they learned (while pinning their certificate to the wall for everybody to see) into development process. They are usually so clueless that the concept of thinking outside the box and adjusting what they 'learned' from book/seminar is unknown to them. So if company you want to work for has a 'SCRUM MASTER', do your self a favor and run.

lgleason 13y ago

Purr Programming is much more fulfilling :) http://purrprogramming.com/?page_id=2 http://purrprogramming.com/?page_id=2

jbondeson 13y ago

Repeat after me: "Scrum is Agile, but Agile is not Scrum" The Agile Manifesto is a simple set of 4 values and 12 principles to aid in building software, that's it. The different signers of the manifesto had different visions of implementing it, Schwaber's was Scrum, Beck's was XP. Saying that a particular methodology isn't a silver bullet therefore it's Agile's fault is a bit like saying science is dead when we disprove a theory.

MartinCron 13y ago
I don't even agree that Scrum is agile. It's a one-size-fits-all prescriptive methodology with rigidly defined schedules, rituals, and roles. If I had the memory erasing device from the Men In Black movies, I would use it on people who advocate for by-the-book scrum.
- paulhauggis 13y ago
  I'm contracting for a small company that uses by-the-book scrum. I like the idea of it and it allows us to easily see what needs to be done. But, I feel like the boss is more interested in the methodology than actually finishing our project, which is frustrating. He came from big corporate, went to all the seminars on scrum, and things it's the answer to everything.
  - MartinCron 13y ago
    It's probably just a phase, he'll outgrow it :)
- gutnor 13y ago
  Scrum is agile. You are not supposed to implement everything that's in it - even better, you are supposed to pick one stuff at a time if you face the specific problem the new stuff is supposed to solve. Adding/Removing stuff is the whole purpose of the retrospective, the last feedback loop of scrum, feedback on the process itself. That should be the first thing you add and the last thing you remove. "By-the-book" scrum is like applying all the GoF Patterns in your project. But yeah, I'm nitpicking, I know what you mean: I see around me plenty of positions for "Scrum master, good at removing impediments, x years line management experience, expert with Microsoft Project, no development experience necessary ..." and I'm thinking WTF ...

geebee 13y ago

Zed Shaw had a very entertaining semi-satirical bit on this, involving a pulp-fiction cultural reference.

chris_mahan 13y ago
that would be programming-motherfucker.com (don't forget the hyphen or you'll get NSFW)

mavdi 13y ago

Well said. Agile isn't your collection of software toys, and yeah, fuck your long term self-assuring development plans too.

agotterer 13y ago

I've been saying the same thing for quite some time. What I have no found the answer for is how to respond to managers that claim the "agile" process exists to measure developer productivity and accountability. Thoughts?

gutnor 13y ago
"Measure developer productivity and accountability" is already looking at the problem the wrong way. A bit like saying a GPS exists to measure car speed and facilitate insurance paperwork. Agile is about a team and how to make it deliver a product as fast as possible. (that wording can be misinterpreted, but that is for HN audience not PHB) The key tenet of agile is that people just can't estimate - so sure fine, use magic PM formula - experience, whatever, anything to have a budget approved, but as soon as the real work start, don't bother your developers with it, just get it done ASAP. Agile can help you to estimate better on the long run but not really because of agile directly, but because agile facilitates creating a consistent more uniform development team. As for developer productivity, at best it will because more apparent who is slacking in a agile team, but if management listen to metric rather than their team lead or the developer themselves all they are measuring is people successful at producing the right metric. Accountability, that's a corporate issue. When accountability is an issue in a company, it means that somewhere along the line it lost the ability to stay focused on the end product. Your teams are not working together toward the same goal so you need to find "people to blame". Not quite sure how that is related to agile, you do not make people working together by having them stand up everyday 15 minutes with others or fill a whiteboard with stickers. The problem is that following a methodology like SCRUM, it is possible to produce a shit-ton of metrics, and that's what make managers wet. Those metrics are useful feedback for the team, but if you use it for anything else, you have just recreated the old 90's LOC stupid productivity metrics with fancy looking new terminology.

FollowSteph3 13y ago

For me agile is a way of making bringing what's wrong with your development painful and front and center, forcing you to address it. As such many people don't like this and as a result agile tends to get warped into whatever process it is they had before, but now it's just called agile. And this is why almost everyone can say they are agile, even thogh they aren't.

vyala 13y ago

When you see Waterfall, Agile as a process, yes they are dead in the software industries. If you see them as a practice, it vary team to team, project to project, time to time. Agile is NOT dead. It was not there at all.

jggkffkfjfjfjfj 13y ago

the problem was the ruby crows who took the pragmatic art of agile, amd mandated a wanky set of slow bloated tools and dogmatic agile. They killed it.

exelius 13y ago

All this Agile purism is great. I'm glad we're having the discussion, because that's how we can breed some understanding. The only problem with "pure" Agile is that it doesn't scale past 10 or so developers. If you're developing a sufficiently complex product, you need process. You need specs that can be distributed to other teams so they can build around the planned changes your team is making to its module. This can be done in a pseudo-Agile way and coupled with a continuous integration process, which is what most companies call "Agile". Releases get cut every few sprints, so the product guys are happy. Developers hate it because all process that interferes with coding is bad, but it's still better than a traditional 6 month waterfall cycle. It's not really Agile if you're being a purist, but it's a good compromise that keeps the business happy with the visibility they get while still releasing code on a relatively short cycle. There will always be process in any sufficiently large organization, since we all have different opinions on how to do things but we need to be on the same page.

michaelochurch 13y ago

I don't care to compare XP vs. Scrum vs. Kanban vs. Lean. That's just an array of banners for MacLeod Clueless, a way for them to form initiatives and conflicts that don't really matter. The top-down closed-allocation organization cannot hit technical high notes. At that, it is unfixable. The best solution (see: large companies) is to let your best people work in an effectively open-allocation setting (while the peons toil under closed allocation) but, as has been discussed in other threads, that becomes politically difficult. Rather than trying to fix closed allocation, which we can't, we should be throwing it out. It might work for a hedge fund that can afford to pay $5 million per year to a mediocre trader. It doesn't work for tech. Never did, never will.

Communitivity 13y ago

I think it is important to note that the Agile manifesto does not say we don't need the things on the right. Instead it says value the things on the left over the things on the right. For example it doesn't say you only need people, no process - that would be ridiculous. What it does say is that people are more important than process. In other words, make your processes fit your people not your people fit your process. Processes and tools are a good thing...if you use them as aids rather than straightjackets. As a final thought, consider the quote 'Justice, tempered by Mercy'. I hope that we can all agree that all justice, no mercy would be very bad. I hope we can all also agree all mercy, no justice would be very bad. We need both, one tempered by the other, just as we need both sides of the Agile manifesto list -- as long as we value the items on the left more.

AnimalMuppet 13y ago

Agile's great. But somewhere up the chain of command, it runs into somebody who views the world through 17-page PERT charts. At that point, there's an impedance mismatch. The "agile" tools help the boss feel better, even if they're a complete misunderstanding of agile. (This is not a trivial problem, by the way. A boss several layers up who doesn't get the expected reports can decide that your project is floundering, no matter how well things are going in reality.) But you can hit an impedance mismatch before that. You can hit it within your team, if you have developers who think in terms of following procedures instead of in terms of working code that creates value for the user.

makabee 13y ago

In my opinion the problem with Agile is that developers are focusing too much on the process and not enough on the product: http://effectivesoftwaredesign.com/2014/01/20/attention-agile-programmers-project-management-is-not-software-engineering/ http://effectivesoftwaredesign.com/2014/01/20/attention-agil...

nathansadia 13y ago

I agree with everything you say. Good simple idea become a source of money with all the classes and certification that just kill the idea.

PeterMerel 13y ago

The choice of syllables is irrelevant. The choice of values is what matters. As Dave says, there are a whole bunch of people selling heavy tools and frameworks and calling them "Agile" where they are anything but. Safety, to pick the obvious example, is not an Agile value, and numerous commentators have called SAFe nothing but RUP in Agile clothing. Declaring Agile dead seems a bit naff, but obviously the manifesto lacks values and principles to address Dave and Richard's concerns. So I've kicked off an initiative to do exactly that. Agile: The Next Generation or A:TNG for short, augments but does not replace the Manifesto values with four new ones specific to Agile at scale. It offers pattern languages (not frameworks or methodologies) based on Kurosawa's The Seven Samurai" and the thousand year Iroquois Confederacy. Most importantly it rebases the whole Agile Alliance shtick on github, where it can be properly open and we can properly self-organise and evolve it without some clique of middle aged white guys dictating to the community at conferences. Details and some starter patterns are up at http://agiletng.org http://agiletng.org . So, yes, Agile is dead. And long live Agile! -- Peter Merel.