8 ms·

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions ov

• baxtr 5y ago
  It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.
  • outsomnia 5y ago
    You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.
    • watwut 5y ago
      But agile project get effed where management is not messing into internal process too. Developers make agile into hell too.
    • brtkdotse 5y ago
      You can also flip that around. As much as devs try to disagree, technology is not a goal in of itself. Management is an abstraction on top of money in/money out and if in<out it doesn’t matter if you have the crispest tech, you’re going out of business.
      • yobbo 5y ago
        > As much as devs try to disagree, technology is not a goal in of itself Can you find one dev that has ever disagreed with this?
        • brtkdotse 5y ago
          I can find a ton of devs paying lip service disagreeing, but the second they utter “we need to rewrite this in…” the facade falls apart.
          • choeger 5y ago
            Management in turn doesn't pay any attention whatsoever to the technology. They have no idea how quality and productivity is influenced by outdated or poor choices or simply a lack of investment into maintenance. You need people that care about the how you do it as much about the why and the what. Everything else is going to be disfunctional rather soon.
            • sorokod 5y ago
              I would argue that technology is in general not management's responsibility, but resource allocation is. If you care about quality and productivity, please quantify those and present your findings in terms of tradeoffs.
            • Ma8ee 5y ago
              It’s part of your job to explain that to them. And you have to do it in business terms, that is, how it will impact budget and schedule for the project. And prepare for questions like “ok, you have convinced me that Kotlin is superior to Java, but you are the only one in the team with any Kotlin experience, and we have a rather hard deadline for this project in 9 months. Are you hundred percent sure that we will both manage to train the team and deliver in that timeframe? And you know Karl, who’s retiring in a few years, he doesn’t seem to be very eager to learn something new. And he’s a damn productive Java programmer.”
          • rgblambda 5y ago
            When I hear “we need to rewrite this in…”, it's usually because someone isn't familiar with the language it's currently in and wants to switch to the old language/framework they like best. I don't think I've ever actually heard someone trying to advocate for shiny new x just because.
    • smokey_circles 5y ago
      The air quotes sell it. It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does. Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners. Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. I absolutely hate how accurate that is because I always thought I was a big boy and I wouldn't need management if I just had "1 good tech idea". Docker had the philosophy. Now they are dying after losing the container wars. That's what happens when you have no idea what a product actually is... >but insist to intercept every decision Yes, because left to our own devices, developers will not contribute meaningful business value. There is a better way, evidently it's not agile, but it needs management's buy in, because well they're in charge (get over it in all honestly, none of us actually want the job, trust me). WE as engineers need to find a better way to engage management. But those of you who just grumble "management ruin everything" deserve the pain that such a divide causes and we need to stop wasting lifeboat's on that mentality please
      • sorokod 5y ago
        I agree and want to add that sometimes the devs are not very good at, well... "deving". It is very convenient then to shift attention to inadequacy of others.
      • denton-scratch 5y ago
        > Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. I beg to differ. A dev team doing agile, with a team leader who is a manager/dev, can definitely self-organise. The team leader interfaces with non-dev management, removes roadblocks, and in collaboration with the rest of the devs sets the direction for a sprint. You need this team lader role to keep the suits off your back, and to ensure the demands are achievable. Project managers used to be people who wandered around with GANTT charts, and signed-off expenses and timesheets. Very rarely, I worked with a PM who saw their role as removing roadblocks, and shielding devs from suits. Those few PMs were a delight to work with (this was long before the appearance of Agile etc.) > Yes, because left to our own devices, developers will not contribute meaningful business value. I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.
  • mmarq 5y ago
    The existence of coaches and scrum masters is the result of decisions of management, that see agile as a way of getting daily reports from the team through the daily standup. I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “improvement” we will get is millions of dead and injured. But for whatever reason we allow freshly minted certified scrum masters to lecture seasoned professionals on process, to organise 19 meetings a day to discuss the differences between scrum and agile and, in general, to unleash havoc and destruction.
    • AndyPa32 5y ago
      This is exactly what drove me off my last team. We were seasoned developers with a combined experience of more than 50 years, 25 of them in scrum. And we were assigned a scrum master that never worked in software development before, fresh of the scrum master training and was telling us in a very condescending tone, how we could improve ourselves and our team. That guy didn't know anything about software development, not anything about our problem domain and nothing really about our client or users. It was ridiculous.
      • walshemj 5y ago
        How can you even get a Job as a "scrum master" with no experience in development or the industry. You should collectively have just refused to work for them in this case.
        • wheelinsupial 5y ago
          The consultant that comes into your company decides to start by applying scrum to software development teams. Leadership likes this new approach and expands it to other departments. Now you have scrum masters who were previously accountants, marketers, HR, and other business domain experts. Consultant decides that it’s in the scrum coaching team’s best interest to let the scrum masters determine where they are placed. Scrum masters want to work on software because other companies pay more. All scrum masters converge to become involved in software teams.
  • klodolph 5y ago
    It’s easy to blame management but there are also good reasons for it. The naïve thing to do when you’re a manager is to manage more in response to problems. When you start out with an agile process, and you manage more / manage harder, you end up with no agile process at all. Scrum masters / agile coaches are very hit or miss. Just like managers, just like programmers. Management takes the blame because their failures have a larger blast radius.
• dragonwriter 5y ago
  I think the way the Manifesto and early community around it lent itself to this inversion is this: (1) The Manifesto is written in non-actionable terms. (2) Many of the same people that initially attached themselves to the manifesto were already pitching canned processes, that may have been the outcome of agile process where they originated but did not put the critical feedback mechanisms more prominently than the low-level processes. So, those became the actionable versions of “Agile”. It would be so much better if instead of the “X over Y” language, the Manifesto has spent a few words talking about how the less important things were subordinated to the more important ones. The weird thing is that continuous, bottom-up, empirically-based process improvement wasn't an unknown concept at the time the Manifesto was written. It wouldn't have been hard for it to reference more concrete, actionable, concepts and practices.
• pydry 5y ago
  The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are, frankly, ill-defined bollocks. The principles are better but still suffer the same problem. If the most efficient way to convey information in a dev team is face to face why don't you come over here and I'll whisper my pull request in your ear. Jesus. There's no point complaining about the perversion of a thing that was never very specific about what it wanted to be in the first place. Once people (especially managers) get specific about what agile means to them it turns out it means very different things to different people. This is entirely the fault of the originators. One benefit of Scrum (the catholic church to agile's christian sect) was that it was proscriptive and was specific. Unfortunately it's also a bit shit and its practitioner-priests LOVE to tell you that if it isnt working, well, You Probably Just Weren't Doing It Correctly.
  • g051051 5y ago
    > those hallowed commandments are, frankly, ill-defined bollocks. I wish I could upvote this more.
  • lrdswrk00 5y ago
    They’re purposely ill defined. The outputs they seek are emergent. You also belittle scrum for becoming too specific. Seems you’re still processing what to make of any of it. Knowledge work is immaterial and should have no prescribed rails or all you get is run of the mill outputs. It’s similar to business; billions have been spent investigating what technology or management style brought the biggest gains. The math quickly becomes so Byzantine there no meaningful conclusions. No matter how detailed our consciousness will let us imagine, there’s still one reality ruled by physics. Esoteric math may be correct in that it has the order of operations right, but that truth doesn’t give it any real influence on physical reality.
    • pydry 5y ago
• steveBK123 5y ago
  The problem is most agile followers take "Responding to change over following a plan" to mean Don't plan. So you have 100+ person organizations running in a direction quickly for 2 week sprints to find out what the new direction they are going to run once they get there.
• felipellrocha 5y ago
  This reeks of “no true scotsman” to me. They claim is the manifesto, but the author even makes the claim that his process allowed engineers “a month of time without management intervention (a sprint length of 4 weeks). The author being one of the original signers and creator of scrum. If that’s not following a plan over responding to change, i don’t know what is.
• walshemj 5y ago
  Exactly I did a couple of very early agile projects for BT in 94 One using RAD/DSDM and one using a waterfall design with a RAD development phase
• andrei_says_ 5y ago
  There’s a fascinating talk by Dave Thomas, one of the authors of the agile manifesto, speaking of the simple meaning of the manifesto and the insanity of the Agile Industrial Complex bureaucratic cult created around it. Agile is Dead - https://m.youtube.com/watch?v=a-BOSpxYJ9M https://m.youtube.com/watch?v=a-BOSpxYJ9M Here’s a blog post by him: https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html
• commandlinefan 5y ago
  The Agile Manifesto never came out and said so, but it only ever made any sense if you give up the idea of a fixed delivery date. Of course, the idea of a fixed delivery date for a software project never made sense in the first place, but you’ll have to pry that nonsense from their cold dead hands. Big-A “Agile” is an attempt to keep what they (think they) want… so it ends up being useless.
  • zugi 5y ago
    Or you can have a fixed delivery date, but not a fixed feature set. If a feature isn't ready by the release date, it gets pushed to the next release. If you deliver often as agile encourages, this is a fairly short delay.