1. 31
  1.  

  2. 14

    Questions (and answers) like this really ought to start with a definition of what they mean by “Agile”.

    The top voted answer appears to be critiquing a very rigid Capital-A-Agile methodology, but none of it comes through to me as a valid critique of a more general lower-case-a-agile methodology: deploy regularly, tight feedback cycles with users, integrate feedback.

    1. 10

      I guess these discussions are always a bit futile, because “Agility” is by definition a positive property. It’s a tautology really.

      Most criticism of agile methods are more focussed on a specific implementation (scrum at company X), and the usual response is “this is not true agile”.

      1. 7

        “this is not true agile” I’ve been guilty of this in the past. Agile is good, therefore if what you’re describing to me isn’t good then it’s not true agile.

        But after years of Scrum at various shops, sometimes under the guidance of pricey “Scrum coaches” consultants I’m totally burnt out and disillusioned by it.

        As you say agile is by definition positive but beyond this, I think there are still a lot of good ideas and principles in the early agile movement just not in the Scrum process itself (which doesn’t predate Agile) and what it has come to represent.

        1. 6

          I would define Agile as “follows the principles of the Agile Manifesto”. This implies a few things:

          1. The Manifesto devalues things like comprehensive documentation. This can be criticized and discussed.

          2. Scrum is only one possible instance of Agile. Not necessarily the best, maybe not even a good one. I would suspect that people discussed that to death already when Scrum was fresh.

          3. You can do Scrum without Agile. Scrum is usually defined superficially. This means there is a lot of room for variation including stuff which undermines the Agile intentions. Second, it helps the consulting business, because how could you get Scrum right except by oral teachings of certified people?

          1. 1

            The Manifesto devalues things like comprehensive documentation. This can be criticized and discussed.

            This aspect is a bit peculiar. Do they devalue software-documentation? (which is how I understood this principle). Or maybe it can be thought of a devaluation of a requirements-library/document. I came to terms with this principle in the sense, that it meant as an advice to avoid wasteful, up-front documentation, because clearly you cannot build a good product without documentation.

            1. 1

              From the manifesto:

              That is, while there is value in the items on the right, we value the items on the left more.

              It’s not “documentation doesn’t matter”, it’s “deliver something that works or your documentation is pointless”.

            2. 1

              The key bit of superficiality that reduces Scrum’s value is that people ignore the fact that Scrum does not mandate a process:

              It is the opposite of a big collection of interwoven mandatory components. Scrum is not a methodology. What is Scrum?

              Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum Guide

              They take the initial process guide, defined in Scrum as a starting point to test, reflect, and improve upon, and treat it as a big collection of interwoven mandatory components. It makes middle management feel good as they get to hold meetings, see progress, and implement a buzzword, but avoids all of the valuable parts of Scrum.

            3. 3

              Bertrand Meyer has some criticisms (and compliments) of the core ideas, especially user stories vs requirements.

              1. 1

                thank you for that link. Would prefer text over video, but if it is Meyer, I’ll try to make room for it.

                1. 1

                  Yeah, I feel the same way. He apparently has a book on the same topic, but I haven’t read it.

                  1. 1

                    okay, I haven’t watched it fully, but skipped over a few parts ,but I made sure to look at the user storeis and requirements parts. I am a bit torn on his view, because I can relate to his feeligns as a software user, that many times his user-story was forgotten and he attributes this to not generalizing them into requirements. However, I wonder if the lack of a requirements document is really the reason. Also, I think he must have forgotten how unusable a lot of requirements-backed software has been.

                    I share his sentiments on design and architecture work. However, good teams with good management have always made it possible to fit such work into the agile workflow. I attribute to agile consultants, that throughput and “velocity” have been overemphasized to sell agile, when it should much more be about building good products.

                    He lost me when he commented on test-driven development.

                  2. 1

                    His book is called “Agile! The good, the hype, and the ugly”, it’s brief, insightful, and well worth a read.

              2. 5

                I would argue that what you’re talking about there is more the consequences of adopting continuous integration and making deployments less painful, which one might call operational agility, but it has very little to do with the Agile methodology as such, at least from what I can see.

                1. 6

                  Nope. Having tight feedback cycles with users is a core principle of Agile. Continuous integration on its own has nothing to do with user feedback, and doesn’t necessarily cause responsiveness to user feedback.

                  1. 1

                    The Agile Manifesto does not mention tight cycles, only “customer collaboration”.

                    1. 2

                      the Agile Principles (you have to click the link at the bottom of the manifesto) make multiple references.

                      1. 1

                        Can you explain? I don’t see the words “tight”, “feedback” or “cycles” here http://agilemanifesto.org/principles.html

                        1. 1

                          Presumably: The main difference between collaboration with customers (vs contract negotiations) is that rather than getting a single document attempting to describe what the customer wants up front (feedback cycle = one contract) you continually work with them to narrow down what they actually want (shorter/tighter than that).

                          1. 1

                            the first principle, satisfy the customer through early and continuous delivery of valuable software, implies it. the third, deliver working software frequently, implies it. the fourth, business people and developers must work together daily, is an out-and-out statement of it.

                      2. 1

                        In my experience CI&CD is more useful for bugs than features. If you are coming from waterfall I understand where the connection between CI/CD and agile comes in.

                        1. 2

                          Regardless of your experience and opinion of utility, those strategies are core to Agile and have obvious analogues in other industries that Agile draws inspiration from. They aren’t unique or novel products of Agile, but I think it’s fair to say that’s how they reached such widespread use today. It’s definitely incorrect to say they have little to do with Agile methodology.

                    2. 3

                      After having been making the error of using the word “agile” in the latter generic sense for some time, I came to realize that pretty much nobody does it. When you say “Agile” business people automatically think “Scrum” and it works (still) as a magical incantation. When you try to talk about the actual merits of agile approaches (plural) they tend to phase you out and think you’re trying to look smart without knowing anything.

                      1. -2

                        The top voted answer appears to be critiquing a very rigid Capital-C-Communism ideology, but none of it comes through to me as a valid critique of a more general lower-case-c-communism ideology: democratic, common ownership of the means of production, state and classlessness

                      2. 7

                        I think it’s important to ask why Agile is so easy to screw up. We don’t want fragile software applications and certainly shouldn’t want fragile software methodologies either.

                        1. 2

                          imho if agile fails, it usually is because people applied some Agile workflow (like Scrum) while losing orientation of the goals these methods want to achieve. For example:

                          • User stories are unclear / badly written. This is probably a very overlooked problem, but I have seen it many times. Sometimes the wording is not understandable at all, or no acceptance criteria are defined, or they spell out the technical realization instead of the functional requirement, leaving no room tfor engineers to find a better solution / architecture for the change. The solution is to have good refinement meetings were devs read and challenge stories, ask questions, get the PO to remove implementation advice but add intent of functionality and demand proper acceptance criteria.
                          • Backlog is prioritized sloppily by the PO, this is especially harmful if it is done in a way that delays an initial break through of getting a prototype up and running.
                          • Confusing “Agile” for only planning the next two weeks. Doing scrum does not mean that you shouldn’t think about a roadmap or plan for the next year. However, it is important to plan on a much coarser level for long -term planning, and not stick to plans that are obsoleted by reality.
                          • Lousy estimation. Many people think estimation is about planning, and that is partially right. However, estimation is also an indicator for whether a story is well-written. If 2 devs estimate a different workload for a story, chances are good that the story is not clear on what should be done.
                          1. 2

                            Is Agile more or less easy to screw up than any other methodology? It could be that all methodologies are hard to follow; I remember reading that the most development popular process in practice (at 60% of those surveyed) was “no process”.

                            IME Agile mostly gets screwed up by not actually doing it - or by falling back to non-Agile as soon as anything goes slightly wrong. I suspect this is simply a case of people responding to their incentives; management is rewarded for claiming to adopt Agile, but has very little incentive to actually follow it.

                            1. 1

                              Probably more interestingly is what would be the alternative to Agile?

                              1. 3

                                Spiral, Chaos, Unified Method, OOSE, Rational Unified Process… there are few, and while some of them (looking at you RUP) are widely known to be terribad I don’t think all of the others can be dismissed out of hand. One of the challenges is that research into it kinda stopped (TtBoMK) after Agile went big.

                                1. 1

                                  When I read comments criticising Agile, I often feel that the commenters would rather like to work on their own plans, i.e. with a goal in mind, start implementing and provide a solution. So it would probably be unfair to dismiss all of these attempts as chaos, but from what I have seen it requires above-average people to work. If it works, the work shows all signs of Agility (prioritization, delivering increments, working software over documentation, people over processes, etc.).

                                  I have also seen truly chaotic development that was a pure waste. Also not pretty, and every time I read a critic of Agile, I worry that people would rather work this way.

                                  1. 2

                                    Chaos is a method inspired mathematical chaotic systems, not social chaos.

                                    1. 1

                                      ah, thanks for that hint.

                                      To summarize it seems that Spiral and chaos could be applied in any agile workflow as a method to prioritize backlogs, they seem to operate a bit on other levels than RUP/Scrum/Kanban.

                            2. 6

                              I worked at Facebook for around 15 months in 2014-2015, and what I saw there was self-organising teams, who valued working software over comprehensive (indeed in many cases any) documentation, and responding to change over following a plan.

                              They did not value customer collaboration over contract negotiation: many of the teams had no customer collaboration at all, valuing “we know what’s right and will build that” (there were posters saying “code wins arguments”, which I disagreed with) and “we will pick analytics metrics to represent our customers en masse”.

                              They did not uniformly value individuals and interactions over processes and tools. Many people did, many preferred a predictable work stream that they could plug away at, and some vocal egotists preferred interactions when it got them their way, and hiding behind process when it did not. When the thing you are working on is broken, you need to fix that clowntown right now because it’s basically stopping me working. When the thing I am working on is broken, why are you even talking to me and interrupting my flow? You should file a task, I’ll look at it later.

                              They had very capable continuous delivery processes supported by a very capable (and large) developer efficiency division. This supported a workflow where getting something out was incredibly quick (if you got lucky in code review), and then getting the inevitable bug fixes out would have to be just as quick. Coding standards were enforced by a combination of lint and culture, test coverage purely by culture. Some teams prefer to get something right before shipping it, some prefer to ship it then find out what right is, Facebook was definitely in the latter camp and it definitely worked for them.

                              I won’t go through all twelve of the agile principles individually, but will say that teams at FB (the ones I saw, when I saw them) probably practise eight of the principles and believe that they are practising ten. And yet they would identify with everything in the linked Quora answer and say that they are post-Agile. That’s partly due to the “capital A”/“lower case a” issue marked elsewhere. It’s also because FB leadership raised “the culture” to a capital C level, almost as tangible as if it were an Iain M. Banks novel. “The Culture” was a reason for doing things, a reason not to do things, a reason not to consider doing things, a reason to question why people who even suggested other ways of doing things were even working here (particularly on the employees’ channel in Secret), and a fragile artefact that defined what made working at Facebook so “super-awesome”. But most of all, it was unique to Facebook, and certainly couldn’t have been written down by a bunch of old (and therefore, presumably, not smart) guys back in the Myspace days.

                              Summary: Facebook is in many ways a very agile organisation, and many people working there would reject Agile.

                              1. 1

                                When the thing you are working on is broken, you need to fix that clowntown right now because it’s basically stopping me working. When the thing I am working on is broken, why are you even talking to me and interrupting my flow? You should file a task, I’ll look at it later.

                                Oh, my. seriously. I see this now as $WORK sputters and spirals.

                              2. 4

                                An awful lot of No True Scotsman surrounds Agile puffery, which raises the hackles of any sceptical developer immediately.

                                1. 2

                                  Waterfall didn’t work for you? You just weren’t doing waterfall right.

                                2. [Comment removed by author]

                                  1. 3

                                    here

                                    He is so “crazy” that one of his former colleagues has a totem that they use to mock him in his absence? Fascinating.

                                    1. 4

                                      I would just keep in mind that Michael is a member of this community when making comments like this.

                                      1. 2

                                        I think being skeptical is fine, and perhaps even warranted. However, the top level link /seems/ like a fairly reasonable read to me. Judge it on its content.

                                        1. 5

                                          I think the problem is he speaks pretty authoritatively despite his expertise being based on just his experiences, or his perception of his experiences. It sounds good, but a lot of things sound good and are only occasionally true, not always true.

                                          I used to think he was just idiosyncratic til I had an experience that contradicted his claims, and then he just said “wait til you enter the real world.” I’m actually a few years older than him I believe. He’s incapable of imagining that things may be different. Even if he were right, it’s a very rigid view that doesn’t account for contrary evidence. I’m wary of trying to learn anything from people like that.

                                        2. 2

                                          He showed himself to be pretty out there at Google, when he rage-quit with a particularly nutty letter to the entire company after not getting a promotion. Lots of bits of that letter were memes when I left Google (“I have T7-9 vision!”).

                                          1. 2

                                            He showed himself to be pretty out there at Google, when he rage-quit with a particularly nutty letter to the entire company after not getting a promotion.

                                            It wasn’t about not getting a promotion. I was marked down in “Perf” for speaking up about an impending product failure. (Naively, I thought that pointing out the problem would be enough to get it fixed. It was obvious to me what was about to go wrong– and I was later proven right– but I lacked insight into how to convince anyone.) I found out years later that I was put on a suspected unionist list. Needless to say, the whole experience was traumatic. There’s a lot that I haven’t talked about.

                                            The mailing list activity… I’m embarrassed by that. I did not handle the stress well.

                                            Lots of bits of that letter were memes when I left Google (“I have T7-9 vision!”).

                                            Isn’t it a sign of success, if people are talking about your mistakes several years later?

                                          2. 1

                                            Personally I think Michael O Church is a genius but I’m keenly aware that there’s a fine line between genius and madness. /u/churchomichael is not Michael O Church but seems to be another very intelligent writer but without the anger and national and international politics interest.

                                            1. 1

                                              doing some digging he seems….. crazy.

                                              I’ve had a lot of difficult experiences, some related to the political exposure that comes from being outspoken in a treacherous industry. I’ve needed treatment for some of the after-effects.

                                              Like, he got banned from Hacker News, and also Wikipedia.

                                              And Quora, too! Wikipedia I actually deserved; that was 2006 and I was being a jerk. The Quora ban was specifically requested by Y Combinator after they bought it.

                                              He just seems to spend an insane amount of time writing ranty comments/articles/etc online and not much else.

                                              It’s not that much of my time.

                                              See /u/churchomichael

                                              That’s not me. I’m as surprised as you are that someone would name his account in homage to me. There are also Reddit accounts (and even a subreddit!) that exist to mock me.

                                              Dude just seems to want to complain.

                                              No, I’d like to fix things, but the odds of that are very, very poor.

                                              He has 45 suspected sockpuppet accounts on Wikipedia

                                              Yeah, most of those accounts don’t exist. That’s a hit piece. I’m embarrassed by some of what I did on Wikipedia in 2003-6, but I never had 45 alternate accounts, though I did use so-called “role accounts” back when it was accepted.

                                            2. 3

                                              Businesses tend to derail software development practices because they tend to view it as “hip brand name for how we exert power over employees”.

                                              They will hang on to small pieces of a methodology as a cover for something else.

                                              For example they may weaponise “daily agile standup meeting” for micro-management.

                                              1. 1

                                                Exactly - this is the most dangerous thing about “Agile”. It makes software developers the least important and least powerful people in software development, when really we should be the ones controlling our own field.

                                              2. 2

                                                anyone with more than 5 years of experience is going to find it to be a dissatisfying way to work. There is no place for an actual senior engineer on a Scrum team.

                                                Not true, speaking from direct personal experience. Maybe some people don’t like working that way, but if that way is effective, then it’s on them to get over it. “Senior engineers” should be about filling the needs of the business, not about having the most polished plans.

                                                Second, if you carry this way of working on for months or years, you get a lot of technical debt and you get low morale.

                                                Not my experience. I’ve only ever seen “long-term” approaches introduce more technical debt. Continuous refactoring, the Agile approach, is the most effective way to minimise technical debt.

                                                Saying, “I was in the War Room and had 20 minutes each day with the CEO” means that you were important and valued. Saying “I was on a Scrum team” means “Kick me”. On the whole, Agile and Scrum expect you to put your career goals on hold, and people will tolerate that during an exceptional short-term crisis (that merits an actual sprint) but not in perpetuity.

                                                Eh. Agile expects you to contribute to the business, which is what businesses ought to reward. If you were looking to get a promotion to a position like “senior developer” or “technical architect” where you could be highly rewarded while destroying the business, then yeah, Agile expects you to give that up. I don’t think that’s unreasonable.

                                                Even for people who have nothing to hide– even for people who’d be strong performers in a more sane, relaxed, progress-over-rapidity organization– a surveillance state is an anxiety state. It sucks, and if you’re good at what you do, it’s insulting to have to justify days and sometimes even hours of your time

                                                That’s the opposite of my experience. You know what really sucks? Working on something for six months only to find out that what you’ve produced, technically elegant as it may be, is no use to anyone. Delivering something to an actual customer who will thank me for it every two weeks is a much happier way to work.

                                                Actual problem employees are already visible to the team and manager regardless of whether this nonsense is used. (In many organizations, nothing is done about them because the organization or circumstances may make them hard to fire, but that’s a separate issue.)

                                                If companies that use Agile consistently eliminate incompetent employees and companies that don’t use Agile consistently don’t, surely it’s fair to say that Agile is helping. And if Agile doesn’t make any difference to whether people get fired, why would it cause so much concern?

                                                When you start playing the perpetual-crisis/surveillance-state game of Scrum, you end up losing a lot of good people. Either they take the perpetual performance review seriously, get stressed out, and start to falter after a while; or they disengage and become minimum-effort players just trying to protect an income.

                                                Or you could just… not? I guess Agile makes the fact that even the best engineers have unproductive weeks more visible to management, but, well, that happens to be the truth; I don’t think concealing it from management is a good foundation to build a methodology on.

                                                You’d rather have the variable worker who has some home-run weeks and some false starts than the reliably mediocre one.

                                                That’s management’s choice to make. Either way, they should have the information they need to make that choice.

                                                There is, it turns out, an intrinsic positive correlation between the variability of work (or risk) and the value rendered.

                                                That’s the opposite of my experience. Doing the simplest, easiest, most obvious thing at every step turns out to be a lot more effective.

                                                The Scrum/Agile mess prevented people from working on what was actually important to the business

                                                Then something went seriously, badly wrong, because the whole point of Agile is that you demonstrate business value every two weeks.

                                                I’ve seen non-Agile destroy a business. Indeed I’ve seen a direct correlation between how Agile the places I worked were, and how successful the business was.

                                                the “Scrum” is project-specific and therefore time-limited: getting the project done (actually done, not “done” in some corporate sense) and scoring the client and getting a retainer means that people can relax.

                                                Most non-consulting businesses are still in the business of landing a small number of big contracts with clients. Delivering a big feature to your client and then relaxing a bit after is a cadence that exists in most tech companies. Even for a direct-to-consumer business it’s there to some extent.

                                                No one’s going to put his career goals on hold and work through of a bunch of feature-level tickets for months, just for an average salary or for 0.05% in equity.

                                                Again these “career goals”. I just don’t understand it. Working through feature-level tickets is how you produce value and how your company stays in business. Almost all non-feature-level-ticket roles add less value to the business, or even subtract value. That’s not a nice thing to want from your career even if your employer makes it an option.

                                                1. 1

                                                  Strange, Adwords revenue took off like a rocket only after they introduced scrum to the team.

                                                  https://www.alexanderjsingleton.com/google-adwords-the-art-of-scrum-quintuple-constraint/

                                                  Maybe big A Agile sucks, but scrum certainly made Google a shit ton of money .

                                                  1. 1

                                                    For a more mature perspective on agile and scrum. https://www.youtube.com/watch?v=ZrBQmIDdls4

                                                    1. 1

                                                      I want to know how “agile” (little ‘a’) folks are dealing with:

                                                      • R&D
                                                      • similar to above, on-boarding vendor or large open source stacks
                                                      • integration issues/break-fix
                                                      • cross-team dependencies