Ask New Question
Sign In
Quora uses cookies to improve your experience. Read more
Answered 178w ago · Upvoted by Dan Pham, works at Google and Stephen Kurtzman, former Director of Engineering at Google · Author has 1.5k answers and 13.6m answer views
Before I get into why this "Agile" stuff is horrible, let's describe where Agile/Scrum can work. It can work for a time-sensitive and critical project of short duration (6 weeks max) that cross-cuts the business and has no clear manager, because it involves people from multiple departments. You can call it a "Code Red" or call it a Scrum or a "War Room" if you have a physical room for it.
Note that "Agile" comes from the consulting world. It suits well the needs of a small consulting firm, not yet very well-established, that lands one big-ticket project and needs to deliver it quickly, despite changing requirements and other potential bad behavior from the client. It works well when you have a relatively homogeneous talent level and a staff of generalists, which might also be true for an emerging web consultancy.
As a short-term methodology when a firm faces an existential risk or a game-changing opportunity, I'm not opposed to the "Code Red"/"crunch time"/Scrum practice of ignoring peoples' career goals and their individual talents. I have in mind that this "Code Red" state should exist for no more than 6 weeks per year in a well-run business. Even that's less than ideal: the ideal is zero. Frequent crises reflect poorly on management.
Now, let us count the sins of "Agile" and Scrum in the more common corporate context, where they're permanent working arrangements.
Note that "Agile" comes from the consulting world. It suits well the needs of a small consulting firm, not yet very well-established, that lands one big-ticket project and needs to deliver it quickly, despite changing requirements and other potential bad behavior from the client. It works well when you have a relatively homogeneous talent level and a staff of generalists, which might also be true for an emerging web consultancy.
As a short-term methodology when a firm faces an existential risk or a game-changing opportunity, I'm not opposed to the "Code Red"/"crunch time"/Scrum practice of ignoring peoples' career goals and their individual talents. I have in mind that this "Code Red" state should exist for no more than 6 weeks per year in a well-run business. Even that's less than ideal: the ideal is zero. Frequent crises reflect poorly on management.
Now, let us count the sins of "Agile" and Scrum in the more common corporate context, where they're permanent working arrangements.
- It's a culture of terminal juniority. Product development and architecture aren't the programmer's job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level "user stories". This is OK for a junior who's learning the codebase and software engineering principles and may appreciate the guidance, but 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. The only way to move up is to become a "Scrum Master", a bullshit management role that involves responsibility without power. If you don't believe in this stuff yourself (and I don't) then you sure as hell don't want to move up into a role where you're responsible for enforcing it over people who technically answer to someone else.
- It's aggressively short-term, by design. These methodologies are designed for scrappy, unproven consulting firms that need to bear down and pass their first high-profile project. In that context, they probably work-- at the expense of technical debt and tired workers. There are two problems here. First, Agile/Scrum is the way that a consulting firm behaves when it's an underdog, but people who join large corporations do so because they don't want to be underdogs. They'd rather be a small part of something stable than a bigger part of something that no one else yet believes in. If they wanted that other deal, they'd be in tiny startups. 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. Senior engineers are quicker to go, because they usually want something meatier than filling out some other guy's "user stories".
- It has no regard for the programmers' career needs or desires. See the points above about Agile's short-term orientation. Now, people are willing to give up their career goals to pitch in on a short-term crisis, for two reasons. First, if it's genuinely important to the firm, then it does help their career to do so. Second, a story of having solved a genuine crisis under time pressure can be a career booster. 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.
- It's micromanagement. User stories and backlog grooming are there to control what the engineer works on. The absurdly frequent meetings (and so many different kinds of status meetings!) are to intimidate him into not slacking. The story points are there to track productivity (in some superficial, inaccurate way). The talk of "removing impediments" is code for "spotting slackers". 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, and to be jerked around if these estimates are even slightly displeasing to the "product owner".
- At identifying low performers, it has an unacceptably high false-positive rate. Let's not kid ourselves. The reason "Agile" is so popular is that it carries this mythology of spotting low performers immediately-- in two weeks instead of over months-- and giving objective cause to fire them. (Agile/Scrum is, in essence, a permanent PIP.) I've heard it put this way: "use Scrum to spot your Scum." The problem is that it also turns good workers into low performers. 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.) You don't need Scrum for that. 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.
- It punishes R&D, and it hurts the best engineers the most. Corporations tend to value reliability over total productivity. In terms of negative impulses on the company, the emphasis on reliability is correct. When it comes to being ethical, people who are unreliable are disastrous. In terms of positive impulses, you often care more about total productivity (averaged over a year, two years, maybe longer) more than reliability. You'd rather have the variable worker who has some home-run weeks and some false starts than the reliably mediocre one. There is, it turns out, an intrinsic positive correlation between the variability of work (or risk) and the value rendered. Agile and Scrum, however, single out and humiliate anyone who works for 2 weeks and doesn't have something to show for it. This means that there's no room to fail, thus no room to experiment. For senior engineers who already know that they can fulfill user stories and trivial features, this also means that there's no point in going to work.
- I have actually seen it kill companies. I can't get too specific here, but I could name a company (once valued over $1 billion) that, following a merger, got neck-deep in Scrum. It lost over 80 percent of its value. The Scrum/Agile mess prevented people from working on what was actually important to the business, and the insulting juniority of the regime pushed away senior engineers in droves. Between the talent bleed and the loss of the engineering organization's ability to identify and fulfill core business needs (since Scrum is all about engineers not thinking for themselves) it got into a state from which I am doubtful that it can recover. This is just one story of an engineering organization killed by Agile, but there are others. Given that the Googles of the world need senior talent to keep themselves running, you can see why they wouldn't want to use it. If you're the back office at a bank, you can take your chances on a senior-level talent bleed and try Agile. (You might even have that as a goal, if you need to cut costs.) You can always hire legacy rescue consultants (at $300/hour, which is chump change to a bank) to cover the mess, later. If you're Google, your problems are just too big to hire those kinds of consultants; losing your seniors can be calamitous.
- It's sold dishonestly. This stuff can actually work when you're trying to mobilize an "emergency team" around an ill-defined and evolving but time-critical target. It's hard to motivate smart people to put aside their career goals and specialties and bear down on a task that might spit out some hilariously unsexy work. But in a consulting shop, there are a few countervailing motivations that don't exist in typical corporate employment. First, 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. Second, consulting firms rarely give startup-style equity or options, but they are often more generous in profit-sharing than the hot startups, so senior talent is aligned with the success of the business and 3-6 weeks of grunt work doesn't seem so bad if you're going to get a performance bonus that could be 50% of your salary, and possibly a promotion to the partner level. Those factors don't exist in corporate IT or even in startups. 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. Where is the dishonesty? Agile/Scrum works in a temporary setting, especially when commanding a just-now-assembled "emergency team" with no clear manager. It also works for small consulting shops mobilizing around a do-or-die project. It doesn't work in a permanent context. It's my belief that the "Agile coach" consulting shops actually know that it's not sustainable. So why would they sell it as a permanent productivity-enhancer? Because almost no one would buy it if it were sold as what it was: something that works in the short term, does a lot of damage, and will require after-the-fact cleanup effort on the tech-debt and morale fronts. This isn't the first generation to invent "crunch time" or "war rooms", but this ideal of a permanent "sprint" is so appealing to eyes-on-the-scoreboard middle managers that it persists and it sells like it's made out of rainbows and kittens.
