13 ms·

Agile is Dead

121 points by dsego 11y ago

sharemywin 11y ago
As with any tool there is a place for it. Daily stand ups sucked but on the big project I was on, it did help with people needing to bring up roadblocks. open floor plans suck but you get used to them and start feel isolated when you go back to a cube. Code quality suffered because of the constant pressure to get things done now.
- mindcrime 11y ago
  open floor plans suck but you get used to them Open floor plans are not a requirement of "agile". That people think this, is evidence of the real problem here: hucksters have been selling something else, but using the word "agile" to promote it. If one wants to argue that the term "agile" is dead, then maybe one has a point. But I'll argue that the essence of agile is just as sound as it ever was, it's just that we let the term get misappropriated. How to proceed from here is an open question...
  - sharemywin 11y ago
    The problem with agile is it's not management friendly. And since they cut the checks, they get to dictate how things get done. All they care about is when is it going to be done and how much will it cost. Oh, and make sure all that shit management promised is in there.
    - emodendroket 11y ago
      Well, it does seem like an odd thing to sell your customer on, doesn't it? If you wanted to do some home renovations and somebody told you they had no idea how much it would cost to do until they started working on it, you might be uncomfortable. There are scenarios where this isn't an issue but I wonder if it's as broadly applicable as we've made it out to be.
      - hiou 11y ago
        Its almost as if service based economies are not that compatible with property rights based capital markets.
        emodendroket 11y ago
        OK... so what do you propose software developers do to usher in the post-capitalist age?
        mindcrime 11y ago
        Its almost as if service based economies are not that compatible with property rights based capital markets. I don't see it quite that way. Services business work in our economy, but if you're doing something on a services basis, you have to understand the implications of that and how to manage them. There are all sorts of services in our economy that work (mostly) fine today. To illustrate what I mean, let me use an example.. if you take your car in to a shop for repairs, you expect an estimate, and you aren't necessarily pissed if the final tally is off the estimate by a bit. But you will be royally pissed if it's off by an order of magnitude or more. So, do software projects sometimes cost (in time, money, both, etc.) an order of magnitude more than estimated? Yeah, I'd say so. But here's the rub... are car mechanics better at estimating than software developers? Not necessarily, but their customer doesn't typically come along when the project is half done, and yank the rug out from under them and ask for something that negates half the work they've already done. "Yeah, about replacing that spun bearing...I don't really want that, just replace the fuel injectors instead". Nope. Doesn't happen. But I'll argue that the equivalent does happen in our world. Of course the Agile Manifesto is all about the idea of embracing change, and accepting change even late in the process. So we have to accept that and deal with it. But the rub here is that we have do so in a way that doesn't come across to the customer as an order of magnitude failure. This is one place where I think we, as an industry, kinda fell on our swords. WE understand agile, but we didn't always educate the customer on what agile meant. And we didn't do a very good job of communicating to the customer what the impact of their change in requirements is. We accept changing requirements, yes... but we haven't always made it absolutely clear to the business customer that "making this change is the equivalent of asking the auto mechanic to replace the fuel injectors instead of fixing the bearing. This is throwing out all the work we've already done, and we need to re-estimate everything now." Is it because IT people lack the nerve to push back when business users make huge demands? Or something else? I don't know, but over the years I've become convinced this is a big part of the problem. We let the users change things (which they have the right to do), but we don't make damn sure they understand the implications of what they're asking for, and update the estimate/plan/etc. to reflect the new reality.
    - stcredzero 11y ago
      Are you redefining "friendly" as, "makes promises that can't be kept and tells you what you want to hear?"
      - bitwize 11y ago
        It's an operational definition of "friendly", as implemented by middle managers across the globe.
        stcredzero 11y ago
        By more than middle managers. I think some people also use this when seeking relationships.
  - AnimalMuppet 11y ago
    > How to proceed from here is an open question... Keep doing the parts of it that work for you. If parts of it don't work for you, change them or drop them. (Part of the agile philosophy is that you can hack your process.) We may need to drop the word "agile". But if the mindset leads to you practices that are helpful, use them.
- wccrawford 11y ago
  Stand ups didn't suck at my last company. (My current one doesn't do scrum at all.) But they were okay because I refused to let people screw them up. If anyone got off-topic, I simply asked a pointed question and got them back on track. Everyone appreciated it, and it kept the stand-ups short, like they were supposed to be. When others ran the stand-ups, they tended to let people ramble more, and they were more painful. I did my best not to step in and corral the situation, but I still often ended up asking the appropriate question. My meetings went the same way, with a focus on getting things done so we could all go back to our desks. We socialized plenty from our desks and other times, and there was no need to drag out meetings. I was thanked for my efforts numerous times, and I tried to be aware of any discord that was created, so I'm fairly sure I wasn't making enemies by doing it. My point is that standups don't have to suck, but someone has to keep them on track. That's what the standup leader is supposed to be doing anyhow.
  - Cpoll 11y ago
    >If anyone got off-topic, I simply asked a pointed question and got them back on track. I'd love to hear some examples here, maybe a snippet of one of your stand-ups.
  - nostrademons 11y ago
    Heh, on one of the projects I once worked on, we had a problem with the stand-ups getting too longwinded, and so we instituted a 1-minute time limit for each persons' update. And then we were like "Hey, this is working pretty well, let's see if we can shrink the time limit!" We ended up getting it down to 10 seconds/person, with the entire standup over in one minute. The essential purpose of a standup is to make sure everyone knows what everyone else is working on, to identify any potential blockers early, and to get the right people collaborating offline to work out details. It really doesn't take very long to say this: "ComponentX, componentY; Blocked on componentZ; need to talk to Bob and Sue afterwards" is fine.
    - LargeWu 11y ago
      There's no reason you need to get everybody in the same physical place at the same time for this. If you are just giving status updates, team chat is a perfectly viable option. I know I personally can't get started on things right away in the morning because of the psychic weight standups carry. I can't get focused because in the back of my mind I know I'm going to get interrupted soon for a meeting that mostly has little relevance to me.
- shepardrtc 11y ago
  > open floor plans suck but you get used to them and start feel isolated when you go back to a cube I felt the same way. And now after a few years of open floor plans, I actually love them. Sure there are some drawbacks: noise can increase, and certainly there are more distractions, but there are many benefits. Communication is easier. That feeling of isolation is gone. The group feels more cohesive. I think the only modification that could be made would be to create more isolated areas off to the side either for individual work or team meetings. And companies are doing that, although the private areas are moreso for meetings. But I hear that some are even making smaller areas just for individuals who need a few hours to focus on one task. > Code quality suffered because of the constant pressure to get things done now It takes some wisdom for managers to be able to properly apply Agile principles. Pressuring devs to spit something out without properly designing it is poor management practice. Its common, yes, but its still wrong. That's why Agile suggests a fairly wide range of time to deliver software (from two weeks to two months). Every piece of software is different, and it takes good people to determine the correct balance between release frequency and development time. You should prefer to release frequently, but if you're releasing garbage then what's the point?
vannevar 11y ago
Agile will be dead as long as it's the dominant management methodology and there are page-views to be had. It'll be replaced with essentially the same process but with different terminology. Long before the Agile Manifesto, when I was working at NASA, we talked about the reality that the state of knowledge about a project is at its lowest at the beginning, and that any realistic project planning and management process must acknowledge and accommodate that fact. Subsequent research has confirmed that human beings consistently underestimate complex tasks, and that this bias persists even with experience, so no matter what methodology you adopt, you will always be under unrealistic deadlines. This results in distortions to whatever process you use, and flaws in whatever product you produce, and these distortions and flaws will be blamed on your development process, since no one will accept that it's simply an unfixable feature of human nature.
- kfunk 11y ago
  Do you have any references to "subsequent research"? I am truly interested in digging deeper.
  - hiou 11y ago
    I know that Code Complete 2 has quite a few discussions about the phenomenon of consistently missed estimates and many references about those. I would definitely look there for a starting point about the impossibility of successful estimation in software.
  - vannevar 11y ago
    Daniel Kahneman's book "Thinking Fast and Slow" is a great overview of the field of cognitive bias. For a more academic treatment of his research, check out "Heuristics and Biases". The part of his work most relevant to project estimation can be found in the "planning fallacy" section. Aside from Kahneman, there are numerous papers on software estimation, many of which note these consistent biases (for example Jørgensen, https://pdfs.semanticscholar.org/fd87/d248dd55f59d8d93742fb3a7edc2d5bec2e1.pdf https://pdfs.semanticscholar.org/fd87/d248dd55f59d8d93742fb3...).
- einrealist 11y ago
mindcrime 11y ago
Just to illustrate an example of how people are using the term "agile" wrong: If you ask around, you'll notice that (many|most) people equate "agile" with "two week sprints". But if you actually read the Agile Manifesto you find this: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Agile does not dictate that you use two week sprints. In fact, th term "sprint" itself is not even part of agile! The term "sprint" comes from Scrum, which is simply one specific methodology which claims adherence to the agile philosophy. But Scrum != Agile. Agile can also be XP, Crystal Clear, or AUP, etc.
- bitwize 11y ago
  Scrum is the easiest for management to grasp at a surface level so out of all the methodologies under the Agile banner Scrum is most readily and widely adopted. The problem is that Scrum "sprints" are like treating a marathon as 422 contiguous 100m dashes.
  - mindcrime 11y ago
    The problem is that Scrum "sprints" are like treating a marathon as 422 contiguous 100m dashes. Yep. Or to put it another way, too many shops seem to think that you can "sprint" ALL THE TIME. And while it's "only a metaphor", it's a meaningful one in this case. You can't: sprint -> sprint -> sprint -> sprint -> sprint -> sprint -> ∞ You have to: sprint -> sprint -> breather -> sprint -> breather -> sprint -> sprint -> breather -> ∞ or something like that.
    - UK-AL 11y ago
      Sprints aren't sprints. Replace sprint with time segment. And you get more accurate picture.
      - mindcrime 11y ago
        Sprints aren't sprints. Except when they are. And just using that term encourages people to treat them like actual sprints, instead of just metaphorical sprints. This is why I advocate for use of the term "iteration" instead. But even then, I think it's important to include "slack" iterations that are for random bug fixes, miscellaneous refactoring, etc., that is developer driven, not business user driven.
wmt 11y ago
Agile and was indeed the OOP Design Patterns of the late 2000s. Sure, there's many smart things in it, and many of those will survive, but when consultants started selling cargocultish dance moves you have to do to succeed, and where all failures happened because you were just not pure enough, it became as awkward as AbstractsSingletonFactories.
shockzzz 11y ago
Does Agile really not work with large enterprises? Or is it more that "fake agile" doesn't work?
- ssi1111 11y ago
  Fake agile does not work. Large enterprises come with all their problems in processes, tools, skills, etc. They hear this new buzz word and latch on to it. They take this new thing to their teams and ask them to implement it. And all this while, the upper management just knows how to pronounce the word "Agile"; they have no clue what it means or the work needed to "implement Agile". So upper management is never in a position to help the teams. Most times, management does not want to change the existing tools, processes or grow people's skills. And so agile fails - because people want the benefits of agile without doing the work.
  - Karunamon 11y ago
    I've got a coworker (absolutely brilliant fellow) who bristles whenever he hears buzzword-compliant terms like ITIL and Agile brought up anywhere near management. Not because those terms mean anything even remotely bad (in fact, he agrees with a lot of the philosophies), but because those terms come pre-loaded with a lot of baggage and preconceived notions by management, and saying that we have an agile-like process is just begging for some C-level with not enough work to do, to get involved and begin dictating requirements they don't understand. I doubted this until I saw it happen personally a couple of times. The process is completely, totally meaningless (and in many cases actively harmful), unless you also get the culture change to go with it.
- mbesto 11y ago
  Agile isn't binary in the sense that it either "works" or "doesn't work". Do enterprises adopt agile? Yes. Is it not "true" agile? Most likely yes. Can anyone equivocally determine what true agile is? No. Agile is what you make of it. The biggest thing holding back a "by the book" agile scrum implementation at enterprises is budgetary process. Business people, who own budgets, have an extremely hard time understanding why they can't build X for $Y, because there are few agile processes that help them clarify that.
einrealist 11y ago
"Agile is Dead" is like saying: Life sucks. Agile is a phenomenon with lots of different manifestations that try to do their best at embracing the Agile Manifesto. Yes there is hype and people who make money of it. But that hype is justified by many examples of successful Agile manifestations. Most important to Agile is to get it. To get into the mindset of feedback loops and collaboration. For larger companies with "non-Agile" habits, that is hard by default.
- draw_down 11y ago
  But also, agile is dead.
  - Karunamon 11y ago
    Long live Agile?
- askyourmother 11y ago
  I hope 'Agile', as a product, with the capital A, that sells lots of worthless pulp fiction "how to" books, with dogmatic consultants propagating useless practices they neither understand nor can follow, well I hope that is dead. It was and is a cancer on the industry as a whole. I however hope 'agile' as a spirit of talking to your users, breaking down tasks into bite size deliverables, testing, and making sure things move in a generally agreeable direction, well, I hope that persists and flourishes.
  - curiousGambler 11y ago
    Yes! Agile with a small 'a' is something I talk about at work too often. I don't want to be "Agile" but rather "agile" as in the definition of the word, "able to move quickly and easily."
  - michaelbuddy 11y ago
    Agreed. It's interesting because we all know branding aside, feedback, frquent builds, communication is something you can't deny is a good thing. But it's not unfortunately hard to decouple enthusiasm for agile from a perception of zealotry.
deleted 11y ago
[deleted]
huherto 11y ago
> Agile is Dead. Ok. I listen. What is it wrong with it ? Then there is an endless list of links. I don't even know where to start. Impossible to argue against that. But I still don't understand what the author meant. So. If we just stick to the agile manifesto. Is there something wrong with it ? The worst part is that there is no proposed alternative. I kind of get the idea that the author still thinks big upfront design is the way to go. If he believes agile is no better than Waterfall. I can't agree with that. I would hate to go back to that.
- JakeAl 11y ago
  Since no one has posted it, Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value Individuals and interaction over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in items on the right, we value the items on the left more.
- halhen 11y ago
  One answer is by Simon Bennet. See https://vimeo.com/138060217 https://vimeo.com/138060217 , in particular 13:10-16:00
paulddraper 11y ago
LinkedIn's really on a roll here. 72 hours ago there was "The Lie That Has Beguiled A Generation Of Developers" (https://www.linkedin.com/pulse/lie-has-beguiled-generation-developers-richard-eng https://www.linkedin.com/pulse/lie-has-beguiled-generation-d...), and now there's this. I can't wait to see what's next. Maybe "The End of Programming".
- herge 11y ago
  It's not really LinkedIn, it's more their built-in blogging platform, pulse.
  - vram22 11y ago
    Is their Pulse related to, or the same as, that startup called Pulse that was acquired a few years ago, and in the news?
    - jonathankoren 11y ago
      They are one in the same.
  - paulddraper 11y ago
    Oh I didn't know LinkedIn hosted blogs. That makes me sense. Now I know what blogs are just sensational twaddle.
- talmand 11y ago
  Bah, as a front-end developer paying attention to my space I hear about "HTML/CSS/Javascript sucks and this is why" articles nearly every day. I'd rather these people tell me what they like and why; it would be far more productive use of time.
  - dclowd9901 11y ago
    I'm a huge fan of the web as it is today, maybe I should write that article. But nothing gets you to click like, "everything you know is a lie."
spalt 11y ago
hurray!
feduzi 11y ago
But we're alive. Let's move on.
woah 11y ago
This guy is decrying a bunch of hucksters selling buzzwords to corporate managers with more money than sense. What's his solution? > If I were king, I would prefer to see a methodology using the (ISC)2 recommended practices in the SDLC, and the emerging OWASP practices, with more certifications like the CSSLP. The author apparently calls himself an "Enterprise Architecture Evangelist MSEA BSEE CEA³ CISSP-ISSAP PMP ITIL" I've got to chuckle. What does any of this even mean? And what does it have to do with writing good software?
- buckbova 11y ago
  What is CEA³? edit: Perhaps it is a certified enterprise architect "black belt" such and such from: https://www.feacinstitute.org/feac-courses https://www.feacinstitute.org/feac-courses Looks like all you need is 11K and 14-16 hours: http://www.tomsitpro.com/articles/enterprise-architect-certifications,2-640-6.html http://www.tomsitpro.com/articles/enterprise-architect-certi...
- meddlepal 11y ago
  I think all those letters are meant to test whether you can read letters or not. An eye chart if you will. It has nothing do with writing good software. I've seen these sprinkled about on titles before and I've just rolled my eyes in the past and will continue to do so in the future.
- andor 11y ago
  He's either a troll or lacks reading comprehension. The first article he links to is well summarized by this paragraph: "And, unfortunately, I think time has proven me right. The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products." (https://pragdave.me/blog/2014/03/04/time-to-kill-agile/ https://pragdave.me/blog/2014/03/04/time-to-kill-agile/) "Doing the right thing at any time" is still a perfectly valid principle, though.
- jenkinsj 11y ago
  Perhaps: MSEA (Master in Science of Engineering Awesome) BSEE (Binomial System Enterprise Engineer) CEA³ (Crack Enterprise Architect -to the 3rd!) CISSP-ISSAP (Calisthenic Infrastructure with Solipsistic System Paradigms - Isomorphic and Soporific System Accreditation Practices) PMP ITIL Pusillanimous Management Practices for Information Technology Inline Languages (or Pmpster IT for short)
binaryapparatus 11y ago
Good Riddance. While applying for jobs last year, I have seen huge difference between companies that demonstrate great pride in using Scrum and Agile and (insert any other buzzword here) and others that really understand how software gets developed. Software is and ever was product of art and skill. There are great ways to improve productivity, for instance I really like how kanban fits software development. On the other hand, using Scrum and sprints and what not is how non-tech HR person explains to the non-tech management how software should be developed.
- talmand 11y ago
  Seems to me that if you are a decently talented developer one would be able to adjust to whatever work methodology a company uses. It's a pointless thing to involve whether a candidate knows anything of the system currently in place. Every job I've worked has been different, some have even changed, and it's worked out fine enough.
dandare 11y ago
It is irrelevant if agile is dead until we have something to replace it with.
doingmyting 11y ago
Agile doesn't work in large enterprises because Dinosaurs still want to exist after the meteor-strike. Sorry we are not going back. No way in hell I'd go back to the waterfall model. I like shipping things my customers want quickly and easily to production rather than have some disconnected board member in their ivory tower tell me what to build and how to build it.
swagtricker 11y ago
Oh, look. Another PMP proponent who didn't _WANT_ any agile practice success rushing to quote everyone who has reflected on the fact that it isn't perfect. This guy kills his credibility with the "let's hold a rave on the grave of Agile, I'll bring the Molly" attitude. Also, he clearly never learned the secret sauce of "agile" that Scrum and modern proponents only pay lip service to because it doesn't "sell well": Fucking. Technical. Practices. I've spent over a dozen years now on teams that focused on a.) pair programming b.) test coverage and testability c.) CI (actual CI on one branch - not GitFlow B.S.) and d.) Close customer involvement. We shipped high quality, low bug software that made money for the businesses. Teams that fail to learn technical excellence leave 75% of the value of "agile" on the table, and 9 times out of 10 it's the fools in suits that won't 'let' them do it. As far as I'm concerned, big organizations can go to hell & keep failing over and over. As software becomes more powerful, 'we' don't need them: http://allankelly.blogspot.com/2015/10/software-has-diseconomies-of-scale-not.html http://allankelly.blogspot.com/2015/10/software-has-disecono...
DanielBMarkham 11y ago
You can't kill Agile because Agile doesn't mean anything. It's a marketing term. It's the place in the bookstore you go to buy books about cool stuff technology teams are doing nowadays. If I want science fiction, I go to the science fiction aisle. If all the science fiction sucks this week, I either buy something else or wait until next week. I've already established that I like reading science fiction. If I'm consuming material titled "Agile" that doesn't seem to work, or seems like a scam? I stop consuming that material. More will be along later. And just like in books, many times you have to take the book home and try it out to see if it works for you. I think there are some people who really, really, really want a magic bullet. They want an answer to life, the universe, and everything. And in so many fields, that just doesn't exist. These are some of the same people, by the way, who make Agile so terrible for everybody else. You gotta dial back the feverish adopter thing, whether you're for or against Agile, to make any progress in your career.
pg_is_a_butt 11y ago
hacker news is dead
vorg 11y ago
> DevOps is the next wave replacing Agile DevOps is about eliminating the decades-old division between development staff who control the programs and operations staff who control the data. By having "DevOps" staff who control both programs and data, businesses open themselves up to large-scale employee theft and fraud.
UK-AL 11y ago
The guy advocates CMMI in other posts which is a bureaucratic nightmare to work under. I think this guy isn't a developer, and fetishes over planning and really process driven development.
blue_dinner 11y ago
One of my last clients used scrum (I was a contractor). The boss ran a fortune 500 company during the day and decided to take everything she learned to run her own small 20-person company. Our standups lasted minimum 1 hour every day. Every Thursday we had a show-and-tell meeting, which meant going through everything we worked on and fixed (some of these meetings lasted 3 hours) and we also had a pre-planning and post-planning scrum meeting, each lasting 3 hours. At one point I was charging the company more for meetings than actual work (it was 70/30 meetings to work). I finally left when we added another 1-hour meeting on Fridays where we would just tell a joke, funny story, or something about our life. Since the majority of other contractors/developers on the team were from other countries (and didn't speak English very well), it was one of the most awkward situations I've ever encountered at work.
- solarengineer 11y ago
  Sad. It looks like the someone going through the motions without understanding the intent. In contrast, I've been part of agile teams where we were from three different timezones, had short standups (sometimes multiple times a day depending upon the need), and focused on delivering value.
PhilWright 11y ago
His account is a troll right? Anyone that lists under certifications... 'Winter Survival, Civil Air Patrol, Starting 1974' ...is impressed with certifications more than they should be. Or anyone that lists... '22% raise in one year, CDC' ...under Honors & Awards is surely making a joke?
hbcondo714 11y ago
We ended up implementing Scrumban [1] [1] https://en.m.wikipedia.org/wiki/Scrumban https://en.m.wikipedia.org/wiki/Scrumban
solarengineer 11y ago
Being "Agile" means being able to respond to change. For software, that means delivering high value, high quality working software quickly and frequently. One needs the fundamentals of short feedback loops, the ability and willingness to inspect and adapt, and collaboration and teamwork. Everything else - training, release planning, standups, story card walls, iterations - is all just the ceremonies and techniques that support these fundamentals.

121 points by dsego 11y ago

As with any tool there is a place for it. Daily stand ups sucked but on the big project I was on, it did help with people needing to bring up roadblocks. open floor plans suck but you get used to them and start feel isolated when you go back to a cube. Code quality suffered because of the constant pressure to get things done now.

mindcrime 11y ago
open floor plans suck but you get used to them Open floor plans are not a requirement of "agile". That people think this, is evidence of the real problem here: hucksters have been selling something else, but using the word "agile" to promote it. If one wants to argue that the term "agile" is dead, then maybe one has a point. But I'll argue that the essence of agile is just as sound as it ever was, it's just that we let the term get misappropriated. How to proceed from here is an open question...
- sharemywin 11y ago
  The problem with agile is it's not management friendly. And since they cut the checks, they get to dictate how things get done. All they care about is when is it going to be done and how much will it cost. Oh, and make sure all that shit management promised is in there.
  - emodendroket 11y ago
    Well, it does seem like an odd thing to sell your customer on, doesn't it? If you wanted to do some home renovations and somebody told you they had no idea how much it would cost to do until they started working on it, you might be uncomfortable. There are scenarios where this isn't an issue but I wonder if it's as broadly applicable as we've made it out to be.
    - hiou 11y ago
      Its almost as if service based economies are not that compatible with property rights based capital markets.
      - emodendroket 11y ago
        OK... so what do you propose software developers do to usher in the post-capitalist age?
      - mindcrime 11y ago
        Its almost as if service based economies are not that compatible with property rights based capital markets. I don't see it quite that way. Services business work in our economy, but if you're doing something on a services basis, you have to understand the implications of that and how to manage them. There are all sorts of services in our economy that work (mostly) fine today. To illustrate what I mean, let me use an example.. if you take your car in to a shop for repairs, you expect an estimate, and you aren't necessarily pissed if the final tally is off the estimate by a bit. But you will be royally pissed if it's off by an order of magnitude or more. So, do software projects sometimes cost (in time, money, both, etc.) an order of magnitude more than estimated? Yeah, I'd say so. But here's the rub... are car mechanics better at estimating than software developers? Not necessarily, but their customer doesn't typically come along when the project is half done, and yank the rug out from under them and ask for something that negates half the work they've already done. "Yeah, about replacing that spun bearing...I don't really want that, just replace the fuel injectors instead". Nope. Doesn't happen. But I'll argue that the equivalent does happen in our world. Of course the Agile Manifesto is all about the idea of embracing change, and accepting change even late in the process. So we have to accept that and deal with it. But the rub here is that we have do so in a way that doesn't come across to the customer as an order of magnitude failure. This is one place where I think we, as an industry, kinda fell on our swords. WE understand agile, but we didn't always educate the customer on what agile meant. And we didn't do a very good job of communicating to the customer what the impact of their change in requirements is. We accept changing requirements, yes... but we haven't always made it absolutely clear to the business customer that "making this change is the equivalent of asking the auto mechanic to replace the fuel injectors instead of fixing the bearing. This is throwing out all the work we've already done, and we need to re-estimate everything now." Is it because IT people lack the nerve to push back when business users make huge demands? Or something else? I don't know, but over the years I've become convinced this is a big part of the problem. We let the users change things (which they have the right to do), but we don't make damn sure they understand the implications of what they're asking for, and update the estimate/plan/etc. to reflect the new reality.
  - stcredzero 11y ago
    Are you redefining "friendly" as, "makes promises that can't be kept and tells you what you want to hear?"
    - bitwize 11y ago
      It's an operational definition of "friendly", as implemented by middle managers across the globe.
      - stcredzero 11y ago
        By more than middle managers. I think some people also use this when seeking relationships.
- AnimalMuppet 11y ago
  > How to proceed from here is an open question... Keep doing the parts of it that work for you. If parts of it don't work for you, change them or drop them. (Part of the agile philosophy is that you can hack your process.) We may need to drop the word "agile". But if the mindset leads to you practices that are helpful, use them.
wccrawford 11y ago
Stand ups didn't suck at my last company. (My current one doesn't do scrum at all.) But they were okay because I refused to let people screw them up. If anyone got off-topic, I simply asked a pointed question and got them back on track. Everyone appreciated it, and it kept the stand-ups short, like they were supposed to be. When others ran the stand-ups, they tended to let people ramble more, and they were more painful. I did my best not to step in and corral the situation, but I still often ended up asking the appropriate question. My meetings went the same way, with a focus on getting things done so we could all go back to our desks. We socialized plenty from our desks and other times, and there was no need to drag out meetings. I was thanked for my efforts numerous times, and I tried to be aware of any discord that was created, so I'm fairly sure I wasn't making enemies by doing it. My point is that standups don't have to suck, but someone has to keep them on track. That's what the standup leader is supposed to be doing anyhow.
- Cpoll 11y ago
  >If anyone got off-topic, I simply asked a pointed question and got them back on track. I'd love to hear some examples here, maybe a snippet of one of your stand-ups.
- nostrademons 11y ago
  Heh, on one of the projects I once worked on, we had a problem with the stand-ups getting too longwinded, and so we instituted a 1-minute time limit for each persons' update. And then we were like "Hey, this is working pretty well, let's see if we can shrink the time limit!" We ended up getting it down to 10 seconds/person, with the entire standup over in one minute. The essential purpose of a standup is to make sure everyone knows what everyone else is working on, to identify any potential blockers early, and to get the right people collaborating offline to work out details. It really doesn't take very long to say this: "ComponentX, componentY; Blocked on componentZ; need to talk to Bob and Sue afterwards" is fine.
  - LargeWu 11y ago
    There's no reason you need to get everybody in the same physical place at the same time for this. If you are just giving status updates, team chat is a perfectly viable option. I know I personally can't get started on things right away in the morning because of the psychic weight standups carry. I can't get focused because in the back of my mind I know I'm going to get interrupted soon for a meeting that mostly has little relevance to me.
shepardrtc 11y ago
> open floor plans suck but you get used to them and start feel isolated when you go back to a cube I felt the same way. And now after a few years of open floor plans, I actually love them. Sure there are some drawbacks: noise can increase, and certainly there are more distractions, but there are many benefits. Communication is easier. That feeling of isolation is gone. The group feels more cohesive. I think the only modification that could be made would be to create more isolated areas off to the side either for individual work or team meetings. And companies are doing that, although the private areas are moreso for meetings. But I hear that some are even making smaller areas just for individuals who need a few hours to focus on one task. > Code quality suffered because of the constant pressure to get things done now It takes some wisdom for managers to be able to properly apply Agile principles. Pressuring devs to spit something out without properly designing it is poor management practice. Its common, yes, but its still wrong. That's why Agile suggests a fairly wide range of time to deliver software (from two weeks to two months). Every piece of software is different, and it takes good people to determine the correct balance between release frequency and development time. You should prefer to release frequently, but if you're releasing garbage then what's the point?

vannevar 11y ago

Agile will be dead as long as it's the dominant management methodology and there are page-views to be had. It'll be replaced with essentially the same process but with different terminology. Long before the Agile Manifesto, when I was working at NASA, we talked about the reality that the state of knowledge about a project is at its lowest at the beginning, and that any realistic project planning and management process must acknowledge and accommodate that fact. Subsequent research has confirmed that human beings consistently underestimate complex tasks, and that this bias persists even with experience, so no matter what methodology you adopt, you will always be under unrealistic deadlines. This results in distortions to whatever process you use, and flaws in whatever product you produce, and these distortions and flaws will be blamed on your development process, since no one will accept that it's simply an unfixable feature of human nature.

kfunk 11y ago
Do you have any references to "subsequent research"? I am truly interested in digging deeper.
- hiou 11y ago
  I know that Code Complete 2 has quite a few discussions about the phenomenon of consistently missed estimates and many references about those. I would definitely look there for a starting point about the impossibility of successful estimation in software.
- vannevar 11y ago
  Daniel Kahneman's book "Thinking Fast and Slow" is a great overview of the field of cognitive bias. For a more academic treatment of his research, check out "Heuristics and Biases". The part of his work most relevant to project estimation can be found in the "planning fallacy" section. Aside from Kahneman, there are numerous papers on software estimation, many of which note these consistent biases (for example Jørgensen, https://pdfs.semanticscholar.org/fd87/d248dd55f59d8d93742fb3a7edc2d5bec2e1.pdf https://pdfs.semanticscholar.org/fd87/d248dd55f59d8d93742fb3...).
einrealist 11y ago

mindcrime 11y ago

Just to illustrate an example of how people are using the term "agile" wrong: If you ask around, you'll notice that (many|most) people equate "agile" with "two week sprints". But if you actually read the Agile Manifesto you find this: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Agile does not dictate that you use two week sprints. In fact, th term "sprint" itself is not even part of agile! The term "sprint" comes from Scrum, which is simply one specific methodology which claims adherence to the agile philosophy. But Scrum != Agile. Agile can also be XP, Crystal Clear, or AUP, etc.

bitwize 11y ago
Scrum is the easiest for management to grasp at a surface level so out of all the methodologies under the Agile banner Scrum is most readily and widely adopted. The problem is that Scrum "sprints" are like treating a marathon as 422 contiguous 100m dashes.
- mindcrime 11y ago
  The problem is that Scrum "sprints" are like treating a marathon as 422 contiguous 100m dashes. Yep. Or to put it another way, too many shops seem to think that you can "sprint" ALL THE TIME. And while it's "only a metaphor", it's a meaningful one in this case. You can't: sprint -> sprint -> sprint -> sprint -> sprint -> sprint -> ∞ You have to: sprint -> sprint -> breather -> sprint -> breather -> sprint -> sprint -> breather -> ∞ or something like that.
  - UK-AL 11y ago
    Sprints aren't sprints. Replace sprint with time segment. And you get more accurate picture.
    - mindcrime 11y ago
      Sprints aren't sprints. Except when they are. And just using that term encourages people to treat them like actual sprints, instead of just metaphorical sprints. This is why I advocate for use of the term "iteration" instead. But even then, I think it's important to include "slack" iterations that are for random bug fixes, miscellaneous refactoring, etc., that is developer driven, not business user driven.

wmt 11y ago

Agile and was indeed the OOP Design Patterns of the late 2000s. Sure, there's many smart things in it, and many of those will survive, but when consultants started selling cargocultish dance moves you have to do to succeed, and where all failures happened because you were just not pure enough, it became as awkward as AbstractsSingletonFactories.

shockzzz 11y ago

Does Agile really not work with large enterprises? Or is it more that "fake agile" doesn't work?

ssi1111 11y ago
Fake agile does not work. Large enterprises come with all their problems in processes, tools, skills, etc. They hear this new buzz word and latch on to it. They take this new thing to their teams and ask them to implement it. And all this while, the upper management just knows how to pronounce the word "Agile"; they have no clue what it means or the work needed to "implement Agile". So upper management is never in a position to help the teams. Most times, management does not want to change the existing tools, processes or grow people's skills. And so agile fails - because people want the benefits of agile without doing the work.
- Karunamon 11y ago
  I've got a coworker (absolutely brilliant fellow) who bristles whenever he hears buzzword-compliant terms like ITIL and Agile brought up anywhere near management. Not because those terms mean anything even remotely bad (in fact, he agrees with a lot of the philosophies), but because those terms come pre-loaded with a lot of baggage and preconceived notions by management, and saying that we have an agile-like process is just begging for some C-level with not enough work to do, to get involved and begin dictating requirements they don't understand. I doubted this until I saw it happen personally a couple of times. The process is completely, totally meaningless (and in many cases actively harmful), unless you also get the culture change to go with it.
mbesto 11y ago
Agile isn't binary in the sense that it either "works" or "doesn't work". Do enterprises adopt agile? Yes. Is it not "true" agile? Most likely yes. Can anyone equivocally determine what true agile is? No. Agile is what you make of it. The biggest thing holding back a "by the book" agile scrum implementation at enterprises is budgetary process. Business people, who own budgets, have an extremely hard time understanding why they can't build X for $Y, because there are few agile processes that help them clarify that.

einrealist 11y ago

"Agile is Dead" is like saying: Life sucks. Agile is a phenomenon with lots of different manifestations that try to do their best at embracing the Agile Manifesto. Yes there is hype and people who make money of it. But that hype is justified by many examples of successful Agile manifestations. Most important to Agile is to get it. To get into the mindset of feedback loops and collaboration. For larger companies with "non-Agile" habits, that is hard by default.

draw_down 11y ago
But also, agile is dead.
- Karunamon 11y ago
  Long live Agile?
askyourmother 11y ago
I hope 'Agile', as a product, with the capital A, that sells lots of worthless pulp fiction "how to" books, with dogmatic consultants propagating useless practices they neither understand nor can follow, well I hope that is dead. It was and is a cancer on the industry as a whole. I however hope 'agile' as a spirit of talking to your users, breaking down tasks into bite size deliverables, testing, and making sure things move in a generally agreeable direction, well, I hope that persists and flourishes.
- curiousGambler 11y ago
  Yes! Agile with a small 'a' is something I talk about at work too often. I don't want to be "Agile" but rather "agile" as in the definition of the word, "able to move quickly and easily."
- michaelbuddy 11y ago
  Agreed. It's interesting because we all know branding aside, feedback, frquent builds, communication is something you can't deny is a good thing. But it's not unfortunately hard to decouple enthusiasm for agile from a perception of zealotry.

deleted 11y ago

[deleted]

huherto 11y ago

> Agile is Dead. Ok. I listen. What is it wrong with it ? Then there is an endless list of links. I don't even know where to start. Impossible to argue against that. But I still don't understand what the author meant. So. If we just stick to the agile manifesto. Is there something wrong with it ? The worst part is that there is no proposed alternative. I kind of get the idea that the author still thinks big upfront design is the way to go. If he believes agile is no better than Waterfall. I can't agree with that. I would hate to go back to that.

JakeAl 11y ago
Since no one has posted it, Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value Individuals and interaction over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in items on the right, we value the items on the left more.
halhen 11y ago
One answer is by Simon Bennet. See https://vimeo.com/138060217 https://vimeo.com/138060217 , in particular 13:10-16:00

paulddraper 11y ago

LinkedIn's really on a roll here. 72 hours ago there was "The Lie That Has Beguiled A Generation Of Developers" (https://www.linkedin.com/pulse/lie-has-beguiled-generation-developers-richard-eng https://www.linkedin.com/pulse/lie-has-beguiled-generation-d...), and now there's this. I can't wait to see what's next. Maybe "The End of Programming".

herge 11y ago
It's not really LinkedIn, it's more their built-in blogging platform, pulse.
- vram22 11y ago
  Is their Pulse related to, or the same as, that startup called Pulse that was acquired a few years ago, and in the news?
  - jonathankoren 11y ago
    They are one in the same.
- paulddraper 11y ago
  Oh I didn't know LinkedIn hosted blogs. That makes me sense. Now I know what blogs are just sensational twaddle.
talmand 11y ago
Bah, as a front-end developer paying attention to my space I hear about "HTML/CSS/Javascript sucks and this is why" articles nearly every day. I'd rather these people tell me what they like and why; it would be far more productive use of time.
- dclowd9901 11y ago
  I'm a huge fan of the web as it is today, maybe I should write that article. But nothing gets you to click like, "everything you know is a lie."

spalt 11y ago

hurray!

feduzi 11y ago

But we're alive. Let's move on.

woah 11y ago

This guy is decrying a bunch of hucksters selling buzzwords to corporate managers with more money than sense. What's his solution? > If I were king, I would prefer to see a methodology using the (ISC)2 recommended practices in the SDLC, and the emerging OWASP practices, with more certifications like the CSSLP. The author apparently calls himself an "Enterprise Architecture Evangelist MSEA BSEE CEA³ CISSP-ISSAP PMP ITIL" I've got to chuckle. What does any of this even mean? And what does it have to do with writing good software?

buckbova 11y ago
What is CEA³? edit: Perhaps it is a certified enterprise architect "black belt" such and such from: https://www.feacinstitute.org/feac-courses https://www.feacinstitute.org/feac-courses Looks like all you need is 11K and 14-16 hours: http://www.tomsitpro.com/articles/enterprise-architect-certifications,2-640-6.html http://www.tomsitpro.com/articles/enterprise-architect-certi...
meddlepal 11y ago
I think all those letters are meant to test whether you can read letters or not. An eye chart if you will. It has nothing do with writing good software. I've seen these sprinkled about on titles before and I've just rolled my eyes in the past and will continue to do so in the future.
andor 11y ago
He's either a troll or lacks reading comprehension. The first article he links to is well summarized by this paragraph: "And, unfortunately, I think time has proven me right. The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products." (https://pragdave.me/blog/2014/03/04/time-to-kill-agile/ https://pragdave.me/blog/2014/03/04/time-to-kill-agile/) "Doing the right thing at any time" is still a perfectly valid principle, though.
jenkinsj 11y ago
Perhaps: MSEA (Master in Science of Engineering Awesome) BSEE (Binomial System Enterprise Engineer) CEA³ (Crack Enterprise Architect -to the 3rd!) CISSP-ISSAP (Calisthenic Infrastructure with Solipsistic System Paradigms - Isomorphic and Soporific System Accreditation Practices) PMP ITIL Pusillanimous Management Practices for Information Technology Inline Languages (or Pmpster IT for short)

binaryapparatus 11y ago

Good Riddance. While applying for jobs last year, I have seen huge difference between companies that demonstrate great pride in using Scrum and Agile and (insert any other buzzword here) and others that really understand how software gets developed. Software is and ever was product of art and skill. There are great ways to improve productivity, for instance I really like how kanban fits software development. On the other hand, using Scrum and sprints and what not is how non-tech HR person explains to the non-tech management how software should be developed.

talmand 11y ago
Seems to me that if you are a decently talented developer one would be able to adjust to whatever work methodology a company uses. It's a pointless thing to involve whether a candidate knows anything of the system currently in place. Every job I've worked has been different, some have even changed, and it's worked out fine enough.

dandare 11y ago

It is irrelevant if agile is dead until we have something to replace it with.

doingmyting 11y ago

Agile doesn't work in large enterprises because Dinosaurs still want to exist after the meteor-strike. Sorry we are not going back. No way in hell I'd go back to the waterfall model. I like shipping things my customers want quickly and easily to production rather than have some disconnected board member in their ivory tower tell me what to build and how to build it.

swagtricker 11y ago

Oh, look. Another PMP proponent who didn't _WANT_ any agile practice success rushing to quote everyone who has reflected on the fact that it isn't perfect. This guy kills his credibility with the "let's hold a rave on the grave of Agile, I'll bring the Molly" attitude. Also, he clearly never learned the secret sauce of "agile" that Scrum and modern proponents only pay lip service to because it doesn't "sell well": Fucking. Technical. Practices. I've spent over a dozen years now on teams that focused on a.) pair programming b.) test coverage and testability c.) CI (actual CI on one branch - not GitFlow B.S.) and d.) Close customer involvement. We shipped high quality, low bug software that made money for the businesses. Teams that fail to learn technical excellence leave 75% of the value of "agile" on the table, and 9 times out of 10 it's the fools in suits that won't 'let' them do it. As far as I'm concerned, big organizations can go to hell & keep failing over and over. As software becomes more powerful, 'we' don't need them: http://allankelly.blogspot.com/2015/10/software-has-diseconomies-of-scale-not.html http://allankelly.blogspot.com/2015/10/software-has-disecono...

DanielBMarkham 11y ago

You can't kill Agile because Agile doesn't mean anything. It's a marketing term. It's the place in the bookstore you go to buy books about cool stuff technology teams are doing nowadays. If I want science fiction, I go to the science fiction aisle. If all the science fiction sucks this week, I either buy something else or wait until next week. I've already established that I like reading science fiction. If I'm consuming material titled "Agile" that doesn't seem to work, or seems like a scam? I stop consuming that material. More will be along later. And just like in books, many times you have to take the book home and try it out to see if it works for you. I think there are some people who really, really, really want a magic bullet. They want an answer to life, the universe, and everything. And in so many fields, that just doesn't exist. These are some of the same people, by the way, who make Agile so terrible for everybody else. You gotta dial back the feverish adopter thing, whether you're for or against Agile, to make any progress in your career.

pg_is_a_butt 11y ago

hacker news is dead

vorg 11y ago

> DevOps is the next wave replacing Agile DevOps is about eliminating the decades-old division between development staff who control the programs and operations staff who control the data. By having "DevOps" staff who control both programs and data, businesses open themselves up to large-scale employee theft and fraud.

UK-AL 11y ago

The guy advocates CMMI in other posts which is a bureaucratic nightmare to work under. I think this guy isn't a developer, and fetishes over planning and really process driven development.

blue_dinner 11y ago

One of my last clients used scrum (I was a contractor). The boss ran a fortune 500 company during the day and decided to take everything she learned to run her own small 20-person company. Our standups lasted minimum 1 hour every day. Every Thursday we had a show-and-tell meeting, which meant going through everything we worked on and fixed (some of these meetings lasted 3 hours) and we also had a pre-planning and post-planning scrum meeting, each lasting 3 hours. At one point I was charging the company more for meetings than actual work (it was 70/30 meetings to work). I finally left when we added another 1-hour meeting on Fridays where we would just tell a joke, funny story, or something about our life. Since the majority of other contractors/developers on the team were from other countries (and didn't speak English very well), it was one of the most awkward situations I've ever encountered at work.

solarengineer 11y ago
Sad. It looks like the someone going through the motions without understanding the intent. In contrast, I've been part of agile teams where we were from three different timezones, had short standups (sometimes multiple times a day depending upon the need), and focused on delivering value.

PhilWright 11y ago

His account is a troll right? Anyone that lists under certifications... 'Winter Survival, Civil Air Patrol, Starting 1974' ...is impressed with certifications more than they should be. Or anyone that lists... '22% raise in one year, CDC' ...under Honors & Awards is surely making a joke?

hbcondo714 11y ago

We ended up implementing Scrumban [1] [1] https://en.m.wikipedia.org/wiki/Scrumban https://en.m.wikipedia.org/wiki/Scrumban

solarengineer 11y ago

Being "Agile" means being able to respond to change. For software, that means delivering high value, high quality working software quickly and frequently. One needs the fundamentals of short feedback loops, the ability and willingness to inspect and adapt, and collaboration and teamwork. Everything else - training, release planning, standups, story card walls, iterations - is all just the ceremonies and techniques that support these fundamentals.