6 ms·

In a nutshell, why do a lot of developers dislike Agile?

PaulHoule 9y ago
I think those conflicts exist in all so-called "teams", but in Agile those conflicts become sublimated by a grumbling about "process" on a sprintly, if not daily, basis. If your plan, on the other hand, is to have three people develop three separate parts for a year, and then think you are going to stick them together and release in two weeks, people can avoid interpersonal conflicts entirely for a year, after which there is a crisis, which is often survivable by the participants because there are already so many chips in the pot...
- convolvatron 9y ago
  there is a pretty vast middle ground between 'talking every day for a year, and never making any plans' and 'make a plan for a year, don't meet in the interim and try to integrate then' make plans. try to gauge costs. change plans when necessary. integrate as soon as is reasonable. use consensus to drive structure/interfaces. maintain a testable artifact. maybe running a service is different, but variants on the above seem to be the only thing that works for software.
bsg75 9y ago
> People desire a structure that allows them to abdicate responsibility. s/People/Managers/ In many of the cases I have experienced, agile breaks down into an excuse to not plan ("Requirements just slow things down!"), and the elements of it that would drive success are ignored. So often business leaders just want shit done, and when the technical types warn about reliability or technical debt, there is a lot handwaving. Thus short attention spans see agile as a way to justify shortcuts. When this happens the result can be worse than a poorly executed waterfall model. Agile works when all the proper elements are used, just like any other endeavor, and it fails for the same contrary reasons. Developers become frustrated when yet another path to accomplishment is blocked. Disclaimer - Am technical manager. Have watched business peers shortcut to failure. Have fought the battles and lost. Frustration apparent.
- ZenoArrow 9y ago
  > "So often business leaders just want shit done, and when the technical types warn about reliability or technical debt, there is a lot handwaving. Thus short attention spans see agile as a way to justify shortcuts." This is the crux of the problem with agile. The reason it's embraced so readily by business types is the reason that it fails. With the 'justifying shortcuts' description you hit the nail on the head.
- oceanghost 9y ago
  This exactly. Agile allows managers to push all responsibility onto the developers (design, testing, deployment, ops, customer service, spec writing, documentation, training, etc), while simultaneously enabling them to demand milestones every two weeks. I have seen this taken to the extreme-- the management at one company I worked for would not specify ANYTHING in writing. Nothing. Not even bullet points on what a feature would do. They would then micro manage intensely (I had a non-technical VP doing code reviews on a Senior Architect). Estimates, however, only included development time, never any other tasks, and were always challenged. Deadlines were always hard. In short, we had all the responsibility of Agile but none of the empowerment. Engineering was to blame for everything. If you think this was some small crazy startup... This companies revenues are about 500m a year. Almost every American has our products in their homes.
throwme_1980 9y ago
Truth is you need to get st done, I see a lot of mediocre developers hiding behind agile processes, when they can't figure out something they throw their hands in the air and scream "bad requirements" , boohoo man-up and do the business.
thisisit 9y ago
This like essentially justifying - "Why do X dislike Y?" questions by the person who loves Y. It is not surprising that there has to be set of process or steps when doing anything, and I mean anything. The problem arises when Y is suited for type A projects but just because the Manager has read about Y in some magazine he thinks "one size fits all". The problem can be seen from the blog itself. The Toyota Way and contextual changes. In software sometime defining the context itself becomes impossible. It certainly is more difficult in a company which has no other defined processes but wants to implement Agile.
trentnix 9y ago
Because few organizations actually enable real Agile development. I did some "Agile coaching" in a previous life and time and time again I'd see teams embrace the cosmetic parts of Agile - daily standups, iterations, retrospectives - but workflow was still much the same as it always was. Agile, done right, is more about how work is broken down into consumables and deliverables. It's about clear prioritization and freedom to focus on the task at hand. But most development teams would iterate aimlessly, while the organization around them continued doing business as usual. To successfully embrace Agile, the entire organization has to do so at some level or another. You have to break requirements down into pieces that can be consumed in an iteration. You have to prioritize clearly. And you can't change priorities until the iteration is complete. Additionally, many software teams misunderstand how they work. I can't tell you how many times a team would insist to me they were using a waterfall process, but when I asked them to describe the previous workday they'd describe end-to-end firefighting. When I would introduce Agile and the controls that it brings, they would react negatively expecting that Agile was some magical organized free-for-all. Additionally, lots of consultants made money off of the promise of Agile and the cult of Agile. They didn't provide practical solutions, and organizations resisted change. So much of the indigestion that developers have regarding Agile is due to their own experiences with organizations that bought the promise of Agile but didn't do the necessary work to make it successful.
- Tomis02 9y ago
  > real Agile Heh, classic response. Whenever your project fails, your coach tells you it's your fault because you didn't do real Agile. Same with OOP, whenever your code inevitably becomes a tangled mess of classes, you will have all sorts of gurus making metric shit tons of money from books and consulting telling you you didn't do real OOP. Guys, please, can you just admit there is no recipe for success (rhetorical question, of course you can't, that's where you money comes from, maybe you even believe your own bullshit)? There is no real Agile and OOP and other crap that I forget, they're just buzzwords that, when applied long or hard enough, produce shit. If you had kept you project to an absolute minimal level of Agile and OOP, it would probably still be alive and kicking. But you didn't, because you jumped on the bandwagon, you used religiously whatever was popular. > Agile, done right ... Yeah, heard that a thousand times before. Sadly, younger developers fall for this all the time, so shit grows exponentially. I'm aware my opinion has always been in minority but whatever.
adreamingsoul 9y ago
I love Agile and Scrum for solving my own problems. Nothing is better than being able to iterate on an idea to determine if it's right or not. However, I mostly witness selfish, political, or misinformed ideas being dictated as "requirements". I learned really fast that stakeholders do not like their ideas being questioned with data points from a scrum research spike. So who enjoys wasting time when your professional viewpoint won't be heard? If management or stakeholders are unwilling to listen to the team that solves problems for a living, why should I/we waste energy on Agile or Scrum?
api 9y ago
Agile often allows no time for doing it right, leading to high levels of technical debt. In the end it leads to Rube Goldberg machines and the "big ball of mud." It's suitable for prototyping but often fails for producing quality software. The nastiest balls of glued together snot I have ever seen were almost all from textbook Scrum shops. The rest were from lowest bidder outsourcers that probably use similar management methods to try to get code from bad or underpaid/unmotivated coders. The problem is that deep conceptual thought about a design and deep refactoring are hard to capture as a ticket item. Quality is something that perfuses all deliverables but is not itself a deliverable. Agile is also totally unsuited for innovation. You will never get a Xerox Parc or SRI with agile. You can only make what you already know to make with agile.
- kwhitefoot 9y ago
  This should be the top ranked comment!
sgt101 9y ago
Because it's misused as a way of doing things on the cheap, and the people who have to live with the consequences are the developers. The anti-patterns of Agile are... - no documentation - incoherent design - no tooling This doesn't have to be Agile, but often is.
makecheck 9y ago
Processes are needed for sanity, and not much else. Don’t be the baker who’s really firm on a choice of a 9x13 pan and the entire set of ingredients for a cake, only to find out that people want cookies. To move quickly, you really need just two things: a way to make sure things don’t change unexpectedly, and a way to recreate anything you had before (where the 2nd is a crutch if the 1st fails). To have sanity, you need somebody setting a direction (“we’re doing this”), and somebody deciding what can wait. For software, this means things like: “for Pete’s sake, use revision control”, “track versions of dependencies”, “back things up”, “write scripts instead of step-by-step instructions”, “test somehow”, and “track problems”. There is no “daily one hour meeting” phase of software development.
smoyer 9y ago
I'm not sure that developers dislike those they work with so much as they dislike being managed - the fun part of the job is exploratory programming and chasing technical curiosities. Having a manager and customers means we actually have to create something that works and generally includes more "drudge work". If developers dislike agile, you'd expect them to be happy with BDUF (waterfall) and I never hear people saying they're happy with book-sized specification documents. Isn't this really the difference between computer science and software engineering? As developers we have to straddle the fence.
- TimJYoung 9y ago
  Software developers are human beings. This seems like a "duh" moment until you realize that we routinely ignore this basic fact. As human beings, we operate best when we feel like we're doing something important or valuable. If we are tasked with something that is neither, then it is up to the person that is assigning the task to acknowledge the situation and make it be known that "taking one for the company" won't go unnoticed. There are also additional compensation options that could be used to make the whole situation more tolerable. Something along the lines of "Bill spent two weeks documenting that entire area of the product that everyone is so wary of altering, so he's earned that extra 3 days of vacation". Edit: In case it wasn't clear, I agree with everything you're saying. However, I do think that good managers that understand their developers can make things work and keep everyone happy.
flaviusas 9y ago
No sane developer dislikes agile. We only dislike agile-done-wrong.
nikanj 9y ago
Because a lot of places assume the dev team can run an ultra-marathon in an hour, by dividing it into 500 hundred-meter dashes.
kps 9y ago
The difference between agile and Agile is the difference between a democratic republic and a Democratic Republic.
chrisbennet 9y ago
When developers are the one doing agile-ing, it seems to more successful. When it's a process driven by/for management it can get frozen in place making change harder. Developer driven: Mike: "Bob, I'm skipping scrum today." Bob: "K" (Thinks "He's still working on the gnarly multithreading problem.") Management driven: Manager/Scrum Master: "Bob, where's Mike?" Bob: "He's deep in flow working on that multithreading problem." Manager: "Go get him, he can work on that later." (Thinks "I have boxes to fill in my spreadsheet. How can I do that without a scrum meeting??")
ajarmst 9y ago
I think some dislike agile because its adherents so often write articles like this. Pompous, dismissive, assuming facts without providing real measurable evidence and implying that people who disagree only do so because they're just not smart enough. If Agile didn't improve your processes, why it must be because you didn't do it right! And because of that, you hate yourself! You're just afraid of success! Uh-huh.
- deleted 9y ago
  [deleted]
scarface74 9y ago
About nine months ago I was hired to create a modern "agile" development shop with an IT department that had a legacy product built on Access, SSRS, stored procedures, an old version of Sql Server, etc... It broke every single rule of what I look for when accepting a job. I only took the job with the condition that I would have 100% support, budget and time to set things up right from my future manager. I laid out my vision.... 1. Realistic timelines based on a 40 hour work week. All estimates and deadlines were based on realistic hours, realistic staffing levels, and realistic utilization. 2. I would be given the time and budget to setup a proper CI/CD platform. 3. We would put in all of our estimates time for automated testing and code reviews. 4. Devs would have direct access to the (internal) customer. 5. I would have the budget to contract smart people at market rates. 6. Any dissension from the legacy developers with an attitude of "why do we need to change. That's the way we've always done things" wouldn't be tolerated. If they couldn't get on board, I would hire my own team and let the existing developers support the legacy product.
- appleflaxen 9y ago
  you are leaving out the punchline... how is it going?
  - scarface74 9y ago
    See a more detailed summary in my previous response, but well so far. If it doesn't work out, I have no one to blame but myself. I've been giving the authority, the budget, and the support to do it right.
- fnbr 9y ago
  Did it work? It sounds like you made all of the correct conditions, but that seems like an incredibly difficult environment for you to succeed in.
  - scarface74 9y ago
    It's working well so far. I would never have accepted the job as just another developer. I only accepted it as an architect that was given the authority to make the changes. I haven't gotten any push back from the higher ups. I had to sell everything as a long term cost savings: - automated tests keep the cost of hiring QA down. QA only has to test new functionality. The more automated tests you have -- both unit and integration tests - the less manual regression testing you have to do. - automated testing also allows us to ramp up with contractors and you don't loose business knowledge when people leave because the business logic is in the automated tests - not a bunch of documents in SharePoint. If a contractor comes in and makes a change and the tests break, they've broken a piece of business logic. - Once everything is setup, and documented, you don't need dedicated "release engineers" all releases are coded with Powershell and configured with Consul. We treat servers like "cattle not pets". We also based the project on Mongo and not sql server so we don't have to worry about database deployments. We decorate the fields in our POCOs that are being stored with attributes that tell the individual services at startup to auto create any missing indexes that we need. Schemas are enforced by microservices that are the only way to access Mongo.
eesmith 9y ago
I dislike Agile because apparently the only thing is "waterfall" or "Agile". Many seem to think that before "Agile" or at least "Extreme Programming" there was nothing but the waterfall boogie-man. It's as if they had never read books like "Rapid Development" which describes over a dozen different design approaches, with pros and cons. I dislike Agile because apparently the only important thing is the Toyota Way. They never mention alternatives like the Volvo's Uddevalla plant and humanistic manufacturing. Eg, quoting from http://gerpisa.org/ancien-gerpisa/actes/9/9-5.pdf http://gerpisa.org/ancien-gerpisa/actes/9/9-5.pdf "After a slow start Uddevalla took off and in 1991 reached the level of the Gothenburg mass production plant. From the last quarter of 1990 to the last quarter of 1992 Uddevalla cut the assembly time at an average rate of one hour a month. This rapid learning curve surpassed developments at the Gothenburg plant, where lean production techniques were introduced to boost performance." Yes, such conclusions are contested, but it's still a concrete alternative that's almost ignored by those repeating the chant "Toyota ... Toyota ... Toyota." I dislike Agile because it's a collection of ill-defined mush. If a group adapts or changes in any way during a project, and the project is successful, then it's counted as an Agile success story, while if it project fails despite flexibility then it must not have been True Agile, or at least Enough Agile.
- Clubber 9y ago
  "Rapid Development" was/is one of my all time favorite "project management" type books. Waterfall is a baseline. Even in what people would consider waterfall, there were "buffer" items incase we needed to change everything. The scrum disciples are being disingenuous when they compare everything to waterfall. It's like comparing the newest language to programming the Altair.
- drieddust 9y ago
  IMHO purpose of agile was to reduce the work in progress at Toyota. This can improve efficiency of existing assembly line. It was never supposed to build the new and improved assembly lines in short sprints. But that's what it is being shoe horned into and have become an excuse for not spending time doing the requirement gathering and deep design thinking. I strongly feel Agile is a nice fit only when base work is done properly in terms of getting the software architecture and contracts correctly defined.
TimJYoung 9y ago
When software projects fail, it's natural to think "wow, if only we had organized things in this way...", or "if only we had a more accurate schedule...", but it's just a way of ignoring the elephant in the room: your developers weren't up to the task. Think about it this way: if your developers knew about all of the issues that would result in a failed project and a) didn't tell you or b) didn't quit if you ignored their warnings, then what kind of professional developers are you employing ? This micro-management of the entire software development process is completely unnecessary and contrary to every bit of real-world evidence that we have about what has made certain software projects successful, and others not. Ambition, drive, and a penchant for excellence is what makes great software, not a bunch of managers pushing along a group of mediocre developers like cattle.
- humanrebar 9y ago
  > This micro-management of the entire software development process... I've been there. I've also been in the opposite, where there really is no technical leadership. I can't say it's better. For what it's worth, certain agile techniques do provide a structured way to make clear group decisions. Unfortunately those decisions usually revolve around development methodology and not, you know, the design of the actual product. Point being, micro-management is often a broad reaction to a vacuum of technical leadership. But instead of innovating, with the team makeup in mind, on how to make sure good decisions emerge, a manager will figure they need to personally make those decisions. So they need more structure to make sure they're better informed, and agile techniques tend to get hijacked to that end.
  - TimJYoung 9y ago
    Yes, but that's my point. If you have a lack of technical leadership, then you need a different set of developers and need to look at who you're hiring as developers, not whether you need more management of the group of developers. For the cost of a technical manager, you can add quite a bit of salary to each developer position in a small group.
- itsdrewmiller 9y ago
  Hardly anyone is going to quit just because you ignore their warnings and let them work on a project doomed to fail, barring a significant equity stake. Software projects fail due to bad management, not (solely) bad developers; you go to war with the army you have.
strictnein 9y ago
Jira The Greenhopper plugin was a joy to use, 10 years ago. Jira Agile is an atrocity, especially in an enterprise environment. About 5% of the time you'll actually be using it to help you do your job. You'll spend far more time answering questions and doing risk analysis, etc, etc all at the request of some random person you've never met who needs reporting on some random bit of information that is of no consequence. It's used as a reporting and tracking tool now, not a tool to handle development flow.
empath75 9y ago
I feel like in order for agile (and devops) to work, you have to at least half invent it yourself, before realizing what it is. If you try to just impose it on a team, then it get a little cargo cult-y and people don't understand why they're doing it.
jeffdavis 9y ago
Because it doesn't really mean anything, and people act like it does. Maybe there's some description somewhere with meaning, but it doesn't matter because the meaninglessness has prevailed.
wpietri 9y ago
I was an early adopter (1999-2000), and for years was excited. I was burnt out on programming and considering quitting the industry, but adopting XP made things so much saner that it turned things around for me. But circa 2007 I heard more and more horror stories about companies that were "doing Agile", by which they meant top-down imposition of some fraction of things, plus managers slapping shiny new labels on their same old bullshit. It was heartbreaking to see something that helped me and my teams a great deal get so throughly misused. It became just another stick to beat developers with. I spent a lot of time apologizing for all the pain people endured. It's hardly the first time, though. The original paper on Waterfall basically said, "This is a thing that is bad and does not work." But people went and did waterfall anyhow, because a) it conforms to a number of human biases, b) it reinforces the typical top-down corporate power structure, and c) provides endless opportunities for people to blame other people for problems. So in retrospect I'm not shocked at all that we've mostly turned the various Agile methods into meaningless pablum.
alkonaut 9y ago
I dislike it because it makes me a worker at a conveyor belt rather than a craftsman or artist. The person paying the bill might argue they need something built so can't pay a craftsman to improvise - which is why this friction occurs. It's between software development as engineering vs. as an art/craft. It will always be both.
- wpietri 9y ago
  It depends on which "Agile" you mean, but for me it's just the opposite. It's no accident that a lot of the people behind the Software Craftsmanship movement were part of the early Agile movement: http://manifesto.softwarecraftsmanship.org/ http://manifesto.softwarecraftsmanship.org/
deleted 9y ago
[deleted]
martijn_himself 9y ago
The first realization should be that Agile is not a silver bullet and is not needed to build great software. Great software was built before Agile existed. People who care passionately about technology and software build great software. On recent Agile projects I have been involved in, a lot of Agile 'artifacts' were produced (mostly walls covered in Post-it notes). Software seemed to by a by-product and didn't really feature much. I think this is a result of the 'busywork' Agile created.
- lj3 9y ago
  This is something I hadn't considered. Thinking back on it, the teams I've been on that did agile had 3 or 4 times the number of managers that non-agile teams did. You needed more people to enforce the process, wrangle the engineers, plan the meetings and make sure that wall of post-it notes was updated. Something I frequently heard was that programmers were paid too much to waste their time playing arts and crafts.
a3n 9y ago
I dislike it because it forces you to think, work and report almost exclusively "in the small." I prefer to focus on larger scope, not merely live surrounded by a fog of scope, while working on the small things that contribute to the larger scope. I eat hamburgers, not bites.
- humanrebar 9y ago
  I'm the same way. Though you need the whole team working on the same larger scope. The Agile approach is to break everything down and make many small adjustments to make sure that happens. That's certainly not the only way, however, to ensure a common vision of the future.
SAI_Peregrinus 9y ago
Proper Planning Prevents Piss-Poor Performance. Agile encourages staying flexible and able to change plans on a whim. In practice that tends to mean that people using agile processes don't plan long term. Piss-poor performance is the result. Breaking tasks down into manageable pieces is hard, and requires good long-term planning for any significant project. Agile in practice is "weeks of work can save you hours of planning".
- jalfresi 9y ago
  This my experience too - agile seems to exist because clients and middle management refused to determine and plan exactly what the want developed, preferring to "know it when I see it". Agile encourages this attitude.
  - scarface74 9y ago
    No one knows what they want until they see it. They may have some vague idea but without seeing at least a minimum viable product or at least a non production ready proof of concept how can they know what they want? The other side of rapid iteration and emergent design is building a system with change in mind, not over architecting and living by the principle of YAGNI - You Ain't Gonna Need It. It's the job of the architect who should have both the people skills and the technical skills to give the customer what they want and not what they ask for.
wolfi1 9y ago
scrum could work, but only in speciql cases. for example, it cannot deal with new coworkers, at least not in the teams I experienced. it could work for ad hoc teams with the same knowledge, but in practice that is never the case
hibbelig 9y ago
Maybe in some companies they do Half Arsed Agile, instead of Agile? http://www.halfarsedagilemanifesto.org http://www.halfarsedagilemanifesto.org SCNR, it's too beautiful...
transverse 9y ago
Personally I blame Scrum or attempts at Scrum rather than Agile. Kanban is more flexible. Effective Scrum just means sacrificing code quality sufficiently to make your ticket fit your sprint. /s
WheelsAtLarge 9y ago
Simple, developers dislike it because it leads to very messy code, quick fixes that lead to messier code, and a stressful work environment. On the other hand, waterfall leads to missed deadlines, cost overruns and applications that don't meet needs. I think we need something in the middle. Does anyone have any ideas? I suspect the fix will be on the type of software app that people are writing rather than the way apps are written. Monolithic apps are hard to write and maintain so we need to think small and generalize software something similar to lego bricks.
true_tuna 9y ago
Standups
sli 9y ago
In and of itself, I don't see much wrong with it. Agile itself does not seem to be the problem. Problems arise when it is heavily abused and applied incorrectly by management, in my experience. My first time doing Agile (well, SCRUMM, but bear with me here) was someone using it to manage multiple unrelated projects at once. Predictably, it crashed a burned miserably. The person who decided on it was suckered by the buzzwords but failed to actually understand the purpose of the process. My current company uses SCRUMM quite effectively, and it's been a wildly different experience. It probably helps immensely that the people in charge are also developers.
kapauldo 9y ago
Unrealistic expectations.

I think those conflicts exist in all so-called "teams", but in Agile those conflicts become sublimated by a grumbling about "process" on a sprintly, if not daily, basis. If your plan, on the other hand, is to have three people develop three separate parts for a year, and then think you are going to stick them together and release in two weeks, people can avoid interpersonal conflicts entirely for a year, after which there is a crisis, which is often survivable by the participants because there are already so many chips in the pot...

convolvatron 9y ago
there is a pretty vast middle ground between 'talking every day for a year, and never making any plans' and 'make a plan for a year, don't meet in the interim and try to integrate then' make plans. try to gauge costs. change plans when necessary. integrate as soon as is reasonable. use consensus to drive structure/interfaces. maintain a testable artifact. maybe running a service is different, but variants on the above seem to be the only thing that works for software.

bsg75 9y ago

> People desire a structure that allows them to abdicate responsibility. s/People/Managers/ In many of the cases I have experienced, agile breaks down into an excuse to not plan ("Requirements just slow things down!"), and the elements of it that would drive success are ignored. So often business leaders just want shit done, and when the technical types warn about reliability or technical debt, there is a lot handwaving. Thus short attention spans see agile as a way to justify shortcuts. When this happens the result can be worse than a poorly executed waterfall model. Agile works when all the proper elements are used, just like any other endeavor, and it fails for the same contrary reasons. Developers become frustrated when yet another path to accomplishment is blocked. Disclaimer - Am technical manager. Have watched business peers shortcut to failure. Have fought the battles and lost. Frustration apparent.

ZenoArrow 9y ago
> "So often business leaders just want shit done, and when the technical types warn about reliability or technical debt, there is a lot handwaving. Thus short attention spans see agile as a way to justify shortcuts." This is the crux of the problem with agile. The reason it's embraced so readily by business types is the reason that it fails. With the 'justifying shortcuts' description you hit the nail on the head.
oceanghost 9y ago
This exactly. Agile allows managers to push all responsibility onto the developers (design, testing, deployment, ops, customer service, spec writing, documentation, training, etc), while simultaneously enabling them to demand milestones every two weeks. I have seen this taken to the extreme-- the management at one company I worked for would not specify ANYTHING in writing. Nothing. Not even bullet points on what a feature would do. They would then micro manage intensely (I had a non-technical VP doing code reviews on a Senior Architect). Estimates, however, only included development time, never any other tasks, and were always challenged. Deadlines were always hard. In short, we had all the responsibility of Agile but none of the empowerment. Engineering was to blame for everything. If you think this was some small crazy startup... This companies revenues are about 500m a year. Almost every American has our products in their homes.

throwme_1980 9y ago

Truth is you need to get st done, I see a lot of mediocre developers hiding behind agile processes, when they can't figure out something they throw their hands in the air and scream "bad requirements" , boohoo man-up and do the business.

thisisit 9y ago

This like essentially justifying - "Why do X dislike Y?" questions by the person who loves Y. It is not surprising that there has to be set of process or steps when doing anything, and I mean anything. The problem arises when Y is suited for type A projects but just because the Manager has read about Y in some magazine he thinks "one size fits all". The problem can be seen from the blog itself. The Toyota Way and contextual changes. In software sometime defining the context itself becomes impossible. It certainly is more difficult in a company which has no other defined processes but wants to implement Agile.

trentnix 9y ago

Because few organizations actually enable real Agile development. I did some "Agile coaching" in a previous life and time and time again I'd see teams embrace the cosmetic parts of Agile - daily standups, iterations, retrospectives - but workflow was still much the same as it always was. Agile, done right, is more about how work is broken down into consumables and deliverables. It's about clear prioritization and freedom to focus on the task at hand. But most development teams would iterate aimlessly, while the organization around them continued doing business as usual. To successfully embrace Agile, the entire organization has to do so at some level or another. You have to break requirements down into pieces that can be consumed in an iteration. You have to prioritize clearly. And you can't change priorities until the iteration is complete. Additionally, many software teams misunderstand how they work. I can't tell you how many times a team would insist to me they were using a waterfall process, but when I asked them to describe the previous workday they'd describe end-to-end firefighting. When I would introduce Agile and the controls that it brings, they would react negatively expecting that Agile was some magical organized free-for-all. Additionally, lots of consultants made money off of the promise of Agile and the cult of Agile. They didn't provide practical solutions, and organizations resisted change. So much of the indigestion that developers have regarding Agile is due to their own experiences with organizations that bought the promise of Agile but didn't do the necessary work to make it successful.

Tomis02 9y ago
> real Agile Heh, classic response. Whenever your project fails, your coach tells you it's your fault because you didn't do real Agile. Same with OOP, whenever your code inevitably becomes a tangled mess of classes, you will have all sorts of gurus making metric shit tons of money from books and consulting telling you you didn't do real OOP. Guys, please, can you just admit there is no recipe for success (rhetorical question, of course you can't, that's where you money comes from, maybe you even believe your own bullshit)? There is no real Agile and OOP and other crap that I forget, they're just buzzwords that, when applied long or hard enough, produce shit. If you had kept you project to an absolute minimal level of Agile and OOP, it would probably still be alive and kicking. But you didn't, because you jumped on the bandwagon, you used religiously whatever was popular. > Agile, done right ... Yeah, heard that a thousand times before. Sadly, younger developers fall for this all the time, so shit grows exponentially. I'm aware my opinion has always been in minority but whatever.

adreamingsoul 9y ago

I love Agile and Scrum for solving my own problems. Nothing is better than being able to iterate on an idea to determine if it's right or not. However, I mostly witness selfish, political, or misinformed ideas being dictated as "requirements". I learned really fast that stakeholders do not like their ideas being questioned with data points from a scrum research spike. So who enjoys wasting time when your professional viewpoint won't be heard? If management or stakeholders are unwilling to listen to the team that solves problems for a living, why should I/we waste energy on Agile or Scrum?

api 9y ago

Agile often allows no time for doing it right, leading to high levels of technical debt. In the end it leads to Rube Goldberg machines and the "big ball of mud." It's suitable for prototyping but often fails for producing quality software. The nastiest balls of glued together snot I have ever seen were almost all from textbook Scrum shops. The rest were from lowest bidder outsourcers that probably use similar management methods to try to get code from bad or underpaid/unmotivated coders. The problem is that deep conceptual thought about a design and deep refactoring are hard to capture as a ticket item. Quality is something that perfuses all deliverables but is not itself a deliverable. Agile is also totally unsuited for innovation. You will never get a Xerox Parc or SRI with agile. You can only make what you already know to make with agile.

kwhitefoot 9y ago
This should be the top ranked comment!

sgt101 9y ago

Because it's misused as a way of doing things on the cheap, and the people who have to live with the consequences are the developers. The anti-patterns of Agile are... - no documentation - incoherent design - no tooling This doesn't have to be Agile, but often is.

makecheck 9y ago

Processes are needed for sanity, and not much else. Don’t be the baker who’s really firm on a choice of a 9x13 pan and the entire set of ingredients for a cake, only to find out that people want cookies. To move quickly, you really need just two things: a way to make sure things don’t change unexpectedly, and a way to recreate anything you had before (where the 2nd is a crutch if the 1st fails). To have sanity, you need somebody setting a direction (“we’re doing this”), and somebody deciding what can wait. For software, this means things like: “for Pete’s sake, use revision control”, “track versions of dependencies”, “back things up”, “write scripts instead of step-by-step instructions”, “test somehow”, and “track problems”. There is no “daily one hour meeting” phase of software development.

smoyer 9y ago

I'm not sure that developers dislike those they work with so much as they dislike being managed - the fun part of the job is exploratory programming and chasing technical curiosities. Having a manager and customers means we actually have to create something that works and generally includes more "drudge work". If developers dislike agile, you'd expect them to be happy with BDUF (waterfall) and I never hear people saying they're happy with book-sized specification documents. Isn't this really the difference between computer science and software engineering? As developers we have to straddle the fence.

TimJYoung 9y ago
Software developers are human beings. This seems like a "duh" moment until you realize that we routinely ignore this basic fact. As human beings, we operate best when we feel like we're doing something important or valuable. If we are tasked with something that is neither, then it is up to the person that is assigning the task to acknowledge the situation and make it be known that "taking one for the company" won't go unnoticed. There are also additional compensation options that could be used to make the whole situation more tolerable. Something along the lines of "Bill spent two weeks documenting that entire area of the product that everyone is so wary of altering, so he's earned that extra 3 days of vacation". Edit: In case it wasn't clear, I agree with everything you're saying. However, I do think that good managers that understand their developers can make things work and keep everyone happy.

flaviusas 9y ago

No sane developer dislikes agile. We only dislike agile-done-wrong.

nikanj 9y ago

Because a lot of places assume the dev team can run an ultra-marathon in an hour, by dividing it into 500 hundred-meter dashes.

kps 9y ago

The difference between agile and Agile is the difference between a democratic republic and a Democratic Republic.

chrisbennet 9y ago

When developers are the one doing agile-ing, it seems to more successful. When it's a process driven by/for management it can get frozen in place making change harder. Developer driven: Mike: "Bob, I'm skipping scrum today." Bob: "K" (Thinks "He's still working on the gnarly multithreading problem.") Management driven: Manager/Scrum Master: "Bob, where's Mike?" Bob: "He's deep in flow working on that multithreading problem." Manager: "Go get him, he can work on that later." (Thinks "I have boxes to fill in my spreadsheet. How can I do that without a scrum meeting??")

ajarmst 9y ago

I think some dislike agile because its adherents so often write articles like this. Pompous, dismissive, assuming facts without providing real measurable evidence and implying that people who disagree only do so because they're just not smart enough. If Agile didn't improve your processes, why it must be because you didn't do it right! And because of that, you hate yourself! You're just afraid of success! Uh-huh.

deleted 9y ago
[deleted]

scarface74 9y ago

About nine months ago I was hired to create a modern "agile" development shop with an IT department that had a legacy product built on Access, SSRS, stored procedures, an old version of Sql Server, etc... It broke every single rule of what I look for when accepting a job. I only took the job with the condition that I would have 100% support, budget and time to set things up right from my future manager. I laid out my vision.... 1. Realistic timelines based on a 40 hour work week. All estimates and deadlines were based on realistic hours, realistic staffing levels, and realistic utilization. 2. I would be given the time and budget to setup a proper CI/CD platform. 3. We would put in all of our estimates time for automated testing and code reviews. 4. Devs would have direct access to the (internal) customer. 5. I would have the budget to contract smart people at market rates. 6. Any dissension from the legacy developers with an attitude of "why do we need to change. That's the way we've always done things" wouldn't be tolerated. If they couldn't get on board, I would hire my own team and let the existing developers support the legacy product.

appleflaxen 9y ago
you are leaving out the punchline... how is it going?
- scarface74 9y ago
  See a more detailed summary in my previous response, but well so far. If it doesn't work out, I have no one to blame but myself. I've been giving the authority, the budget, and the support to do it right.
fnbr 9y ago
Did it work? It sounds like you made all of the correct conditions, but that seems like an incredibly difficult environment for you to succeed in.
- scarface74 9y ago
  It's working well so far. I would never have accepted the job as just another developer. I only accepted it as an architect that was given the authority to make the changes. I haven't gotten any push back from the higher ups. I had to sell everything as a long term cost savings: - automated tests keep the cost of hiring QA down. QA only has to test new functionality. The more automated tests you have -- both unit and integration tests - the less manual regression testing you have to do. - automated testing also allows us to ramp up with contractors and you don't loose business knowledge when people leave because the business logic is in the automated tests - not a bunch of documents in SharePoint. If a contractor comes in and makes a change and the tests break, they've broken a piece of business logic. - Once everything is setup, and documented, you don't need dedicated "release engineers" all releases are coded with Powershell and configured with Consul. We treat servers like "cattle not pets". We also based the project on Mongo and not sql server so we don't have to worry about database deployments. We decorate the fields in our POCOs that are being stored with attributes that tell the individual services at startup to auto create any missing indexes that we need. Schemas are enforced by microservices that are the only way to access Mongo.

eesmith 9y ago

I dislike Agile because apparently the only thing is "waterfall" or "Agile". Many seem to think that before "Agile" or at least "Extreme Programming" there was nothing but the waterfall boogie-man. It's as if they had never read books like "Rapid Development" which describes over a dozen different design approaches, with pros and cons. I dislike Agile because apparently the only important thing is the Toyota Way. They never mention alternatives like the Volvo's Uddevalla plant and humanistic manufacturing. Eg, quoting from http://gerpisa.org/ancien-gerpisa/actes/9/9-5.pdf http://gerpisa.org/ancien-gerpisa/actes/9/9-5.pdf "After a slow start Uddevalla took off and in 1991 reached the level of the Gothenburg mass production plant. From the last quarter of 1990 to the last quarter of 1992 Uddevalla cut the assembly time at an average rate of one hour a month. This rapid learning curve surpassed developments at the Gothenburg plant, where lean production techniques were introduced to boost performance." Yes, such conclusions are contested, but it's still a concrete alternative that's almost ignored by those repeating the chant "Toyota ... Toyota ... Toyota." I dislike Agile because it's a collection of ill-defined mush. If a group adapts or changes in any way during a project, and the project is successful, then it's counted as an Agile success story, while if it project fails despite flexibility then it must not have been True Agile, or at least Enough Agile.

Clubber 9y ago
"Rapid Development" was/is one of my all time favorite "project management" type books. Waterfall is a baseline. Even in what people would consider waterfall, there were "buffer" items incase we needed to change everything. The scrum disciples are being disingenuous when they compare everything to waterfall. It's like comparing the newest language to programming the Altair.
drieddust 9y ago
IMHO purpose of agile was to reduce the work in progress at Toyota. This can improve efficiency of existing assembly line. It was never supposed to build the new and improved assembly lines in short sprints. But that's what it is being shoe horned into and have become an excuse for not spending time doing the requirement gathering and deep design thinking. I strongly feel Agile is a nice fit only when base work is done properly in terms of getting the software architecture and contracts correctly defined.

TimJYoung 9y ago

When software projects fail, it's natural to think "wow, if only we had organized things in this way...", or "if only we had a more accurate schedule...", but it's just a way of ignoring the elephant in the room: your developers weren't up to the task. Think about it this way: if your developers knew about all of the issues that would result in a failed project and a) didn't tell you or b) didn't quit if you ignored their warnings, then what kind of professional developers are you employing ? This micro-management of the entire software development process is completely unnecessary and contrary to every bit of real-world evidence that we have about what has made certain software projects successful, and others not. Ambition, drive, and a penchant for excellence is what makes great software, not a bunch of managers pushing along a group of mediocre developers like cattle.

humanrebar 9y ago
> This micro-management of the entire software development process... I've been there. I've also been in the opposite, where there really is no technical leadership. I can't say it's better. For what it's worth, certain agile techniques do provide a structured way to make clear group decisions. Unfortunately those decisions usually revolve around development methodology and not, you know, the design of the actual product. Point being, micro-management is often a broad reaction to a vacuum of technical leadership. But instead of innovating, with the team makeup in mind, on how to make sure good decisions emerge, a manager will figure they need to personally make those decisions. So they need more structure to make sure they're better informed, and agile techniques tend to get hijacked to that end.
- TimJYoung 9y ago
  Yes, but that's my point. If you have a lack of technical leadership, then you need a different set of developers and need to look at who you're hiring as developers, not whether you need more management of the group of developers. For the cost of a technical manager, you can add quite a bit of salary to each developer position in a small group.
itsdrewmiller 9y ago
Hardly anyone is going to quit just because you ignore their warnings and let them work on a project doomed to fail, barring a significant equity stake. Software projects fail due to bad management, not (solely) bad developers; you go to war with the army you have.

strictnein 9y ago

Jira The Greenhopper plugin was a joy to use, 10 years ago. Jira Agile is an atrocity, especially in an enterprise environment. About 5% of the time you'll actually be using it to help you do your job. You'll spend far more time answering questions and doing risk analysis, etc, etc all at the request of some random person you've never met who needs reporting on some random bit of information that is of no consequence. It's used as a reporting and tracking tool now, not a tool to handle development flow.

empath75 9y ago

I feel like in order for agile (and devops) to work, you have to at least half invent it yourself, before realizing what it is. If you try to just impose it on a team, then it get a little cargo cult-y and people don't understand why they're doing it.

jeffdavis 9y ago

Because it doesn't really mean anything, and people act like it does. Maybe there's some description somewhere with meaning, but it doesn't matter because the meaninglessness has prevailed.

wpietri 9y ago

I was an early adopter (1999-2000), and for years was excited. I was burnt out on programming and considering quitting the industry, but adopting XP made things so much saner that it turned things around for me. But circa 2007 I heard more and more horror stories about companies that were "doing Agile", by which they meant top-down imposition of some fraction of things, plus managers slapping shiny new labels on their same old bullshit. It was heartbreaking to see something that helped me and my teams a great deal get so throughly misused. It became just another stick to beat developers with. I spent a lot of time apologizing for all the pain people endured. It's hardly the first time, though. The original paper on Waterfall basically said, "This is a thing that is bad and does not work." But people went and did waterfall anyhow, because a) it conforms to a number of human biases, b) it reinforces the typical top-down corporate power structure, and c) provides endless opportunities for people to blame other people for problems. So in retrospect I'm not shocked at all that we've mostly turned the various Agile methods into meaningless pablum.

alkonaut 9y ago

I dislike it because it makes me a worker at a conveyor belt rather than a craftsman or artist. The person paying the bill might argue they need something built so can't pay a craftsman to improvise - which is why this friction occurs. It's between software development as engineering vs. as an art/craft. It will always be both.

wpietri 9y ago
It depends on which "Agile" you mean, but for me it's just the opposite. It's no accident that a lot of the people behind the Software Craftsmanship movement were part of the early Agile movement: http://manifesto.softwarecraftsmanship.org/ http://manifesto.softwarecraftsmanship.org/

deleted 9y ago

[deleted]

martijn_himself 9y ago

The first realization should be that Agile is not a silver bullet and is not needed to build great software. Great software was built before Agile existed. People who care passionately about technology and software build great software. On recent Agile projects I have been involved in, a lot of Agile 'artifacts' were produced (mostly walls covered in Post-it notes). Software seemed to by a by-product and didn't really feature much. I think this is a result of the 'busywork' Agile created.

lj3 9y ago
This is something I hadn't considered. Thinking back on it, the teams I've been on that did agile had 3 or 4 times the number of managers that non-agile teams did. You needed more people to enforce the process, wrangle the engineers, plan the meetings and make sure that wall of post-it notes was updated. Something I frequently heard was that programmers were paid too much to waste their time playing arts and crafts.

a3n 9y ago

I dislike it because it forces you to think, work and report almost exclusively "in the small." I prefer to focus on larger scope, not merely live surrounded by a fog of scope, while working on the small things that contribute to the larger scope. I eat hamburgers, not bites.

humanrebar 9y ago
I'm the same way. Though you need the whole team working on the same larger scope. The Agile approach is to break everything down and make many small adjustments to make sure that happens. That's certainly not the only way, however, to ensure a common vision of the future.

SAI_Peregrinus 9y ago

Proper Planning Prevents Piss-Poor Performance. Agile encourages staying flexible and able to change plans on a whim. In practice that tends to mean that people using agile processes don't plan long term. Piss-poor performance is the result. Breaking tasks down into manageable pieces is hard, and requires good long-term planning for any significant project. Agile in practice is "weeks of work can save you hours of planning".

jalfresi 9y ago
This my experience too - agile seems to exist because clients and middle management refused to determine and plan exactly what the want developed, preferring to "know it when I see it". Agile encourages this attitude.
- scarface74 9y ago
  No one knows what they want until they see it. They may have some vague idea but without seeing at least a minimum viable product or at least a non production ready proof of concept how can they know what they want? The other side of rapid iteration and emergent design is building a system with change in mind, not over architecting and living by the principle of YAGNI - You Ain't Gonna Need It. It's the job of the architect who should have both the people skills and the technical skills to give the customer what they want and not what they ask for.

wolfi1 9y ago

scrum could work, but only in speciql cases. for example, it cannot deal with new coworkers, at least not in the teams I experienced. it could work for ad hoc teams with the same knowledge, but in practice that is never the case

hibbelig 9y ago

Maybe in some companies they do Half Arsed Agile, instead of Agile? http://www.halfarsedagilemanifesto.org http://www.halfarsedagilemanifesto.org SCNR, it's too beautiful...

transverse 9y ago

Personally I blame Scrum or attempts at Scrum rather than Agile. Kanban is more flexible. Effective Scrum just means sacrificing code quality sufficiently to make your ticket fit your sprint. /s

WheelsAtLarge 9y ago

Simple, developers dislike it because it leads to very messy code, quick fixes that lead to messier code, and a stressful work environment. On the other hand, waterfall leads to missed deadlines, cost overruns and applications that don't meet needs. I think we need something in the middle. Does anyone have any ideas? I suspect the fix will be on the type of software app that people are writing rather than the way apps are written. Monolithic apps are hard to write and maintain so we need to think small and generalize software something similar to lego bricks.

true_tuna 9y ago

Standups

sli 9y ago

In and of itself, I don't see much wrong with it. Agile itself does not seem to be the problem. Problems arise when it is heavily abused and applied incorrectly by management, in my experience. My first time doing Agile (well, SCRUMM, but bear with me here) was someone using it to manage multiple unrelated projects at once. Predictably, it crashed a burned miserably. The person who decided on it was suckered by the buzzwords but failed to actually understand the purpose of the process. My current company uses SCRUMM quite effectively, and it's been a wildly different experience. It probably helps immensely that the people in charge are also developers.

kapauldo 9y ago

Unrealistic expectations.