Why “Agile” and especially Scrum are terrible

Agility is a good thing, no doubt, and the Agile Manifesto isn’t unreasonable. Compared to a straw-man practice called “Waterfall”, Agile is notably superior. Yet, so much of Agile as-practiced is deeply harmful, and I don’t really think that the Agile/Waterfall dichotomy is useful in the first place.

There’s a variety of Agile, called Scrum, that I’ve seen actually kill a company. By “kill”, I don’t mean “the culture wasn’t as good afterward”. Rather, I mean that its stock dropped by almost 90 percent in less than two years.

What is Agile?

Agile grew up in web consulting, where it had a certain amount of value: when dealing with finicky clients who don’t know what they want, one typically has to choose between one of two options. The first is to manage the client: get expectations set, charge appropriately for rework, and maintain a relationship of equality rather than submission. The second is to accept client misbehavior (as, say, many graphic designers must) and orient one’s work flow around client-side dysfunction.

Programmers tend not to be great at managing clients. We’re very literal people. We like systems that have precisely defined behaviors. This makes working with non-technical people harder for us than it needs to be, because we tend to take every request literally rather than trying to figure out what they actually want. Corporate Agile, removed from the consulting environment, goes further and assumes that the engineers aren’t smart enough to figure out what their internal “customers” want. This means that the work gets atomized into “user stories” and “iterations” that often strip a sense of accomplishment from the work, as well as any hope of setting a long-term vision for where things are going.

In general, people tend to create two types of jobs, whether inside a company or as clients when off-loading work. At the high end, they hire for expertise that they don’t have. At the low end, they dump all the stuff they don’t want to do. It’s probably obvious that one class of consultant gets respect and the other doesn’t. Mismanaged consulting firms often end up becoming garbage disposals for the low end work. Scrum seems to be tailored toward the body shops, where client relationships are so mismanaged that the engineers have to be watched on a daily basis, because they’ve become a dumping ground for career-incoherent work that no one wants to do (and that probably isn’t very important, hence the low rate and respect).


Violent transparency

There are a lot of workplace trends that are making the programming career extremely unattractive, especially to the sorts of creative, intelligent people that it’s going to need in order to fill the next generation.

Open-plan offices are the most egregious example. They aren’t productive. It’s hard to concentrate in them. They’re anti-intellectual, insofar as people become afraid to be caught reading books (or just thinking) on the job. When you force people to play a side game of appearing productive, in addition to their job duties, they become less productive. Open-plan offices aren’t even about productivity in the first place. It’s about corporate image. VC-backed startups that needed to manage up into investors used these plans to make their workspaces look busy. (To put it bluntly, an open-plan programmer is more valued as office furniture than for the code she writes.) For a variety of cultural reasons, that made the open-plan outfit seem “cool” and “youthy” and now it’s infesting the corporate world in general.

It’s well known that creative people lose their creativity if asked to explain themselves while they are working. It’s the same with software. Programmers often have to work in an environment of one-sided transparency. These Agile systems, so often misapplied, demand that they provide humiliating visibility into their time and work, despite a lack of reciprocity. Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories” and often disallowed to work on improvements that can’t be related to short-term, immediate business needs (often delivered from on-high). This misguided but common variant of Agile eliminates the concept of ownership and treats programmers as interchangeable, commoditized components.

Scrum is the worst, with its silliness around two-week “iterations”. It induces needless anxiety about microfluctuations in one’s own productivity. There’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. It just makes people nervous. There are many in business who think that this is a good thing because they’ll “work faster”. I’ve been in software for ten years, as a manager and a worker bee. It isn’t true.

Specific flaws of “Agile” and Scrum

1. Business-driven engineering.

Agile is often sold in comparison to “Waterfall”. What is Waterfall?

Waterfall is legitimately terrible. It’s a “work rolls downhill” model in which each tier of the organizational hierarchy picks off what it consider to be “the fun stuff”, and passes the rest down the line. Projects are defined by executives, design is done by architects, personal deadlines are set by middle managers, implementation is performed by the top-tier grunts (programmers) and then operations and testing are handed off to the lower tiers of grunts. It’s extremely dysfunctional. When people have a sense that all of the important decisions have been made, they’re not motivated to do their best work.

Waterfall replicates the social model of a dysfunctional organization with a defined hierarchy. Agile, quite often, replicates the social model of a dysfunctional organization without a well-defined hierarchy.

I have mixed opinions about job titles like “Senior” and “Principal” and the like. They matter, and I probably wouldn’t take a job below the Principal/Director-equivalent level, but I hate that they matter. If you look at Scrum, it’s designed to disentitle the senior, most capable engineers who have to adhere to processes (work only on backlog items, spend 5-10 hours per week in status meetings) designed for people who just started writing code last month.

Like a failed communist state that equalizes by spreading poverty, Scrum in its purest form puts all of engineering at the same low level: not a clearly spelled-out one, but clearly below all the business people who are given full authority to decide what gets worked on.

Agile, as often implemented, increases the feedback frequency while giving engineers no real power. That’s a losing bargain, because it means that they’re more likely to be jerked around or punished when things take longer than they “seem” they should take. It creates a lot of anxiety and haste, but there’s little of what actually matters: building excellent products.

Silicon Valley has gotten a lot wrong, especially in the past five years, but one of the things that it got right is the concept of the engineer-driven company. It’s not always the best for engineers to drive the entire company, but when engineers run engineering and set priorities, everyone wins: engineers are happier with the work they’re assigned (or, better yet, self-assigning) and the business is getting a much higher quality of engineering.

If your firm is destined to be business-driven, that’s fine. Don’t hire full-time engineers, though, if you want talent. You can get the best people as consultants (starting in the $200-per-hour range, and going up steeply from there) but not as full-timers, in an business-driven company. Good engineers want to work in engineer-driven firms where they will be calling shots regarding what gets worked on, without having to justify themselves to “scrum masters” and “product owners” and layers of non-technical management.

Ultimately, Agile (as practiced) and Waterfall both are forms of business-driven engineering, and that’s why neither is any good at producing quality software or happy employees.

2. Terminal juniority

Software engineering, unfortunately, has developed a culture of terminal juniority, lending support to the (extremely misguided) conception of programming as a “young man’s game”, even though almost none of the best engineers are young, and quite a few of the best are not men.

The problem with Agile’s two-week iterations (or “sprints”) and user stories is that there is no exit strategy. There’s no “We won’t have to do this once we achieve [X]” clause. It’s designed to be there forever: the business-driven engineering and status meetings will never go away. Architecture and R&D and product development aren’t part of the programmer’s job, because those things don’t fit into atomized “user stories” or two-week sprints.

As a result, the sorts of projects that programmers want to take on, once they master the basics of the craft, are often ignored, because it’s annoying to justify them in terms of short-term business value. Technical excellence matters, but it’s painful to try to sell people on this fact if they want, badly, not to be convinced of it.

I once worked at a company where a product manager said that the difference between a senior engineer and a junior engineer was the ability to provide accurate estimates. Um, no. That’s insulting, actually. I hate estimates, because they generate politics and don’t actually make the work get done faster or better (in fact, it’s usually the opposite).

The worst thing about estimates is that they push a company in the direction of doing work that’s estimable. This causes programmers to favor the low-yield, easy stuff that the business doesn’t actually need (even if bumbling middle managers think otherwise) but that is “safe”. Anything that’s actually worth doing has a non-zero chance of failure and too many unknown unknowns for estimates to be useful. Agile’s focus on short-term business value ends up pushing people away from the kinds of work that the company actually needs, in favor of each programmer’s real-time reputation management.

What this culture says to me is that programming is a childish thing to be put away by age 35. I don’t agree with that mentality. In fact, I think it’s harmful; I’m in my early 30s and I feel like I’m just starting to be good at programming. Chasing out our elders, just because they’re seasoned enough to know that this “Agile”/Scrum process has nothing to do with computer science and that it adds no value, is a horrible idea.

3. It’s stupidly, dangerously short-term. 

Agile is designed for and by consulting firms that are marginal. That is, it’s for firms that don’t have the credibility that would enable them to negotiate with clients as equals, and that are facing tight deadlines while each client project is an existential risk. It’s for “scrappy” underdogs. Now, here’s the problem: Scrum is often deployed in large companies and funded startups, but people join those companies (leaving financial upside on the table, for the employer to collect) because they don’t want to be underdogs. They want safety. That’s why they’re in those jobs, rather than starting their own companies. No one wants to play from behind unless there’s considerable personal upside in doing so. “Agile” in a corporate job means pain and risk without reward.

When each client project represents existential or severe reputational risk, Agile might be the way to go, because a focus on short-term iterations is useful when the company is under threat and there might not be a long term. Aggressive project management makes sense in an emergency. It doesn’t make sense as a permanent arrangement; at least, not for high-talent programmers who have less stressful and more enjoyable options.

Under Agile, technical debt piles up and is not addressed because the business people calling the shots will not see a problem until it’s far too late or, at least, too expensive to fix it. Moreover, individual engineers are rewarded or punished solely based on the optics of the current two-week “sprint”, meaning that no one looks out five “sprints” ahead. Agile is just one mindless, near-sighted “sprint” after another: no progress, no improvement, just ticket after ticket after ticket.

People who are content to shuffle mindless through their careers can work that way, but all of the really good engineers hate it when they go to work on a Monday morning and don’t know what they’ll be working on that day.

4. It has no regard for career coherency.

Atomized user stories aren’t good for engineers’ careers. By age 30, you’re expected to be able to show that you can work at the whole-project level, and that you’re at least ready to go beyond such a level into infrastructure, architecture, research, or leadership.

In an emergency, whether it’s a consultancy striving to appease an important client or a corporate “war room”, career coherency can wait. Few people will refuse to do a couple weeks of unpleasant or otherwise career-incoherent work if it’s genuinely important to the company. The work’s importance creates the career benefit. If you can say “I was in the War Room and had 20 minutes per day with the CEO”, that excuses having done grunt work.

When there’s no emergency, however, programmers expect their career growth to be taken seriously and will leave if it’s not. Saying, “I was on a Scrum team” says, “Kick me”. It’s one thing to do grunt work because the CEO recognized that an unpleasant task would add millions of dollars of value (and that he’d reward it accordingly) but doing grunt work just because you were assigned “user stories” and Jira tickets shows that you were seen as a loser.

5. Its purpose is to identify low performers, but it has an unacceptably high false positive rate. 

Scrum is sold as a process for “removing impediments”, which is a nice way of saying “spotting slackers”. The problem with it is that it creates more underperformers than it roots out. It’s a surveillance state that requires individual engineers to provide fine-grained visibility into their work and rate of productivity.

There’s a fallacy in civil liberties debates: the “nothing to hide” argument. Some people like to argue that invasions of privacy– by, say, law enforcement– are non-issues because they’re not themselves criminals. It misses a few key things. For one thing, laws change. Ask anyone who was Jewish in Central Europe in the 1930s. Even for respectable people, a surveillance state is an anxiety state.

The fact of being observed changes the way people work. In creative fields, it’s for the worse. It’s almost impossible to work creatively if one has to justify the work on a day-by-day basis.

Another topic coming to mind here is status sensitivity. Programmers love to make-believe that they’ve transcended a few million years of primate evolution related to social status, but the fact is: social status matters, and you’re not “political” if you acknowledge the fact. Older people, women, racial minorities, and people with disabilities tend to be status sensitive in the workplace, because it’s a matter of survival for them. Constant surveillance into one’s work indicates a lack of trust and low social status, and the most status-sensitive people (even if they’re the best workers) are the first ones to decline when surveillance ramps up. If they feel like they aren’t trusted (and what else is communicated by a culture that expects every item of work to be justified?) then they lose motivation quickly.

Agile and especially Scrum exploit the nothing-to-hide fallacy. Unless you’re a “low performer” (witch hunt, anyone?) you shouldn’t mind a daily status meeting, right? The only people who would object to justifying their work in terms of short-term business value are the “slackers” who want to steal from the company, correct? Well, no. Obviously not.

The violent transparency culture is designed for the most status-insensitive people: young, usually white or Asian, privileged, never-disabled males who haven’t been tested, challenged, or burned yet at work. It’s for people who think that HR and management are a waste of time and that people should just “suck it up” when demeaned or insulted.

Often, it’s the best employees who fall the hardest when Agile/Scrum is introduced, because R&D is effectively eliminated, and the obsession with short-term “iterations” or sprints means that there’s no room to try something that might actually fail.

The truth about underperformers is that you don’t need “Agile” to find out who they are. People know who they are. The reason some teams get loaded down with disengaged, incompetent, or toxic people is that no one does anything about them. That’s a people-level management problem, not a workflow-level process problem.

6. The Whisky Goggles Effect.

There seems to be some evidence that aggressive management can nudge the marginally incompetent into being marginally employable. I call this the Whisky Goggles Effect: it turns the 3s and 4s into 5s, but it makes you so sloppy that the 7s and 9s want nothing to do with you. Unable to get their creative juices flowing under a system where everything has to be justified in terms of short-term business value, the best programmers leave.

From the point of view of a manager unaware of how software works, this might seem like an acceptable trade: a few “prima donna” 7+ leave under the Brave New Scrum, while the 3s and 4s become just-acceptable 5s. The problem is that the difference between a “7” programmer and a “5” programmer is substantially larger than that between a “5” and a “3”. If you lose your best people and your leaders (who may not be in leadership roles on the org-chart) then the slight upgrade of the incompetents, for whom Scrum is designed, does no good.

Scrum and Agile play into what I call the Status Profit Bias. Essentially, many people in business judge their success or failure not in objective terms, but based on the status differential achieved. Let’s say that the market value of a “3” level programmer is $50,000 per year and, for a “5” programmer, it’s $80,000. (In reality, programmer salaries are all over the map: I know 3’s making over $200,000 and I know 7’s under $70,000, but let’s ignore that.) Convincing a “5” programmer to take a “3”-level salary (in exchange for startup equity!) is marked, psychologically, not as $30,000 in profit (which is tiny) but as a 2-point profit.

Agile/Scrum and the age discrimination culture in general are about getting the most impressive status profits, rather than actual economic profits that would be attained, usually, by hiring the people who’ll deliver the most value (even if you go 50% above market rate, because top programmers are worth 10-30 times their market rate).

The people who are least informed about what social status they “should” have are the young. You’ll find a 22-year-old 6 who thinks that he’s a 3 and who will submit to Scrum, but the 50-year-old 9 is likely to know that she’s a 9 and might begrudgingly take 8.5-level conditions but she’s not about to drop to a 3, or even a 6. Seeking status profits is, of course, useless. These points don’t mean anything. You win in business by bringing in more money than you pay out in costs, not by exerting margins in meaningless status points. There may be a whole industry in bringing in 5-level engineers and treating (and paying) them like 4’s, but under current market conditions, it’s far more profitable to hire an 8 and treat him like an 8.

7. It’s dishonestly sold.

To cover this point, I’m going to focus on Scrum. Some people argue that Scrum is “extremist Agile” and others say that it’s the least Agile variant of Agile. (This, perhaps, underlies one of the problems here; we can hardly agree on what is and is not “Agile”.)

Something like Scrum has its place: a very limited, temporary one. The dishonest salesmanship is in the indication that it works everywhere, and as a permanent arrangement.

What Scrum is good for

Before the Agile fad made it a permanent process, “Scrum” was a term sometimes used for what corporations might also call a “Code Red” or a “War Room emergency”. If there was an unexpected, rapidly-evolving problem, you’d call together your best people and form a cross-cutting team.

This team would have no clear manager, so you’d elect a leader (like a “Scrum Master”) and give him authority. You’d want him not to be an official “people manager” (since he needs to be as impartial as possible). Since the crisis is short-term, individuals’ career goals can be put on hold. It’s considered a “sprint” because people are expected to work as fast as they can to solve the problem, and because they’ll be allowed to go back to their regular work once it’s over. Also, in this kind of emergency, you need to make it clear that no one is being evaluated individually. The focus is on the mission and the mission only.

When you impose process and demand one-sided transparency of all the workers, people feel watched. They get the sense that they’re being stalked and will be labelled “low performers” as soon as their week-by-week, individual fluctuations go the wrong way. So they become resentful. That’s dysfunctional. On the other hand, when you call together a group of known high-performers to handle a specific and time-limited crisis, they don’t mind giving frequent status updates so long as they know that it’s the exigency of the situation, rather than their own low social status, that is the reason behind it.

There are two scenarios that should come to mind. The first is a corporate “war room”, and if specific individuals (excluding high executives) are spending more than about 4 weeks per year in war-room mode, than something is wrong with the company, because emergencies ought to be rare. The second is that of a consultancy struggling to establish itself, or one that is bad at managing clients and establishing an independent reputation, and must therefore operate in a state of permanent emergency.

Two issues

Scrum, in this way, acknowledges the idea that emergency powers must sometimes be given to “take-charge” leaders who’ll do whatever they consider necessary to get a job done, leaving debate to happen later. That’s fine. It’s how things should be, sometimes.

A time-honored problem with emergency powers is that they often don’t go away. In many circumstances, those empowered by an emergency see fit to prolong it. This is, most certainly, a problem with management. Dysfunction and emergency require more managerial effort than a well-run company in peace time. The result is that there are many managers, especially in technology, who seek out opportunities for emergencies and emergency powers.

It is also more impressive for an aspiring demagogue (a “scrum master”?) to be a visible “dragonslayer” than to avoid attracting dragons to the village in the first place. The problem with Scrum’s aggressive insistence on business-driven engineering is that it makes a virtue (“customer collaboration”) out of attracting, and slaying, dragons (known as “requirements”) when it might be more prudent not to lure them out of their caves in the first place.

“Agile” and Scrum glorify emergency. That’s the first problem with them. They’re a reinvention of what the video game industry calls “crunch time”. It’s not sustainable to work that way. An aggressive focus on individual performance, a lack of concern for people’s career objectives in work allocation, and a mandate that people work only on the stated top priority, all of these provide a lot of value in a short-term emergency, but become toxic and demoralizing in the long run. People will tolerate short-term losses of autonomy, but only if there’s a clear point ahead when they’ll get their autonomy back.

The second issue is that these practices are sold dishonestly. There’s a whole cottage industry that has grown up around teaching companies to be “Agile” in their software development. The problem is that most of the core ideas aren’t new. The terminology is fresh, but the concepts are mostly outdated, failed “scientific management” (which was far from scientific, and didn’t work). Again, these processes sometimes work toward hitting well-defined targets in emergency circumstances, but permanent Scrum is a disaster.

If the downsides and upsides of “Agile” and Scrum were addressed, then I wouldn’t have such a strong problem with the concepts. If a company has a team of only junior developers and needs to deliver features fast, it should consider using these techniques for a short time, with the plan to remove them as its people grow and timeframes become more forgiving. However, if Scrum were sold for what it is– a set of emergency measures that can’t be used to permanently improve productivity– then there would be far fewer buyers for it, and the “Agile” consulting industry wouldn’t exist. Only through a dishonest representation of these techniques (glorified “crunch time”, packaged as permanent fixes) are they made salable to the corporate world (“the enterprise”) at large.

Looking forward

It’s time for this culture of terminal juniority, low autonomy, and aggressive management to die. These aren’t just bad ideas. They’re more dangerous than that, because there’s a generation of software engineers who are absorbing them without knowing any better. There are far too many young programmers being doomed to mediocrity by the idea that business-driven engineering and “user stories” are how things have always been done. This ought to be prevented; the future integrity of our industry may rely on it. “Agile”, at least as bastardized in every implementation that I’ve seen, is a bucket of nonsense that has nothing to do with programming and certainly nothing to do with computer science. Business-driven engineering, in general, is a dead end. It ought to be tossed back into the muck from which it came.

1,050 thoughts on “Why “Agile” and especially Scrum are terrible

    • Not SCRUM itself is evil but the evildoers are evil. A developer not filing refactoring user stories or a product owner writing detailed technical instructions without discussion are not a proof of failed principle but of misunderstood roles/ responsibilities. Also if a participant of backlog grooming feels like his overwhelming creative force is not necessary is maybe part of the wrong project. Sometimes technical interfaces don’t need as much CSS3 as one might be able to deliver and maybe a 10th login form is technically no rocket science one wants to be part of.

      • riiiiiiiiiiight… First, business owners will spend tons of time bemoaning their lack of progress on non-feature work, and frequently carry the day with executive management (I’ve observed this directly, to my comment is NOT theoretical). The infernal visibility given by agile process doesn’t allow for good managers to do the proper work of laying down a good bedrock of preparation for the near term future.. its just stay on the hamster wheel and hope things go well..

        And technical debt is generally magnified in these situations.. rarely is there time to ‘do the right thing’.

        And finally.. get someone who is a behavior problem, with managment that is less that stellar (the norm), and you’ve got a terrorist in your org who creates tons of problems and solves few.

        I don’t know how old you are, but I’m guessing not very. I’ve spent 30+ years in the industry, 13 as a manager.. scrum is a disaster, and its religious adherents are at best brain damaged useful idiots. The sooner everyone wakes up, the better.

        • I would say religious adherents of anything or any methodology in this case are at best brain damaged useful idiots. You would not use hammer, nor small screwdriver for everything, yet they both are very useful.

        • Second comment in as many hours but with respect to the OP picture this:

          You are the performance tester on a mobile banking application project which is being run as scrum/agile. The stack consists of web services, ESB layer down to an (awesome) mainframe. The project is due to go live in 2 weeks and business (I.e marketing) are really driving it. First peak load test I submitted this thing to chewed up 340MIPS -mainframers and I agreed very quickly that this was a no-go. In the scrum meeting there were 2 key issues: 1.how do we bundle the font into the application so it looks the same on everyone’s handset, and 2: do we really want the Ui to have a glass effect look? The performance issues only become important AFTER someone had suggested the bright idea of simply cutting the. Link to the mainframe at peak load – the upshot would be people hitting the app over and over again placing more load on the rest of the infrastructure and bring that down instead. The problem and he solution were simple and just required the engineer and I to work together however so much time was wasted in in crisis stand ups discussing fonts …

      • No. Scrum itself is a problem, as was well-argued in the article. People implementing cargo-cult Agile, or doing what they did before but with Agile labels rather than the old ones make the problem worse.

        A handful of anecdotes by you do not prove your point.

          • Insisting that his conclusion or assertion is wrong because he makes a fallacy is a fallacy referred to as “argument from fallacy”. I don’t think he’s wrong. I think he can be a bit ad hominem, but I don’t think Scrum works.

            • scotthmccoy didn’t insist that the conclusion was wrong. He said that the logical fallacies indicated that the author has more of an axe to grind than a sound argument to make. Seems fair. This blog has little to no evidence that Scrum is “terrible” and instead is full of conjecture and personal anecdotes.

              • The author’s points and views are the result of his personal experiences. In that regards, you can’t really say he’s right or wrong. Any methodology is only as good as the people in charge of making it work. If you have inept people in charge, you’re going to have problems. I think that’s really what most people should get out of this. Anything can be corrupted if done incorrectly.

                • Where are the numbers ? When you write “There’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run”, you must have a way to point at studies showing that. Without this, it’s only anecdotes. You have yours, I have mine. If they prove nothing for scrum, then surely they prove nothing against it.
                  So a company lost 90% of its value allegedly because it suddenly started practicing agile ? Another won the same while practicing agile.

                  Thus, I can’t say whether the author is wrong or not, but I can definitely say that if he is right, it’s only luck of the draw.

                  • The author made the counter claim that there is no evidence that says agile or scrum is “better”(more productive, higher quality, better at managing technical debt, etc.). He didn’t say it was bad or good, just that the claims others have made have no proof. Agile is gods gift to programming is essentially the preexisting condition whole article is addressing.

                    The burden of proof is on the ones making the original claims that the author says there is no evidence for. All one must do, is provide 1 set of empirical evidence to prove agile is “better” and the author is wrong. It is an easier and more realistic condition to prove.

                    The claim: “Agile methods are superior to other project management methods”
                    Assumption implied: the claim is true because it has not been proven false
                    Logical fallacy: argument from ignorance & anecdotal fallacy

                    One might say the author also makes a bold claim of his own. However, it is clear that is not the case, rather, he is challenging the claims of others, and rightly so for a field that is supposed to be an applied science.

                    • It’s not too useful though unless he has some concrete alternative that is proven to work rather than something equally unproven. Also, you explained the problem very nicely in a few short paragraphs. The OP on the other hand makes lots of subjective claims about agile that are not facts IMO – unnecessary really – if he just wants to make the point you made. Furthermore, there are an infinite ways in which scrum/agile can be interpreter and implemented – more reason to avoid making hard claims and counter-claims.

          • Main point is very simple though:
            Scrum is bad because it revokes right of self-organization from talented people and instead grants it to people who has very little idea about creative work in general and engineering in particular.
            Where logical fallacy is?

        • I agree with you that cargo-cult agile gives agile a bad name.

          Perhaps the OP is bemoaning that there are too many cargo-cult agile environments. (Maybe all his experience with agile is with cargo-cult agile environments.)

          I think the biggest problem with companies trying (and failing/flailing) to do Scrum is that Scrum is an agile management practice. It’s not something that the developers “do”; it’s something that the management does… changing its management process. Developers will do whatever cockamamy process management is foisting upon them. Those developers who are fed up with that process can vote with their feet (which I’ve done once, at one company, that was “agile… in spirit” which is a euphemism for being not agile whatsoever).

          I always see Scrum fail when management itself refuses to embrace Scrum, which is a direct result of management failing to realize that their processes need to change.

          Empowering developers to be able to embrace agile software engineering practices (TDD-style unit testing, pair programming, continuous improvement, yada yada) would even be better, but is not really part-and-parcel of Scrum.

          How hard is it do try Scrum? Kelly Waters laid out the 10 simple steps to adopt Scrum, back in 2007… http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps/ . It looks easy.

          After having been in 3 different (self-designated) Scrum shops in the past 10 years, every one of them has ultimately succeeded-to-fail to achieve Scrum or agile. Best intentions, road to hell, yada yada.

      • My experience with refactoring stories is they sit in the backlog for a couple years until someone looks at it and decides to close it. Refactoring just isn’t a priority to the business.

        • If you make it a priority even just within the IT dept, I’ve found the best way to refactor is to do it as you work stories rather than create PBI’s that are simply for refactoring. Bake it into your estimates even. As you touch various areas of the code you end up refactoring substantial %s. But I can see I’m in hostile territory here so carry on.

            • As I’ve become more senior developer, I never ever consider quick and dirty solutions to business people who never understand the risks of ever growing technical debt and unmaintainable code and architecture. If the budget of the project doesn’t leave much breathing room for quality development then I’d rather not do it at all.

            • You are making the author’s point. To do refactoring, you need to do it under cover of some user request. You need to hide it, or justify it by claiming that the code is impossible to fix otherwise. Which typically isn’t true; typically, refactoring is the best approach for the long haul but cannot be justified within the context of this iteration’s user story.

              • We always allocate at least 3 points per Sprint to do re-factoring. The devs decide which pieces of code are the highest priority and work their way down through the tech debt backlog Sprint over Sprint. Sometimes, we do de-prioritize tech debt, if the team says that we don’t have any high priority tech debt stories and we use the points to focus on something else that’s higher priority. We learned the hard way over 3 years, that if we didn’t reserve time for tech debt, the tech debt backlog would get huge and we’d start to see code failures, so the lesson learned by the teams and trickling upstream to management, was don’t let the tech debt backlog fester.

                When Scrum works, it’s because everyone on the team does have a voice and management empowers their teams to do a good job, not just get the next bottom line and the next bottom line done, at all costs.

      • Agile/Scrum:
        If the evildoers are evil then why give the tool to the evildoers ??
        All the pressure are put on the software engineer’ heads.
        Even factory workers are not treated like that.
        The engineers/developers should take legal actions on organizations
        who use these inhumane methodologies.

    • I quite agree. I’ve seen agile at a number of companies.. and it all devolves down to exactly what is described in this article.

      To be fair, some portions of agile are VERY useful (as a manager at a very large Software concern, we introduced short release cycles and it worked VERY well for us.. ).

      The big common denominator is good vs. bad management. Good management will root out the evil parts of Scrum very quickly and get on with their normal business. This is because good management always converges on what works best for their specific problems. The overarching issues is that most managers aren’t GOOD managers. And they grab onto process thinking its a silver bullet.. BUT IT ISN’T.

      I’ve managed under waterfall, managed under scrum.. both can work if your intelligent about doing what is required for your problem, and skipping stuff that doesn’t work.. I just wish I could figure out how to train folks to be good managers. I know the elements required, but few are willing to follow them..

      • ” I just wish I could figure out how to train folks to be good managers.”

        I have been developing software for 30 years. I once worked for a manager that could actually manage (rather than hinder, bully and interfere) for all of 6 months.

        • Thing is, if you have a good team, they don’t need a process.

          Sorry, that is so not true! If you have a team producing code for any significant task, they will have to have a process in order to work together on that task. The processes might not be very heavyweight, but they will be there. That will be true for and SDLC, agile or not.

        • I agree with this comment fully. The most efficient team I ever worked with was only a handful of talented developers and we didn’t need all of the middle-management to get things done.

          • Craig, I have the same memory from my career. I worked for a company that had a six person team of developers that created, updated and maintained a medical billing and scheduling system. We were rated ‘best of breed’ in our niche every year. Our users and VARs sent us presents at Christmas. We were then purchased by a large company and the team was expanded to 30+, including offshore workers. We were then processed and micro-managed to death with the result that we did less and did so very badly. And some of our formerly happy customers initiated lawsuits against us. Small focused teams that have a shared vision do not really need much process or management to succeed.

      • that was pretty much what I was about to say. It has to do with people less than process. Strong, good managers will find success and root out incompetence and inefficiency no matter what system they are working within. In that regard, Scrum just seems to be more of a handicap to them using their strengths to the benefit of the process, because they are being forced into someone else’s process.

        Maybe Scrum is useful in helping squeeze a little bit more effectiveness out of poor managers working with a poor team, but a good manager kinda by definition generally succeeds at management… without need of spiffy pitched “management systems” that sell the idea that the same prescription eyeglasses is appropriate for anyone with sight issues.

    • “Probably the best written blog post about Scrum in a long time.” At last an intelligent, independent view of scrum that reflects most of my sentiments around this toxic process.

    • While I agree with most of what the author says I think he throws the baby out with the bathwater and misses a key root cause.
      Agile was created by commercial IT folks who believed Waterfall was the problem. While Waterfall does have issues the problems were lack of best practice use and under bidding/estimating. Commercial IT rarely uses best PM or software development best practices. This, to the authors point, makes Agile worse. The reason for that is that the usual inexperienced and/or unscrupulous IT dev manager bastardizes the practices even more and eliminates upfront scope, cost and schedule due diligence. This results in no project level data for any oversight. Thereby allowing for eternal software development work based on almost zero cost, scope or schedule accountability. Having said this Waterfall can suffer from trying to know too much upfront and being boxed in by that. Given this my suggestion is to use a hybrid. A best of both approach to mitigate the weaknesses of the other. A DSDM like with actual best practice use. Those being for example – EVM, WBS, schedules with dependencies and critical paths shown, productivity, defect density, rework and scope volatility metrics, root cause data, RTVM etc.

      • Agile was entirely created by people who decided that “submission” (very well termed by the author) to the client was the only reliable way forward since finding people who can operate effectively without total submission is difficult. All of “waterfall”‘s shortcomings can be explained away in exactly the same way “agile”‘s shortcomings usually are – “you’re doing it wrong.” To an extent, that’s usually true – but it doesn’t mean you’re not following the methodology properly, it usually means you’re applying the wrong methodology to a particular project.

    • nicely written article. thanks for enunciating clearly some of the things that just seem wrong with agile/scrum from the outset, without knowing exactly what it is, besides the laughable little techniques like system analysis/design for dummies. anyway, wanted to point out that waterfall is often mislabelled as a analysis and design methodology when it’s actually a particular AD project management cycle, one of many. Most of the time “waterfall” should be replaced with “structured analysis and design” when comparing to agile etc. Structured A/D is purely focused on methodologies/tools, i.e. requirements analysis, document current system, design conceptual new system..part of which is DFDs, data dictionary, ERD, CRUD analysis, pseudo code and finally code…and all the design documents can be manually or sometimes automatically cross-check. Waterfall is the project management of the whole AD process in a strictly linear fashion, which it has been always accepted as being only purely hypothetical, as real projects are never actually driven like that. Somewhat waterfall like design cycle is desirable, as opposed to the agile chaos, as discovering requirements later costs much more to implement instead of when requirements known early.
      I’m of the view that even agile might be better than nothing or the crazy local inventions for design methodologies. The dumbing down of the workforce is a desired outcome by some organisations…keeping good engineers out of management…for the horrors they would discover.

      • Ya… among the many other things I would have to agree with in posts above, the whole problem of people winding up in management positions that clearly have no business there and no idea how to effectively manage either people OR processes is part of what gets industries into the market for things to try to fix that which could be fixed by simply using better hiring and placement practices.

    • what more could you want as a middle-level know nothing manager than a system of control of compliant and non-thinking underlings, whilst you get on with the job of politics to drive your career? fill in some spreadsheets of garbage to document your sprints and you have plenty of time in the day. btw waterfall is a project management cycle for A/D, usually mistakenly compared to Agile when they actually mean Structured A/D. Waterfall cycle always accepted as purely theoretical…in any case it’s always better to do analysis before design, despite people promoting contrary via Agile speak.

    • I’ve been agonizing over Agile for a couple years now, thinking I must be losing my mind. As a somewhat seasoned software designer I feel this pain every day now and I just want my autonomy back. Agile has managed to suck the creativity right out of design. What I do now looks something more akin to Customer Service Representative. I ask myself every day how this came to pass and how I can get back the career I got into in the first place.

      • For about 3 years I had the unique opportunity to pick anything we like fro Agile and do or not do. Like happy children we tried Scrum elements, and found out only a few things really work.

        Biggest benefit not the short planning sprint, but the result from it – a vertical release of the stack, as much as possible. This created a space of navigable release artifacts for selection from other stakeholders: QA would binary search the assemblies to find when we introduced a degradation, Ops would pick up to upgrade a customer up to a version we ha a fix for in already, Sales would pick a version that had their thing to demo. We as devs can always go back in our stream and rerun some tweaked test. Investing in automation and comparative testing added trends and graphs of various qualities (memory, CPU usage, coverage, resilience, and so on) of the release artifacts dimension.

        Other elements from Scrum that we found useful, here and there.

        Standups, but not every day, too intrusive. 2 stand ups a week worked well to catch up and have the ‘aha, you do this, I can latch and do something with this too’. With remote workers it is more of psychological, see their faces, hear their voices. We do not do guilt trips or blame games.

        Regarding estimation, mind that the team prioritized, the business influence only landed tickets/stories, and we would order and say roughly when we can work on them. We found departing from time-based estimation to using relative Fibonacci, helped a lot get a general idea of who thinks what regarding the size of things. If we overflow to the other sprint (Kanban style), no big deal. Moving away from time-based estimation really reduces stress from a ‘promise’ to finish in N days. Things usually intertwine, and the completion date moves, while the total amount of work may have stayed the same. So with Fibonacci we would more or less get an idea whether we try to bite to many big pieces in the next weeks.

        Then, a large corporation purchased us, enforced formal Scrum and work stopped being fun. Lost 90% of the seniors in under a year and the half. Enter the juniors.

        • I’ve been doing scrum for a few companies both start ups and large organizations. I have seen it be very effective and also a trainwreck.

          Here’s what I’ve learned:
          Each team is different.
          Each team needs to decide what their processes will be.
          The Product people need to be willing to adjust their approach to the development team’s needs
          The Scrum Master needs to empowering everyone AND keep everyone accountable.
          Accountability goes both ways. The developers need to be able to call the business on their shit, and the business needs to be able to call developers on their shit (this is what the Scrum Master should do). We are all professionals, we should respect each other’s opinions. I had a Scrum Master that would shut me down in sprint planning if I didn’t have the business value defined.
          Story point estimation is effective if you are willing to measure it and discuss it in retrospective. How long are you actually working on a 3 point story vs an 8 point story. “Why do we keep having 3’s that take longer than 8’s? We keep estimating stories using that involve Angular.js as 3’s, but we have a problem with Angular. We should fix our angular integration, or rip angular out…”

          Scrum processes are as iterative as development. You focus on what works and you quit doing what doesn’t work. Keep cutting the process fat and in 3 months you’ll end up with something that everyone is comfortable with.

          This is hard in large corporations but those managements issues go much higher than middle management. The finance team has the same issues. The sales team is being micromanaged. The customer service is micromanaged. Thats more of the problem IMHO than “scrum”. If you are stuck in that situation RUN. RUN FOR YOUR PROFESSIONAL LIFE. That culture won’t just get better with time.

          • I hear what you’re saying, Jeff. I was at a company where the Java stories were largely finished on time, but the UI stories were not. We had three different UI developers during the time I was there and all struggled. The fact is the company’s Java code was pretty good while the UI code was unreadable crap.

            To make this much worse, the manager would largely base his performance reviews on the number of story points that folks accomplished. We lost two good UI people because of this.

            I know what the response will be. The Scrum documentation says that people should not be rated on their story points. The fact is that managers need metrics to do their reviews and metrics are hard to find, so if they are presented with an easy metric like story points, they will use it even if it is a very poor one. People will say that this is an abuse of Scrum. I say that Scrum is easily abused.

            I do draw a major line between Scrum and AGILE. The AGILE manifesto explicitly downplays process while Scrum is process on steroids. I actually like AGILE and use AGILE in my own projects. I divide my projects up so that I can come up with a minimal deliverable as often as possible. The last thing I want is a piece of code which cannot be tested end to end until months later.

    • The one thing that occurs to me as I read this article, is the increasing prevalence of the word “coders” in widespread media supplanting the term programmers. I don’t think this is an accident. It seems that the methodologies discussed seem to favor many coding minions doing lots of quick turn around grunt work. These minions are just translating requirements or coding processes not really thinking about systems and solving problems. I wonder where the true Programmers of the future are coming from? Makes me worry about the security of our financial and health systems.

    • Agile summarily eliminates best practices in software engineering, but claims to increas customer satisfaction and overall system reliability. I can’t understand how this is possible, given that practices like Software Reliability Engineering are not used in Agile. This is especially important when Agile is used for enterprise network services, where 99.999% reliability is DEMANDED.

      How is the industry falling for this nonsense?

      • Its not possible. I’m living proof from the 6th largest software manufacturer in the world. Agile is a complete disaster. It completely demoralized our experienced engineers, when they left the 7’s had no one to learn from/look up to, no one with expertise in the field or on the code, left a void that eventually destroyed the team and product quality. The “Team” with all of its hierarchy, pecking order, experience, and quality was changed from a group of developers with ownership, responsibility, and a sense of pride into a “pool of coding resources”. That was the point I left as the lead developer, after 12years of delivering market leading software.
        Sales fell, investment in the product went with that, and the product was EOL’d. This was a high touch, top right Gartner quad product that dies because of blindly following this Agile garbage. True to Agile, it died quickly (less than 36 months). Nope if you want to be in the software business, you have two choices. Now the “street cred” of our business is crap, (even in India) and we can’t hire anyone of value to design or code for us much above a 5. even then, they have already been privy to the “agile way” and as a result the employee we get is nothing more than a robot coder that has little motivation to innovate. Agile is evil corporations. My favourite part of the whole Agile process was the Big Room Planning where everyone would stand up and feed us BS about how they where 100% feature complete – but with issues! How the hell is a customer facing, feature complete for anything if it “has issues”? Most moronic thing I’ve ever had to hear from a manager in my life. Other favourites include “Good enough” software, “Minimal Viable Product”, and my #1 completely non-responsive response “contact the team”.
        On the good side, leaving was the best thing that could’ve happened to me, as I now work for a company that cleans up Agile disasters in the software industry. Teams over commit, and they continue to roll issues and features into next PI, ultimately requiring pro’s to come in and help them play catch-up.

        • Sorry to hear that and I feel your pain as this was pretty much my experience too. In agile/scrum, a coder is a coder is a coder. No credibility was given to the decades it took me to develop and hone my skills and knowledge. And the product headed for the toilet.

      • so you sold your soul! Hope it was worth it. I am not against becoming a scrum master, but preaching the scrum gospel means you sold your soul.

        • I would probably have loved being a scrum master too except I just couldn’t drink the kool-aid. And I loved software development too much.

  1. I just read the great book, “Agile: The Good, The Hype, and the Ugly” by Bertrand Meyer. He made many of the same points you have.

    I consider this one of the top 5 books on sofware of all time, and would recommend it to anybody.

  2. Pingback: 4 – Why “Agile” and especially Scrum are terrible | Exploding Ads

  3. Perhaps you might want to think about why dysfunctional management (in its various forms) has always been the norm, rather than exceptional, in large impersonal human groups- be they corporations or nations.

    • I tend to agree that the core problem resides in knowing why dysfunctional management has always been the norm in large organizations.

      • The Peter Principle states that each managed gets promoted one step beyond his competency.

        Also, psychopaths seem very adapt at negotiating corporate boardrooms.

        • As a manager I have to agree with this. I am tired on repeating other managers that the best kind of management is self-management, as they did at the Bell Labs while creating Unix. And the manager just eases the information channels to make others easier to decide themselves.

          The opposite is wanting to managing all by yourself. Then you get responsable of every little problem that could happen, your mind blows up, and for sure you will get angry with the hole world because of been everyone all over you.

          That is how psychopaths are made! Give a healthy person that kind of work, and soon you will have a tyrant. Let people decide themselves and you can just relax a little bit, because even if you die you know that everything will continue working.

          • Amen! I prefer to help team members grow into independent proactive engineers. How to do this? Well, first remove the obvious counter productive routines – too detailed apriori planning produces people who become good at covering their asses when they cannot meet the deadline; standups unveil half-baked work that a senior will inadvertently comment on, making a junior shy away from initiative; “commitment to a promise” whether a priority level, a scope of tickets, a date, becomes a killer of initiative and independent thought; planning for 100% sprint with tickets removes the fun and psychological relief to get to do something different for a few hours or days (and do it good and produce huge amount of unplanned value); FEAR of erring – instead of nurturing experimentation and learning through through erring.

            – Nurture independence – less scrutiny on intermediate product of team members; guide to a result, instead through a process; delegate decision power for small things down to team leads and team members; Check general progress directions.
            – Nurture proactivity – build structure for post-factum fixing and detection, instead of a priori planning of the correct and stepping on eggshells all the time.

      • Dysfunctional management is the norm because it is made within that environment itself, because a piramidal structure will always encourage focusing on reputation over in doing good work.

        Many times good work relies in doing well when nobody is watching.

  4. Pingback: 4 – Why “Agile” and especially Scrum are terrible | Offer Your

  5. I see a lot of hate for a decent programming methodology with no offer of any better path. You hate waterfall and you hate agile. So am I to assume that anarchy is your preferred method? You really just seem like every other jaded programmer who has either worked in a bad system or can’t accept that they aren’t some special snowflake.

    • Waterfall is mostly a strawman. It’s not actually how software engineering was done. Before the current idea of “agile”, there were many other methods used.

      For that matter, XP, the grandfather of current Scrum, was better than the current version.

      I’m not saying those methods can’t be improved upon. But Scrum is worse, not better.

      • I can verify that waterfall is actually how it was done. In 30 years of being a programmer I have only ever seen waterfall, “rapid application development”, and Agile. RAD failed. I have had most success with Agile. Scrum is more MEAN than Agile.

        • True waterfall would mean that once the requirements were written they could never change, once design is written, it can never change, etc. I’ve never seen that methodology used and I’ve been programming just as long.

          • Agreed. Much to the dismay of hardcore agilists, pure waterfall doesn’t exist. Requirements and Design could/can change in the “traditional” method. There were/are change management processes in place to accommodate error-correction.

            • I’ve seen it: companies insisting that requirements never changed, their devs are just too stupid to understand them in the first place. No system for re-estimation after scope changes because “scope never changes”. Scope always changes.

          • AGREE. I have been doing this 25+ years and the so called Waterfall is really Spiral. Requirements and design get modified or enhanced all the time. It’s done successfuly without the time box mentalityy that Agile bestows and without scrum. Agile’s claim to greatness is done by bashing Waterfall. I just went through Agile Training (barf). The argument was constantly, “waterfall is terrible” and therefore Agile is better. Leftism at it’s finest.

          • Avionics and other mission/life critical systems. I worked for a company doing contract work for military avionics and it is in the contract. Thou shall develop this software using waterfall methodology. Requirements are defined and locked down before a single line of code is written. All software is written to the requirements. That code is tested against the requirements. The code and test cycles continue until all requirements are met and all defects are eliminated.

            Just because you never worked in waterfall does not mean no one works in waterfall.

      • Scrum was introduced to the public in 1995, earlier than XP. You should not call the one the grandfather of the other, they’re brother and sister.

        • Per Tilman, Extreme Programming (XP) was after Scrum. XP was created as a superset of Scrum that added, among other things, engineering principles. Scrum is purposely sparse in respect to what it includes, making it broadly applicable. XP is much richer, and hence less broadly applicable.

    • One prof told me: if you can phrase the problem well, you’re on a good path to the solution.

      The thing with problems is that they don’t have a solution yet.

      So dumb, besides the problem, what solutions could you have or how would you find them?

      • +1
        Good article and a good warning too.
        So you’ve covered Waterfall and Agile/Scrum, and both have their problems. What could be a working alternative?

    • very swift and straight to the point with your comment which is neither rude nor is it not well thought through! i share your opinion very much!

    • Strangely, I was recently thinking about how I want to work (senior architect). And I thought back to the “Lead Programmer” principle. The fact is I can write this entire app, but first of all it’d take too long, and secondly there are lots and lots of small “stupid” tasks. These aren’t really stupid – they require an actual programmer, and a reasonably competent one, to complete.
      As an example, I’ve been doing lots of simple front end stuff for a recent app. Does this play to my best abilities? Certainly not. I can do it, but I’d rather have somebody else do it, and I concentrate on the big picture.
      Solution: The lead programmer model, which is positively ancient, I think it’s actually from the 70ies. It was replaced later by the waterfall model, another equally dysfunctional model where I forgot the name, and lastly, agile.

      The author suggests that a programmer / manager might be the best approach. A competent manager who can actually jump into the code and fix things, and who can look at others’ code and suggest improvements, find problems, etc. That is… the good old lead programmer model, just with a different, modernized name 😉

      As evidence for why this works – all those companies which have kick ass software are lead by very competent software engineers, or at least people who have some programming background. By lead I mean they have an engineering manager, CTO or whatever, at a high level.

    • “I see a lot of hate for X religion, but no offers for better alternatives.”

      Agile has some good ideas, and some bad ideas, but the #1 problem is agile prescribes itself as the solution to anything and everything that ails you (i.e. snake oil, religion).

      Replacing one management-methodology with another is maybe not the solution. Management, if it does it’s own job, should theoretically know how to manage or work on becoming better. It’s not our (programmers) responsibility to tell management how to do their job, we’ve got our own job to do. We can however tell Management when they’re making our lives miserable, and fucking up.

      Having worked in other industries, one’s methodology (or workflow) is typically developed around one’s business. It’s not really a difficult process either. Agile might possibly make sense for some businesses, but I’m skeptical of a one-size-fits-all methodology for everyone.

    • I’ve had nothing but success with Waterfall for the last 20 years. Never tried agile and have no interest. Daily meetings are for teams that can’t deliver. Seems like the project is setup for failure by letting the business team and developers run most of the show. What a terrible idea.

      Production releases are time suckers for everyone. Why would you want to have deployments every 2 weeks when you can get it all “perfect” and deploy it once properly?

      • gives the customer a false sense of efficiency and security and the manager does not do anything anymore. this the reasoning behind agile.

      • The point of doing production releases every ‘2 weeks’ (at a minimum; one place I worked our record minimum time between releases was 6 hours) is that “what you do often, you do well”: our release process was down to a couple of scripts (which included all the SCM work, running all the automated tests, and deploying the artifacts (from binaries to documentation) on our web infrastructure), so we averaged two releases a week for several years.

        Also, I disbelieve that you get any release “perfect” unless you do it fairly frequently. There’s always something that gets forgotten, or has changed and not been updated since the last release, or etc etc. Releasing often means those nits get fixed just as often, and ideally even the fix gets automated away.

        • You make a valid point, and I agree that small, frequent releases are better than large, episodic ones.

          I don’t think that individual programmers should be managed, in all of their work, down to the 2-week increment. That’s the sort of humiliating micromanagement that just poisons everything. On the other hand, the team should be releasing and improving software constantly.

          • If you’re following a “purist” approach, the team doing the work should be selecting and estimating items off of the backlog at the beginning of the sprint, and they should have full autonomy as to how they meet the acceptance criteria defined by the story.

            Compared to design-up-front methodologies I’ve worked in where I was handed a “finished” wireframe and design diagram that I wasn’t involved in the creation of (since it was done 3-6 months ago before the majority of developers were brought onto the team), the properly-implemented Scrum approach leads to much more wiggle room on how to accomplish the goal.

            Sure, if a company implements a hack-job of Scrum where the business or management is telling the team which stories they’ll be working within an iteration and how many, adding things mid-iteration and pulling them out, and not giving the team the ability to add technical tasks to the backlog – then of course that will demoralize the team.

            • I tend to agree with you Clint. I was lucky to be on a well-run Agile Scrum team for a year and half. The team selected the work each sprint, and had autonomy on how to accomplish a story. It was “purist” — with a seasoned scrum master, and the team and product owners all educated on and buying in to the methodology.

              I do wonder, based on this article, whether the team devolved into something more like the author describes. But it was successful and satisfying while I was there.

              • I agree too with Clint. The main objective of Agile / Scrum is about the collaborative, team commitment that is made. In our organization, we have an Agile approach from management down to the Application Developers. Management only needs to prioritize where the business gains value, and everyone is in agreement and buys into the deliverables. That being said, our organization invests heavily in having every member of our business “know the business”, understand it well, so that each contributor sees where / how their individual contributions fit into the grand scheme of the operation. Neither Scrum nor Agile have ever proclaimed to be better or superior…rather they claim to be “self-improving”. The author of this article should read (or, re-read) Fred Brooks’ paper, “No Silver Bullet”. Sounds to me, and this is my very personal opinion, that like many other “software engineers”, the team and experiences that the author had lacked those critical, self-improvement views that continually make a team evolve and get better. I’ve been doing Agile for 5 years now, and have worked with manifold teams and management scenarios…my experience has been that you define the agility that works for the team, and it is only meant to be a starting point…from there, you MUST evolve…it was never meant to be a “once and done” approach.

                • “you define the agility”… wow… of course if someone is vague enough it can mean anything but then just as the Agile Manifesto it has no value. About evolving depending on what you mean by that the team cannot evolve forever . But I believe what you mean is deliver code faster and faster and in the deluded minds of managers better and better. Things do not work like that. Agile is promoted by people that have 0 understanding of the complexity of software development. They talk big words using cliche lines like team work and such but have no idea what happens at factory level and what those words mean. Also it seems that all agile promoters, including you, cannot stop themselves of doing ad hominem attacks to the vast majority of developers that find Agile to be cancer.

                  • Of course, you prove the very point that most so-called “software engineers” seem to think they have all the right answers and nobody else can contribute to their god-like [alleged] knowledge. Before you can accept some thought and/or idea from another, you must first be willing to to accept that the other person may have something to contribute. I write from my 30+ years of software development/engineering, plus teaching Graduate level courses at a major university…so, before you make statements like, “Things do not work like that. Agile is promoted by people that have 0 understanding of the complexity of software development”, you should know your audience! Maybe the folks with whom you’re working might deserve a little more respect than what is being offered…and, who knows, you might learn something too!

                    • Having x years experience does not impress or matter to me. What would bring more validity is specifying a software you brought significant contribution to. Of course since in Agile the tasks are split so much that none of the pieces is comprehensible having a meaningful contribution is almost impossible which is one of the reasons I hate it. About teaching software development I did that too for a while… is irrelevant. And I do not know to have all the answers to recognize a turd when I see it. I never said I know everything or have all the answers but I can say with certainty Agile is crap and does not work. You do not need to be expert to realize something does not work. You need to be one to make something work, not see it does not.

                    • @cyprian “Having x years experience does not impress or matter to me” I tend to agree that just having a number of years is not necessarily impressive. I think what most posters (including myself) mean by an experienced developer is a person who has a proven track record of solving complicated programs systematically. Having solutions that have a low problem incidence (bug count) and that are still in use and able to be modified after years of usage. Solving increasingly complicated problems is analogous to growing in knowledge by taking (and understanding) increasingly complicated courses in college. This is what the ‘dumbed down’ agile/scrum denies current developers. I have seen young developers who I immediately knew had talent but what they needed was to add to that the years of actually doing and learning. I say this as one of those ‘experienced developers’ with 30+ years of successful software design and development. Some of my designs/solutions were still in usage 15+ years after I implemented them. Some of them were easily modified as new business models emerged. And yes, I had a couple of clusterfucks in the process.

                    • Personally I don’t see AGILE and Scrum as the same thing, and I think that’s part of the disagreement here. Scrum is said to be one variation of AGILE. I like AGILE but hate Scrum. The AGILE manifesto says, “Individuals and interactions over processes and tools.” Scrum is process on steroids

                      It is definitely wrong for engineers to think others don’t know anything. It is also wrong for others to think they know how to do the engineering job better than engineers do.

                      Any methodology will work well if managed by good managers. The true measure of any methodology is how well it works in the hands of mediocre or poor management. Scrum fails this test. Mediocre or poor managers often see Scrum as a miracle cure to their problems and a way to micromanage the engineers.

                    • I don’t agree that any methodology will work if well managed. Some methodologies are better in certain business models. Other than that, a very well written and expressed post.

                  • Very nicely said. Agile/scrum has been known as a dehumanizing disaster for 6 or so years now. My company’s managers started teaching it using (of all things) YouTube videos. A solution to all of our problems – free on the internet (sarcasm mine). Passion and overtime trumped experience and logical thinking.

    • You can use various tools all together:
      + Just in time
      + one piece work-flow
      + eat that frog
      + kaizen
      + kankyo kaizen
      + visual management
      + minimum planing
      + short o no meetings
      + Spartan programming
      + minimal methods
      + simple test-case for each function

      Result: no bugs for the late 2 years. Perfection is not achieved when nothing cannot be added, but when nothing cannot be removed.

      As specimen:

      If it does not deliver a clear value, discard it. You are better served with a 9 that takes 2h, than with a 10 that takes 10h.

    • Exactly the type of person who will never, ever get software development. You are probably a manager who’s developed one application and now knows everything. Probably follow your buddies around from company to company too. Scrumbag.

      • Agree with this comment. As a team leader, I have tried both methodologies : Kanban and Scrum.

        I hated Scrum because of its lack of flexibility. Anything wrong in the sprint and you’re out ! It was a complete disaster and I had to leave the project.

        While Kanban is much more flexible and you can still handle if something in the project realization went wrong. Even if you, as a team leader, never worked with Kanban before, you can even implement it in an intuitive way. I found out that it gave much better results, much more happiness among developers and higher customer satisfaction. This is also Agile but that does not need to waste time in standing meetings, sprint plannings, sprint reviews and other bullshits.

        And guess what ? My developers are not even aware I am applying Kanban. They just need to focus on their work, having enough time to think carefully about how to implement their features. Bottlenecks ? Dev status ? Delivery ? They do not need to care : this is my job. Backlogs ? Also my job, no need for any Product Owner so that the customer as well also has nothing to do. Everything smooth, triple-win situation.

        Whereas Scrum is like a Cultural Revolution for every part : understand it, accept it or say goodbye !

        By the way, I have always been told that Scrum is based on Agile Manifesto and its twelve principles. OK, let us take a look at it and show me, where it is written that we have to do stand-up meetings, estimations, sprint plannings, sprint reviews and such uselessly time wasting bullshit. I saw this nowhere !

  6. I think people will follow scrum tactics instinctively in a corporate war mode. Scrum just seems to describe what people do in a war mode. That’s why I think they don’t need to learn scrum to do scrum in a war mode. This articles reminded me of the days when I had a job at an agile software company. Thinking about how I was treated under agile practices causes mild nausea quickly.

    Fortunately, I won’t have to deal with agile shops again in my life as of this year.

  7. Thanks for the article. It was interesting. As someone who is working in an agile team I have two points though: 1- Isn’t it possible for teams to adopt their own agile process and fix the issues they have with the process? For instance introducing internal hackathons to fix part of the R&D issue, or dedicate a separate team to R&D? I say this because I agree with the point you made about R&D. I can also see your point about career growth. 2- What is the alternative? One of the things I like about Agile and Scrum is that it forces the “business partners” to think about what really matters to them and not ask for everything under the sun. I also like the idea of stand ups; so clearly there are parts of scrum that do work. Should we look for a hybrid? Or follow an entirely new process? By the way I don’t work at a consulting firm. I work within a small team in a financial firm where the engineering team can’t practically (at least fully) dictate the direction of the product because we don’t have all the business knowledge.

    • Standups are one of the worst things about the whole process – EVERY single day you know you have a scheduled interruption at 10am. This means that every single day there is no point committing yourself mentally to a deep dive task as you’re racing the clock knowing you’ll get pulled out to listen to a lot of talk irrelevant to the task you were in the middle of working on.

      I firmly believe (borne out by experience) that only those who have not coded for a living love standups and SCRUM. When you’ve experienced the reality of working a problem for hours, days, weeks on end – in the shower, on a bus, waiting for coffee, in the traffic or as soon as you open your eyes in the morning – you feel very different about a scheduled daily interruption.

      In the name of productivity engineers have to dumb down what they’re doing and explain ad nauseum to people not qualified to understand. That’s not an insult – a civil engineer doesn’t explain the properties of material plastic yield stresses to lay people either.

      I recently worked at a startup where they hired a SCRUM fanatic micro-manager. Within a year 5 senior engineers left – all with 12+ years experience a piece. Over 50 years commercial experience walked out the door and management did nothing – because they could *understand* SCRUM – so the problem *must* have been the engineers.

      I’m frankly sickened by the whole thing and its been one of the drivers for my decision to get getting out of commercial software development altogether.

      You want an alternative solution to the SCRUM vs Waterfall debate? Hire a really good team of engineers and get the fuck out of the way – we are perfectly capable of designing for change.

      This is what we do.

      • I think it’s possible to do SCRUM right. An agency I know has frequent scrum meetings – but it’s not about “performance” or whatever, it’s just to keep the team aware of what the rest of the team is doing. And it’s limited to 5, 10 minutes every morning. As an engineer, I never felt this to be a problem – nobody will go into technical detail, nor would it make sense to do so.

        Again, I think SCRUM, as any engineering method, is good if management, e.g. the boss, knows software. If the boss knows software, they’re not going to ask dumb questions (“couldn’t you do this?”).

        Or, come to think of it, the boss might ask “couldn’t you do ?” and it’s actually a great suggestion. But I guess that only happens when your boss is a certified genius, only had the pleasure to work under one once 😉 he’d do business deal, then hop on to engineering meetings and despite not being involved in day to day coding, he’d have really good ideas to contribute. Not all the time, but on occasion.

        • Why do you care what other team members are doing?
          If their projects interfere with yours, you will talk to them about it anyway, in smaller groups and in greater detail.
          If their projects have nothing to do with yours, you don’t need to know what everyone is doing every single day.
          If it’s for personal interest, you can small talk with individual developers over lunch breaks.

          It’s only 5 minutes a day, but for me this is 5 minutes of wasted time. Everyone throws in a few buzz words and nobody listens. Half of them will solely consist of “Still working on XY” for 2 weeks straight.
          Every morning I get 12 short status updates of projects I don’t understand (because 2 sentences are not enough to to into details) and 98% of this has absolutely no relevance for my job.
          Yet it postpones my actual start of the day to 10:05am, because there’s no point in doing anything but reading my emails before this, knowing that I will get interrupted soon anyway.

          Sometimes, if people talk about what they are working at lunch breaks I notice that nobody has a clue what others (or I) are working on at all.

          • Sorry! It seems, young padawan, you still lack quite a lot of experience 😉 at least in *huge* projects.

            How can you be sure that the work of other team members is not interfering? Who knows this and who coordinates? This is exactly the idea of an agile process: Self-organisation. I.e. the team itself must coordinate these interferences. And please tell me: If it is not mentioned (quickly, not in depth!) on a daily basis, how do you know what the others are doing and whether it interferes with your work?!

            One example: I very often experienced someone saying (or said it myself): “Hey, what you’re talking about somehow sounds familiar – I lately worked on X – maybe you can refactor the common part out of this and make my feature X and your feature Y use the common code.” Isn’t this interference? Would you prefer redundant code instead?

            There are many more examples I experienced in real life, but I hope I don’t need to iterate them one by one to make clear that it’s the team who needs to talk. And a once-per-day meeting is a great opportunity for this. Otherwise you don’t get everyone together and the risk that interferences go unnoticed is far greater (and there are greater risks than redundant code).

            • Well, because not everyone works on whatever they come up with. Few tasks come from developers. There is a defined channel for incoming feature requests, bug reports, etc.
              There’s a person turning these into tickets and assigning them to developers.

              These assignments are not random. Everyone has their fields of responsibilities and expertise.
              Out of 12 people there are never more than 2-3 working on the same region of the whole blob of software. And the people working on similar things as I have their desks around mine.
              I know what they are doing and they know what I’m doing, because we talk about it all day.

              I can always be sure that the frontend devs hacking their CSS and JS won’t interfere with me optimising data flow deep down in the backend.
              In the rare case that my work may affects theirs, I know so and talk to them to before I do it.

              Individual in-depth communication is way more effective than noisy, unfiltered broadcasts.

              For 80% of our code, I know roughly who is championing it – and for the rest I can find it out within 2 minutes.

              • > “There’s a person turning these into tickets and assigning them to developers.”

                Then what you describe is definitely *not* Scrum! In Scrum, everything to be done comes as a story in the backlog. And then the developers *pull* out the stuff they’re working on. Nobody is “assigning” anything “to developers”.

                One of the main goals of Scrum is to spread knowledge among the team. This cannot be achieved, if everyone only works on the things he already knows.

                And there’s one more goal: Review. If the same people constantly work on the same code, there’s obviously no review. If you pulled a task/story you don’t know anything about, then pick someone who does and do pair-programming. At the end, both people will have learnt something.

                I know that many companies strictly separate certain types of work from each other (e.g. frontend from backend), but IMHO this is not very wise. And even if it is so, where’s the problem of hearing 2 sentences from a frontend-developer about what he’s doing even though you work on the backend? Are you that ignorant that you really do not want to know? I mean this might be a personal choice, but at least I am always interested in the entire project – not only the part I’m working with.

                > “Individual in-depth communication is way more effective than noisy, unfiltered broadcasts.”

                I totally agree. That’s why the daily stand-up is *not* in-depth and only superficial. It is meant to give everyone an idea about what’s going on. It is not meant to explain in depth what genius ideas every dev is currently implementing.

                • …btw. I forgot to mention: If there are only 2 to 3 working on the same region, you have a small team! I lately had 12 devs in one scrum team working on one part of the big project. There were multiple Scrum teams working together. You cannot know what these 11 other people are doing because you don’t want to sit with everyone in the same room.

                  • Then how about this: ditch scrum and make smaller teams. That way you can get problems solved without introducing a new layer of management specifically designed to solve the problem you introduced by creating the large team.

                    “I had a huge problem so I hired 10 programmers and now I have two huge problems.”

                    There’s also something to be said about having too many cooks in the kitchen. If you actually had 12 devs looking at or relying on the exact same lines of code, then either your system architecture was not modular enough or you just had too many people making decisions about the same logic. In either case, it sounds like your team was pretty inefficient. It’s fine to have 12-man “teams”, but they shouldn’t all be working on the same thing. The “12-man” team at my office (it’s more like 20, but hey) is actually segregated into much smaller 2-4 person teams when it actually comes down to writing code. In other words, There might be 16+ people on my team whom I *NEVER* interact with. Unfortunately our standups involve all 20 people, which makes them pretty inefficient, because I really don’t care what those 16 other people are doing, and I shouldn’t need to. And that, my friend, is the point.

                    • > 12 devs looking at or relying on the exact same lines of code
                      You have an IMHO very strange understanding of architecture. In my world, it is common that there are layers with one relying on the other. Thus, it’s totally normal that for example a domain-specific module relies on an infrastructure core module. Someone working on the domain-specific module might very well detect a problem with a core module or identify a need to somehow extend it.

                      Or someone working on a domain-specific UI module might very well rely on the domain-specific corresponding data model.

                      > your system architecture was not modular enough
                      Wrong! Our architecture was *very* modular: Our project contained far more than 500 sub-modules (each being a separate Eclipse-/Maven-project and producing an OSGi bundle as its primary artifact).

                      Honestly, I wonder how your architecture looks like, if you have no such dependencies. Btw., IMHO, you failed extracting common code (which reduces redundancies), if you didn’t create such common core modules.

                      > In either case, it sounds like your team was pretty inefficient.
                      You draw very strange conclusions! The opposite is the case: Our team consisted primarily of highly experienced developers and was one of the most efficient I’ve seen in my life. Btw. our team was the first to complete our work within the scope of the bigger project (consisting of many teams).

                      Most importantly, we did not only do our primary work, but we also identified and removed redundancies, thus improving code quality, and did quite a few refactorings in order to clean things up. Furthermore, we reduced boilerplate code (older parts of the software were not yet using newer technologies like IoC with dependency injection). In short: We reduced the technical debt, significantly.

                      All this would not have been possible, if everyone had only cared about his immediate task without looking and thinking around and beyond.

                      > because I really don’t care what those 16 other people are doing
                      Well, friend, sorry to say this: This statement implies that you’re quite ignorant.

                      I prefer to understand the big picture. I like to contribute improvements that I could not devise without looking behind my own nose. And I made very good experiences with this strategy: Not only keeps it software development in general and the projects I work on *interesting* to me, but also was I able to significantly improve the overall code quality in every project I worked so far (or kept things clean from the beginning, if I worked in a project from its start).

          • I care what my Scrum team is doing, so that is the value of having a daily Scrum stand-up meeting.

            Since my team is all working on the same feature, at the same time, working on tasks to complete the joint objective… knowing where everyone is at, and what they are stuck on, and what’s about to be available as we’re all cranking away on that same thing. Very, very valuable use of 15 minutes.

            However, a daily non-Scrum-team stand-up meeting where everyone is working on different things, and no one is on the same team, and your work doesn’t impact anyone else, and your (non-team-mate) co-worker’s work doesn’t impact you… then that’s not a daily Scrum stand-up meeting. That’s a useless status report amongst people that don’t care and have no skin in the game regarding each other’s progress.

            To have a daily Scrum stand-up meeting you need to have a Scrum team — which are all working towards completing the same product backlog item.

            No Scrum team, no need for a Scrum team’s daily stand-up meeting.

            • Exactly correct! If your entire team is always working on a single project, then Scrum makes sense.

              But most teams find themselves dealing with many smaller issues which change the existing code base. So everyone is not working together. Rather, they need a little coordination to avoid “working together”, to keep their separate projects separate. But I only need to know the way other team member’s work might impact my own, and a general idea about how it changes the code base so I will be informed in the future when I do some work on that part of the code. Because of its rule that only progress reports are are allowed, Scrum standup doesn’t accomplish this; it block it by giving the appearance of communication without the substance, thus discouraging the communication which is actually needed.

      • “Hire a really good team of engineers and get the fuck out of the way – we are perfectly capable of designing for change”

        There you go. That’s exactly what Agile says. The only change would be “Get the efff out of the way and come in only when I have a problem and call you for help”

        Going by the story you have narrated, the manager your management hired is anything but an agilist. Scrum does not have room for fanatics. “Inflexible Scrum” is oxymoron.

      • In regard to flow state, the advantage of the daily standup isn’t what goes on in the meeting; the advantage is that it’s very brief and it replaces ALL OTHER MEETINGS about the project during the sprint… with the exception of those that you the developer *want* to have to solve specific problems as they arise.

        If the daily standup is not accomplishing that, then I agree it’s an impediment. I’d argue the problem is with management for doing it wrong.

      • “In the name of productivity engineers have to dumb down what they’re doing and explain ad nauseum to people not qualified to understand.” That’s IS an insult , to any self-respecting engineer.

        • Yet it IS what happens in most scrum stand ups. This I know from experience. For people that are insulted, I say study and learn (like I had to do).

    • The common myth is agile is adaptive and “every team can tailor it for its needs”. In reality it means you have to implement bare minimum: stand-ups, story points, capacity/velocity metrics, two-weeks sprints, scrum of scrums, backlog grooming/planning, reviews and retrospectives. And after that you’re free of course to tailor whatever its left of your project time.

      • All those activities should not take more than 10-15% of your time and it’s much better than the traditional weekly status review meetings + change management meetings which take more time.

      • Have you realised how many mature agile teams dropped those parts of scrum (not AGILE) that was unnecessary for them? e.g. estimating and velocity. And sure, you can skip grooming and planning, but somehow the team should know what to build next and should understand the tasks. You are not *expected* by agile to spend hours and hours on meetings if they are a waste; on the contrary, the philosophy behind scrum is to get rid of waste. So whatever you do and not helping you to deliver what your team should, your team should not do. But it’s much easier of course to say “we are doing scrum” and just introduce the typical scrum ceremonies. That will definitely not help anything.

        • Exactly. None of those things are required to be Agile. Most of them aren’t even required for Scrum. The term “Cargo Cult” comes to mind when I read this article.

    • @emaghsoudi: The answer to your question is yes.. but it requires really good managers to adapt like that. I’ve seen situations where literally every manager but one was terrible. In those situations the process is meant to substitute for intelligent management, with predictably terrible results.

      Scrum starts out thinking everyone is thinking and of excellent quality.. this is my precise problem with it.. it doesn’t recognize that in the real world frequently we are stuck with less than optimal people to get things done.ESPECIALLY non-optimal managers!

    • 1. No is not. The main problem with agile is that it is a series of continual sprints. Sprints do not work this way. Look at sprints in running. When sprinting you force yourself to be at top capability. This means that you face exhaustion at the end of a sprint which means you need a time to rest. But Agile puts you to run in another sprint instead. This means the developer gets burned out. There are times when such type of things are necessary. For instance if the product deadline is close and there is still work to be done but not continuosly. Your solution is apparently making the developer that is already tired to run even faster (hackaton) because the solution to a problem is doing things even worst. The second part of the problem is the useless meetings and the need to register everything. This is a problem especially since some tasks cannot be atomized without loosing software integrity and coherence. Agile starts by assuming atomizing is always possible, but except for web design it is usually not possible without destroying any coherence or sense of quality from the software.
      2. The solution is a milestone system. It is not by any means the only alternative but it is a good one. Once a milestone is reached changes that are more complex than x will be denied. If they are absolutely necessary the milestones will be moved, more time allocated and the customer will be charged much more money. This was a model used before Agile and the false Waterfall/Agile dihotonomy. Scrum and Agile actually does the opposite of what you said: it allows the customer to change requirements whenever and however they want. So basically it gives the power to the “bussiness part” to quote you “to ask for everything under the sun” for free. If you say you like standups maybe you do not have real work to do. A simple 5-10 min standup equates to 30-60 minutes lost from the work day because it takes time to return to the task you were doing unless you are somekind of robot… but hopefully Skynet is not yet self aware. In most serious projects is the responsability of the customer to clearly explain what they want and the responsability of the Managers to translate this into project specifications for the programmers. But of course none of these do they work anymore.

        • The Agile Manifesto does not prescribe almost anything. It just gives extremely vague directions on what needs to be done. This makes it almost impossible to contest because almost every type of design process except the original Waterfall which was never used except as a straw man argument by agilists implements most of its directions in one way or another. When we are talking about Agile methodology we are not talking about the extremely vague manifesto but of the metodologies that call themselves Agile. The most prevalent of those is Scrum which does prescribe sprints.

          • “It just gives extremely vague directions on what needs to be done.”

            I’ve got a lot of time for your arguments against scrum – any process followed at the expence of communication and getting the job done is going to be destructive ( one could say “individuals and interactions over processes and tools” ) .

            But your constant arguments against agile don’t seem to be as well considered – which leads me to question if the inclusion of “agile” in the title was an attempt at clickbait or seo?

            I can’t remember any part of where the agile manifesto suggests directions. Its really clearly a summary of the practices which some expererienced thought leaders had found were common in successful software development projects – it even open and closes with clear statements stating it was the result of the experiences of the signatories – read it, it’s blatantly clear:

            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 interactions over processes 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 the items on
            the right, we value the items on the left more.

            • This bears repeating

              Agile was created by commercial IT folks who believed Waterfall was the problem. While Waterfall does have issues the problems were lack of best practice use and under bidding/estimating. Commercial IT rarely uses best PM or software development best practices. This, to the authors point, makes Agile worse. The reason for that is that the usual inexperienced and/or unscrupulous IT dev manager bastardizes the practices even more and eliminates upfront scope, cost and schedule due diligence. This results in no project level data for any oversight. Thereby allowing for eternal software development work based on almost zero cost, scope or schedule accountability. Having said this Waterfall can suffer from trying to know too much upfront and being boxed in by that. Given this my suggestion is to use a hybrid. A best of both approach to mitigate the weaknesses of the other. A DSDM like with actual best practice use. Those being for example – EVM, WBS, schedules with dependencies and critical paths shown, productivity, defect density, rework and scope volatility metrics, root cause data, RTVM etc.

              For those citing Google and Apple. Those companies are in their heyday and are making tons of money. But doing so at a massive and avoidable cost. they are insanely inefficient. This will come home to roost. Examples – Blackberry and Yahoo.

              The core problem is that far too many folks only know what they know. Most people are from commercial IT where very, very few best development or PM best practices are used. Heck I bet than less than 10% even know what CMMI is or what it means to be a Level 5. Decades of this has ruined the experience base ;leaving leads to think they know what the best practices are when they have no clue. The loop will continue except for those rare places where someone comes in from the outside, probably DoD, has the courage to drive change and beats the culture back. Lightning striking the same spot 10 times in a row has better odds.

            • value Individuals and interactions over processes and tools: how? and what does his mean exactly? doesn’t it seem extremely vague to you?

              Working software over comprehensive documentation – this is just wrong. yes working software is the most important but without comprehensive documentation it cannot be maintained or updated. People change jobs all the time. If a new person comes to the project the lack of comprehensive documentation makes his work sisifian and inefficient. Also Waterfall provides a working software, agile does not. Software that partially works is not working software.

              Customer collaboration over contract negotiation- each time a customer wants an important change this means more time of work and should mean more money paid by this customer. this is normal way of functioning because work costs. The customer should collaborate to the project by saying exactly what he wants. The customer is usually not technical so he cannot contribute in technical details like the structure and such. Having it collaborate in this is problematic. So I disagree with this.

              Responding to change over following a plan- again wrong. A structural plan is absolutely needed. If you would build a house following this motto it will collapse at the smaller pale of wind. There are some basic structural things that needs to be known from the start. Changing them late in development usually means redoing at least 60% of work which is immense. And the customer should pay for this change. You cannot weasel out by saying respond to change over following a plan. This may work in the business work, but in the real work it does not. That does not mean everything has to be planed up front but to remake the house analogy you cannot tear down a sustaining wall/pillar without major rework.

              • I think this is a popular misconception with Agile. Just because we value the left statement more, does not mean we don’t also value the right. Does not mean we do not document or have a plan

                In fact most decent / mature Agile deliveries I’ve seen delivered more comprehensive documentation than most Waterfall projects I’ve seen as it’s built into the definition of done per sprint and not squeezed into the end phase of a project and, often, compromised in Waterfall.

                Equally, Agile does not mean no planning, it means planning is continuous, but does not mean following an initial plan by route, rather re-planning as evolving circumstances, opportunities and threats occur and making the plan transparent as well as the reasons for change.

                • actually most if not Agile teams use that statement to avoid any documentation whatsoever.

                  Again is wrong to call a project Waterfall as Waterfall was not used by anyone in its pure form.
                  About done by sprint here is a big issue: some things cannot atomized enough to fit into your neat sprint. Also testing cannot usually be automatised so Agile fails once more.

                  Agile means you change the plan so often that no one is sure how a feature should work internally by the end of the sprint. The reason for change is because the client had a bad idea while sitting on the toilet. Or because he saw something at another similar and thought it was neat although usually it is just dumb.

                  Please stop with your idealism and smell the roses . The reality is that Agile was designed for whiny undecisive customers that do not know what they want.

                  • You don’t appear to be describing agile. Gary pointed out that agile recognises the importance of processes, documentation, contracts and planning, but seeks to suggest appropriate priorities for these concerns.

                    You seem to be describing anarchy, which isn’t agile. It seems to me that you may have experienced a misadventure in change, for which “agile” has been declared the scapegoat. This seems, unfortunately, to be a common misadventure, which I suspect is to do with either ignorance of, or contempt for process and culture management within IT.

                    • what can I say? if it walks like a duck and quacks like a duck… every agile implementation out there is like this. Is just that many choose to turn a blind eye to this reality of Agile development. Maybe there are 1 or 2 exceptions to this but in majority of cases this is what agile is.

                    • Again. Those of you with only commercial IT experience none in DoD (or the like) where actual best dev and PM practices are used are not seeing the forest for your trees. The issue is not Agile vs Waterfall. It is that you literally don’t know what the majority of the best practices are. That and not understanding that the best method is one that employs the best of Waterfall and Agile to mitigate the other’s weaknesses are the solutions. You need to get out of that forest to see how incredibly off your understanding is.

                  • Most documentation created during a sprint is of little value months later. What was coded in one sprint will be improved in a later one. So “sprint level” documentation is of little long term use.

                    Actually useful documentation includes: (1) Documentation which appears as comments in the code, which will be changed in the future if the adjacent code is changed. (2) System level documentation such as data structures, whose documentation should be attached to the structure definition, just as the code’s documentation should be a part of the code. (3) Test cases, which quickly lose all value unless maintained and exercised regularly.

                    Since documentation which tracks what happens within the sprint “spoils quickly”, it is, as agile suggests, kept minimal.

                    • “Most documentation created during a sprint is of little value months later” yes because when someone wants to work on a piece of code he has never worked before he must do detective work every time and assemble dozens of jiras and talk to dozens of persons just to understand what the fuck is happening with that code. This is my experience with Scrum “documentation”.
                      ” Documentation which appears as comments in the code, which will be changed in the future if the adjacent code is changed” and most Agilist do not put enough because they are pressured to write the code faster and faster.
                      “System level documentation such as data structures, whose documentation should be attached to the structure definition, just as the code’s documentation should be a part of the code” inexistent in Agile
                      ” Test cases, which quickly lose all value unless maintained and exercised regularly” more detective work.
                      What you seem to fail to understand is that documentation is invaluable to anyone new to the project or even the section of the code. Because otherwise is detective work going through dozens of jiras and mails and so on until you can figure out what the code was supposed to do. Sometimes moronic clients make requirements changes so often that I have trouble keeping track even with the changes I made. This is stupid. Agile MUST DIE!!!

      • I agree, Rational Unified Process uses Milestone system. RUP is more heavier on documentation than Agile but all the templates are defined for you so you can easily fill them up and the whole document framework can be easily created for every project. Requirements and design phases are more in focus at the beginning, until they become more stable and less prone to changes.

  8. > Programmers are, in many cases, expected to provide humiliating visibility into their time and work, meaning that they must play a side game of appearing productive in addition to their actual job duties

    It’s only humiliating if you don’t get much work done. This is a benefit, not a gotcha or failure of the process. What are these “actual job duties” if they aren’t documented in the process?

    • It’s also humiliating if you believe “appearing productive” isn’t a core job duty.

      As for what they are — think of refactoring and other repaying of technical debt. Not big debt, but the small kind that accumulates constantly. You *can* pay it down, but the process gives you every incentive not to.

      That’s irresponsible, and adds up in ugly ways. A Scrum codebase, being kept in a state of perpetual emergency, quickly comes to reflect that fact. “No time to fix it now, I’ll go do features.”

      You could say that engineers can just communicate that technical debt to the business and wait for them to realize that they need to fix it. Ever tried that? I have a number of times. I have a pretty good idea how it comes out.

      • I don’t understand what’s wrong saying “I was working on refactoring this module yesterday” as status update. That’s the reality.
        On technical tasks, if you don’t understand why the task is important for business and what value it’s going to give to business, then you shouldn’t be doing it in the first place. Refactoring giving no business value, is not worth doing at all. Never do refactoring because “you feel code is ugly”. Do refactoring only when “it’s slowing our new feature delivery”, or “it’s increasing our bug count”, or similar business reasons.

        Nobody gives a damn about how ugly your code looks, because business doesn’t know how even the good code looks like. So, STFU and find business value of refactoring.

        • “…business value of refactoring.”
          Security. Long time criminally undervalued and a hefty price to pay nowadays.

          • Sorry, can you please elaborate? I don’t understand what you mean.
            Are you saying business value of refactoring is security? But that doesn’t make any sense.

        • > Do refactoring only when “it’s slowing our new feature delivery”, or “it’s increasing our bug count”, or similar business reasons.

          The new feature comes with a deadline, so refactoring can’t be done anymore. So you try to cram the new feature into the codebase as it is leading to more and more ugly code making changes more and more time consuming leaving less and less time for refactorings.

          • >> …. So you try to cram the new feature into the codebase as it is leading to more and more ugly code making changes more and more time consuming leaving less and less time for refactorings.

            And that’s the trap developers goes into. If you already know you are not going to be able to deliver the functionality (including quality), then tell that to customer instead of increasing the mess. You know that’s exactly what gets us into the mess. 😉

            Of course, it’s business’s decision to say “okay, I will pay this cost now, so that I get the quality”, or say “I have to market this thing now ahead of competitor, I will worry about the quality later”.

            • I agree. I think that it’s also important to consider refactoring separate from quality. Quality is about meeting requirements. Refactoring is reorganizing code based on a particular expectation of change which may or may not happen.

              I think “technical debt” is a poorly thought-out concept. It’s really projected future cost. Like all projections, it’s speculative and the costs may never materialize. If you’ve refactored in anticipation of those costs and they don’t occur, you’ve wasted your resources.

              • > Quality is about meeting requirements.
                This would be true if correctness, performance, security, usability and maintenance costs (i.e. overall quality of the product) were always thoroughly considered when talking about requirements.

                > If you’ve refactored in anticipation of those costs and they don’t occur, you’ve wasted your resources.
                Sorry but I think this is just paradoxical and circular.
                These costs not occurring is most probably the result of fixing the problem early in the first place (unless you are just plain lucky). Sadly, the other way is more common, i.e. “no time right now” to create solid design or architecture, or to fix well-known issues and the mess we created – often referred to as “refactoring” with a grin, as if it was a developer hobby.

                On the other hand, experience shows that poorly built things (buildings, roads, bridges, companies, hardware, *software*…) *do* break eventually, if they make it into production at all. I wouldn’t necessarily call this speculative.

                Bottom line:
                I think “technical debt” is the most valid and tangible concept around in software development.
                I’ve never seen any project get away with unhandled technical doubt, i.e. “technical debt” not being repaid with huge “accumulated interest”, be that extended project timeline, scoping down, staff replacement, or total project failure.

                  • It’s especially haunting when you open up some of that spaghetti code and run “Annotate source” or “Git blame” in your versioning system and it feels like looking at the Vietnam memorial wall.

            • “then tell that to customer instead of increasing the mess” the problem is the customer of an Agile project in most cases is a complete moron and as a result is so conceited that he will not listen in the best case scenario and will choose someone else in the worse. Agile transforms the client in a whinny baby. If you ever had to deal with children you will have had the situation where you tell the child that something he does not like needs to be done. No matter the arguments a spoilt child will keep asking “But why?” until you break and either do it his way or say “Because I said so!”. Problem is you cannot say “Because I said so!” to the client. So you end up dong what the moron tells you to and when the shit hits the fan you show him that you warned him this will happen but it does not matter anymore.

        • > On technical tasks, if you don’t understand why the task is important for business and what value it’s going to give to business, then you shouldn’t be doing it in the first place. Refactoring giving no business value, is not worth doing at all. Never do refactoring because “you feel code is ugly”. Do refactoring only when “it’s slowing our new feature delivery”, or “it’s increasing our bug count”, or similar business reasons.

          But a business stakeholder probably doesn’t…

          > Nobody gives a damn about how ugly your code looks, because business doesn’t know how even the good code looks like.

          Ah ha.

          He’s not saying engineers shouldn’t communicate what they’re working on and articulate the value, he’s saying it’s a losing proposition for the engineer if every choice is beholden to managements’ judgement. If I’m the expert on whether refactoring a chunk code will add value and I judge that refactoring is worthwhile, what rational choices does a manager have other than “okay, do it” or “no, I would rather not have additional value today”? If management can’t make meaningful judgements at that level of detail, why should they get involved beyond ensuring the engineering team is achieving their goals?

        • If the present code looks ugly, nobody cares about the future code. If the present code looks ugly, nobody understands it. Beautiful code is the art of solving the problem of feature, maintainability, testability, readability, chosen language, programmers state of joy and a too short life.

          Programmers tend to get frustrated over ugly written code – nobody wants to clean the shit of someone else or to get trapped in someone’s weird ideas (here comes too short time and too much junior into play).

          So my experience is, that people anyway will avoid certain tickets and try to get involved in other tickets, because the code has a certain ownership. In the end ugly code breaks up your team. What are you going to tell the man, who is asking you: Why are you leaving that shit on my way? Are you telling that ugly code has more business value than beautiful code?

        • Refactoring “ugly” code isn’t about aesthetics, it’s about maintainability. And the bottom line is no matter how good you are, if your code isn’t maintainable, then it’s worthless. Always code for maintainability over everything else, because if a decent coder can’t look at your code and immediately see what’s going on, not to mention make changes, then your feature development, ability to fix bugs and patch security holes slows exponentially.

          If your coding practices and processes are done properly and in place, then when your lead developer gets hit by a bus / gets a better offer you don’t immediately lose your competitive advantage. This make an enormous difference for the saleability of products and companies.

          I’ve seen a lot of businesses die because they go hell for leather getting their MVP or new featureset done, then very soon find out that ongoing maintenance and new directions are going to require way too much work or a rewrite.

        • This can be correct in some cases, and not in others.

          Apple turned into the biggest corporation on earth because they had a good, clean, object-oriented operating system which, when the need arose, could be ported to a phone!

          Windows, on the other hand, simply couldn’t be ported to a phone – there was no way, and no amount of money could make it happen. Other players at the time – Nokia – couldn’t compete with the iPhone thanks to crappy Symbian software.

          So it all depends. Good code can make or destroy a company. Good code can also be a waste of time – this most often happens when there is premature optimization on the engineers part (e.g. spent the last week refactoring so you can scale to 100M customers when your actual problem is acquiring the first 10 customers).

    • Appearing busy is the opposite of productivity. For a coder, nothing is easier than to appear busy. If the status meetings turn into a beauty contest to management who knows nothing about coding, I can guarantee they’ll never know who actually gets things done and who doesn’t.

      I had a corporate client where everyone was “very busy” with constant meetings and status sprints and whatever else. But hardly anything ever got one. Productivity was a factor 10 lower than I was used to in this place.

  9. Thanks for writing this Michael. I agree putting all your faith in any tool, language, framework, etc is a bad idea. I really would like to see you write about microservices. I think we need some discussions to again call it like it is since 1) I think most of it is not so “new” and 2) like agile/scrum not for every project. Probably we could try and prescribe when and where such things have highest probability of success?

  10. Michael was most likely part of mismanaged agile project. All of his claims about agile are made up or misinterpreted from bad project that dont use or misuse agile / Scrum principles. Poor Michael

    • I had my share of scrum/agile projects and I fully agree with Michael. Scrum/agile done by the books is horrible for productivity and quality. Even more so if its established/controlled by upper management.

    • No True Scotsman, yes?

      So how does one determine a good Agile/Scrum project from a bad one? And why aren’t those indicators front, back and center in any Scrum training so bad Scrum projects don’t happen?

      • Well, if your product owner and scrum master outrank your developers, you’re failing at Scrum. If you’re being punished for making long estimates, or for tasks taking longer than estimated, then your scrum master is failing to respect the team’s judgement; the stand-ups are there to highlight impediments and the retrospectives are there to determine if the team was lacking information or manpower and how the business can either help support the team, or else modify their completion estimates to compensate.
        How is the business supposed to make reliable judgements about development times if they ignore the judgement of senior developers, or even junior developers, and make up their own estimates about how long something ought to take?
        Michael made an argument about not having time to try something which might fail – but Scrum lets you make time. You factor doubt into your feature estimates just as you do complexity and effort; a task you don’t know how to complete will take longer, so its estimate will be high. Or you create a ‘spike’ task explicitly for experimentation.
        And yes, ‘sprints’ of ‘war room’/’crunch time’ mode are bad. That’s why you estimate tasks so you can work at a sustainable rate in an iteration without burning out.

        So I’d say the indicators of a good Agile/Scrum project include being able to be honest about when the business isn’t supporting the team, isn’t clearing impediments out of the way (there does need to be a less intrusive way of recording the hours) and is making unrealistic expectations about productivity.

      • Yes and no. This is where I have trouble, because on the one hand No True Scotsman, and on the other hand, I’ve witnessed non-violent transparency, strong stakeholder participation, collective ownership of the code, and it has all led to really good results. I’ve also witnessed violent transparency, weak stakeholder participation, and juvenile redesign tug-of-war in code, and that has all led to predictably poor results. I’ve noticed a pattern in the cases of poor results: enterprises adopt a defined process that takes the easiest-to-implement elements of agile software development (writing tests first, sprints, backlogs, having a Scrum Master, tracking velocity) and ignores the most effective ones (rapid market research and feedback through delivery, stabilising teams, involving programmers in the business in order to develop ownership of the product, ruthlessly eliminating any unnecessary work, allowing mutual voluntary transparency to develop, ruthlessly planning to measured capacity).

        I don’t call this No True Scotsman. On the contrary: clearly some people are missing the point of agile software development. Many. Most, it seems. I understand why.

        If you’ve never seen it work well, then I find it reasonable for you to conclude that it doesn’t work. I’ve seen it work well, so I’m left saying, “Maybe you missed something.” Maybe. It annoys the hell out of me, too, when someone assumes that you must have missed something. I say “Maybe”.

        As for your second question, the forces that lead to doomed agile adoptions are much, much larger than a single person can handle. An executive who believes that “Only by demanding the impossible do I get greatness” has a fundamental, philosophical opposition to planning to measured capacity, and will instead use team velocity as a club to beat the programmers about the head. That’s just one example. How the hell do you expect two days of Scrum training to address that problem? That’s a religion-level difference of opinion. It’s a clash of worldviews. That, I think, lies at the heart of why so many people think agile doesn’t work.

        When I teach this stuff, I tell people plainly about two fundamental, diametrically-opposed assumptions focused around how a person reacts when mistakes happen/things go wrong/they encounter results they don’t like. People generally believe one of two things: (1) We need to think longer and harder about this in order to get it right next time; or (2) We need to get more feedback sooner in order to get back on track sooner. That’s one snapshot of the difference in worldview that I see. The people who tends towards (1) will find agile anywhere from annoying to insane. The people who tends towards (2) tend to succeed with agile, assuming that they can find the resources (ideas, money, time, and people) to do something valuable with the feedback they gather. (Some people never improve their lives, but they enjoy buying self-help training so that they feel like they’re doing something.)

        That’s how I see it. Like I often say, I live where No True Scotsman meets But You’re Missing The Point. Opponents find it so easy to brush off “You missed something” with “No True Scotsman”. I’m not moving the goalposts here. Many people out there are kicking the ball in entirely the wrong direction, and people like the author of this blog post end up hurt as a result. I don’t want to see that, but as long as some enterprises are run by executives and managers who believe in beating people to get results out of them, and as long as those same executives and managers golf with other executives and managers whose companies have “gone Agile” and find it fashionable to do the same themselves, then those enterprises will continue to miss the point, perpetuate the cycle, and burn well-meaning people out, like the author of this blog post, who remains left with the impression that agile did it. I understand. I think it’s wrong, but I understand. Fundamental Attribution Error. We all make that mistake.

        • Isn’t Fundamental Attribution Error the one where I act how I act because of temporary circumstances, but you act how you act because That’s Just How You Are?

          If so, I’m missing the connection to the previous topic.

          • My mistake. Ignore the Fundamental Attribution Error bit. I mean to say that one blames one’s failure on the rules, rather than questioning one’s application of it. “We tried baseball and it didn’t work.” No True Scotsman does not absolve one of the responsibility of understanding the fundamentals of what one is being advised to do.

        • WordPress ate my longer version of this comment, but…

          Michael is saying, among other things, that applying the Scrum rules as written often gives a bad experience. In fact, a much worse experience than *not* applying Scrum rules. I’ve worked at a number of Scrum shops, I’ve read the book, and I agree.

          When you say, “there are a set of things which, if your workplace is already good and healthy, will make Scrum work well” I’m inclined to say, “good people trumps good methodology. So why are you focusing on methodology, and worse, on methodology that makes bad people worse?”

          I used to consider Scrum an interesting experiment in how to do project management. Having now worked in four shops doing Scrum, punctuated by one that didn’t, I’m now basically of Michael’s opinion.

          Scrum is a set of rules that must be carefully applied by good people or they actively do harm. In a workplace of less than 95th-percentile quality, that’s a recipe for disaster.

          • I agree with one addition: applying the Scrum rules as written *without listening to the feedback that the pain in applying those rules exposes* often gives a bad experience. When 50 kg overweight, one tries to do sit-ups. One does 10 of them, then feels sharp abdominal pain. One summarily decides “sit-ups don’t work”. The fat, not the sit-ups, causes the problem.

            We used to write often that agile/Scrum shine a light on problems; you then have to decide whether you want to fix those problems. When you shine a light in your basement and see 100 cockroaches scatter, the light didn’t put those cockroaches there.

            • Reviewing the Scrum guide (http://www.scrumguides.org/scrum-guide.html), I’m reminded that I’ve never actually used Scrum. Indeed, almost nobody has. It bans titles other than developer (“no exceptions”), subteams (“no exceptions”), and requires that the team is self-organizing and fully cross-functional.

              I had thought Michael was doing a pretty good job in his article of picking something specific to address as Agile, but I had forgotten the extent to which nobody actually does Scrum.

              With that said: I agree that a lot of the problems that Scrum shows are real and not caused by Scrum. I’m bothered that often it makes the symptoms of those problems worse. It’s a little like if you had a great diagnostic method that also caused harm, but only to sick people. Is that a good thing? Well, maybe.

              • Scrum gives the middle finger to specialties, which goes back to MOC’s point about Scrum having little interest in one’s career. If I want to specialize, or am really good at something, or happier doing something … not allowed.

                There’s also the concept I’ve seen proposed that “the team succeeds or fails, not the individual.” I don’t buy this concept. Stronger team members end up supporting the weight of the weak, and no one is allowed and excuse of “not my specificity.” Nothing is outside of your job description, whether that be writing Cobol, cleaning toilets, or stripping for clients.

                > I agree that a lot of the problems that Scrum shows are real and not caused by Scrum.

                “In a perfect world, scrum works:” Maybe, but the world isn’t perfect, and neither is scrum. Even in a perfect world, I disagree that scrum is always the right way to do things. Solutions should be designed around the problem, not the other way. “Jesus is the answer” but I didn’t even ask my question.

                Is scrum ‘revealing’ problems, or is it exacerbating problems? I’m not denying the existence of problems, but what if it’s just making those problems worse?

                  • In addition to the above, please also see this video from Dave Thomas:

                    “Agile is Dead” https://youtu.be/a-BOSpxYJ9M

                    Robert C. Martin (“Uncle Bob”) and Dave Thomas are longtime software developers and were both present at the original meeting where the “Agile Manifesto” was created (http://agilemanifesto.org/). In these two videos, they describe the history of software development problems in the 1990’s that led to the creation of Extreme Programming, Scrum, and “Agile”, and how a good idea has been hijacked and has mutated into something harmful.

        • To look at it another way: emergency powers for leaders and crisis mode can also lead to really good results. It’s still a bad idea 98% of the time.

          • I struggle with this one. On the one hand, yes, any crazy recipe can be made to work by sufficiently-determined people. On the other hand, I see a significant, clear difference between martial law and agile software development!

            We come back to the clashes of worldview. Dictators can always seize power temporarily, but the long arc of time bends towards justice. From this you can believe either that dictators have free rein to run parts of the world at their whim and leisure or you can believe that dictators will always fail. Two reasonable interpretations of the same observations. So it is with agile: people fail 95% of the time with agile (mostly, I think, because of a fundamental clash in worldviews with many established business practices in general and software project management practices in particular), but the 5% who succeed never, ever want to do it “the old way” ever again. Never.

            There’s something there.

            • On the one hand, that’s fair. I can’t say “I’ve used this in several places and it caused problems, therefore it always causes those problems.” If you’re right about the 95/5 thing, no wonder I’ve never seen it work.

              On the other hand, be careful with this argument — even with crisis mode, crunch time and martial law, 5% or more of people “succeed” and never, ever want to go back to the other way. Alas, that explains things like the games industry and most modern police departments.

              I worry about Agile *specifically* because of who I see be enthusiastic about it. I wish I had camera footage from my last round of job interviews because it was a place that *loved* Agile, is famous for it, makes well-known Agile tools and could have stepped directly out of Michael’s article.

        • Hi Joe, very well said! And I concur with your assessment.

          (Also I’ve also really enjoyed all your presentations I’ve seen. *hugs* I find your efforts to be very encouraging. My many thanks, keep up the good fight!)

      • In my experience, I have come to believe that there is no such thing as a real good Agile/Scrum project. In all versions I have encountered, quality suffers, and no clear management structure exists. If anything, I think Scrum makes it, even more, possible to brush issues/bugs (even those caught by developers) under the rug.

    • What a surprise – if you have a problem with SCRUM then the problem is you. Standard response – thanks for the null input.

    • @Sila: sila is obviously young and hasn’t seen the type of terrible results agile can create in organizations that don’t have the personality/domain makeup required for it to work well.

      I’m saying this as a 33 year veteran with 13 years of management experience. I’ve seen agile failures for quite a while now.. my question is, where is agile succeeding? I’D REALLY LIKE TO KNOW!

  11. Pingback: Why "Agile" and especially Scrum are ...

    • No good answer. It could be hard to find a methode which is not containing more than a bit of the others. If this is the plan, the engineers need more time to find the “right” methode than to make the job.
      And: There is no perfect rule to choice. It’s depending on the project type, size and integration. And finally it’s depending on the people’s team skill. A lonesome wulf is a lonesome wulf. I any kind of project.

      • You hit the nail. I’ve worked with “Waterfall”, “Scrum” and “XP”, and the best results came from an “unknown methodology”: A mix of them. Is it Agile?, yes, but it is not Scrum.

        1) Identify the modules (as in old waterfall)
        2) Decompose the module in functionalities
        3) Develop functionality and deliver to be tested (not in production at all) (an Agile approach)
        4) Get feedback from the business (as you are still developing the module, it’s an early stage)
        5) Convert the feedback into new functionality
        6) When the module is ready, release it (waterfall again?).

        The problem with this? It’s a pain in the neck for Project Managers, because of step 5. They need to know ahead the cost per module, but there is no way, because new functionality can be found during the development (Moreover if you are using UCD). That’s why everyone should be screaming to the PMs and Managers: Estimation is not commitment, look for “uncertainty cone”!.

        • I would add ‘repeat steps 4 and 5 as necessary’. This would be what I have always called ‘iterative development’ and what has always worked best for me, producing stable, feature rich, bug free code. I say this having developed software since 1978 (the days of the big orange Yourdan design book). The companies I worked for that adapted agile were always a disaster and produced (very inefficiently) buggy spaghetti code. Because of the 2 week scrum schedule pressure, there was never time to rework buggy, poorly written code. All of the emphasis was on getting to the next user story as quickly as possible. Taking longer than anticipated on a story was strictly forbidden. It also tended to benefit entry level and clueless team members to the detriment of the more experienced team members. This article accurately describes my experiences with agile/scrum development.

    • I came across the Spiral Model – http://en.wikipedia.org/wiki/Spiral_model – which is related to something we do anyway in scientific work:

      1. Identify the problem to be solved, or identify what needs to be improved.
      2. Devise a plan, and define what is a success. How shall we tackle the problem?
      3. Carry out the plan.
      4. Decide if the goals have been met. Success? Failure? Sum up what we’ve learned.

      After each cycle ending with 4, we begin again with 1. This is often done informally, as steps 1 to 4 often result in a single published scientific paper anyway. So it’s rather somebody else that’s picking up at step 4, and beginning his own work at 1.

      Anyway, we very often have mixed assignments: Something should be ready in three days, another thing must be finished in four weeks, another project in five months. We don’t change projects/tasks every week, as Agile seems to imply. Remarkably, I don’t think we’re piling up technical debt at any significant level.

      But again… we’re not driven by “business”, though about half of our projects are privately funded.

  12. Truth spoken. The precious knowledge of skilled programmers being held hostage of the business. They fooled us so well that I know countless developers that are actually proud of being part of a Scrum process, not because makes things easier, not because delivers better software, just for being part of a hype, created and enjoyed solely by the business.

    • Seriously, if you ignore the knowledge of skilled programmers then that is definitely not a problem of Scrum or Agile.
      I work in a company living Scrum and I have influenced a lot of decisions with my “little” experience and knowledge.
      Therefore of you think you have knowledge that is important speak with your team about it, the team itself decides how things are implemented. Definitely it is not written in stone but the point is to improve your way of working and if your knowledge is held hostage I would say first point improving would be to start changing that 😉

      • Fabian – I’m glad you’ve had positive experiences. However your response reads as a standard SCRUM devotee – anytime someone like me (or the OP) discusses the serious issues with it the response we get is “the process is fine – you’re just doing it wrong”.

        • Yes I can see that. Sometime it is helping to sleep a night over. But back to topic, I know there are a lot of problems and as far as I can judge it is because Scrum in general can be interpreted and adopted in many ways, some work, some do not.
          In some cases people blame it on Scrum, in some cases they blame it on Management in some cases they blame whoever. I blame myself sometimes 😉
          When I have read this blogpost I was a bit shocked about how “aggressively” the writer is against Scrum and/or Agile and as Scrum works for me I get into the thinking that something went wrong on the writers side.
          As what Scum is, is written down the same for everyone, it does not work for everyone the same way, so I would say the problem is neither the process nor the writer or everyone it didn’t work out. I think the problem is shifting to the environment and situation around.
          Well Scrum is really open actually, so that is why the process might be the problem for a lot of people, can we agree on that?
          As Carlo has written, he points out that knowledge is held hostage. That’s something that should not happen. Question now would be why he is thinking it is held hostage? I think as a developer I should be free to use my knowledge to improve whatever product and process is used, help out my team as much as I can.
          I can agree that some companies do “use” Scrum or Agile because it is fancy pancy and sometimes it blows up badly, sometimes it works out.
          But I am drifting off. I think the process can be fine, but is not fine for every situation and environment. Best would be to empirically try it out and improve it if it does not work out, that would be an Agile way, tailored exactly for the situation over time.
          Who is to blame? Noone! Instead of saying what is bad it would be way more interesting on how can it be improved or what people do that can work as that definitely would be more productive.

          • I think we’re in agreement now.

            Look at it this way – this article has triggered a situation where a whole lot of people are venting against SCRUM (obviously including me) & Agile (I’m not against this). OTOH a whole lot of other people are saying its fine, it’s works etc etc.

            This is where the scientist must conclude that the model as it stands is broken – clearly *something* is wrong somewhere.

            My own experiences are that most technical people hate it and pretty much all non-technical people love it (your mileage may vary).

            But it isn’t the technical people who have an input into what process is used – it’s management. They love it because it forces technologists to de-mystify things and makes them feel safer and more in control of risk (real, stolen, borrowed, imagined). Technology is scary if you’re not “in it”.

            Clarity of action is not a bad thing in itself – but forcing professionals to do it every single day is garbage, self-defeating and demeaning. The doctor, the lawyer, the vet, the structural engineer, the pilot are not forced to breakdown their daily tasks into easy to understand terms for the layman. If they were people would stay sick, criminals walk free, pets die, bridges collapse and planes sit on the runway.

            But as someone else said earlier on this post – we’ve already lost this battle.

  13. Michael, I would greatly appreciate it if you could write about what, precisely, your definition of Agile is. It makes it very hard to understand these articles otherwise, despite sensing that they contain good insights.

    • I think a problem is that Agile ends up being what ever you (really, someone in management someplace) decide you’re willing to do. Don’t like that part of the process? Then don’t do it. Makes it difficult to talk about deficiencies then because “Well, you weren’t doing True Agile!”

      For example, IMAO having unit tests is an Enabling Mandate to be able to do Agile of any kind. Without the unit tests you simply can’t make a change to code without worrying that you’ve broken something. In the last ten years every company I’ve worked at says they are doing Agile, but NONE of them have had running unit tests. NONE. (Note that they have all _had_ unit tests, but they were not turned on and were so badly out of date as to be useless.)

      Most forms of agile *give permission* to choose to not follow practices that you deem “not useful”. The problem is that choosing to do the Right Thing is often costly and its not always evident what either the right choice might be or what the final cost will be /at the time you need to make the decision/.

      The practices associated with more traditional project patterns were the result of a lot of though about “How would we avoid making that stupid mistake again in the future?” With Agile, if you don’t see the risk coming you can’t justify the effort to avoid it. With traditional patterns you do things in a certain way knowing it’s not always required but it will keep you out of trouble without thinking about it. (Sort of like staying on your side of the center line in fog…)

      IMAO, adopting an Agile development style opens you up to a lot of unnecessary risk. It doesn’t guarantee you’ll have problems, but then again neither does competent Iterative!

      • This comment is making me rethink my opposition to the original blog entry.

        Agile has always suffered from a lack of hygiene factors. Anyone can do whatever they want and call it agile.

        I would love to see some kind of hygiene factor, like an agile maturity model.

        If there was a 1 – 10 agile maturity model, I’d be willing to bet that in the fortune 1000, maybe 1% (that’s 10) would have a maturity rating higher than 3.

        Those 99% which would have a rating of 3 or lower are what agile and scrum are being used for comparison.

        Without some kind of hygiene factor, agile and scrum will naturally devolve to what this article describes.

  14. It sure sounds like bad experiences made and mismanagement sufferd. Any system and model will fail if you don’t question it as you do it, may it be waterfall or agile. The base of doing agile right is living the deming cycle and listen to your workers/colleagues. Everyone matters, everyone wants to do a good job and achieve something. (If not, take measures..) The PO/SM/PL/Team all have their duties and are sitting in a boat together. If they don’t see that, you’ll have a hard time. That includes showing respect for the knowledge and personalities. Everyone does have their strength and will contribute it. But if the shit hits the fan, I expect a developer or even the PO or PL to do testing for example.
    On the other end, I expect the PO and PL to watch ahead and talk to the team, so the architectural problems are reduced. As written, you can not take the chance to work only sprint-by-sprint.
    In the end, it takes the right environment, the right company, the right people, to get it done right. It doesn’t matter if it’s agile or waterfall or whatever. If it fails, it fails. Not because of “the management”, not because of “the process”, “the design”, “the architecture”… It’s always just about humans and communication (and that’s so easy, isn’t it 😉 ). The funny thing ist, the agile manifesto does put exactly this into focus.
    Argue about agile, about waterfall or whatever. They are not the problem. People and their (inter)actions are.

    • Great comment! I totally agree: It’s primarily the people who matter – the process definitely has an influence, but it does not decide about success or failure.

      And as I already said in my previous comment: I was lucky enough to always work with great teams 😉

      In all these projects, we didn’t follow the process mechanically, but instead we continuously improved it. Btw. this is why there’s a retrospective: If sth. is bad, talk about it and improve it. This includes the process itself! Of course, some things cannot be changed (especially in big companies), but this is independent of whether you’re doing waterfall, scrum, kanban or any other process model.

  15. Thanks for this great blog post! But sorry, I have to disagree. I mean you’re totally right about some problems, but you’re IMHO not right in saying that it’s all Scrum’s (or Agile’s) fault. Bad management is the norm, customers not knowing what they want is the norm. Btw. this applies to both, external customers and internal (same company, different department).

    Scrum provides a very good way (short feedback loops) to crystallize what the users of the software really want. At least, this worked very well in my experience.

    I am a very experienced software architect + developer (working for 21 years, now) and I worked with many companies organising their work in many different ways. For already a few years, I work as a freelancer – and many of my customers use Scrum. Nobody ever abused me for work that is “demoralizing”. Scrum simply caused the work to be split into chunks (user stories + tasks) and then every team member picked what they could do. Being one of the most talented and most experienced, I usually picked the tasks that were most complicated, of course – it was usually fun 😉

    Additionally, it was definitely *not* true that all the input into the product backlog came from the product owner / customer. The team often added things they considered necessary (e.g. refactorings for purposes of cleaning up, improving performance, …). These stories – we usually call them “technical stories”, because they don’t come from the user – were discussed with the product owner (who has the final word about priorities, because he *pays* for it) and we usually managed to get them into one of the next sprints (because he always understood why they are necessary – of course, we had to explain this). Btw. in some projects, we had a certain percentage of the capacity reserved for technical stories from the beginning – then we didn’t have to discuss them with the product owner – but we usually still explained why we did what we did.

    However, I definitely can agree that many companies implement Scrum incorrectly. Already your impression that the Scrum master is in a hierarchy above the team is IMHO absolutely wrong and implies that the company you experienced this in made major mistakes. In all environments I worked, we actually didn’t have any hierarchy at all – just division of labour with nobody looking down on anybody else. But if you want to imply a hierarchy by who tells whom what he needs to do, then it was usually the Scrum master who was “below” the team: He had to clear impediments identified by the team. And these impediments were nearly always external (usually missing interface specs from other teams).

    But then, I usually work in Germany. Maybe the work culture is different in your country. Or maybe I was just lucky? If so, I was for many years and I hope this continues 😉

    • I can confirm, that it is a good way to organize in a better way. For me it works like it does for you, like the team members are the guys who make the call on what will be done, and what not. Additionally we don’t expose our selves. Only the team can say whether something will or can be done. However the team is mostly not involved in getting the first information on what is required, but we have so called “research” stories (or spikes), that are in use to talk to customers and whoever to get a grasp on what is needed.

    • “Btw. in some projects, we had a certain percentage of the capacity reserved for technical stories from the beginning…but we usually still explained why we did what we did” 😀
      You are saying you needed to do this and let the business know AFTER you did it. You are cheating Scrum, and that reinforces the concept of this article.

      • No, we were not cheating Scrum, because at least the way I understand it, it’s one of the core ideas of being agile to adapt the process to your situation in order to maximise the benefit. It’s not dogmatic! Read the agile manifesto, if you don’t believe me. It states:

        “Individuals and interactions over processes and tools”

        At least I understand this as a clear “adapt the processes, whenever it makes sense”.

        And if this adaption means to simply allocate e.g. 20% of the time for work *the* *team* (not the PO) considers necessary, then be it. It’s still Scrum! Why? Because this stuff still is in the product backlog, it still is described as a story, it still is broken down into tasks (if needed, i.e. if not already small enough) etc.

        Btw. one of the goals of Scrum (and Agile in general) is to reduce overhead. If there is enough mutual trust, it is clearly possible to reduce some overhead by not discussing certain things with the product owner in advance (or even at all).

        For example: Need to switch from library A to library B, because it’s faster, more secure or has whatever advantage? Why should you consume the product owner’s and your own valuable time discussing this? If he trusts you (= the team) and your expertise enough, then having the said 20% limit is enough for the product owner to be sure the project does not burn too much of his money without his control – and especially he trusts that this money is burnt in alignment with the PO’s goals (i.e. better quality, lower technical debt etc.).

    • But bad management is pretty much exactly what this is about.
      The management will simply enforce these models as they are “flavor of the month” so to speak and in big companies you have no real possibility for feedback that gets respected because as developers you are usually in the “delivery” part of the company and automatically are outranked by either management or business needs.
      The article, IMHO, is not strictly about why agile and scrum without any outside factors are objectively bad, but how these models are enforced by management expectations, business needs and so on to ruin the company in the end.

      • Well, “bad” is a very vague term. There can be bad management in multiple ways. Without wanting to elaborate more on this, I made the experience that Scrum helped to give everyone – including the managers – a better idea about the situation of the project. This often already helped to improve things.

        If “bad management” means, you have a project manager who tries to micromanage everyone, then obviously Scrum won’t help. But then, nothing will help but a clear statement: “Either you do your job and leave me alone doing mine, or you can continue tomorrow doing yours and mine!” I’m sure this would help 😀

        • …just wanted to add: If you don’t have the guts or simply don’t want to confront this micro-managing manager, then go to the Scrum master. You found an impediment! And it’s his duty to clear your way 😉

  16. Any sane person would not do sprints after sprints after sprints. I think Agile was coined by people who never did any serious sport in their live. 🙂

  17. I think this describes a process that I don’t recognize at all, despite working with scrum and other agile methods for years.

    The only point that doesn’t strike me as an outright straw-man is the difficulty of representing technical debt in the process (which can be mitigated by a disciplined team that factors this in when estimating story points and that considers a clean and thorough implementation part of every task).

    The rest?

    Business-driven? No real power for the engineers? In basically my entire career the openness of management to engineer input regarding strategy and priorities has been proportional to how agile the project was. Giving the customer the chance to change directions by prioritizing differently usually elicits fruitful discussion and promotes better domain knowledge among engineers. Despite what their names (“Master”, “Owner”) imply to the superficial reader, scrum roles are not at all about establishing a pecking order, but about defining responsibilities among equals. Tasks are not imposed on, but claimed by developers, which gives me plenty of power over what I am going to work on and in what order.

    Young man’s game? The agile part is not about aggression, reflexes and quick thinking, it’s about how the project deals with change. It acknowledges that changing requirements is inevitable and, ultimately, to be welcomed. It does so by delivering iterations early and often, by making the cost of change transparent and, again, by giving the client a way to reprioritize.

    Career coherency? How long and in what technical capacity one works on a given project has little to do with the methodology. Also, I have never been asked to provide a list of projects that I have worked on from start to “finish” (whatever that even means).

    Impediments are about identifying slackers? Toxic micromanagement? I have yet to see an impediment that even implied that “Frank is too slow”. Usually it’s stuff like “slow network”, “library x makes it very hard to do y”, “we lack expertise in the field of z”. Which are all fine and necessary problems for the scrum master to solve. The increased transparency in who is doing what only becomes a problem when the project is managed incompetently or maliciously. So far I have mostly encountered management that understood that certain tasks take much longer than others and that developers need quite a bit of wiggle room to find good solutions (and therefore that “tasks closed” is only marginally better as a metric than “lines of code”).

    Whisky goggles? The best engineers leave? Setting aside the weird tangent about measuring engineer capabilities on a one-dimensional scale with unclear units and drawing far-reaching conclusions from that, my experience has been quite the opposite. Apart from making below average developers do average work, in my experience agile methods seem to provide an environment in which above average developers and “stars” thrive. This is because it encourages the team to pick the tools they deem most appropriate for the task. Delivering early and often is something the better developers that I know are doing anyway. Claiming tasks also lets them use their abilities much more efficiently than having tasks imposed on them.

    Of course there are scenarios in which agile methods don’t really apply, such as exploratory software development and r&d. But, apart from marketing pitches, I rarely see agile methods advanced as a dogma. It’s a tool in the toolbox that is not nearly as catastrophic as you, probably hyperbolically, describe.

  18. You’re so right with this blog. These companies using crap are falling to pieces. I mean look at them, Salesforce, Google, amazon, spotify. These companies have been effected by Scrum in such a bad way. Which planet do you live on? Lol… Apple just reported some of the highest profits the world
    Has seen and their secret sauce being Agile. Forbes covered it all very well. Don’t tell me, they don’t know what their doing either? Lol…

      • Jones, are you serious?

        Apple reported its financial results for the quarter ending December 27, 2014. The company posted $18 billion in profit (on $74 billion in revenue), the largest quarterly profit by any company, ever.

        There outspoken secret sauce a combination of Agile thinking & methods.

    • Their secret sauce isn’t agile but good people. Also, I wouldn’t really call what Google does “business driven developement” but whatever – thats maybe just me.
      This article isn’t about singling out agile or scrum as the single bad thing but how the usage of those two paradigms combined with bad management hurts especially IT corporations with detached management in the long term.

      • Sebastian, “Their secret sauce isn’t agile but good people”…. have you ever read the Agile values or principles properly? Nearly all 12 map to cultivation of collaboration – (check out Schneiders model and map it for yourself) – nearly nothing falls into control and a little chunk in competence. Agile in one word IS people.

        ” bad management hurts” – exactly – it’s nothing to do with the approach or mindset used (which has been cried about in this blog ‘Scrum is bad’ etc”). So should we gun down proven mindsets or approaches which bring benefit – or ask the people who are trying to use those approaches to use ’em properly? What’s next? Butter knives are banned because people are using ’em to stab people and not butter bread? “Why Butter Knives are terrible” – looking forward to the next blog.

  19. Pingback: When (not why) "Agile" and especially Scrum are terrible - LeaseWeb Labs

  20. I’ve been fighting a rear guard action against SCRUM at my current place. It’s had mixed results. I’d like to say that this post would help but when the bum master admits that the stand ups don’t add any value yet refuses to change them or cancel them, I have little hope.

      • but thats exactly the problem, isn’t it?
        The management hears of a new trend. Call it “agile”, “scrum”, “ITIL” or whatever. The management also hears its totally great and should be done to the T so they enforce it in all their glory without realizing that they are doing more harm than they would without doing it because there is no continious improvement of the process and because these models/paradigms aren’t tailored to their scenarios.

  21. Agile is a lot like communism. Both have a eponymous manifesto, and whenever one of them inevitably fails, the apologists just say “Agile/Communism didn’t fail! You failed because you didn’t implement true Agile/Communism”

  22. There’s so much wrong in this article…

    I suppose Scrum and Agile _can_ be implemented in the way you describe, but that would be totally wrong. I’m sorry people have to endure that…

    Good Agile (not necessarily fundamentalist Scrum) can empower the team and everyone in it. In my last team, I saw a junior programmer thrive, and a “Senior” developer get the exposure needed to become “Principal”. We had a great working environment, with acceptable pressure.

    But you need to enforce (especially to management!) certain non-negotiables:
    * The team is free to pick as much or as little as they feel can be achieved without overtime.
    * The team is free to drop stories from the sprint.
    * The Definition-of-Done cannot be weakened by management (quality, testing)
    * The team keeps about 20% of it’s capacity to handle tech debt
    * Status reporting is limited to Stories, Epics, and important bugfixes. Anything more granular (sub tasks, spikes, etc.) is team-internal. (There is no brutal transparency!)
    * Team “velocity” is a team-internal measure only; it exists to help the team improve its forecasts, _never_ for reporting to management.
    * The Scrum master’s task is protecting and supporting the team, NOT driving it.
    * The Product Owner has no say in the organization of day-to-day work beyond pushing for stories in the sprint planning.

    • You are right, there is much wrong in this article.

      I have 30+ years of experience in software development in all kind of positions.

      I worked with a wide variety of development processes, from waterfall, Scrum, Extreme Programming to “Head Physician”-like Guru-lead teams, Lone Warrior Teams and total anarchy development.

      First of all, there is no one-fits-all process or organization. The people, the project, the organization and the type of funding are all things that need to be considered, and you have to make an effort to improve each of these factors. You also have to adapt to what you can’t change, and work with what you have or can reasonably get.

      To make things work, you can draw from all known processes and add and mix in whatever works, and don’t forget your try your own ideas. The agile movement has quite enriched the toolbox of what is available, but if you grab the wrong management tool set or do not understand the limitations and prerequisites, everyone will suffer.

      And I can agree that agile is definitely not suitable for many types of projects and organizations. It is not very good for mass product development, and agile also has problems with contract work if the customer does not fully buy into it, which is the usual case.

      There are also people where a process complete clashes with their personality. Some people just can’t do agile, some just can’t stand documentation. What kind of process you personally
      like to work with also changes with age and experience.

      Just from reading the article I get the feeling that the author wants to or already has moved on from dreadful jobs like he describes, and he still seems hurt. He also does not seem to be happy with his current situation and might be unknowingly regretting some decisions he made.

      He is right about one thing, though: There are more fucked up companies and IT-jobs out there, and probably everyone in the field has seen bad things and even might not have escaped unharmed.

      However, if you are not satisfied with the jobs the market offers, get together with some friends and create the jobs you would like to see, including your own. That’s what I ended up doing in my 30s, and I enjoy it. And don’t forget to move on when things get boring. There is so much out there to see and learn!

    • I surmise your last team really needed agile to succeed. I think your team could have succeeded just as well without agile or scrum. The points you made here doesn’t require agile.

  23. Pingback: Software’s management issues | Michael O. Church

  24. Really interesting article. Thank you!

    I am an engineer wanted to implement scrum or/and kanban, because the currently applied time in estimations and ways we do engineering are even worse, I think. Only for my team, I´m a firmware programmer. I heard so much good thinks about agile it, the self improving and so on, how could it be so bad?. But now I´m really unsure about it. It looked great to me, but indeed I don´t want to work every day in war-mode, and only feature driven with now big goal. I wanted to get better product requirements, get more time for programming and less for writing documents. Better team communication. Get rid of time estimations for the next one and a half year, while knowing it is not worth of doing it and in the end everythink is different. we got problems because of not getting the firmware finished in time. The idea of weekly builds, that are are tested automatically should find errors much faster, and should also reduces the long testing periods. I work on many project at the same time and it slows down everything. Agile claims to improve it. But I have many old programmers (50 and older) that are not that good but good enough. I made the experience that especially the old programmers are having even more problems to accept new processes.

    What do you think should I do?

    I also think good programming and engineering is more important in the first time than improving processes.
    What are you think about CleanCodeDeveloper (http://clean-code-developer.com/)? It really like it, and it helped me a lot.

    (excuse me for my bad english)

    • automatic testing does not check for most problems. If your software is so simple it can be checked by automatic testing then is something one person can do by itself. If not you still need human testing. Just stay away from Agile…

  25. The description of your “Scrum master” might be the reality in the environment where you have seen Scrum at work, but that role is not meant as deciding manager. The role of a Scrum master (bad word) is not a technical leader, that is the “Product Owner”. Scrum does also not only base on “User stories”, but can and should have a design document, which is maintained by the “Product Owner”. The main problem with the “Scrum master” is that he imposes the rules (the Scrum rules).

    That doesn’t make Scrum as a whole a good idea, but it is very obvious that Scrum originally was not meant as business-driven process, but as engineering driven one. And the “Project Owner” should be a senior engineer with a product vision.

    What makes Scrum so appalling in reality is that it is the best way for a “chaos manager” to keep the chaos alive and grow it. This “chaos manager” must take the role of the Scrum master, because that’s the part who can make sure that chaos will come and stay. That’s why the Scrum master is supposed to be a servant to the team, and I’d say the team should have the right to replace the Scrum master whenever they want to. Or “at the end of the season” when you think of him as “coach”.

    IMHO the essential problem of *all* these methods is when they are adopted for business driven companies, which will create the same perverted framework out of all of them: The technical part will, no matter what kind of original idea you take, always be “grunt work”. That’s the wrong approach.

  26. A rant by a disgruntled engineer at best. Agile isn’t perfect but there are no alternatives either. Plus there are always ways to avoid the issues he has management e.g. you can prioritise long term issues in favour of short term, I have done that several times. Maybe he needs better product managers around him.

    • Total bullshit answer. A great engineering team can produce great outputs – but not when you constantly interrupt them to find out what they’re doing at any given time.

      There are plenty of alternatives – spit out the Kool-aid Fahd.

  27. Pingback: » This Post Brought to You by the Word Study A Book A Day

  28. Definitely a good article on this topic.

    First things first: I am neither a programmer nor a native English speaker, so I can’t judge if the concepts of Scrum/Agile make sense or not and maybe I am not able to bring my point across.
    What I can say is that from what I have seen amongst my programming friends, Scrum/Agile sometimes made things better but in most cases killed the fun and creativity they have with and in their jobs.

    This is the point I want to highlight: Neurosciences show clearly that there is a strong correlation between being able to learn/being creative and being happy/feeling good.

    The last environment in which you want your brain work getting done is in an environment of fear and granular control mechanisms. This is what our school system does wrong on a global scale and in many cases our employers as well.
    Being controlled in an asymmetric relationship can drive humans into a state that psychology calls “learned helplessness” with the above mentioned outcome.

    Let’s be crystal clear about our world of work: In most cases the work is done in capitalistic environments. This means that there are contracts between several parties which have to be fulfilled and everybody has to work in order to get money, because this is what has to be used to pay back the debt an individual has. In either cases the lack of being able to fulfil gets sanctioned in some way. You don’t fulfil your contracts? Boom, here comes the government/lawyers. You are not able to pay a certain amount of money at a certain point of time? Boom, here comes the government/lawyers again.
    So we see it’s all about money and money is in almost any cases I can imagine free of moral and ethics.
    Scrum/Agile just emphasises this aspect of capitalistic systems to a degree that we, as hard and brave working people, start to recognise how messed up our working environments are.

    We blame the sender of the bad news. The culprit is something else. 😉


    • Even though I don’t agree with Scrum being as bad as it is talked here (I still have a lot of fun doing my job), I definitely agree with you that capitalism totally sucks.

      To be most precise, I think that we, the software developers, still drew one of the best lots in the current times: We have still far more space for creativity and far more freedom than most other jobs.

      • True!
        And yet we still seem to be more affected by doing less than ideal tasks or downright nonsense under a less than ideal or idiotic management.

    • +1

      Great observation. It puts the whole “agile / scrum / waterfall / causes of project failures” debate in a so much broader and more important context.
      Arguing about agile vs. waterfall (“sender of the bad news”) seems to me the result of a top-down “divide and conquer” strategy applied by ones who actually benefit from this (“the culprit”), just like how “chaos managers” benefit from chaos.

      Any methodology could work if we value our own and each others’ time and work enough by not creating or accepting rubbish, and keep people, honesty, and common sense in mind – words not often heard, or heard in a twisted context, on software development projects.

  29. Massively agree with all of this. The comments here along the lines of “you’re just not doing it right / believing hard enough” are depressingly predictable too.

    • Yes, it’s a power play, and the developers lost. People of “average” (I use the term loosely) intelligence, e.g. management, are fearful of tech people because tech people can easily lie to them and get away with it. Waterfall is by far worse than Agile in its dysfunction, but Agile has much to answer for. Over the past ten years, I have suffered through everything the author speaks about while working on Agile projects, including outright humilliation, not to mention the lousy work areas that all use “agile” as an excuse. I have seen the “brain drain” phenomenon twice now–and the crappy people never leave because they have nowhere to go! You can’t make this stuff up. It’s a race to the bottom, and as someone who just hit 20 years in the business, it weighs on me heavily because there just is no clear path to “what next.” How do you make a career in software development? You can’t. It is designed to diminish and ultimately ward off the most intelligent, most experienced, and most highly paid people and replace them with as many “commodity” underlings as possible.

      Businesses want quick sugar rush work done, not thoughtful engineering, nor long-term employee satisfaction.

      • It’s very likely that companies you describe exist, but they are doomed. One “star” developer is worth far more than a dozen “commodity underlings”, because the latter will screw up architecture, increase technical debts more and more and finally lead to an absolutely unmaintainable mess. That’s the end – at least of the project in question – maybe even the whole company.

        I made the experience that many companies understand this risk very well and thus welcome highly talented, experienced and *expensive* developers. I don’t know, if this only applies to freelancers (I’ve never been employed – except at my own companies). But only lately, I was in a team where the majority were highly talented and very experienced developers. And the minority of newcomers (with little job experience) definitely learnt a lot due to the agile way (e.g. via pair-programming [we could have done more of it, but at least we did some]). Btw. despite 21 years of experience, I myself learnt quite some stuff, too (as always – that’s one of the reasons why I still love this job). 🙂

      • You nailed it. I think that, unless software engineers mobilize in order to take back their industry and find some kind of collective solution (it doesn’t have to be a union; it could be a professional guild) to keep it taken-back, then the whole game is fucked.

        • Yes. Great article. To me it’s clear ‘agile’ originally was a programmer-driven initiative to take back some measure of control (particularly against outsourcing in the US), that has now been twisted against us. Partly we can still use it to our advantage, and partly it uses us. This kind of thing is nothing new in the history of social movements. I wonder if you have seen this article which kind of lays this out — http://westspacejournal.org.au/article/summer-2013/the-agile-union. We need a new tool now.

          In my opinion, if we don’t prioritize ways of crossing the divides between programmers and other tech workers (not to mention other workers period, without whom we could not function), the whole game is fucked for sure. That is one of the main weaknesses of agile in my book, its ‘guild chauvinism’.

          Could we start with e.g. demanding jobs with less working hours? It seems insane to me that industry-wide, part-time positions (not consulting etc.) are very rare. Few of us (in US and Europe anyway) need to work full time to earn a living wage.

  30. Seriously?!

    You totally missed the point of agile workflow, and probably that the reason why it makes thing worse. Agility is not a matter of managing developers, it’s a matter of involving everybody. Company shall protects his programmers, while the customer is enough involved in the project to A) understand constraints (and thus accept R&D / Refactoring / Improvements) and B) get a final product that suits his need and does not generate frustration.
    Customer and developers should be equal in the balance. If not, something is done wrong.

    A scrum meeting protects the team, a scrum master is not a foreman. A sprint meeting with a customer is always a negotiation for both sides.

    • And once again we get the standard response – “Oh you just don’t understand SCRUM”

      SCRUM dictates to intelligent people the boundaries within which they are “allowed” to operate. This kills innovation at super-luminal velocities.

      It does have some benefits – eg. when you have a mix bag of juniors and rubbish engineers
      and its better than a free for all.

      But the cost to real talent is exorbitant. Just because you can’t see it doesn’t mean it isn’t there.

      It’s standard management high-level fluff – get everyone talking and some kind of magic gestalt will happen – even in the face of all available evidence to the contrary.

      I understand SCRUM perfectly – inside and out – and it is the worst thing to happen to our industry since Facebook.

  31. Dumb POs/managers stay dumb, if you change the process. If you really know your product and the programmers work, you can give room for individual things. In a good scrum team you plan 50-80% of the time for the whole team.

    Additionally its a common thing to ask the team for internal needs and put them into a sprint.

    The only thing what scrum really demands is cycles and 3 meetings per cycle. The rest is open to you.

    At least I know several companies, which asks the teams itself about the processes and change between several processes related to the task they have to work on.

    So in fact you’re blaming an (stupid) imlementation. Its similar to blaming C, Java or whatever, because you found code that sucks.

    Similar to a programming language, the tool scrum doesn’t say to you, in which cases, in which departments of your company and how much you should use it.

    If you have stupid scrum masters and/or managers which makes from every problem a nail, you will have a perfect tool with a hammer.

    • >> The only thing what scrum really demands is cycles and 3 meetings per cycle?
      So If I participate in 3 meetings once a cycle of any length then it’s legitimate Scrum? That’s a bit too broad for a silver bullet methodology. Can I sleep or play angry birds during those meetings?
      Programming language analogy is good, C & Java indeed don’t show you what the best practices of using them and suggest bad things by default (nulls, mutability, implementation inheritance etc.) but this is very different topic

  32. I am sorry you suffered so much with Scrum and Agile.

    You’ve put your finger into many things that do occur at companies that are trying to adopt agile practices. Yet none of the things you describe are necessities of Scrum or Agile. They are just conditions a company can be in, but should progress through if they are truly Agile.

    Thank you for your opinion it helps to make the world better.

  33. I am a Postdoc in Bioinformatics (prior to my PhD/Postdoc time, I worked for many years as a bioinformatician in the life science industry) and I would argue that Agile software development is a brilliant approach to structure (and finally realize) rather complex scientific programming projects as well as to help supervisors to keep an overview on their students’ progress and potential problems.

    The biggest issue in academia is, in my opinion, that hands-on programming skills (including design patterns, software development techniques etc.) are somehow neglected because there is a huge emphasis on the theory part. Ok, the latter is important but are computer scientists not supposed to be able to write good code/programs once they finished their education? To make it clear, when I left university many years ago, I was quite enthusiasiastic but I soon had to learn that my skills required a lot of improvements.

    If you are not bringing these skills to the party, it is very likely that no one will teach you these in a desired extent. Thus, young scientists, at the beginning of their PhD (or their first job in the industry), oftentimes are not sufficiently able to structure their programming projects. They are wasting a lot of time in writing code which is literally unusable by others (their supervisors / other PhD students who need to work on that code base some years later). I saw this with my very own eyes multiple times.

    In combination with the acquisition of design patterns, Agile software development can actually teach people to successfully finish their projects. Moreover, by nature, academia doesn’t have this “we will all die if the project isn’t finished in time”-mentality. There is simply more time to thoroughly think through all the different aspects of an application. Here, Agile helps a lot to guide you through long-term projects and to use your time in an efficient way.

    TL,DR Agile is not necessarily bad, especially in academia it comes in very handy

    • So in summary it allows people who are not formally trained in software development to produce code that doesn’t suck.

      OK – fair point. That’s hard enough to do even when that’s *all* you do.

      But the article is discussing professional engineers and computer scientists who are treated as cattle under SCRUM regimes.

      It doesn’t mean agile (not SCRUM) isn’t useful in many areas – as you point out.

      Agile methods are great – SCRUM is a whole other story though.

      Hey good luck with your studies!

  34. Pingback: Why "Agile" and especially Scrum are ...

  35. Interesting blog post beside of the fact, that it is written “pretty aggressively” against Scrum.
    I am working in a company where we use Scrum and guess what, it works pretty well.
    When I read your blog post I had to laugh a few times because I see mistakes like team members being outranked for example. It sounds so wrong honestly! Which developer wants to switch to Scrum if he can’t influence a project?
    If a PO is saying what has to be done and not listening to the team then it is predestined to go wrong. Besides, a Scrum Master is a servant leader, serving the team, not ruling over it. Back to the PO stuff, the PO should always keep an open mind for refactorings for example. Some people argue refactorings do not bring values so they don’t do it, later they complain about their technical dept piling up. In my opinion refactorings do add value, but it is not direct value, it is indirect value and a lot of people are only thinking about direct value, unfortunately.
    Well, in the end everyone has to decide for themselves how they want to work.
    For me, my company and our customers Scrum works great so far. So if it works right for you, keep doing it. If it is not working for you change it so it works for you. And if you really hate it, than that’s okay, too, probably.

    • Fabian – that’s the most reasonable statement I’ve read of yours so far. Thanks for not just spouting the SCRUM kool-aid and presenting a good argument.

      I agree – if it works awesome.

      My objection is the fanatics now infesting every company everywhere telling me how I am to work every day and what I must (“no exceptions!”) and must not (“no exceptions!”) do.

      I’ve sat in too many all day meetings doing planning/grooming/retros etc when no one wanted to be there simply because management bought into the whole thing.

      I knew it was time to go when the engineering manager (a high priest of the SCRUM church) showed me how to draw a smiley face on a post-it note to stick on the white board under “things we did well” during a retro.

      I’m forty-fucking-three years old and a professional computer scientist and I’m NOT doing this anymore…….:)

  36. In my opinion the core of the article is here:

    “[scrum] has engineers still quite clearly below everyone else: the “product owners” and “scrum masters” outrank “team members”, who are the lowest of the low.

    […You] work only on your assigned tickets”

    When this is true, get out as soon as you can!

    IMHO, the product owner and scrum master should be part of the team, not stand above it. Scrum only works when people in the team are responsible for their own work. This means everybody is involved in creating the user stories and in evaluating their impact.
    Only when a team member comes up with their own tasks and estimates will scrum work.

    Besides that, I think a very valuable point is that you can’t be sprinting all the time.
    Three days of sprint per week makes sense.

  37. This article gets so many things so wrong so many times words fail me. Sir, in all honesty, you have no idea about Agile or Scrum and your claims are false so many times over I cannot count them.

    What you describe as Scrum has nothing to do with it – those things are, if at all – fragments of completely backwards and crummy implemented Scrum Methods.

    You mention companies going near broke because of Scrum but fail to offer examples. You mix up Agile and Scrum (hint: they do not overlap entirely, in fact, they can contradict each other at some points) and you call Agile a “fad” that is cool with web consulting but fail to mention the Agile Manifesto that started the craze.

    On top of that, your classification of people and IT professionals and their performance is one-dimensional, degrading and disrespective to the point of being anti-social.

    Bottom line:
    I’m sorry to say, but your assessment of Agile and Scrum being terrible is worthless with this essay as a backup to those claims.

  38. Thanks for writing this up. You seem to be frustrated.

    Im a Software Engineer with 15 years of professional experience and am in the process of implementing scrum in my company right now. There are several things I disagree with:

    1. Engineer driven Companies: There are good and bad examples. Only the good get the awareness, no one knows how many failed. In my experience writing business software, software enigneers suck big time at defining the product that sells, that meets the customer needs, that works on the market. Everything designed like that, that I have seen, failed, even my own designs. Let’s be honest. Most of us are software engineers out of passion, I sure am, but the stuff needs to sell, otherwise we’ll only be doing it as a hobby. Lots of these new companies swim in investor money. They don’t need to work profitable for some years. Only time will tell if their business and therefore their products are profitable… and if they are I am sure they are more than just good engineers.

    2. The way you describe scrum leads me to the conclusion that where you experienced it, scrum started way too late in the development process. Experienced engineers are the most valueable ressource, they code better, they estimate better, they document better, they teach how to be better. Scrum, in my understanding, does not lead to a sprint backlog full of simple tasks that every monkey developer can do. The first scrum task for every requirement we get is: Design the software. Requirement specs in our company are reduced to the form “I want this and that. Make it work.”. Designing how that could work is the first task for that requirement. That’s where the experenced programmer, the software architect, works together with the requirement owner to work out the design, the architecture, the dialogs, the test cases etc. This design document is managed and owned by both as a team.

    What you describe really sounds like a “waterfalled srcum”: Do all spec work beforehand. Break it down to simple dumb tasks, and make sprints out of them for the novice programmer.

    In my understanding scrum is not for coding alone. It’s for design, coding, validation, testing, documentation, etc.

    3. As others said. The Scrum Master is no desicion maker. He simply is an enabler to make the sprint work. And the scrum master is a technical guy. Not business management.

    4. Transparency is a good thing. My team was intransparent. No one knew what we were up to until one year later when we dropped a huge pile of new software at the feet of our quality management. The transparency introduced by scrum, in my opinion is helpful. It makes the development team transparent to its peers. It helps the team reflect on its work, refine the teams skill in time estimations and gives the rest of the company a good indicator, that the team is indeed productive. What tasks are done in a sprint, even their definition, is the teams desicion. If the team decides, that the refactoring of a module is necessary, that task is valuable.

    Me and my team are looking forward to working in scrum, but we’ll surely will look for the points you make here.

    • Engineer-driven programming itself is not sufficient.
      For example, gitlab receives feedbacks from customers on http://feedback.gitlab.com/
      ZeroMQ receives feedbacks and pull requests from customers and developers on github projects.

      I think it helps to receive feedbacks from stakeholders(users and developers).
      My idea is to let everyone report problems and vote on those problems.

      And, while some transparency is good, it is a terrible idea to expose one’s daily performance fluctuations to everyone else, which makes developers vulnerable to outside attacks regarding daily performance fluctuations. And, scrum doesn’t help with violent transparency. In my past company, every worker was attacked almost daily by middle managers and product managers, and I was too stressed out that I quit the job.

      • Transparency is good, I agree on that.
        Honestly, your middle managers and product managers should have been kept away from the working team! Your scrum master should have seen that problem.

  39. In our company scrum had positive effects. What you call “dangeroursly short-term” helped us to stop doomed approaches after few sprints instead of waiting until the “7+” engineer finally had to admit his failure to himself. What do you propose to avoid such costly vanity projects?

    What you call terminal juniority helped us to integrate junior programmers in work that created benefits for customers, instead of keeping them away from knowledge and our brilliant heritage until they ripened (or quit). What do you propose quickly get new employees up to speed?

    Scrum isn’t for geniuses that don’t like to lower them selves to to common plebs. Scrum isn’t for those brilliant minds, that cant stand being judged by the ignorant.

    It’s for making progress visible the way the customer values it. It forces the developers to talk to each other. Sad but true: I can write breathtaking brilliant, beautiful code. But if it’s not what the customers need, I’m entertaining a hobby on cost of our teams productivity.

  40. SCRUM is not the problem, it is the the people doing SCRUM.

    Management believes the hype.
    Adopting a process out of hype before checking if the actual work to be done fits into the process, is really bad management. For instance, a “many projects all at once with different skill sets required” type of workload does not work at all. I know what you are thinking: The typical workflow of web company

    Management reshapes work
    After realizing that it does not work as advertised, the organizational and operational structure of the company undergo an “optimization”. While this is necessary for SCRUM to a certain extent, one major mistake is to understand SCRUM roles as a sort of hierarchy. A SCRUM master is not a “manager” sort of thing … the bossy type of “leaders” really like being SCRUM masters because “Master” is really what they feel like being … and management tends to assign “master” type of jobs to “master” type of people … Another mistake is to wildly mix and reorganize teams by means of leveraging knowledge, counseling others, and so on and on and on and on …

    Workforce gets pummeled
    The workforce gets pummeled by a shitload of organizational stuff and role switching and role playing. Advertisement of SCRUM says: “Teams lead”, reality says “Money leads”, management then says “bad teams”, reorganize … until: reduce headcount. Management then never blames it on themselves trying to force a system into the company which does not belong there … Also dogmatically following the rules or not following the rules at all will lead to catastrophic results

    Consulting by SRUM companies
    There’s a whole bunch of professionals out there teaching SCRUM. But, as always, how can you tell real pros apart from the amateurs without having the slightest clue of the game yourself? It is like screaming “Offside” in a basketball game. So the consultants come, teach, take your money, you feel fine because “I learned a lot” but you did not understand a thing. You need to learn but you refuse because the teachers told everything and they where fucking expensive so it should work now and you don’t hire them again because “Hey, I doesn’t work, bad teachers, not worth the money” … devils circle, cat biting own tail or whatever …

    Just my 2ç 😉 …

    • Nicely said!
      I want to extend your points about Scrum Masters by one simple sentence “Scrum Masters are servant leaders serving the team, not leading them”

      • Some say the scrum master should be a rotating position, as different members are master for each sprint.

        • Nice idea! I think for some people that might not work out as they are not that type of people.
          Will bring this up at our next retrospective.
          Still in my opinion I think there should be someone doing scrum mastering most of the time supporting the rotating scrum master with his experiences, could be helpful.

        • That won’t happen because often times the scrum master is chosen because the person is so abysmally bad at writing code that the company is desperate to find them some role where they can do less apparent harm. That they should be outright fired never seems to make it into the decision tree.

            • Many places “do it wrong”.

              Another common occurrence: The daily “standup” lasts an hour, with the boss telling everyone what they did wrong.

          • I’ve never seen a “bad developer” in a scrum master position. Moreover, I’ve never seen *any* developer there.
            They were always ex-PMs without any hands-on technical background. 😦

            • This is most common. But according to Scrum founders, the Master is supposed to be a rotating position filled by a team member, not an outside snitch for management.

  41. Interesting article, thanks for that.
    It seems you see the mismatch between Propaganda and Reality to be an accident.
    But it is not. It’s systematic. It’s divide and conquer.

    See here: http://softwareandmind.com/
    e.g. page 34/35 (and footnotes on page 35).
    “deskilling of programmers” dojne on purpose.
    In that way, the programmer relegated to being a “coder” becomaes cheap and replacable, and powerless.

    • The footnote states “Their authors were unaware of the fallacies of software mechanism, and that theories like structured programming do not, in fact, work. Thus, the delusion that programmers must be a kind of factory workers”.

      I understand that they tried it and “deskilling of programmers” simply does not work, right?

      Well, no matter, if I understand this correctly or not, I – being a skilled and experienced developer – can tell you for sure that this is bullshit. And it becomes even more bullshit. Today, software development is far more complex as it was 20 years ago: We use far more libraries (thanks to Free Software, hooray!) and thus don’t need to reinvent the wheel, i.e. we need to write less. But our challenges grow from day to day – and in order to integrate the multitude of libraries correctly, you really have to understand what you’re doing.

      Deskilling?! Only a non-skilled manager could have such an idiotic idea! 😀

      • You think like a developer, not like a manager 😉
        If you can get 5 cheap coders for one expensive, but experienced programmer,
        add some SW-methodology-voodoo (plus Scrum-stuff), the manager may think,
        this is a way to go.
        Of course it’s good to now some methods, but it’s also necessary to know the limitations. The one who does not see the limitations of the methods may have less experience than he/she thinks 😛 and/or not enough overview.

        What A. Sorin writes about, could also be called “the mythical man month” (Brooks),
        which Brooks also had good reason to write about – because managers all too often fall into that fallacy.
        (Sorin goes more into detail than Brooks, but also covers a much wider field. The book is about “myths of mechanistic thinking”, which are wide spread. The library-mess also is mentioned…)

  42. So, what you are basically saying is that agile fails because companies are not following it’s principles but instead adopting project managers, management hierarchies and other old school habits that are result of power struggles and mistrust to the process to cripple the team, the product and their transparency. This is hardly a problem in the methodology but rather in the people not following it, probably because they do not believe in it. We have been doing agile and lean for 3 years now and have almost nothing but positive experiences and can honestly say that the overall success rate of web development projects has never been nearly this high in this business.

  43. I’ve lived in a waterfall-type environment and many scrum/agile-type environments. I think it comes down to the team. If the team has a great team-lead (not scrum-master), it seems that everything goes well: the team generates great features and quality code and is happy. When the team has a poor team-lead, things tend to spiral down to a grinding halt. The book Tribal Leadership talks a lot about teams. Waterfall/agile/scrum/RAD are all more business-based and process-based … usually to help programmers and upper-manager communicate back and forth. Whatever works best … use that. I’ve had some project managers that have a gift for communicating to upper management and allowing us coders to do our job, and insulting us from the painfully stupid questions upper management asks.

    Personally, I hate the idea of running an all-out sprint, followed immediately by another all-out sprint. I never ran two sprints back-to-back in track — I’d throw up and maybe pass-out.

  44. What utter nonsense. Both scrum and waterfall are legitimate forms of managing a software project – I’ve seen both work with success. It’s easy to develop a hybrid approach as well. Like all methodologies, agile and waterfalls have strengths and weaknesses. You only focus on the latter and offer no improvement or alternatives. Contrary to your article scrum DOES in fact empower developers. This was a pointless rant – I want my 20 minutes back

  45. And you think that all your negative experience with flaccid Scrum applies to everyone else and all other companies?! Some of your critism has its truth, some I cannot follow at all. However, criticising something is good, but having better ideas is much better. And I cannot get any better idea out of your blog. This is disappointing.

  46. Hi @Michael : I agree with your quote

    ” I know 3’s making over $200,000 and I know 7’s under $70,000, ….”

    Why is this so? How do we fix this? Or, better, what kind of system would incentivize a fix? (I have my own ideas about this…but, wanted to hear yours).

  47. Michael, first of all TLDR and to much venom spread to go through. Second do your homework first, because writing articles on false assumptions to make point is easy but lame. Just few things I noticed.
    “The “Agile” fad grew up in web consulting” – no, it didn’t. It’s quite opposite end of the scale. Read up about first Scrum implementation by Jeff Sutherland.
    “Waterfall replicates the social model of a dysfunctional organization with a defined hierarchy” – no, it doesn’t. It doesn’t say about hierarchy. Dr. Royce in the original paper about waterfall writes about iterations between phases and there should be more phases than what was used by the last 40 years. Even waterfall wasn’t implemented correctly in companies.
    If in our opinion both Agile and Waterfall replicate dysfunctional organization model, what is the methodology or model that replicates well built organization?
    “It has engineers still quite clearly below everyone else: the “product owners” and “scrum masters” outrank “team members” – no, it’s hasn’t. PO, SM and Development Team are equal, they are part of the Scrum Team working together on common goals.
    “work only on your assigned tickets, spend 5-10 hours per week in status meetings” – nobody talks about tickets in Scrum or Agile. And there are no status meetings run. There are only minimum required inspections with appropriate attendees to check the real progress and make decisions.

    “There’s no role for an actual senior engineer on a Scrum team, and that’s a problem, because many companies that adopt Scrum impose it on the whole organization.” And what’s the problem with that? You need to have a senior label sticked to your back to know what is your value and feel good? In the Development Team there are only equal Developers in order not to apply hierarchy and fixed set or responsibility. In other words it’s about responsibility in the whole team.

    “It’s stupidly, dangerously short-term.” Again, it’s not. We encourage long term planning. Agile planning is about Portfolio->Product->Release->Sprint->Day planning.

    “Its purpose is to identify low performers, but it has an unacceptably false positive rate.“ No, no again. The purpose is to build high quality Products, learn fast and adapt quickly to the environment.

    I believe that all this negativity comes from your personal experience in environment where Scrum was implemented totally upside-down with some silly ideas behind. What you are describing here is not real Scrum. It is some gimp called Scrum implemented to check the box on TODO list in the organization. What you mentioned here is not why Scrum is bad or Agile is bad. These are simply the DON’Ts that we teach about in the class or at work with teams site.
    I strongly recommend you Scrum training with one of PSTs, to show you what Scrum is really about and how it should be implemented. I would give you special discount, but I guess I am based to far from you. Learning how to work with the method and be effective is much more professional than whining why it’s difficult. Every day there are less and less Waterfall cage where dinosaurs can hide 😉

    • Mostly +1.

      One of the points of the rant of the OP is that Agile is imposed on teams. Getting people to the mindset of adapting and responding to change is really the goal of Agile. Once there most of the crap can go away. Who really cares if a standup happens or not. If it provides value then it will be done, and, it will be done in the way that suits the team best in accomplishing their outcomes.

      I said “Mostly +1” because there is a statement in your response that bothers me. Perhaps it bothers me because I catch myself using it and I know I dislike the phrasing. “We encourage long term planning”… I have a problem with “We”. Who are we? Why do we encourage?

      I think that to be empathetic to those being coached, we must move away from encouraging practices and move to sharing practices so that *they* can decide the best approach to get the most value from *their* work.

      Once Agile is not imposed and people feel control over their environment I believe that a number of problems go away very quickly. Moving from being told to being engaged is critical to creating a more joyful workplace. Dan Pink expresses it as “Autonomy, mastery, and purpose”. Dan Mezick use Open Space to introduce Open Agile Adoption (http://newtechusa.net/)

  48. As a few other people have said, this issue has little to do with Agile, Scrum and standups, and more to do with people blindly applying a process for the sake of it. Agile was supposed to be all about horses for courses, and tailoring your process to be more responsive – yet people just grab the Agile bible and bash everything with it, creating loads of process and benefiting little.

    Stand-ups can be very useful if they’re done right. Yes you’re going to have one interruption in the morning but if you can’t handle that then you shouldn’t be on an enterprise development team. If you run a very short standup so the team lead knows what everyone is on an what’s holding anyone up, they can let you go back to your work and fix the problems in the meantime. It lets them pass the necessary info to the higher ups to build trust in the development team, and gives them an early opportunity to escalate any problems so that you don’t have to deal with them, or find workarounds or wait to finish something because of some stupid policy or lack of decisions.

    The entire thing is about finding the minimum amount of useful information to extract from developers in order to be able to relay status to the business, and conversely be able to capture business requirements and extrude the bare bones of technical requirements for proper architecture and development. Do that the right way and everyone’s happy.

    If you’re still complaining about having to log your time, or account for where you’re spending your time, then you’ve no place on an enterprise team. Whether you’re developing MVP for a startup or building ongoing big business software, the only way to manage a project properly is to know where the time is going, and identify blocking issues early. There’s no place any more in modern business for the genius hacker who won’t do what he’s told or fit in with the team – an intermediate coder with passion and the ability to go learn what he doesn’t know, and follow process is worth infinitely more to any business.

  49. Now that I saw it:
    “There’s no place any more in modern business for the genius hacker who won’t do what he’s told or fit in with the team – an intermediate coder with passion and the ability to go learn what he doesn’t know, and follow process is worth infinitely more to any business.”

    oh yes, there needs be a place. otherwise we’ll be going to a full stop staleness within 2-3 years. I hope non-visionary people stop having input soonish or this will be 1984 world to live in.

    And no, I’m not a dev.

    • No I didn’t say there’s no place for a genius, I said there’s no place for someone who can’t follow process and won’t work in a team. Unless they’re the only coder (and sometimes even then) then they’re more trouble than they’re worth. You should always be hiring developers (at all levels) who are innovative, passionate and curious.

      • As long as they don’t work on more than one ticket at once.

        Because it’s been decided that this isn’t the best way to work. So you must do as dictated.

        Whilst I do basically agree with you – I hate those so-called genius types who can’t/won’t work with a team and they definitely shouldn’t be on an enterprise team – the SCRUM affliction isn’t the answer.

        I don’t agree about the scheduled interruptions – they sap motivation faster than an enema. All that happens is everyone turns up at 10 because there’s no point starting anything any earlier.

        A smart PM will get the best out of a team without having to refer to a master manifesto that outlines your working day.

        Agile yes – I’m all for it – but SCRUM is the embarrassing progeny of minimalist thinking.

        • Yeah I agree SCRUM isn’t the answer. And whether you call it a standup or not, a daily catchup *is* needed but it should never be more than a minute or two in length. Generally I avoid anyone labelled as a SCRUM master as they tend (not always, but usually) to be overly focussed on the details of a given process rather than creating process that suits a team.

          There also has to be discipline within a team though. It’s up to the team lead to work out whether it’s best to enforce a standup at a given time in the morning or find some other time or way to do it, and it’s up to them also to manage people in the team who aren’t meeting the criteria.

          If you meetings, stand-ups, reporting or anything along these lines is getting in the way of development, then you have a process problem. If you have good quality, minimally intrusive processes in place and developers just won’t follow them, then you have a discipline problem.

          Get your process right *for your environment/project/team* then get your team working with the process.

          • Well said.

            Agile development is a state of mind – you need to work with the team and people you have – some are best in the morning others at night. It’s a dynamic fluid approach that recognises that people are *complex* thinking beings and tries to get the best out of a team by treating them as adults and professionals rather than plug ‘n play tech units.

            And that’s my problem with SCRUM. It’s a manifesto carved on stone tablets brought down from Mt Sinai. You must do it this way and no other – and woe be unto you who worship false idols.

          • Out of curiosity: why “daily catchup *is* needed” ?

            I found daily startups a useful tool for building a team, but once the team is performing I found it more beneficial to talk with people on 1:1s (coffee?) once a few days to understand the status of the tasks. (project manager view)

            For reaching out for help I found group IMs + direct communication between engs more effective (timely) than stand up.

            So why daily catchup *is* needed?
            Who not once a week, bi-weekly or “let me know when you’re done” ?


            • There are people who are more communicative and others who are – let’s say – shy. Or maybe they just don’t drink coffee. Believe me or not, in my last project, there were really 2 people who didn’t drink coffee! 😀

              The daily stand up gives everyone the possibility (and kicks the shy people’s ass) to shortly (!) mention what they’re doing. This very often actually causes a follow-up discussion about the details.

              And btw., even after team-building, the people don’t communicate via telepathy – they still need to talk to become aware of the big picture. Otherwise everyone only knows his own tasks and maybe a few things closely related.

              Why daily? Because *a* *lot* happens in one single day (at least I’m productive 😀 ). After a week – or even two – so many things happened, that the standup-meeting becomes really long (too long!) and maybe you even forget to mention some of the things you did.

              And even if you did only one or two big tasks: They’re likely already complete and you can only find out afterwards (when it’s too late) that you did unnecessary, redundant work or somehow caused other problems. Meeting daily increases the chance you learn about redundancies and other interferences early enough.

              • At least one good thing I can say about a stand-up meeting is it prepares you for that accidental encounter with upper management in the hallway or restroom when they ask “What are you working on?”

                • What is bad about curiosity of upper management? 😉

                  About daily stand-ups, well sometimes I don’t like them, they look like a burden.
                  But there is a big big upside to them! Like when I had a problem with something some of them were like “Oh I had that problem in the past, I can show you” or “I never got that right in the other project, let’s talk after how you did that”.
                  Well, if I am in the “matrix” and hacking like a machine it is a bit shitty to be interrupted, true, but I am so damn glad some people can help me or I can show them something and in my opinion that is totally worth it 🙂

                  • It is actually great to see people, that observed stand ups working well 🙂
                    Perhaps you could share how you are solving several problems the ones I participated suffered from?

                    1) Updates are cryptic.
                    Half of the team is working on technologies and libraries I have never used.
                    I do not understand what they are saying, what’s more – I do not care (I do not have time to understand all the details).
                    For me to understand – it would take 15mins talking about this problem.
                    The result is that half of the team is at any given point of time bored – the meeting is boring and the energy is drained from the team.

                    2) The amount of work is not enough for an update
                    I worked mostly on backend stuff. The reality was that tasks were taking a developer up to a few days.
                    So such person ended up reporting: “I am doing the same as yesterday, no problems” – the effect is the similar as in 1), the impression that the meeting is a waste of time.
                    When splitting work further, we usually ended up with artificial list (write pipeline – 4h, wire QA data – 0.5h, debug on QA data – 24h 🙂 )

                    3) It is hard to tell what is the purpose of the meeting.
                    I have specifically SCRUM in mind here.
                    If the purpose is to get help – why not just limit to the question “do you have any problems?” (and be done with standup in 2 mins 😉 )
                    If it is status update – why not send a status update email instead?

                    Please do not take me wrong – I absolutely see a need for communication.
                    I just do not understand what is the benefit of daily meeting of the entire team (e.g. 5-10ppl) in a situation, when I am able to really follow technically 2-3 ppl from this group (or you actually do not have this problem? in your teams most people grasp all aspects of the problem/project?).
                    Why not talk in smaller group or send an email?
                    Would it make a difference it the meeting was every second day? Or twice a week?

                    And.. thank you for previous answers 🙂


                    • Hi Mica14
                      That’s a lot of points going on and I know them all from my own experience. Sometimes they even happen to me nowadays, so I can’t give you a direct solution.
                      But I will try to give some hints, you can tell me if they are helpful 🙂

                      1) I get the feeling it has to be a really big product with a lot of technologies and libraries. Difficult to say without knowing more details.
                      One question directly to you: Are you a bit curious what these libraries and technologies can do? How they work?

                      2) One idea in Scrum can be to break down tasks to be less than a workday. So if someone is saying “I am doing the same as yesterday” that automatically becomes a problem. Why was it not possible to complete the task in less than a workday? Code to complex or to much distractions because the guy from management always came to ask stuff? Probably my girlfriend broke up with me and my thoughts were not at work?
                      Debugging uses a lot of time, I have made the same experience. If it is possible the break up this debugging task into multiple tasks, that could be helpful, but that’s a tough one. If I have an idea how to solve this I will let you know

                      3) Well there is different stuff happening in the daily standup in my opinion.
                      One thing is to reflect what everyone has accomplished, well, I could do that on my own like “Yesterday I finished this and that” but I’d like to “show off” that our team has (and in this case I have) made a step to our goal. Honestly it feels awesome seeing that we perform well, melting away the tasks.
                      On the contrary there are problems, what if I didn’t manage to accomplish what I had planned to do yesterday? I could answer that to myself too for sure, but it can be really helpful if someone had the same problem or maybe some inputs. Could give you an extreme example I experienced. And well it stops you from performing great doesn’t it? So it is the whole teams interest to solve that so everyone as a team is performing better. We sit all in the same boat (except of those managers wanting us to row faster and faster) so we should work together (that’s why we as team commit on the sprint goals).
                      And at last there is the point what am I going to do today. Another one I could answer for myself, but communication is an important factor nonetheless.
                      Let’s get back to your team, as you have the problem I had with not getting what all those people are talking about. When those testing people were talking it was mostly like “Aha, okay, no clue, but I think they know what they are doing”. It was boring (and still would be if I didn’t just sit a day together with a tester). For me it helped to start looking into what they are doing. Generally said no one is ever grasping every aspect, that would be to much to ask for! Beside of that no one wants to know everything, but it helps to look left and right.
                      About talking in smaller groups, well you do that after the daily at coffee breaks, during lunch, while going out together.

                      I have no clue if this is helpful in anyway to you, I am not the born talker or explainer 🙂
                      Probably you got some hints from this, probably not. Talk about it with your team on how to improve your daily, experiment a bit with it. You know, it is your team, you have one mission together, so do it together.

                      If you like we can talk more about it, about some ideas you had, some experiences, stuff we tried out or could be worth trying out. Best contact me by mail (fabian dot schweizer at liip dot ch) for that.

                      I appreciate it that you are interested how others look at it, how they do it or how they failed it, you are driven by your will of learning and improving, that’s great! Keep doing that 🙂

                    • => 1)
                      As a freelancer it’s totally normal for me to come into a team which already worked on the project for months or even longer. Hence, I don’t understand anything in the beginning, too. But from day to day, this improves. After usually 1 or 2 months, I understand (nearly) everything and can even give helpful comments.

                      Don’t worry, if you don’t understand all! Nobody knows everything and nobody expects you to. It’s a learning process. Even if you have lots of experience, you (hopefully!) still learn new stuff again and again.

                      For me, these meetings never were boring – even in the beginning, when I didn’t understand much. Maybe I’m just naturally curious 😉 But I had the impression that the meetings actually helped me to get into the projects faster.

                      Somehow, this is like a little baby (I just became a father, lately): The baby doesn’t understand a single word you say. But does that mean, you should stop talking to it? No! The opposite is the case: Talk to it *a* *lot* and it will eventually learn the language in this process (and the more you talk, the faster it likely learns).

                      Of course, learning requires curiosity. But honestly, I never had the impression that people were bored in the daily stand-ups.

                      Since our daily stand-up (in all projects I can remember) was time-boxed (usually to 15 minutes), there’s IMHO really no reason to get bored: This gave every person involved roughly 1 or at most 2 minutes. Hardly enough time to get bored, IMHO.

                      => 2)
                      What’s the problem in saying “I’m still integrating library X, which I started yesterday, and it will likely take another day”? If you can’t break a task down into smaller pieces (even though you should – but again: I hate dogmas and I’m convinced Scrum does not require dogmas) then be it: The task takes longer (how should you break down “integrate library X instead of Y” further?) and you simply report about it. Better this short status update than having a meeting only once a week and bore everyone to death with 1 hour (or even longer) elaborating on the many tasks you and everyone else did during this entire week.

                      Btw. the time-boxing means the daily stand-up should *at most* take this long. If multiple devs state just “same as yesterday – another day to go”, then it’s likely finished even faster.

                      And breaking things down artificially as you said, is IMHO utter nonsense.

                      You know, I’m living in a beautiful country in the far South East (I don’t like Germany and only come there for work, if absolutely needed). Here there’s the philosophy: Laws are guidelines. As long as nobody is hurt, the laws don’t matter.

                      You should IMHO approach Scrum the same way: There are rules, but as long as you get a benefit from not following them then take them for what they are: *Hints* stated to be *helpful*. *Not* rules carved into stone!

                      As I already mentioned in another comment: The agile manifesto explicitly states “Individuals and interactions over processes and tools” => IMHO this means: Never stick to things like dogmas carved in stone. I know that this is hard in the Western world, where people are indoctrinated by 2k years Christianity telling everyone that God carved laws into stones (and thus all laws have to be obeyed this way – everyone else was simply burnt alive). But fortunately, these times are over. You’re not burned, anymore, if you think for yourself and do what should be done.

                      => 3)
                      Why not send an e-mail? Because nobody will read it! Why talk personally? Because we’re humans and it really has “soft” benefits, even if you don’t talk about anything meaningful (that’s why evolution introduced gossip).

                      If you don’t have 15 minutes per day for the entire team (of 10 or even more people) then IMHO sth. is very wrong.

                      Many people stated in the comments that the daily stand-up is an interruption and not worth it, but HELLO?! 15 minutes (only!) of your precious time should really not be too much to personally meet your peers and have some *real* *interaction* (not digital via some programs). See some faces instead of *the* *machine*.

                      Just roughly, the stand-up has these purposes:
                      a) real human interaction (beneficial for team-building, establishing trust and much more)
                      b) status update
                      c) identify problems (kick those people’s asses who don’t raise the issues themselves)
                      d) identify interferences, overlaps, redundancies
                      e) show things (big picture as well as other detail aspects) to everyone beyond the small code/functionality region he’s currently working on
                      f) give an opportunity for further discussion (very often, people walk out of the daily, grab a cup of coffee and talk about certain things in detail).

                      I’m sure there’re even more purposes, which I forgot, now 😉

                      As already said, I myself have – especially in the beginning of a new project – the same problem that I cannot understand what people talk about. This gradually gets less and after a while I can follow most (often even all). I usually had the impression that this was the same for all team members.

                      Agile and Scrum have the goal to distribute knowledge among the team. The more you force people to talk to each other, the more you foster this knowledge exchange. The daily scrum is just one of many ways to do this. Pair-programming is another very good way. But pair-programming approaches it from the opposite side: The daily stand-up is very superficial, i.e. comes from the big-picture-side, while pair-programming is focused on just one concrete feature in depth.

                      Nobody prevents you from *additionally* talk to others in smaller groups (probably more in-depth) about specific topics. Very often, the daily stand-up actually raises exactly these topics and causes such small-group-discussions.

                      Doing the meeting daily aims at keeping it as short as possible. The more time passes between the stand-up meetings, the more happened and thus the meeting would tend to become longer and longer (tiring people even more).

                      Additionally, doing it daily increases the chance that interferences are identified early enough,

                      – before person A broke person B’s great ideas about approaching problem X (which was not yet implemented, but person B already thought about it when working on problem Y)

                      – before redundant code was written (person A mentions sth. that is not the same but somehow similar to person B’s lately implemented stuff => refactor both A and B and use common code instead of introducing redundancies).

                      Of course, nothing is perfect. The daily scrum is not perfect. It’s just one of many ways to encourage people to talk to each other. Hence, I can state just once more: Adapt your process to your team’s needs! Avoid dogmas!

                    • hey,
                      thank you for answers. It is really useful for me to see your perspectives.
                      I guess that as an introvert I undervalue the impact of talking (as opposed to communicating in order to solve a particular problem)

                      I feel I should address one item: it is not that I am not interested. To get a full context for a task I would need to invest quite a lot of time.
                      (eg why changing the variable name that we measure is not 15mins task, but instead requires 3 days of work. It is hard to explain why in 2mins)
                      Given the amount of information I get every day – I virtually do not have time 🙂

                      And small confession – I am one of those who is supposed to want people row faster and faster 😉

                      I do have a feeling that SCRUM stand-up is trying to address to many problems.
                      Therefore it poorly solves them.
                      I would rather prefer to have a meeting focused on one goal only – like Kanban meetings.

                • And if you have to prepare to such accidental encounters and questions, then you already have a bigger problem than having or not having daily stand-ups.

  50. i can relate to the issues you have with agile/scrum. still though, i am happy that this methodology exists.

    in my case it simply helps me to be able to keep developing! i am quite an experienced frontend developer but i am also a single mum with a little 1 year old daughter. i moved to the country side to be close to my family since being a single mum in berlin was not an option for me. it is quite a rural area so there are no jobs here for me (unless i’d like to shave sheep or so :D). luckily, i landed a remote contract so i am able to work. every day there is a scrum meeting over the phone that keeps me up-to-date about what’s going on and makes me feel being part of a team. i get tickets assigned which i solve which is just the right kind of work for me right now. of course it’s not too mind blowing since i don’t work on some big picture. but it’s good enough so that i don’t loose my developer mojo. thanks to scrum the tasks are so well-defined that i don’t need to be physically there to be able to work on them.

  51. I only read the half of the article and stopped. Not because your opinion doesn’t fit into my understanding of effective, highly-productive software development that makes a lot of fun. But your wording is full of hate and frustration.

  52. Being dogmatic to any single approach is a problem – it necessarily makes it a lowest common denominator solution that must fit all situations.

    I understand all of the engineering side reasons why scrum is bad. And employed on a very pure level, it also sucks for the business side counterparts for a lot of reasons…..not the least of which is that ive always seen it detract from accountability – if something doesn’t get done – or engineers need to be moved off to other projects – just push part of this sprint into the next one and as long as its communicated transparently, I’m told this is working.

    That said, there are some conceptd within agile that make sense if incorporated intelligently. I am a huge fan of better connecting the business mgmt and engineering sides but to do that, it starts with the right people. I once worked at a company that professed, “argue like you’re right but listen like you’re wrong”. Get people who think like that and more than half of your problems go away. Hire engineers who not only understand that their code is a means to an end but want to understand the complexities around WHY business decisions are getting prioritized the way they are. Similarly, hire managers who respect engineering, have a capacity and willingness to understand it and share the reasons (and value) behind certain needs. Most importantly, hire business managers who recognize that decisions around value and prioritization CANNOT happen without the input of engineering leadership who provide critical input to the prioritization by understanding and communicating the true “costs” of different options (and their interactions from a code basis) but with their understanding of the business complexities will also provide really valuable alternatives that most business managers won’t see given their different vantage point.

    In other words, come to the table with the problems you’re trying to fix or the opportunities you’re trying to seize. Talk about why those things are important. Ask some thoughts around approaches and what options they open and roads they close off. Ask about the timing and the short and long term resources of different approaches. Discuss the other things that might come up. Jointly agree on the best path. At that point, both sides know why those decisions were made,what the key trade offs were, estimated time frames and the accompanying variables that could throw things off. Have a waterfall-like kick off meeting with the engineering team in which the leads from business and engineering sides jointly explain the whys and what success looks like. Allow for discussion and feedback. You don’t need massive amounts of written documents. You do need your engineering and business leads to stay in regular communication about internal and external developments impacting the project…and then most importantly, make your business managers sit with the engineers. It makes for better communication in the long run and in the short run, when a question comes up about which approach might make more sense on a UX component, you don’t need a meeting – you slide your chair over and get it resolved in a 10 minute conversation. Not only are projects getting completed at higher quality but engineers should also have a higher job satisfaction because they not only see their code but understand why its valuable.

    Yes – you still need some sort of accountability metrics, but like most crappy KPIs, code committed and stories completed measure the activity and not the outcomes. There are smarter ways to do this.

    In the end, this comes down to trust and recognizing that shit happens. A weeks worth of code will become throw away work sometimes because something was FUBARd at the beginning. And business side priorities will suddenly change because of something that was foreseeable. This WILL happen. Everyone needs to work hard to make sure it’s minimized, but it will happen….on both sides. And when it does, it needs honest conversation about why it happened. And then, move on with the best possible plan. If it happens more than it should, you move to another conversation about the person/people consistently responsible for the failures.

    I don’t know what to call this methodology other than “practical”. It has elements of waterfall and of scrum. It’s not one size fits all. It’s built on trust, communication, having the right people and the realization that success requires collaboration from both disciplines.

  53. A thoughtful and well-reasoned post which is, unfortunately, based on a complete failure to understand what Agile is for.

    To deconstruct everything would take forever. Usefully, you provide a helpful microcosm of the problem with the statement:

    “Scrum is sold as a process for ‘removing impediments’, which is a nice way of saying ‘spotting slackers'”

    No. No, it isn’t. The purpose of Scrum and other Agile methods is to help communication. To ensure that what gets developed actually solves the problem it’s supposed to, rather than some idealized problem statement thrashed out between customer and analyst with little understand of what’s required.

    It’s hard to do well. I’ve been fortunate to work in several places where it’s been done well. This post sounds like the product of someone who’s spent too many years in places where it’s been done badly.

    • I think you have to differentiate between why teams want to adopt scrum practices, and why management wants them to adopt it. What Michael is saying is that scrum is sold by management consultants to management as a way of getting rid of underperforming employees. And that may well be true: I’m not privy to those conversations.

  54. Sounds like a lot of belly aching to me. If this time poo-pooing on 2 of the major processes our industry utilizes was put toward being solutions oriented and educating the public how to better operate, we would probably be more receptive. This sounds like one of my kids when I tell them they can’t get a toy from the store.

  55. You seem to be confounding your ideas of how scrum/agile works with an ideal scrum/agile implementation. What you describe above is more of a mini-waterfall implementation which is why it’s so bad. In a good scum/agile implementation the stories are used as a beginning point of a conversation between the entire scrum team and the product owner. From this conversation context and an understanding of what is needed happens and gets developed. The acceptance criteria provides and end point so the people working on the story knows when it’s done and potentially deployable. In good scrum the engineers are just as involved in the story creation as the product people – that’s why it works so well. If you haven’t seen this level and the corresponding success, it sounds to me like you’ve never actually seen a good scrum/agile implementation.

    The second piece you seem to be missing – statistically 64% of what’s developed is never or rarely used. About 20% is always or frequently used. In good scrum/agile the focus is on the 20% so what makes it into production is relevant and as a result, what is delivered is successful and the methodology sound.

  56. This article is a polished turd. It’s well written, but doesn’t say very much that is useful or constructive. In particular you decry “Business Driven Software Development”. I’m not sure what you propose as a better driving force to development than business objectives. Are we supposed to build software to satisfy code aesthetics instead? If you aren’t focusing on value to the business, what precisely are you focusing on?

    This has the bitter undercurrent of someone bemoaning time spent toiling for shitty management in an under-appreciated development role. Get over it.

  57. Enough “truth” in here to make this worth reading, and sharing. I’ve seen both sides of this argument, and I would venture in the end it all comes back to leadership vs management and influence vs authority. Scrum asks for leadership and teamwork. In most companies managers are given roles like Scrum Master, with no idea how to operate without authority they become autocrats instead. An autocratic Scrum Master destroys the basic premise of the scrum. But even a know-it-all Scrum Master is enough to do that. Scrum is a continual improvement model: If you think you’ve learned it all, you’ve failed.

  58. Couldn’t agree more. What’s worse are companies that believe that agile methodologies are so effective that they can be applied in all functions of the business (i.e., Sales, Marketing, etc.). Having two 10-minute daily standups to talk through sales and marketing activities occurring each day is not only a waste of time and energy but also diminishes trust of employees within an organization. And you hit the nail on the head that companies that still use agile as a selling feature are far behind the times and are definitely in survival mode because they do not have a strong reputation within the marketplace. Thanks for your thoughts and words. J.R.

  59. Pingback: Warum Scrum und “agile” toxisch sind | -=daMax=-

  60. What a bunch of horse pooh. You describe cultural & value issues of organisations and management in general and blame the process (agile/scrum). Find a better employer and read a little more about holacracy. Visit us -Groningen the Netherland -> baltimore should be doable- and see what happens if your team is aligned and organisations are management free. Than you’ll see there that agile/scrum is not so bad at all.

  61. Michael,
    Thanks for posting this. I agree with the points you make in regards to scrum. When I started my career as a software developer, as a junior, I had a really bad time grunting trough the user stories and always felt like I am underperforming. Combining all that with the imposter syndrome, it was a nightmare.

    In regards to some project management techniques. I had a really good experience working with a client on a monthly deal. The performance was not measured every single week. If the task takes three days, then it takes three days. That’s it. If there is no trust between you and the client, why the hell are you in business with them?

    I heard a great expression – “If I have self-organizing teams, why the hell do I need scrum?”

  62. Pingback: Thomas Jacob

  63. Pingback: Jason Knight

  64. As an engineer who ave worked from Big Corporations to Growth Stage to 2-person garage startups, I’m a great fan of your blog posts. And this one is no exception.

    This sustained toxicity has to stop and we should start something constructive (project / movement / campaign) in order to change things. If we initiate efforts to address few following causes, QoL of engineers will improve a lot –

    1. Programming/Engineering has ben commoditised (it’s amazing how a creative process has been commoditised !). Hence amidst of high business adoption, there are few uncertainties in developing a “Booking site for hair saloon in Ruby Rails”. It has fallen from its scientific euphoric and exploratory phase.

    2. Engineering is treated as a cost centre. As long as one works in Industry, business juggernauts will ensure that says the same. Also most of time, except few rare cases, developers are often “thought” as “disposable”, as Engineering has ben commoditised (#1)

    3. Somehow it has been assumed that Engineers are all (as opposed to a few) introvert, idiotically passionate about “cool toys and beautiful code” and pathologically incapable of discussing anything on – Market Risk, Finance, Customer Development, Product Design/Management, Customer Channels & Distribution. Hence it has been decided to not to invite them in processes or meetings involving above business verticals.

    4. Engineering & Programming lacks standardisation and hence standard deviation of quality is high. Probably in absence of concrete standardisation (as one of your older posts has mentioned), it’s perceived as a “low status” position.

    Lets start a “pro-something” movement as opposed to “anti-scrum” or “anti-agile”.

  65. LOL
    worse than a fool is people backing up a fool.
    If Agile and Scrum is evil than what is good?
    The problem here is developers not giving a f*ck about what they are developing and doing technology for the technology.
    Grow up guys!
    Scrum helps you delight customers and delighted customers pay you more…
    I’m going to write a blog post about how tech guys earn why too much leading to god complex and arseh*les a like…

  66. Pingback: 06.06.2015 – News | ATTRAPPENJAEGER

  67. I didn’t get chance to read all the comments as there were so many of them so apologies if this is a repeat. I applaud the author as the article is clearly speaking up about things that a lot of people are thinking, but feel uneasy about going public with.

    However the article reminds me of something else I hear a lot about these days – “guns kill people”. I personally hate guns and have no desire ever to fire one, but its not guns that kill people, its people that kill people. And used irresponsibly or even misused, Scrum will sink your boat too. Use scrum in the correct way and it will help your product, just like paracetamol will either kill you or ease your pain dependant on how well you read the label.

    Always read the label:-)

  68. While the most observations made by the author are appropriate, the major conclusion is rather shortsighted.

    It is pointless to blame the Scrum that is only a tool instead of asking whom does it serve.

    The most effects the author accuses Scrum of are the true nature of market fundamentalism and liberal economy itself.

    Under such conditions the short term profit is always going to dominate over sustainability,
    this is where the business goals will conflict with the engineer’s claim for technical excellence.
    More control placed over workforce, less expenditures for human resources are a good way to ensure the maximum profit.

    I could tear up and feel sorry for the qualified IT-expert who is facing devaluation of his workforce and lamenting about his “career coherency”, but I don’t –
    remembering that for the majority of less priviledged professions like cleaning ladies, sales personnel and others it is the only reality they live in, they lack any choices.

    Speaking about “agile” as an engineering approach, you can hardly deny, that from the cybernetics point of view the systems/projects with a shorter feedback cycles are more capable of surviving.
    And the self-organization and facilitated communication in teams have demonstrably proved their contribution to better quality.

    Finally, you cannot compare the Scrum with “failed communist state that equalizes by spreading poverty” without understanding the actual reasons of its failure.
    Nor understanding the fact that this state at least guaranteed to everyone the social welfare, not luxury but sufficient, earned by the land’s people on their own,
    and not at somebody’s costs or by neocolonial redistribution of wealth from the others.

    Remember: under current conditions there is no any “technological neutrality”: whatever improvements the technological progress delivers, it strengthen the power of and delivers
    its benefits to the capital owners, not to you who actually advances the technology.

  69. Pingback: Bookmarks for June 11th through June 12th : Extenuating Circumstances

  70. This isn’t a problem with Agile/Scrum. This is a problem with poor management and not setting up teams for success. The entire point of Agile is to enable teams to deliver on their own schedule and by their own rules, with the team made up of all the people who will enable that to happen.

    The problem with Waterfall is that it created disjoint teams, PMs would chuck the requirements to the Devs, the Devs would try to build to those requirements only to discover two months later that they interpreted the docs wrong, then they’d finally kick that down to QA which would find so many bugs that it needed to be kicked back to dev for another rewrite, only then to discover that it now didn’t function properly to the PMs specs… yay.

    Agile/Scrum brings all those entities onto one team. The best setup I’ve seen is to actually share the scrummaster role around on the team. There should be a technical lead that is helping guide decisions, and if you can’t figure out how to lead a group, then it’s NOT you, as badass as you think your coding skills are, tech leads actually need to LEAD, and titles make no difference.

    For all the different methods I’ve experienced in the industry, Agile/Scrum are the best IMO, it’s your job to make sure that you don’t allow technical debt to back up. That you identify critical issues and fix them as they come up. Businesses must make money, our job is to deliver software to do that, we need to work on teams, b/c you can’t do it all on your own. Talking to that team every day for 15 minutes means that you identify issues early and often and can mitigate them quickly. Planning and creating a backlog means that you have some notion of how long it will take to deliver the software, and allows you to set managements expectations. Doing retrospectives means that you are learning from past behavior and fixing forward.

    Again, your problem is not Agile/Scrum, it’s that managements expectations are not being set and maintained properly and you’re allowing certain individuals on the team to force their agenda. That is not Agile, that’s just a horrible work environment.

    • “The entire point of Agile is to enable teams to deliver on their own schedule and by their own rules, with the team made up of all the people who will enable that to happen.”

      Exactly! And this was how it started and worked for one month, before the PM changed the rules. A fundamental lack of understanding and implementation if the process probably leads to more failures than not. Try explaining to your PM that they are mismanaging the process.

  71. I took over management of a scrum team for a year as a contractor, and found that it had most of the problems you mentioned (starting with reporting to whimsical, unfocused management). I would add one thing though: when I scheduled occasions for developers to actually be creative, think long-range, improve the product, etc, they were as a rule not very productive. While these weren’t exceptional developers, I think the short-termism and atomization of scrum had suppressed whatever creativity and product ownership those developers had had — they were like short order cooks asked to plan next year’s menu. However, it should also be said that none of them voiced any real dislike of scrum as such.

  72. Thanks for sharing such a theory with us. I don’t agree of all of that, but also have the understanding that at the end Scrum is injected to solve the issues about
    – communication
    – transparency
    – workload
    within a project.
    Unfortunately I don’t see any information how to develop if not Scrum? Without any software engineering methods every bigger project would end up in chaos. So what’s your solution?

  73. Pingback: Lazy Reading for 2015/06/14 – DragonFly BSD Digest

  74. Pingback: Why “Agile” and especially Scrum are terrible | The WordPress C(h)ronicle

  75. It’s not about Scrum, Kanban or whatever methodology/framework. It’s about understanding, accepting that the way of (whatever current) work needs improvement. Through recognition of a problem you can find a solution. Not vice versa. Agile is a state of mind. I completely disagree with whoever puts agile in the same bucket with all the rest. Being able to inspect and adapt, always aim for the best, never sit back restless and relax – is not only a way working, but also thinking, feeling, living…

    • +1
      Agile is a means to the end, not a goal.
      Whenever you think that the ever-growing complexity of the world and of software systems can be solved by decent roles or single guys (in isolation) only and by ignoring the fact, that today the only constant thing is change, you are doomed. And no method will help you in that case.

      This article starts with crap and so it ends.
      If something isn’t business (=value)-driven then it’s just playing around or being bored. Even when you do research you most probably have a motivation and expect a value of doing it.

      Another misunderstanding: transparency isn’t there for controlling people but for making everyone involved more successful. For that you need a culture that supports respect and sees failures as chances. Sad you don’t have it.

      Another one: even the best dev in the world won’t build a complex system alone and make it a success on the market. It’s always a combination of the work of many people – a team. It starts with people who listen to demands of people and markets and ends with the ones selling it. In the beginning it could be the idea of one guy but alone hw will be lost in the long term. We often hear about the most successful ones, millions of others failed or stood being small. But that does not mean they were too bad or stupid.

      If I were you I’d think about changing my job…

  76. Obviously, the author never participated in a “real” Scrum project. I feel sorry for him that therefore he cannnot recognize the benefits of agile development.

  77. Maybe you just had bad experiences with Agile/Scrum. There are many areas where I have different opinions but mostly you are talking that engineers and architects don’t have a defined place in this. Scrum Teams are cross-functional so it’s up to the scrum master and the team to identify what roles they need to fulfill the project. I actually have 1 architect and 3 engineers in my scrum team now, along with the developers and testers.
    Also in Scrum architecture emerges. You don’t need to engineer everything upfront. You build the minimal thing that meets the acceptance criteria. Thus you remain focused on the business requirement rather than spending unjustified time in over-engineering something that we don’t know how valuable would be with priorities constantly changing. That’s being Agile!

  78. This article is a classic case of somebody who has had bad experiences. Scrum and Agile isn’t the problem. The problem is that people made you believe that the things you were doing was actually Agile and Scrum. The majority of the things you’ve raised as pitfalls in Agile are the very things that Agile is meant to (and does) eradicate. By the sounds of things you know the buzzwords without really knowing why there were ever born – It’s like me handing someone a fork to eat a yogurt and telling them it’s a spoon. You then start writing about how bad spoons are because it’s not the right tool for the job even though you don’t really know what a spoon actually is…

  79. Pingback: LessThunk.com « Why “Agile” and especially Scrum are terrible | Michael O. Church

  80. Pingback: Why “Agile” and especially Scrum are *not* terrible

  81. I also work in a company that uses Scrum. Currently, we are in a difficult situation. We ca no longer implement features because of the huge number of bugs reported by the client. The huge number of bugs is probably caused by the lack of design and fore-thinking. The Scrum approach is to focus on the moment and forget about the future (to give immediate satisfaction to the customer). Now, we harvest the fruits of this approach. The code looks quite ugly, I am wondering how long it will survive.

    For those who admire Scrum, I think you are still in the early development phase of the project. Wait a little! You will realize its value when the project becomes mature and needs to be maintained.

    I don’t like the never-ending meetings. I would prefer to search silently for solutions than to loudly talk about them, without solving them. I feel exhausted after participating to those meetings.
    The world of software development seems to be led by politicians.

    • If you suffer many bugs and have a huge pile of technical debts, and only find this out now, you – the team – made the mistake to never create technical stories for them, before. This is not Scrum’s fault, but yours.

      Scrum does *not* say, you should forget about the future! Scrum does *not* say, you should write ugly code! In contrary: Scrum is about sustainability.

      That’s why Scrum actually aims at making all things – including the technical debts(!) – transparent! So that everyone in the entire team (not only the devs but also the product owner) can make informed decisions. Obviously, the product owner cannot know about technical debts, if the devs don’t track them.

      Scrum does *not* say “make + ignore technical debts and deliver now”, but Scrum says “this is the situation of your project and you – primarily PO, but also dev team – make an informed decision about it for the next sprint”. If the informed decision is to ignore the technical debt *for* *now*, in order to meet a very important deadline, then that’s fine. Sometimes this is the right choice – even though I’m a perfectionist software architect + developer myself, I understand that this might be needed for business reasons, sometimes.

      However, you can only make an *informed* *decision*, if you have information. Failing to record this information runs contrary to the spirit of Agile!

      We do not live in a perfect world and perfection is never possible. You as software developer should know this best: Very often, you either must optimise an algorithm for performance or for low resource consumption. You must find a meaningful compromise, because both goals exclude each other.

      That’s the same with the overall goals of a project: There are technical goals, usability goals and business goals (maybe even more). It does not help to make a technically or usability-wise perfect software, but deliver it years too late. Then all your (potential) customers would already have abandoned you (and used the worse product of your competitor instead).

      Producing bad software instead and ship with heaps of bugs will make your customers angry, too.

      So obviously, you – the entire team – must find a good compromise inbetween all the different, partially contradicting goals! This is what Agile/Scrum aims at.

      But you know what: I experienced your situation myself in quite a few companies, already, too. They were (mostly) not using Scrum. The problem is IMHO not related at all to the process model. Instead, all these companies had a lack of experienced senior developers. That’s where the lack of foresight came from: It originated in a lack of staff having this foresight 😉

    • …one more thing: Scrum also says you should deliver often, preferably using Continuous Delivery. However, it does not say, you should deliver with bugs. Actually, you’re supposed to use automated tests to prevent exactly this.

      Instead, you should deliver more often with less (new) features (if necessary), and *not* with more bugs.

      Btw. even though architectural flaws are harder to repair, they still can be *safely* repaired, if you have good test coverage (and a good architect). Thus, if you sit on a pile of bugs, now, I urgently recommend to put a high priority on increasing test coverage. One way to do so, is to establish the policy “Always *first* write an automated *test* for a new bug found, *then* fix it.”

  82. Scrum, is a nightmare that I’ve seen actually kill companies.
    — Michael O. Church

    Michael, it’s pretty explicit, and shows a great distress about your Scrum experience. But, as I try to demonstrate below, I fell that this bad experience comes from, simply as that, a bad project manager.

    Even if this billet d’humeur is well constructed, Michael, it clearly demonstrate a big misunderstanding of what Scrum should be, and agile in general. All you described in your post is contrary to all Scrum spirit. And should not even been called Scrum or agile.

    Bad project manager does not need Scrum to tell people they do not work as fast as they should. Scrum helps project manager to give estimate of what can be done in a certain amount of time so other team (marketing, management) have realistic deadlines. And it’s easier ton convince them it’s not possible to go faster with graphics and numbers.
    Biased definition of “what is Agile”

    Michael, you defined Scrum methodology as humiliating for developers, and prevent them to work on their duty to appear productive. Yes, Scrum is based on transparency and communication. Scrum is designed for teams, not for home alone programmers who works for themselves (even if, in my experience, Scrum works very well for one-person projects!). In a team, the lack of communication can only leads to misunderstand and poor-designed features. Reporting, in my experience, is never a waste of time as it can save many hours or days of development.

    The fundamental unifying trait [of Scrum] is violent transparency, often one-sided
    — Michael O. Church

    In great Scrum teams (product owner, Stakeholder and developers included), it’s never one-side transparency. Of course, during development phase, most of the communication comes from the “tech team” (developers and designers), but before that the project definition and the backlog grooming are time for Stakeholder and product owners to be transparent. They share their feelings, their needs. They share why they can’t spare a feature and learn when it’s not possible to deliver on their own agenda.

    After a while, non-tech teams learn that when one feature cannot be delivered in time, there is a reason. It’s not just that developers are lazy (which, before Scrum, they would probably have said).
    Poor Scrum master, lead to poor product and to poor work life

    The transparency should not be violent. In Scrum, as for any part of the life, respect and failure tolerance (to fail is to learn) are signs of great teams. The Scrum Master is not only the task manager. It’s is duty to make the life of all parts as easy as possible; to extract the best of every team member.

    Each person’s hour-by-hour fluctuations are globally visible– and for no good reason
    — Michael O. Church

    On the contrary Michael, there is no such things as hourly commitment in Scrum project, because the development team commit to deliver user stories within a Sprint. Not on a specific day or hour. In my experience as developer and project manager it is most comfortable to not have pressure on daily basis “Is this task done? And this one? And this one?” This is why estimate use abstract items.

    There is no “one person failure”. The beauty of Scrum is that, if the project fails, it’s everybody’s fault, so it’s no one. The developers failed to deliver because the product owner failed to give a good requirement list, a good definition of satisfaction, because the stakeholder failed to give a simple yet complete vision of his request and the product owner failed to detect it and the developer failed to foreseen the whole and of course, the Scrum master failed to catch the missing parts. There is no one to blame except maybe the Scrum master itself.

    Because of concepts like daily Scrum, every part of the team have a clear view on what and who is doing what. Missing, misunderstood are discovered fast enough. If, of course, the team communicate.
    Developers should be interchangeable

    Michael, next, you complain that agile treats programmers as interchangeable. But it’s a very, very good point. You should be very glad if you achieve that, because it means that workflow is consistent, and that, in a business point of view, you’re not bond to one specific person. In case one programmer only could work on one part of a project, would mean that, in case this guy is leaving the company, the product is dead, no one able to update it or finish it.

    And from the programmer’s point of view, it could be very stressful to work in other way (on the condition that the programmer has a professional conscience). Knowing that I can’t be sick or take vacation without pausing the project, put a lot of pressure.

    For people with anxiety or mood disorders, […] who tend to be most sensitive to invasions of privacy, this is outright discriminatory
    — Michael O. Church

    I’m sorry, but I can’t accept this argument! The productivity, or project tracking cannot be “privacy”! You are paid for a work, you work in a team and people wait for your work to continue theirs.
    Business-driven engineering

    I’ll pass on your two paragraphs about “Waterfall” on which I quite agree to go straight to the hierarchy part. You write that agile (while describing Scrum roles) does not have a “well-defined hierarchy”. Once again, I disagree with you because the hierarchy is pretty clear. The stockholder define its needs. The product owner choose, business centric, what should be done or not and development team has full authority on how it will be done and when.

    With Scrum, you can’t have product owner saying “I want that for the end of the month.” No, it’s to the tech team to define what can be done for each sprint, and in what order. As it is well-defined, the product owner has no way to tell the tech team to prioritize one task on another within the time of the deadline. Sprint goals are defined and ordered by the tech team.

    The “product owners” and “Scrum masters” outrank “team members”, who are the lowest of the low.
    — Michael O. Church

    Wrong statement. Each part has authority onto its own domain, to reach the same goal. Once again, it’s the duty of the Scrum master that these principles are respected by each parts.

    Then you state that reporting process should be juniors’ tasks. I’m afraid I’ll have to disagree once more. At every level, reporting help the programmer. First, to be sure that she/he has done what she/he committed into. And second, to be sure that the feature she/he is delivering match the request.

    In Scrum, programmers doesn’t “work only on [their] assigned tickets”. This is what daily Scrum are for. Daily exchanges with everyone to identify difficulties. And for those in difficulty, to ask for help and to get it from anyone in the team. Because everybody talks during meetings, everybody has his change. No newbie is left aside because ashamed of speaking to pgm.

    Agile increases the feedback frequency while giving engineers no real power
    — Michael O. Church

    At any time in the project, especially during daily Scrum, any programmer can convince and argue to delay a story or stop it. In most case, against product owner or stockholder, the programmer has support from the rest of the tech team, who understand the problematic (or can help to find ways to resolve it).

    Silicon Valley has gotten a lot wrong, especially in the past five years, but one of the things that it got right is the concept of the engineer-driven company. It’s not always the best for engineers to drive the entire company, but when engineers run engineering and set priorities, everyone wins: engineers are happier with the work they’re assigned (or, better yet, self-assigning) and the business is getting a much higher quality of engineering.
    — Michael O. Church

    I hope you’ll be glad to read that, this time, I strongly agree with you. But eventually, these engineers stopped to be engineers and became product owners.
    Terminal juniority

    Michael, let’s be back to our disagreement now, or this post will have no means. Agile does not have exit strategy because it doesn’t need to. R&D, improvement and refactoring can easily be Scrummed (or sprinted). In R&D especially, I can’t see any valid task requiring more than two weeks. It would be unmanageable. On the contrary, sprints force you to split your work to fit in. Let’s say you want to find a way to improve the response time of your API. Indeed, if you write your user story like this, it certainly won’t fit. But then, you have to think about it beforehand, and split it per example, by route. Then, improving a route, can fit in a two-week (or so) sprint, among stories from other projects. The epic “improve the response time” has no great business value because the API works well already, but is a long term goal.

    Good practice is even to keep time for anomalies, or bug fixing. I try to not fill my sprint backlogs to more than 80% of the known velocity, to keep 20% of the sprint to fix unplanned bugs, or urgent requests. This is agility, if you’re booked at 100%, of course, you can’t be agile enough to adapt.

    I’m currently reckoning of adding a “refactoring” part for each of my projects from now. And it 100% compatible with Scrum multi-projects.

    What “Agile” and Scrum say to me is that older, senior programmers are viewed as so inessential that they can be ignored
    — Michael O. Church

    Seniors are essential in every projects, Scrum or not. I’m not far from your age (I’m turning 35 soon) and I’m pleased to work with programmer 10 years younger than me to 10 years older than me. Everyone was very kind to test Scrum and, as far I as know found it useful. There is real pleasure to check task after task and see the burning chart going down day after day. And if a line stay flat for a while, we don’t have to wait for the programmer to ask for help, but we can go to propose help.

    This is the role of the Scrum master.

    Scrum does not consider experience as inessential. Bad project manager does. Maybe your team does. Scrum or not, I can’t agree more with you; it’s bad behavior!
    Dangerously short-term

    Within the last two years, before getting my team into Scrum, I was lucky enough to get a pretty good view at it from different roles.

    First, I had inner feedback from one the biggest worldwide tech company which does agile and Scrum for long. Then, inner feedback from one of the three top (if not the top-top) bank company of France which implement Scrum (from a not-at-all agile methodology).

    After many months of almost daily feedback from a friend of mine there, I’ve decided to do it. First for a project on which I worked alone. And, as I found it so wonderful, I’ve evangelized the rest of the company. Even marketers (our product owners) who were reluctant, now are very fond of our daily Scrums and backlog grooming.

    Then, I recently had experience to work as Stakeholder with one other big firm (tech) and the experience was nice. It felt good to have regular updates and mostly, on a few months project, to have a clear view at any time on where we were in the project, what’s left, what’s done.

    I do not work in a big company (but I’ve seen result), nor a startup. My company is a “regular” but dynamic company, with brave enough people at the head.

    individual engineers are rewarded or punished solely based on the completion, or not, of the current two-week “sprint”, meaning that no one looks out five “sprints” ahead. Agile is just one mindless, near-sighted “sprint” after another: no progress, no improvement, just ticket after ticket
    — Michael O. Church

    This only denotes once more the poor project manager you have/had. This is not linked to Scrum or agile. Not at all because as I’ve already said, all of this descriptions is contrary to all Scrum spirit.
    Career coherency

    By age 30, you’re expected to be able to show that you can work at the whole-project level, and that you’re at least ready to go beyond such a level into infrastructure, architecture, research, or leadership.
    — Michael O. Church

    All of this can, and should be part of a Scrum project. It seems to me that in your current position, you’re desperate to get responsibilities, and project influence. It’s very nice and I encourage you, but Scrum is not your enemy.

    Infrastructure, architecture and research are part of the backlog. Leadership is not of course, but Scrum give you many opportunities to gain the leadership not by your job title or age, but by the acknowledgment of your knowledge.
    Its purpose is to identify low performers performance

    Only really bad Scrum master will sack so called poor performers. While Scrum allow to identify impediments, it does not allow to sack a specific person, because all user stories are different, it should not be easy to blame one person for not closing a user story. And if you can, then, I really think it’s because the programmer is really, a poor programmer, and such person should be removed from a team to find another job. Kenneth S. Rubin (twitter) in his amazing book “Essential Scrum” (which I can only recommend) states that “individual velocity should never be use as individual evaluation”.

    Velocity estimation is certainly very imprecise during first iteration, or for a new team member, but this has to be considered by the Scrum master. And after a while, a bad estimate will means problems in the story definition. The Scrum master focus on the team work. Team members focus on each other’s. Programmers can judge their pair.

    The obsession with short-term “iterations” or sprints means that there’s no room to try something that might actually fail.
    — Michael O. Church

    On the contrary, Michael, like in any project management, it’s up to you, as programmer or project manager, to keep user stories dedicated to R&D.

    Focus on idle work, not idle workers […] “Watch the baton, not the runners”.
    — Kenneth Rubin, Essential Scrum p.51

    If your project manager is not kind to add such user stories in the backlog, then it would have been the same in a non-Scrum project.

    The truth about underperformers is that you don’t need “Agile” to find out who they are. People know who they are. The reason some teams get loaded down with disengaged, incompetent, or toxic people is that no one does anything about them. That’s a people-level management problem, not a workflow-level process problem.
    — Michael O. Church

    As I’ve said above! Totally agree.
    “Scrum” was a term sometimes used for what corporations might also call a “Code Red” or a “War Room emergency”

    I’m afraid I’ll have to contradict you there, as Scrum is a term used in rugby (link) and is not so much about crisis (even if I agree it can have been used for that too), but originally for:

    Players packing closely together with their heads down and attempting to gain possession of the ball
    — Wikipedia, referencing Oxford English Dictionary Online

    Go fast but never hurry […] Hurrying will likely come at the cost of quality.
    — Kenneth Rubin, Essential Scrum p.56

    In Scrum, quality […] is something that a cross-functional Scrum team owns and continuously builds.
    — Kenneth Rubin, Essential Scrum p.56

    This makes all your following statements, like “Scrum glorify emergency”, invalid. In my experience, it’s much easier to individual to manage their time and their development in a scrum environment.

    I’m really deeply sorry to read your experience with Scrum, but I’m convinced that it’s a bad experience as you have bad management above you. They failed. Not you. And not Scrum. Scrum is not for every team, as you said, it’s a commitment from every members. You can’t not-be-agile among a Scrum team.

    But when everyone is in, it’s a dream!

  83. Very interesting approach MICHAELOCHURCH and very nice reply Constantine. Your experience is so valuable. I would like to see both of you supporting what you are saying data from serious books or serious web sites about the topic. Also, the figures you are showing… where have you got them from… I really want to congratulate both of you for your contributions but I would like to see a more scientific discussion. Something that can be really probed.

  84. Hi Martin,

    It’s hard to give you objective data, as it’s mainly subjective. Per example, during my first Scrum project in team, as Scrum Master and developer, I felt very relieved every end of sprint, to see all my tasks done. Every end of sprint, you have the feeling that something is done.

    The team said the same after the project. Everyone enjoyed it, especially as we were able to deliver the final product early than expected, because we were able to delay non-essential features (with weak business value) to another release. And finally, final customers asked for more important features than the one delayed. So basically, we were able to not work on feature which would have been deeply modified after first release, or even removed.

    I’ll try to have a written feedback from a friend of mine who works with Scrum on very project, including many externals, and several dozens of developer, on more-than-one-year projects.

    I’ll post here when he’ll have time to write this down 🙂

  85. “Scrum is for the body shops, the ones that expect programmers to suffer when client relationships are mismanaged and that will take on a lot of low-end, career-incoherent work that no one wants to do.” – I’ve seen this in Waterfall organizations.

  86. “Programmers are, in many cases, expected to provide humiliating visibility into their time and work, meaning that they must play a side game of appearing productive in addition to their actual job duties.” – What does this look like? How does it manifest itself? What are some concrete examples?

  87. I disagree. The first point against Agile (Business Driven Engineering) is people specific, and assumes that more “significant” persons in the team – “Product Owners” and “Scrum Masters” are dominating personalities by design. Dominating personalities will ruin ANY team, not just Agile or Waterfall or XYZ.

  88. Pingback: Professional Development 6/22 through 6/28/2015 | Code Ukemi

  89. I believe that it all depends on what are you looking for in agile. I for example can’t say a bad word about. It helped our company to be more productive.
    But you’re absolutely right – there is more and more Agile consulting firsm and the substantial part of them isn’t worth any attention. But it does not necessarily mean that the whole Agile methodology is faulty or that it doesn’t yield any results.
    Here you can find a lot of useful advices about introducing Kanban or Scrum to your company: kanbantool.com/kanban-library/case-studies

  90. Great love-and-hate kind of post, and even more fantastic are the back-and-forths on the comments… but it seems in the end it all comes down to 3 simple things.

    1. SCRUM is made for small teams. Period. The “Agile enterprise”, “Scaling SCRUM” and all that crap is simply and purely RAPING the fundamentals from where SCRUM comes from.

    2. Refactoring tickets are as relevant as any user story or feature request. They MUST be taken care of to pay down the inevitable technical debt the same way user stories/features must be developed so that you have a working product in the end.

    3. Transparency if probably the main pillar on SCRUM. If you, your team or your organization is not ready for it, then you can only rape it in a way that makes management comfortable or simply don’t use it at all.

    • I’ll ignore your annoying use of the word rape in this context Mr Nunes. Just a note on your first point. Scrum is not made for small teams. Scrum and Agile say small teams work better. And in my 25 years of software development I totally agree. Scaling Scrum stems from the fact that there are so many people doing Scrum now, we need a way to manage it. However, I do question the benefits of over complicating it with things like SaFE or whatever overly, heavy-weight process you might want to put on your already disfunctional implementation of Agile or Scrum. You need get the fundamentals right first, before you start off on this road. But I’ve had these conversations with management before and I’m sure you can imagine where they lead.

  91. Hi – I posted this on Linkedin from a share but thought it best to also post here.
    First off, on consideration, I will say I had to take into context that the tone appeared to be written from the viewpoint of a disgruntled, talented, senior engineer who has experienced some pretty bad Scrum implementations. I am truly sorry for that. There are pockets of poor performance even in Agility.
    1. Agile grew up out of web development with “fickle customers”.
    Scrum as a principle came from a report written on development by Takeuchi and Nonaka in 1986 which featured in HBR. They were looking at NASA programme management; hardly fickle web projects? It focused on the key aspects of Autonomy, Team Mindset rather than a self- centred motivation, cross skilling and subtle control systems i.e servant leadership.
    Lean derived in parts from Toyota (Taiichi Ohno, Shigeo Shingo) in the 1940’s-1970’s in order to increase quality, reduce risk and drive out waste in manufacturing cars. Again not a software based implementation.
    2. Agile prevents developers working on “long term” exciting products, micromanages them without empowerment and exposes them to too much visibility.
    a. Exciting Projects – I began my first agile project in around 2009-2010. As at 2015 that product is still in production, with a defined roadmap of improvement with some of the same team still working on it. They are still being rewarded and recognised for their work. To date, I believe, the product has netted more than £100m for the company (It cost about $400k to develop). Pretty good ROI huh?
    b. Micromanagment – I have served both as a scrum master and a product owner., I learned in all the bog standard training that we worked as a team and were empowered as a team. It was not my job to force my team members to perfect their estimates. It was about continuous improvement. As I have matured in my knowledge of agility and the intrinsic motivators of people; micromanagement doesn’t appear high on the list for knowledge workers.
    c. Visibility – . Why would providing visibility of progress of a team be dangerous? It sounds to me that the author had a scrum master who was reporting on the wrong metrics. Unless that teams velocity was being compared to other teams? Which is dangerous, de-motivating and wrong. I do agree that Agile ways of working do determine waste quickly and, in the words of a fellow coach, “People self-select to leave agile teams if they are “super-stars, falling stars or shooting stars”. That’s ok. Agile doesn’t work for everything or everyone.
    3. Scrum has no career path.
    LeSS, SaFE, DAD. Release train engineer roles, architectural epics and runway, Architectural Governance board etc. Agile at Scale offers many more challenges and role for senior engineers.
    I will use the career path of a previous developer I worked with for this. C is a very capable engineer who specialises in C++, .Net and other MS technologies. She worked with me on my 2nd Agile project as my tech lead, she was allocated at 70% capacity to allow her to also do some personal R&D on a separate project she was working on. At a certain point in development, C merged in her “pet project” which allowed us to benefit from automated deployments, this caused me to not deliver some of the features I had promised the business. BUT I respected C’s opinion. C was soon promoted to head of architecture for the Product Group I worked in. She worked across initiation for multiple projects. Since this time C has moved to a new company and is working on Scaled Agile Engineering programmes. C is the perfect example of someone who forged their own path as an Agile engineer.
    4. Agile is Short term
    I have been working in Agile development using Scrum for almost 10 years. Many other coaches I work with have experience in RAD, Crystal, XP, Lean since the 80’s.
    a. “That is, it’s for firms that don’t have the credibility that would enable them to negotiate with clients as equals”
    I work alongside IBM, Accenture, Deloitte etc. These organisations do not seem to lack credibility with their clients given their latest results on the NASDAQ.
    b. ““Agile” in a corporate job means pain and risk without reward”.
    Jobserve, monster etc say the average salary for a developer with agile skill is pretty high? I know personally that headhunters for more senior roles i.e Head of, CTO, CPO are demanding Agile Transformation skill these days.
    c. ”It doesn’t make sense as a permanent arrangement; at least, not for high-talent programmers who have less stressful and more enjoyable options.”
    I agree. See my comment about super stars above. Agility is about the team and the best work for the organisation. My personal move to agile was away from thinking I was the best and toward thinking that actually I want others to succeed. Not everyone is built for Agile development.
    5. “It has no regard for career coherency.”
    I am working with a big banking client who is re-organising their KPI and reward structures around agility. Team metrics rather than soley individual. This is not unusual with scaled agile thinking.
    Secondly, at 33, my tech lead and I were in-front of the Chairman(and country head CEOs)of a large retail company showing my latest project developed in Scrum. I don’t know if there was any higher recognition at the time. (NB: I was head of a department within 5 years. He now leads the engineering department of almost 300 engineers. )
    6. “Its purpose is to identify low performers, but it has an unacceptably false positive rate.”
    Reading this argument I felt genuinely sad. I can say that as both a female in IT and someone who has experienced bad management as it appears this author has.
    The high anxiety state that the author refers to is inherent in a system that does not have sprints or iterations built in for reflection and refinement.
    My key arguments are closed by this: when I experienced these same impediments and challenges in my career I followed it with anger and determination to figure out how to work with the system or change it. Acceptance is the key. Agility is not going anywhere.
    Organisations need to be agile to deliver in a marketplace that is constantly changing. Not ever project, product or person has the capability or necessity to be Agile. That does not mean they do not have value. I personally feel that one must find their own way and their own intrinsic motivation. I am motivated by team success, constant innovation and working in a fast paced environment with brilliant engineers and business people. Agile thinking breeds that kind of work.

  92. Instead of sh**tting over everything, come up with alternatives. Your article is quick to highlight the bad but does not propose alternatives, so i don’t see the point of it. The point is SCRUM is HARD, and needs more people to understand the actual way of implementing it (e.g. r&d can be built into sprints, i i regularly do so)

  93. You Sir are nuts. Iv’e been a lead architect for 25 years and Agile done right is the one and only project methodology I have ever seen that works. But hey you did get a ton of comments 🙂

  94. It’s not the fault of a kitchen knife if somebody uses it for stabbing the others. You dont call for a ban on the knives, do you? Many of the things that have been mentioned in the article result from a wrong implementation of agile principles.

    “Agile” is not the opposite of Waterfall – it is driven by a set of principles focusing on value. if a meeting. say for instance “Standup” is not working for the team, the team is free to dump it. The agilists are expected to question everything – ‘What value does this bring to the team?” and if they find no value in doing something, they just dont do it.

    Micromanagement is different from self-management and agile principles are about the later. If a Scrum Master is micromanaging the team then it’s the fault of that person and the team, not Scrum.

    The bottom line (literally) is: You can not blame “Agile” for its faulty implementations.

  95. I feel this article should be discussed at one of the Agile/Scrum conferences – It clearly showcases how people get the concepts wrong. A wrong application of agile approaches is much worse than the command & control approaches.

  96. Pingback: Monday Meetup to Apply Agile to Business – Hawaii Blog

  97. You’re right about one thing especially. Scrum is a stupid thing where ridiculous amateurs like “scrum masters” and “product owners” get to tell previously senior chief engineers how to develop software, and push them around at their will.

  98. As someone who’s been doing Agile and Scrum for more than 10 years, I should not be suprised with the response from an article like this. It highlights that Agile and Scrum are, yes, not perfect and as many have said before, difficult to do well. Even Mike Cohen says now “I could be wrong”. Agile and Scrum are an approach but I do believe they are better than what has become before. Much of the ranting from people here stems from confusion about the Framework of Scrum, what Agile actually means and, of course, management confusion. I’ve faced all this and will continue to face it. Reading a book, website article or attending a training course isn’t enough. It takes time to understand Scrum and what Agile actually means and what it involves. It’s huge change for everyone in an organisation because everyone has to change. Try, Inspect and Adapt as we work together to produce a quality product. That’s Agile. No one said this was going to be easy. Life is not a long, smooth flowing river.

  99. Great article. In my group Agile / Scrum has been in practice since January. I see the same issues that you describe. The focus is on the sprint. We have long term projects that need to be completed, but they are always pushed aside. The more interesting aspect is the dissatisfaction of the senior people. One is ready to leave the company or force a transfer. Either way it would be a huge loss. Others are looking to transfer into areas that are not under the same constraints. Eventually the boredom and lack of tech growth will take an awesome team and turn it into a low-level one.

  100. I developed software projects for 15 years using waterfall. It failed at it central mission most of the time and management’s response was more waterfall. I’ve worked on a scrum team for 6 years now and I have not one scintilla of doubt that for all of its faults it still beats waterfall by a country mile. I know, “it’s not either” or but really it pretty much is. Most methodologies are just variations on agile or on waterfall. Yes, the standup is mostly a waste of time, yes there is a bit of micromanagement you have to get used to. Still, I would never go back.

  101. You don’t run a marathon in sprints!
    There is a progressive group out of Texas that is selling this scrum/agile garbage to all these idiots in these idiot ran corporations.
    It’s the Russian, Chinese, Australian, and dumb ass American kids that have been indoctrinated into this idiot ology. Defend scrum like you would your communism. If it’s not working right for you then you’re doing it wrong and need to hire the Texas progressives to come in and show you how it’s done. What a bunch of crap! How about conversation based requirements? If that’s not being set up for scope creep, I don’t know what is. Scope changes but timeline does not? But it’s ok because you are agile. WOW.
    What about this activity based development that the Australians are trying to push as part of their scrum bullshit? Should I bring my nap mat? What is this? Kindergarten? They are buying up all our companies in Colorado and now we even give them control of our toll roads.
    One Australian said in a Computershare town hall meeting that if you don’t like the methodologies than you need to look for a new career. Why would he preemptively say something like that unless he knew they were doing something communist? Nobody dare to speak up against scrum/agile or risk losing your job. I say if you like scrum/agile you need to find a different country. Watch out for the Australians, they talk so much smack about the USA they do not like us and are coming here trying to change our ways. Don’t even get me started on the Israelis that seem to be getting all the VP of technology jobs and acting as micromanagers to prove how awesome they are. And now Microsoft jumping on this anti American bandwagon pushing all this crap in TFS along with their government common core. In 20 years of software development waterfall has always worked fine. You actually get requirements and can discuss any issues directly with business or business analysis beforehand and if things need to change it’s never been a problem. If you have a scrum master then you are a scrum slave!

  102. Your article is a clear display of either deliberate or accidental ignorance. You didn’t link to the Agile Manifesto (http://www.agilemanifesto.org) or the Scrum Guide (http://www.scrumguides.org) to refer to the definitions of these. In the charitable case that you were accidentally ignorant, I would love to see an article where you describe the problems with Agile and Scrum as they are actually defined, not some ignorant cargo-cult straw-man definition of Agile and Scrum.

  103. My limited exposure to agile/scrum so far has pretty much amounted to A) Micro-management to the nth degree B) FAR more time spent in meetings: Sprint planning, backlog grooming, daily stand ups, retrospective, show & tell, etc. and C) The constant, and I mean CONSTANT rush to beat deadlines at the end of each 2 week spring (or however long your sprints are). Get the user stories completed by the end of the sprint, or else!

    Yes, in waterfall, you still have a deadline, but it’s ONE deadline at the end of the project, and you’re still busy working.

    “Under Waterfall, engineers are relegated to work on designs and build systems after the important decisions have all been made and cannot be unmade” —-> This is one of the biggest myths that I’ve ever heard. I’ve never worked on a major project under the waterfall methodology where requirements haven’t been changed, added, or removed mid-stream. Nothing is set in stone, no matter which methodology you’re using. NOTHING.

    Agile sucks, IMO. If nothing else, I don’t have to sit in a pod with my coworkers in my lap under a waterfall methodology.

  104. Also, I’ve ready over and over that agile is not necessarily “better” than waterfall and vice versa. That being the case, why is nearly everyone out there converting to Agile if it isn’t inherently “better”? WHY?

    • Waterfall is a plan-based development.
      Scrum is influenced-based development.

      With Waterfall, you have a finished product.
      With Scrum, you have a LEMON product.

      Even gamers notice that the game software today are riddled with bugs because of scrum. They are LEMONS that users put up with everyday. Scrum creates LEMON products that needs constant fixing.

      Google Chrome is becoming a lemon. Firefox is a TOTAL lemon today.
      I now use Slimjet browser because it is the most decently fast browser that i could find online. Torch used to be fast and is now fast-becoming a LEMON.

      Scrum uses influenced-based prioritization. This means that the user with the most influence will have that user’s story on the top of priority list. I am a user of a LEMON product developed using the Scrum framework. My user stories have been on the product backlog for 3 years. I have no influence. I am not bribing the product owner to place my user stories in higher priority.

      When I was a programmer and the users would submit their modification and report requests in the queue, the users who fed me with free donuts, bananas, sodas, etc. were placed in the top priority for their requests. They were all bribing me with food to place their requests in high priority and it worked. With SCRUM, product backlog prioriization is based on influence not business value. Whoever has the loudest mouth kicking and screaming and bribing will get heard and will have their user stories in the higher priority. Those who are silent will have the user stories in the backlog for many years.

      SCRUM produces LEMON software that is eternally deficient and eternally defective.

      SCRUM does not work. I want it to be like in the olden days when software was deployed bug-free and complete with all the working features and functionalities. I want software with features that make sense to general users not a feature that was fantasy feature request of a user with clout.

      Today, as a user, I spend my time working around the deficiencies and defects of the LEMON software developed using SCRUM. I have to put up with these defective and deficient software everyday for work.

      Most software today that is being deployed are lemons compared to the software developed in the 1990s and early 2000s. This is also affecting the gaming industry and the gamers complain that there are more bugs today than there has ever been.

  105. Pingback: Building |

  106. All the opinions in here make me lol.
    If you can’t adapt a style to make it work for the team you have, you’re a bad manager. Don’t blame the books, blame yourself for thinking you can follow a blueprint and manage complex people. These methodologies have merit and can impart ideas, but successful team management requires real agility. Methodologies only care about process. Team management is about people and process.

    • Or methodology you’re trying to apply is stillborn. If you can’t levitate things with a power of thought it’s just you simply not trying hard enough

  107. I think you got the term “agile” wrong. Scrum was labelled “agile” by its inventors, but actually it falls into a different category. Agile describes a software development process, while Scrum is a management method, which may or my not be applied in agile or in waterfall development processes.

    “Agile” basically means that the developers work closely together with their users, and quickly respond to their changing needs.
    Therefore “agile” refers to technical rather than to management methods to achieve the goal of being agile. Such technical methods focus on ways to maintain high quality in short release cycles. They are in the areas of automated testing, continuous integration and delivery, VPN connection to production servers etc.

    Management methods like Scrum have been invented in a more or less successful attempt to support agility by management, but they must not be confused with “agile” itself.

  108. Pingback: Engineers as clerks? How programmers failed to get the status they deserve. | Michael O. Church

  109. Everything I read about Agile is from a software perspective. I’m in marketing and my company implemented Agile 14 weeks ago (via consultants who are pretty much running the department at this point). For me, it has been a fairly miserable experience. Would love to read anything on how to make it successful (or at least bearable) outside of a programming environment. Any suggestions?

    • It is not successful under programming environments, but the problem is that neither the programmers or the customers are the ones that decide of the methodology is good but the managers who do not have a clue about how real code is written.

      • As developers, have you guys ever tried to disobey and just approach the project the way you know is right despite of whatever bullshit methodology is being imposed from the above? I did a few times but it’s not of much use really, first you have to swim upstream and personally bear any risks of failure and once it finally worked out those cowards who “managed” you all this time (didn’t interfere with your work at best) will reap most of the benefits of your hard work.
        I didn’t find other way but to to quit shit projects as early as possible.

        • usually just gets the managers angry. If you do it too often you get canned. So you have to trick them into believing that the change you wanted come from them but is hard as they are like horses with blindfolds. Anyway +1 for the points comment. Also technically it could work in iterations if they are large enough i.e something like 3-4 months.

  110. The real Agile Manifesto of the developers that created the manifesto is JOB security. Agile scrum is what we used to call QUICK and DIRTY in the olden days. The developer creates something quick and dirty for the demanding user who wants the feature immediately. But the end result is a on-going defective, inefficient and incomplete system with faulty overall coding design and architecture. This agile framework wastes overall productivity of the general users and only satisfies a few demanding users who wanted their piece of feature implemented.

    I am surprised the Quick and Dirty development has become a fad and it explains why many deployed software today are inefficient, incomplete and have so many bugs. This explains why Firefox is so inefficient and slow. This explains why IE is inefficient and virtually dead (discontinued). This explains why so many business software are very inefficient and riddled with bugs with the most simple bugs that are easy to fix but never fixed because these bug fixes are low on the product backlog priority.

    All Agile does is create job security for the developers as firefighters to serve the impatient user who cannot make up his/her mind. Because the system is designed and developed in piecemeal, the number of bugs and incomplete features/functions escalate.

    Take a survey of users and you will find out how many users are very frustrated with the massive waste of their time when a new or new release software system is deployed. They are having to work around the bugs, inefficiencies and incomplete features/functions of the system.

    Gone are the days when a deployed system is bug-free, more efficient than the old system and have the complete all-working features/functions as originally required.

  111. I’m sure this has been said before, but there are so many comments I have to admit, I didn’t read all of them. Everyone is entitled to their own opinion and Michael is entitled to his. Mine is that we have all these “lemons” for one very unfortunate reason: those lemon teams tend to pay lip service to the agile principles. Those are the 12 statements beyond the agile manifesto that a few teams ignore because its so much easier to just get on with the sprints and start developing in the same way we did before. They are driven by a different set of principles geared towards just hitting milestones, regardless of quality and sustainability. Very often its not the team’s fault as they are ruled by a culture of fear of reprisal.

    If implemented correctly(and that’s not easy, but who said agile was easy), the agile principles ensure that we develop code that is easy to maintain and enhance, and the team can go on doing that indefinitely if necessary. The problem comes when the objective that agile is used to achieve is not a high quality product that satisfies the customer. Some of these teams say they are agile, but they’re not delivering working product at the end of a release, let alone at the end of a sprint. And they’re developing the code in the same way they did before, ie “test last” rather than “test first”.

    Somehow we need to make saying you’re agile or that you’re doing scrum a lot harder. Agile is too generic a term and its way easier to say than be. So maybe we need to get the 17 back to Utah and do a bit of refactoring on the manifesto. I’m happy to deputise for any of the 17;-)

    • This is a typical day of a user of a LEMON product developed using the SCRUM framework.

      User Call to Tech Support: “Hello, when I click on this button, it is supposed to publish all my changes. But the system stays hung forever.”

      Tech Support: “Let me try it at my end. Oh, it is not working at my end either under your account. But it works for the other accounts, so it must be an intermittent problem.”

      User: “I have submitted a bug fix request on this a year ago. When will it get fixed?”

      Tech Support: “I do not know. The developers are working on other things.”

      User: “So what should I do to publish all my changes?”

      Tech Support: “Do this workaround. Publish it without the changes first, then use edit to make a change one at a time, then publish each change.”

      User: “I have over 100 changes, so I have to publish over 100 times?”

      Tech Support: “Yes. Do that for now, until the developers can fix it.”

      User: “But, they will never fix it. I had another bug fix request that has been on the queue for 3 years and that was a simple alpha sort bug fix that they would not fix. The 200 items are unsorted and out of order. It has been 3 years and they have not fixed this. I am wasting my life looking for items in this unsorted list. Then they come out with a new software release update to include a NICKNAME field so Richard can use his nickname DICK. How is that more important than the sort bug fix?”

      Tech Support: “I apologize that you are having issues.”

      CONCLUSION: A five-second click of the buttom to publish the work turned into an 8-16 hour WASTE of work-around. This has been how the life is like of the VICTIMS of SCRUM LEMON products.

      • Another example victim of SCRUM LEMON product.

        User Call to Tech Support: “I am using this new system. In the old system, it allowed me to copy an existing folder to a new folder. Where is this feature in this new system?”

        Tech Support: “Umm..let me see. The copy feature does not appear to be in the new system.”

        User: “So, what do I do now?”

        Tech Support: “You have to create the new folder and its contents from scratch.”

        User: “You are kidding, right?”

        Tech Support: “No, I am serious.”

        User: <>>

        Because the new system is deployed in pieces using SCRUM, the CONTRACT users who are paid by contract with a fixed $ amount not by the hour have to waste 1 to 3 days of work-around (UNPAID) to create the new folder and all of its contents from scratch in the new software system.

        In the olden days, software was distributed using floppy disks or CDs and the software in those disks were complete, 100% functional and bug-free. I will never see that again with companies using this SCRUM framework.

      • Like I said, its way too easy for teams to “say” they’re being agile or doing scrum. Its obvious that the team responsible for the product in your example is definitely not.

        • Yes, they are doing scrum because they had a job opening for a Scrum Master in which the required skill was leadership in an agile software development environment. Another way to find out is search glassdoor and any job search site for the company name and the job title scrum master.

          Plus I work for a company that uses scrum and I am using their lemon software right now. The state of that software is so miserable that it seems like it was developed by uneducated programmers off the street who know nothing about system requirements analysis and design as well as testing. It is like living in a twilight zone run by poorly educated developers. The difference is so stark when I used to be a programmer in the olden days. The team has NO GUILT and NO CONSCIENCE in deploying a buggy system. The team does NOT apologize for deploying garbage and for wasting the users time with their lemon product. Their software is used by thousands of users and when the users call and complain, they already have their standard workarounds and what/who to blame and their excuses which is EXACTLY what you are doing. They blame the browser of the user, they blame the ISP of the user, they blame the computer of the user, they are the KINGS and QUEENS of excuses. It is literally like working with people possessed by the devil. As long as the system works in their development environment, everyone else is hallucinating about a buggy product. They do not care if users wasted hundreds and thousands of hours on workarounds. Conscience is not in their dictionary.

          • It’s also worth pointing out that, even if there were nothing wrong with Agile processes themselves, they’re sold to businessmen as magic sauce that allows mediocre, “off the street” (to use your terminology) developers to tackle big projects if stapled together in large-enough teams.

            Whatever you think of Agile, the Commodity Developer culture is pure evil. It also doesn’t work. It produces the culture of tolerance for buggy, unreliable, and often unfixable software that you’re talking about.


              I expect Microsoft to hire the most talented software developers. They also deliver buggy apps which leads me to believe that the scrum framework that they use is not effective.

              Search Google for “Microsoft acknowledges multiple issues with Windows 10 DVD Player app, suggests WORKAROUNDS” Sep 16, 2015

              Search YouTube for “Scrum at Microsoft: See the TFS Agile Team do a Scrum (aka Stand Up) – Long”

              The buzz word is WORKAROUNDS.

              The software interface looks good but the features behind this interface is buggy.
              It is like buying a Porsche car that looks gorgeous on the outside but when you try to run the defroster, sometimes it does not work. The WORKAROUND is to blast the heater in front to hopefully defrost the back windshield. When you turn on the normal fan even with the temperature slide in the blue (cool air), sometimes the air that comes out of the vent is super hot like the heater is on. So the WORKAROUND is to turn on the AC to combat the hot air that comes from the vent.

              The value attained from the new software release is that it looks “physically” better than the old release, however start to run it and you have issues. When software is delivered using the scrum framework, the users better be prepared for WORKAROUNDS.

              This is from the user perspective.

          • Like I said, doing scrum and being agile are two very different things. Anybody can say they do scrum but only disciplined teams tend to be agile. Anybody can say they have scrum masters and even product owners, but ask them to have an agile coach come in and observe them will usually result in “ah yes, we have a product backlog, but…”, and “yeah, we have a product owner but….” and “of course we do testing, but….”. In other words there’s more ScrumBut than Scrum.

            • There should only be 10-15 backlogs, not hundreds.

              From a user point of view, when a new software system using the SCRUM framework is deployed to replace the old software system, then the list of user stories grows exponentially after the live implementation. The increased number of user stories is due to the incomplete implementation with missing features as well as defective functions and features of the new software. In other words, the newly deployed system is buggy and incomplete as compared to the old system.

              So the user stories increase tenfold to hundreds of user stories. Do you have any idea what those new user stories are as a result of the live implementation? Those are user SACRIFICES of having the users WASTE MASSIVE AMOUNT OF TIME and wasting their lives with WORKAROUNDS on that buggy, defective and incomplete system that has just deployed. To the scrum team, the user story is JUST A LIST. The list means NOTHING to the team. They are celebrating that they released something and they are proud of themselves that the team accomplished something.

              Let me repeat, if the deployed system is complete and bug-free, there should only be 10-15 backlogs, not hundreds.

              The team is shielded from the users because the users are calling Tech Support. And Tech Support are adept at making it look like that the software issues are the users’ fault. Tech Support is playing mind games with the users or playing dumb with every user as if they are hearing of the issues for the first time at every user call while the team celebrates in the background. In the meantime, the calls to Tech Support die down because nothing was being done. The next release did not fix the bugs, then the next one and the next release after that did not address the bugs and missing features. The next round of update was few and useless to the general users. The users do not even call Tech Support anymore on any new issues because their previous user stories are still on the queue as if they have been forgotten. They call and Tech Support acts as if they are hearing of the issue for the first time after being in the queue for over a year. So the users live with a lemon software system day-to-day with their own workarounds on the defective and incomplete software system.

              The team has no idea how much the users are SUFFERING wishing that the whole system would go back to the old system with no bugs and with all the functionalities some of which no longer exist in the new system. To the users, the user stories are stories of their PAIN and SUFFERING wishing that the deployment of the new system was COMPLETE and BUG-free.

              To the scrum team, the user stories are just a FACELESS to-do list that guarantees their job security. SCRUM is an illusion that the team is delivering business value every 4 weeks but they are not. They do not put REAL suffering humans behind those user stories. If you have 100 user stories from 100 users, then that means 100 users are currently suffering and wasting their lives doing workarounds. Some of these users are contractors with fixed wages and are not paid by the hour. The scrum team has added to their workload (UNPAID) with the time-consuming workarounds.

              If the users could sue the scrum team, the company should pay those users for wasting their time and lives with workarounds.

              • One small comment: they are not playing dumb. Agile means there is no documents withe every change and every feature explained in detail. You have bits and pieces someone has to pick up from maybe a few hundreds of developers and compile into something partially coherent. Considering that some programmers do change jobs this means some pieces on info can be lost forever. This is because Agile is against rigorous planing. You just plan for the next sprint and for your section of the software. There is no big picture. If you ask a programmer about a part of the code they had not worked on they have no idea and there is nowhere these things are listed.

        • This SCRUM approach reminds me of a programmer I supervised when I first worked for a company in the olden days. This programmer managed to come out as a hero everytime he delivered a completed user request because he used quick and dirty techniques and delivered software and fixes to the user quickly. The problem was the software became a lemon. So everytime the user had an emergency with the system, he would fix it and he would be hailed a hero by the user complete with gifts. He loved it. But what the user did not know was that the programmer created the emergency. He was always needed to make the system work doing fixes in the background so it does not die. He created his own job security and he cannot never be fired or the system would die. If he was not around, the software would die on its own.

          I was hired to replace that system with a new one and we replaced it in one year using the traditional methods and full-blown user testing. The emphasis was on complete and detailed testing because I did not want emergencies from users. We recruited a lot of users to test and break the system before going live. We went live with no problems. Everything was 100% working bug-free because we invested a great amount of time in testing.

          Now this quick and dirty approach is everywhere and it is like I have woken up and gone in the twilight zone. Even those young adults who played endless video games when they were young children noticed the stark difference with the quality of video games today. Video games today are riddled with bugs. Search Google for “Why are so many video games broken at launch?” “Why video games today are filled with bugs and glitches”

          Who are this generation’s developers and programmers? Who educated or trained them? What in the world is happening with today’s software? It is like a nightmare.

          • I know what you mean. I usually would find the quick and dirty solution first and basically ask the manager if we should implement it or allocate more time to do things right. And with few exceptions the choice was to allocate more time. Other people just went with the QD and then of course someone else had to rewrite the whole thing later.

  112. Pingback: Silicon Valley can be beaten. | Michael O. Church

  113. This Article show exactly, what I am thinking about and experiencing with SCRUM. I am a senior engineer, and I cannot see any advantage in Agile Programming. On the contrary: At the very least, 20% oft time, precious time, which could be used for R&D, is used for mere meetings about what to do, how to do, and when to do. Because the whole program is divided into hundreds of small tickets, you never have a complete idea, what is going on in the program.

    In the old days, the ToDos were specified by a PM _before_ programming started, a developer team got a whole and complete specification, and developers could think about the best way to implement the requested features.

    These days are over, programming has degenerated into an assembly line job for typing monkeys, driven by always-mind-changing PMs and always-not-certain-what-they-really-want customers.

    • It’s about control as well as managerial face-saving. If there’s a plan, then it can be challenged by programmers who are, quite frankly, often smarter than the people writing the plans. If there’s no plan because you’re “Agile”, then there’s nothing that can be challenged.

    • There are some advantages. The customer thinks he gets a better deal because he gets all the illogical changes he wants even if the software is full of bugs like swiss cheese, the managers can basically do nothing but stay in meetings, the smart programmers can cheat the story points to slack off and everyone is satisfied with a shitty software.

  114. Pingback: Another good rant on Scrum | A developer's blog

  115. Waterfall gets a bad rap. You can change design and requirements if you want to. The point is to gather requirements, design the system and then build it. If you remain reasonable flexible, there’s no reason you can build decent software using the Waterfall approach, or any other approach. It depends on what you want to get done. In two different startup where I worked, we used the Agile approach and were always changing things, client x wants this, ok lets throw that in, client y wants something else, no problem. We did it all in our “sprints” growing incrementally and remaining so flexible that no one had a clue what the hell the entire system is supposed to do. In both cases we had Big Fucking Messes (BFMs).

  116. Honestly I did not read all 314 replays swamped with work) so please excuse me if I am being redundant. First and foremost, In a day and age where the user experience and customer experience a absolute key for a company’s success and survival, I find agile, scrum, etc. totally and undeniably a force against UX/CX., creating teams and tasks that have little or no concern for such “minor details”. As a Senior UX Architect and sometime UI Designer with 17 years of real usability experience, I find that my recommendations are consistently met with the comment “if the product owner asks for a change we will change it”, however, the product owner knows nothing of best practices, usability patterns, IOS and Android guidelines, user flow, proper placement of messaging, placement of key content, and more. They also think using pop-ups instead of good design is the way to go!!!

    Often I am treated as a person without knowledge, someone who draws on the level of third grade and just likes to philosophize and pontificate (which is not the way I roll at all). My years of industry research, ongoing, my training in HCI, my masters, even a couple of UX awards, etc. mean nothing. My ability to advise, listen and learn, mentor product owners and business stakeholders is discredited. The scrum master finally has some authority and definitely has decided with a great deal of self-importance that an intuitive UI with best of UX is not crucial to the success of the project and frankly just is a waste of time. My suggestion of showing product owner A/B and explaining why was also shot down. Even well planned and documented wireframes and user task flows are deemed a waste of time. In fact, many times I am not even brought onto project until all decisions about product flow and ui have been decided. There is no such thing as considering the user persona or empathy charts when determining what the users’ actions, choices and decisions may be so we can proactively design for their real needs—those that are difficult for users’ to perceive and articulate. One comment by a young developer when I insisted on the implementation of form labeling, etc. stated “It is good enough for me, I know what to do”! He just wants to burn down that burn chart! I could go on, however, I think you get my drift.

    Don’t get me wrong, I have worked with excellent “scrum” teams, however, they were implemented by company leaders who put UX/UI first and foremost, along with experienced engineers and scrum masters that had the vision of a great product. They were business owners and leaders who hired the best and let the best do their job. They knew we were committed and passionate about not only the user, but also the business and we knew that scope creep had to be weighed against the success or failure of a project. They trained product owners to ask questions about usability and to stick with what they know best – the product. And leave the design, implementation and usability to the experts.

    I believe the issue lies more in the implementation of a great visionary as a leader who holds “everyone” accountable and insures that SME’s are focusing are their deliverables accordingly. Makes sure their are sprint 0’s for proper research and planning, etc. And scrum masters are project managers for the project, not managers of people with years of expertise.

    • This does not only apply to UX, sadly. From proper business process and requirement analysis, through solid infrastructure and architecture, code and other artifacts of at least acceptable quality, to documentation of any kind and sufficient testing – they are all victims of this incompetent, dishonest and irresponsible attitude often disguised or misinterpreted as “agile”.

      Regarding your comment about junior developers, I think this is the result of aforementioned attitude propagated by incompetent and insecure people. Most junior developers by default *are* motivated, curious and honest, until they realize there is no point and it is actually discouraged. In “agile” projects using Scrum(But), I’ve seen junior (and senior) developers burnt out after a few months just like seniors after a few worst-of-the-kind enterprise project failures.

      In the end, the way Scrum (or “ScrumBut”) is usually implemented in real world *is* all about micromanagement. It’s just that instead of constantly telling you what to do, it is constantly telling you what *not* to do.

  117. Pingback: Der veraltete agile Überwachungsstaat

  118. Fully in agreement. Agile/Scrum’s daily status meetings gives management immense comfort that people are “working” and that they are squeezing out every drop of juice that they possibly can. Management believes, truly and at the DNA level, that they themselves are the smartest (an in many ways are) and that engineers and developers etc are all spoilt brats as a result of the dotcom culture. Agile/Scrum is a management invention to show the technical engineers and developers who stays chained to the assembly lines and who makes “strategic” decisions while playing golf. However no reason to lose hope. Engineer and developers will quickly figure out a way to get back in the game. Be honest and ethical to yourself and your engineering creativity. To deal with a parochial management BS follow this – There are plenty of moving parts in the IT system and there is always some group in the org – not part of Agile/Scrum- who is the perfect bureaucrat. Just make sure this group is a needed approval in everything that you do.

  119. Pingback: The four stages of a company, the resource-extraction culture, and Silicon Valley’s cultural Hayflick Limit | Michael O. Church

  120. As a programmer who has been in the industry 20+ years and now in his 40’s, this article really sums up a lot of my own feelings lately. I came to my current company as a project leader\sr programmer, mostly from companies using waterfall methodologies or variants. The company switched to agile and scrum about 8 months ago. Having followed Agile and Scrum now for 8 months, all I can say is I’m totally burnt out with it and looking for reasons to leave. I was also sold on it in the beginning, since the trainers made it sound so great. And yeah – it’s totally great for product owners and functional managers, but an utter nightmare for self-sufficient and experienced developers in my opinion.

    It’s mentally and emotionally exhausting. Every morning the team has to do the stand-up. It almost always has functional managers in it, listening in and watching the team members, along with the product owners of course. And during each stand-up you must report what you did yesterday, what you plan to do today, and any obstacles you face. It’s not like you can simply decide not to go stand-ups and take a break from it all right? Nope. Accountability and transparency are part of the agile manifesto – right down to explaining and justifying what you do EVERY SINGLE DAY. And every single day when this stand-up occurs, I can’t help but think to myself “How the heck did I go from a highly respected and high performing professional, who’s spent years developing his skills, who has lead and mentored others, and has proven himself over and over again and earned the right to work on my own terms, suddenly find himself being treated like some child? How did I go from being the guy who was needed to interface with multiple teams, business owners, and stakeholders, and provide important guidance and solutions, to the guy that’s now just a lowly code monkey only allowed to work on what he’s told?”. It’s depressing.

    I get it though – some people need that kind of rigid transparent process because they are too junior, have language problems (offshore), are under performers, or just plain slackers. But applying that rigid process across the board simply dumbs everyone down to the lowest common denominator, and demotivates and diminishes the high performers. Experienced professionals know how to manage their time and can estimate with accuracy how long work will take – and they know how to deliver. Good managers trust that, and that’s all they need to know. They don’t need daily forced transparency, and neither do your peers when you are good at what you do. There is no empowerment in Agile for high performers and experienced professionals. You are just another cog in the team wheel.

  121. Best article about Agile vs. Waterfall I’ve ever read.

    When a company abandons “COMMON SENSE” and chooses to manage a team based on a bunch of buzzwords, cliches and acronyms — then that team is doomed to failure.

    I’ve never seen it work any other way and I have 20 years of solid experience in this field. In fact, I am feverishly working toward leaving a company who just implemented SCRUM as fast as I possibly can.

    That is how I stumbled upon this article!

  122. Pingback: Why I’m not quitting technology | Michael O. Church

    • Disagreed and I think this argument is logically flawed.
      I think criticism is always allowed, even without proposals. Otherwise most people should never ever criticise basically anything. (Example: I cannot build a house, but I live in one – so am I allowed to criticise its flaws or not? I think the obvious answer is yes.)

      In short, criticism is the first step towards changing things for the better.

      (Also note that the subtitle of the blog specifically says “rants”.)

    • You know how every year, there is a new model car such as the new 2016 Honda Civic. You do the same thing with software engineering. Plan for a major release each year. You do not do half measures on requirements analysis and all the SDLC phases. You do full measure, prototype and test the product using real users and deliver the product like your life depends on it.

      What scrum is doing today is that it is automating inefficiencies of a business process because the Product Owner is the one making the calls as to what needs to be done. You do not program the inefficiencies of the users. When you build new software and envision how it works, you might be laying off 4 employees when the software is deployed because the software will now take over the jobs of the 4 employees. You cannot do this type of analysis with agile/scrum because scrum is a half measure framework. You need to do full measure like the car manufacturers coming out with new models of cars each year.

      There will also be another group that will handle the day-to-day requests. This is equivalent to the auto maintenance/repair shop. When the state or government has a requirement by a certain date, this group will implement the requirement in the current software. When the CEO of the company wants something from the system immediately in order to make a decision, this group will take care of the request. When a user needs a mass update, you got it. If there is a bug fix request, this team will do it immediately.

      Basically, you are separating the release upgrade team from the maintenance team.

    • In the IT world, there are a number of teams: 1) Product Development Team; 2) Maintenance Team; 3) User Services Team; 4) Help Desk/Tech Support, 5) IS&T Security and QA Team, 6) Computer/Network Operations Team, etc.

      Don’t ever call yourselves the agile team or scrum team or you will be laughed at by the users as the “pretending to be busy” team to score points with the executives while delivering nothing of no value to the users or you will be called the “quick and dirty” team that causes major security breaches in the system due to technical debt and need for refactoring.

      The Maintenance Team is equivalent to the express lane in grocery stores. It is also equivalent to the maintenance shops in auto repair. Something needs to be fixed or maintained now because there is a requirement from the government, executives, users, etc.

      The Product Development Team works on new development/features and major release upgrades. Every year, there will be a major release upgrade or dot release upgrade. This team can use any methodology that works like Spiral, Waterfall, Prototyping, Iteration, any combination, etc. as long as at the end of one year when the release goes live, the software is complete and fully tested by real users with no bugs. When a user request comes in, classify it as either Maintenance or Product Development. If the user request is needed immediately, classify it as maintenance. If it is a new feature that is needed immediately, then mark it also as product development for the product development team to include in their project.

      The User Services Team takes care of the training and user testing. All the organization’s users need to go into training before it goes live. When testing the system, if you need to pay real users overtime pay to test the system, do it. Let them break the system before going live. That is their goal is to break the system, so the developers can fix the bugs before going live. You have the test environment and the live environment. Mass load the live data into the test environment and have the real users test your system. The User Services Team will be in charge of of the user testing (equivalent to Beta Testing). If the Product Development team needs users to test the system in the prototyping phase, then have User Services make this happen. The User Services will work with the Production Team to develop the test plan and the User Services will implement the plan.

      Agile and scrum are just illusions of productivity, but the end result is a defective and deficient system causing the users to do time-consuming, costly and inefficient workarounds.

  123. Pingback: Y Combinator and Paul Graham are bad for the world (Part 1) | Michael O. Church

  124. Agile is what drove me out of programming as a career; actually there’s programming and there’s web development, but that’s another topic. It got to the point where every job I applied to was using agile. The whole ‘open-office’ concept, the noisy environment, the daily status meeting called ‘standup’ (which incidentally, I’ve never gotten anything out of in the 6 years I’ve attended them), the idea that customers actually want software that’s not complete, tiny pieces of functionality to be delivered in sprints instead of complete components of functionality that I can create from beginning to end and own, have all attributed to my decision to keep programming as a hobby.

    Anyway, here’s the middle finger (.I.) to agile and its defenders, those idiots seem to be every where.

  125. Pingback: Agile - enough already

  126. Pingback: It’s not “Early” Exit Disease, just Exit Disease, that’s killing innovation outside of (and inside) Silicon Valley | Michael O. Church

  127. This article is a catalog of the anti-patterns that come with many an enterprise agile adoption, anti patterns that a good coach can work your company through, provided the company is willing to do what it needs to do to get the benefits.

    Look, scrum is best used as an organizational change management diagnostic tool kit (that’s a mouthful)

    Scrum will not make a company go faster, it will shine spotlights on why the company is not already fast.

    I have witnessed *many* situations that are the metaphorical equivalent of the following conversation around a car (automobile)
    (To be clear, the car is a metaphor for the company and it’s culture)

    CLIENT: We’ve been doing scrum for the last 6 months and we’re still not any faster.

    Scrum Person (trainer, coach, scrum master): We’ve been able to determine that
    the gas tank is full of banana’s,
    one tire is flat,
    3 wheels are on rims,
    and there is no steering wheel,

    CLIENT: Right, we know that.

    Scrum Person: In order to faster, you need to fix these things.

    CLIENT: Look, that’s the way we’ve always done things here, now how is scrum going to make us go faster without changing the way we do things?

    Scrum Person: It’s not, you need to get the gas tank replaced and filled with fuel, you need 3 new tires, and you need to put in an engine.

    CLIENT: I told you, that’s not going to happen. You Scrum people are all the same. You make promises, but when it get’s down to it, you don’t actually do anything. This has been a waste of money. I’m going to go write an article about why scrum doesn’t work.

    I wish I were joking.

    Get a coach, insure that you have close executive sponsorship, and for the love of all you hold holy, start small and experiment.

    Good luck.

    • First of all that was not the claim. The claim was not that they did not get faster was that the products become brittle and had low quality which is one of the reasons I am against Scrum in particular and Agile in general. Agile and Scrum encourage doing features and delaying bug fixing because the payoff as story points for features is much greater than for bugs. It can take a week to proper solve a bug but under Agile Scrum it only count as if you worked one day on it. And even if you have to fix a bug since you are pressured to solve it fast you will most likely do a dirty fix and move on. But delaying fixing bugs or doing a quick and dirty fix means that at some later time you will have to fix the bug properly. Only then it will be dozens of line of code dependent on it and most likely you will need to rewrite a big chunk of the code. Basically Scrum and Agile encourage the quick and dirty approach on coding. Your example is from a manager talking with a client. usually neither of those have any clue on what coding means and how is done. Also what your response is basically this:
      1. man goes to a doctor; doctor prescribes medicine
      2. medicine fails for the man and for more than 70 % of those using it
      3. doctor blames the pacient

      • Lets start with the end.
        1) Man goes to the doctor; doctor tells man to start eating healthy and lose weight
        2) Man stops eating all food because he doesn’t like “healthy” food
        3) Man blames doctor

        Agile (and scrum) specifically talk about a definition of done, one of which *should* be, “doesn’t introduce new bugs, or break old functionality”

        You are correct, *most* companies that implement scrum are focused on “increasing velocity” and drive deep levels of technical debt into their code.

        Every agile trainer that I have met and talked with recommends that the teams implement XP practices into their process, because the intent is high quality code.

        Also, there is an expectation that the team will be producing and demonstrating production quality code every sprint. This is difficult and takes time to get to the point where a team can do this (and in the process start learning the secret of having the testing done before development starts). Most companies do not fully integrate their new code every sprint. They manage their project, not their product.

        As to “velocity” I can’t begin to tell you how many times I’ve seen people manage by velocity, no matter how many times you tell them that by doing so, they are destroying most of the value that can be derived from measuring velocity.

        The intent is to raise the visibility on how much time it *actually* takes to build an “entire” new slice of functionality, not increase the speed of delivery by rushing a piece here or there.

        Going back to your analogy, if the man takes his medicine, and it doesn’t work, you’re right, that’s on the doctor.

        However if the man is told to take 1 pill every 8 hours for 2 weeks, and instead, takes 9 pills every three days, because “it’s the same thing” then it’s not on the doctor, it *is* the patients problem.

        • Ok, maybe you have a point, but managers always use velocity as a way to manage. But Scrum assumes that every task can be atomized without causing problems to the coherence of the software which is false. Also it does not allocate time for testing and bug fixing. It may surprise you but testing and bug fixing should be allocated a big deal of time because no one can predict every corner case scenario and because sometimes two pieces of code can work well on their own but when interacting they can cause various problems. So basically after every sprint there should be a period to re-test the whole product. But if we have that then we get to standard iterative methodologies from before Agile which worked much better.

          • Hi cpy, 2 things

            1) using velocity to manage

            Managers using velocity to manage their teams is like expecting your speedometer to ALWAYS read “60 miles per hour” and going crazy when it drops to zero when you’re gassing up your car.
            It’s pretty easy to just superglue the velocity to 60, but most people outside the fortune 1000 would then say that the tool is broken.

            Manage the team by production ready code, not the velocity.
            In fact, don’t manage the team at all, lead them.

            There’s a wiki article on “Theory X and Theory Y” that does a good job of explaining why scrum is usually misapplied. Companies assume that their people are lazy and don’t want to be at work. Sometimes they’re right. Those people need to be managed. And they shouldn’t be on a scrum team.

            2) Scrum assumes that every task can be atomized.

            Scrum doesn’t assume anything. The way it tends to get implemented assumes that every task can be atomized without causing problems, and of course you’re right, that doesn’t work.

            As for testing, I agree with you, there are some crazy things that can show up in corner cases. That being said, many companies insist on having a separate testing phase while not encouraging their developers to learning *any* testing skills.

            Senior developers have learned some testing skills out of self-defense, but junior developer tend to think that testing is beneath them. You have to look for it, but there is a caste system in companies, and testers are at the bottom.

            Scrum doesn’t say anything about how to write your code. Scrum trainers and coaches recommend the teams start using XP practices. In XP, you start flipping things around by getting your tests written first. (Not all of them, Test-First-Development does not and never has meant “write ALL of your tests before writing code – but that’s a different conversation).

            If a team is doing scrum, I’m going to expect – at the very least – some kind of Continuous Integration / Continuous Delivery system into which automated tests keep getting added.

            I also expect those automated tests to be treated like production code.

            What I usually find is an expectation that “someone else” creates and maintaining the continuous delivery system, and that “someone else” writes the automated tests.

            Those two tasks [ 1) Creating and maintaining the CD system, and 2) the writing of automated tests ] are developer jobs in XP. It can’t be farmed out.

            At least it can’t be farmed out if the company want to get the benefits.

            Scrum is painfully easy to get wrong.

            “Scrum can’t possibly mean that the customers actually talk with the developers”
            “Scrum can’t possibly mean that the product IS the status report”
            “Scrum can’t possibly mean that developers work with testers until the testers say it done”
            “Scrum can’t possibly mean that put all outside meetings with the team in the sprint review”

            • > Senior developers have learned some testing skills out of self-defense, but junior developer tend to think that testing is beneath them.

              That is so not true. Both senior and junior developers (not the useless ones, obviously) know that testing is an integral part of their job. What they don’t know usually is how to stand up and say no to “no time for proper testing” non-sense; to the lack of definition of done, acceptance criteria, proper guidelines and infrastructure; and to irrealistic deadlines (even in Scrum) pushed by management (and often POs and SMs themselves).

              > What I usually find is an expectation that “someone else” creates and maintaining the continuous delivery system, and that “someone else” writes the automated tests.

              What I usually find is an expectation that developers can execute these activities without any time allocated for them. (Yes, they are developer tasks.)

              • Patrick, the whole “developers either look at testing as something that needs to be done” or “developers look down on testers in subtle barely perceptible ways” would probably require a full blown research study.

                What I can say is that I have run into *many* more developers who not only *can’t* test, they also are happy that they’re not testers, than I have run into developers who can do a great job of doing their own testing.

                At the end of the day I’m going to agree with you, scrum can’t fix unrealistic deadlines.

                It doesn’t help that I’m running into more and more scrum masters who are 20 year project managers who have erroneously learned that “scrum master is the agile word for project manager” and so they got their CSM and are now happily doing project management using a scrum vocabulary.

                • I guess we agree on all sides then, we are obviously talking based on experience. I would be happy to see such studies really, anyone knows any? (I personally sometimes suck at googling.)
                  I was also lucky to work with many great developers (smart, clean code, happy to test, etc.), but sadly I had no good experience so far with PMs/POs/SMs (who at least would try help the team with stakeholder expectation management).

                  So what you describe in your last paragraph is also painfully true and common.

                  • Patrik – that would be a cool study and it would be trick to do.

                    (If you haven’t read “how to lie with statistics” it’s a surprisingly fun read for such a dry subject ($2.82 + shipping for a used copy on amazon, 65 years old, 124 pages with LOTs of pictures – still used by colleges in post introductory studies of statistics – lastly, it will make you laugh – more than a few times.)

                    Anyway, one of the biggest problems with scrum, is that it is what I call “an organizational change management diagnostic tool kit”

                    It won’t fix a companies organizational dysfunctions, it will merely shine a very bright spotlight on them.

                    The problem is that scrum is thought of as a software development *thing*, and not an *end to end product development thing* and so scrum is brought in by people who do not have the power to change dysfunction at the VP level (let alone at the CEO level) and are left with wondering why this silver bullet didn’t fix their problem.

                    It’s a variation on my favorite programming taglines

                    Software development is a simple matter of figuring out which wrench to use in order to pound in a screw.

            • and here is another problem. The idea that automated tests can replace human testing. It cannot. Your automated tests usually equals 0 in testing. About programmers and testers. As a programmer you have to always test your code before committing. But that does not mean you do the actual testing. The testing team tests the software piece in every concievable way. Agile assumes you have time to do a thorough testing. This is the job of the testing team not the programmer’s and automated tests usually cannot really test the product.

              • cyp, we agree, automated tests don’t replace human testing.

                My expectation is that if a bug is found (and I’ll discuss what “bug” means later), then a developer will write an automated test that exposes that bug and adds that test to the CI/CD system. This way that bug cannot creep back into the system.

                My expectation is that a full regression test is run before the code is checked into the system.
                This is tricky because regression tests tend to be manual processes that take forever (often on the order of weeks) and if someone even mentions adding some form of automation to the mix, it gets shouted down as impractical.

                Where we disagree is in the expectation that developers test their own products. I expect developers and testers to work together and completed both of their jobs at the same time

                [That time is when the both developer and tester say, “it’s good and working as expected, and we have performed the following tests, there may still be bugs, but we haven’t seen them yet, product owner, can you inspect and either accept or reject this?”]

                Most fortune 1000 companies reject this kind of collaboration before they ever try it. Just like the guy who insists on taking 9 pills every 3 days rather than 1 pill every 8 hours.

                Note: Bugs.
                This is not from Scrum, this is from me (and a few other like minded people in the agile space).

                I don’t recognize the concepts of “bugs” as anything but an anti-pattern (and yes, I can already hear the pitchforks being totted and the torches being lighted.)

                I view what we currently call bugs as examples of 3 different things.

                1) Incomplete work, the code broke something on the regression test. This is not a bug, this an incomplete story. The expectation is that a full regression will be passed before code is checked in, or the story accepted. That being said, it can take years to move to that kind of professionalism.

                2) Tester Driven Development – this is where a tester looks at the product and says, “this does not fit my expectation of how the code shall work, I will write up this enhancement as a bug and put it in as a high priority.” This is not a bug, this is a feature request. As such, it needs to go to the product owner to put on the backlog and then decide where in the backlog it should be placed. It is not a bug.

                3) Some weird complex undesirable behavior gets by the product owner, and the regression team, and then gets out into the wild. This is the only thing that I might call a bug. I still expect an automated test to be written to expose the bug, but on some really tricky ones’s this is just plain hard.

                To be honest, when I see well written code, with well written, well maintained tests, I don’t see that many complex bugs. Most complex bugs that I have seen happen deep in nearly abandoned sections of the code base that most employees believe have been obsoleted and taken out of service.

                I’m sure we both agree that quality is difficult.

                A digression.

                The pattern that I’ve seen is that when a company starts up, they are scrambling to make their code work for their first 1000 customers. They don’t have time to handle corner cases, they just have to make it work.

                As they grow, they add people, and if they have funding, they add *a lot* of people, and these people are expected to get a laundry list of features working. There’s no time to get it right, it’s sink or swim.

                Some time in the 7th year of the company they start feeling the pain of their past survival based activities. It wasn’t their fault, they survived where 90% of the companies that started with them failed.

                Some time in about the 9th year of the company, the pain has gotten to the point where they are willing to start hiring someone expensive, someone like me to come in and try to fix their problems. This starts a multi-year process of attempting to shift the culture of the company away from their cowboy roots and move towards the balancing act that is sustainable high quality development

                • “My expectation is that if a bug is found (and I’ll discuss what “bug” means later), then a developer will write an automated test that exposes that bug and adds that test to the CI/CD system. This way that bug cannot creep back into the system.” wrong. Usually bugs are not simply tested with automated tests. What you say only works in theory. In practice to write an automated test for every bug is an extraordinary amount of work and is easier to manually test it.
                  Developers test their commits but you cannot expect them to also do the job of a tester. Because the programmer is not a tester! A tester must bounce the code against any number of situations and see what falls out.
                  About bugs I disagree with you. the most hard to fix bugs are usually caused by the smallest thing. You are very optimistic about writing perfect code. The reality is no one is able to do this because we are limited human beings. Proof is all the fix packs almost every software out there has from windows to whatever. You are talking from the perspective of an manager with pink glasses always on. Also no one is omniscient as you are asking for. There is a big difference between theory and what managers believe and practice and was is seen at ground level.

                  • cyp – we disagree about coders and testers.

                    First, I run into the phrase, “Because a programmer is not a tester!” more than I’d like to. There are unspoken assumptions built into the phrase. The biggest is that there is no overlap in the skill sets.

                    Second, we’re not talking about writing perfect code. I’ve had people get offended by the notion of bug free software. It’s almost like a “get out jail free” card that translates to, “code has bugs, developers can’t be expected to find them, hire more testers.

                    TDD won’t kill all defects, but kills a lot, and it makes trickier bugs more difficult to get into the system. Once in production, TDD provides a framework that makes it much easier to find the bugs.

                    I should probably add that I’ve been a coder for more years than I’ve been anything resembling a manager. For me, TDD made coding fun again. I’m not wearing rose colored glasses, I seen it work, and I’m been involved in making work.

                    • I know is more that you’d like to but I repeat it because you seem to miss the point. To test a product you must run dozens of slightly different scenarios. This takes a lot of time. The programmer cannot be expected to run more than a few most relevant scenarios from that dozen and the tester will run the test. Again the reason is it takes lots of time.

                      A wise man once said : “there are millions of ways to break something but just a few to make it work”. The fact that there is no complex code bug free is not supposed to be a “get out of jail free card”. But the point that you need to hire most testers is true as I see a lot of companies trying to automate everything and remove human testing and as a result they get bugs from clients. And then the programmer is blamed because he did not run 1000 tests in his free time because god forbid will they allocate enough time for testing. Managers must understand that a 3d of all development time is bug testing and they must allocate human time for this. There are bugs and there are bugs. As I said the programmer must run a few representative tests for his code to make sure things work and it does not break the whole thing. Everything more than that should done by testers.

                      I agree that TDD kills a lot of bugs but I disagree it provides a framework to find bugs easier. What does that even mean? That is politician language or lawyer language, not sure what the correct expression is for fancy words that say nothing.

                      For me TDD makes coding a drag because you are treated like a perpetual junior. You are not trusted with anything complex and basically it destroys any sense of inventivity you may want to display. It makes you a little robot. Cam asa ceva: https://www.facebook.com/CrescoGroup/videos/1646918462246977/?fref=nf

  128. You know the feeling when your read an opinion piece criticizing Evolution by someone who is flabbergasted by the whole theory of Evolution and has no idea what it actually is?

    Yeah, I get that same exact feeling reading this.

    • Reza, in your post, substitute “Evolution” with a (real or imaginary) sect that, even though its alleged best intentions, is actually doing harm to people and their work; and substitute the person who has no idea with someone who has spent years in it (forced or voluntarily).

      That’s the feeling many people get when reading this.

      • Patrik – that’s a good analogy.

        My wife’s uncle worked at a large utility, and I heard that they were using scrum and so I asked him about it. I was surprised when he started describing the horrific cargo cult adoption of agile.

        Scrum when badly applied is an amazingly effective micromanagement tool (for the record, micromanagement is a bad thing, that kills the souls of your employees)

        I have worked in companies where scrum was badly applied (a living nightmare) and I have worked in companies where it was well applied (surrounded by unicorns and rainbows).

        The thing that gets me is that in realms where it’s been badly applied, I can’t find anyone who has read the agile manifest, the principles behind the manifesto, or the scrum guide. They didn’t even go to a training, their manager’s manager went to the training.

        These same people who have never read up on the subject (except articles like this one that are more on par with Hieronymus Bosch painting, which reinforce their opinion)

        To be fair, these people are not intentionally victims, they have been put in to what is effectively a forced work camp, where all the fun has been sucked out of their day and repeatedly told “agile says this” and “agile says that.”

        I would be angry too.

  129. Pingback: Agile scrum? |

  130. [Continued from an earlier thread]
    cyp –

    1) When I said “provides a framework to find bugs easier”, I meant just that. TDD (when done right) facilitates refactoring and encourages good object oriented code. This allows the complexity of the code to be reduced over time, making it harder for bugs to hide.

    The video was *wonderful*,

    I would happily use this video before trying to introduce TDD to a group. It’s a great example of what happens when something new is introduced before people are able to accept it. “Oh you brought me something, let me strip off the bits I don’t understand and use the obvious stick to make things go faster. This is also what happens when scrum is used as a micromanagement framework (and leads to people hating it and causing posts like this one we are replying to).

    If doing TDD in your company causes developers to be “treated like a perpetual junior”, causes a lack of trust of a developer’s skills and leaves those developers feeling like “a little robot” then I wouldn’t want to do TDD at your company either.

    Don’t take my word for this, find some other people who have been getting value out of TDD and look up TDD anti-patterns, to paraphrase an old wise man, “there’s a million way to do it wrong, and only a few to do it right.”

    • @Malcom: You’re absolutely right! TDD is extremely helpful to reduce code complexity and to make refactorings much safer: A developer having changed code, immediately sees what he broke, when he either runs the tests himself or when the next CI build (triggered by his check-in) tells him which tests failed.

      @cyp: If TDD makes developers to be “treated like a perpetual junior”, why do you think that we – extremely experienced seniors – use it in our hobby projects?!

      Example? Take a look at: http://datanucleus.org

      I picked this one, because it’s not mine (though I contribute a little) to avoid self-adulation. Additionally, it’s used by Google (in the App Engine) – who care about quality more than most other companies in the software business.

      This project has one of the cleanest code bases I know and it is developed by a very small group of people with Andy being the single main developer doing roughly 95% of the work, currently.

      The same applies to numerous other high quality Free Software projects. Do you think, we – the developers of Free Software – use TDD to make ourselves feel miserable?! No! We use TDD, because it significantly reduces the efforts needed to guarantee high quality in the long run!

      I totally agree that you should *additionally* have human testers. But before you give your application to them, it should have been tested thoroughly by automated tests. And whenever they or the actual users report a bug, the first thing is to add a new automated test for this bug – so it can’t re-occur later on, again.

      • +1 for all possible automated tests plus additional human testing.

        But most of the time I refuse to call common sense and obvious engineering practices TDD or (capital) Agile, because these terms are too often used by groups of people who are everything but agile and don’t have the slightest idea what they actually/practically mean.

      • “If TDD makes developers to be “treated like a perpetual junior”, why do you think that we – extremely experienced seniors – use it in our hobby projects?” – No idea! About Google their code has gone from bad to worse since hummingbird. So not such a good example. About guruanteing high quality this is definetly not true. Look at any piece of software today from an user perspective and you will see it is more buggy consumes more resurces and so on than ever before. And yes the databases are cleaner because once a bug ages enough it is magically deleted. Also a lot of real bugs presented by users are marked as working as designed and closed. I have seen this behavior from Google,FB and so on just to name a few. Also automated tests will never be able to do almost squash in showing bugs. I have had bugs that were not reproducible except on on machine on one os under certain very weird conditions. Can a automated test even deal with half of the scenarios my tester colleagues thought of back then? I think not.

        • cyp – just to make it clear, I don’t believe that TDD removes the need for testers. I wrote an article a few years ago about how the role of testers changes in an agile shop http://bit.ly/6Heart3

          When I mentioned googling “TDD Anti-Patterns” I wasn’t referencing googles code (but google’s CI/CD system is amazing what ever you think of their products). If you were to google TDD Anti-Patters, you would find some things that regularly show up when a shop is adopting TDD. Most of the entries have the same list, and I like James Carr’s because it’s format is pretty easy to read.

          Here are 3 of my favorite TDD anti-patterns

          Excessive Setup
          A test that requires a lot of work setting up in order to even begin testing. Sometimes several hundred lines of code is used to setup the environment for one test, with several objects involved, which can make it difficult to really ascertain what is tested due to the “noise” of all of the setup going on.

          [Malcolm’s Comments – it’s usually the case that the code is not decoupled and that the key word “new” is used outside of factories. – Excessive Setup usually indicates a code base that needs refactoring work just to get to something that resembles “testable” – and I wouldn’t be surprised to find a few 1000 line methods in there too.]

          Hidden Dependency
          A close cousin of The Local Hero, a unit test that requires some existing data to have been populated somewhere before the test runs. If that data wasn’t populated, the test will fail and leave little indication to the developer what it wanted, or why… forcing them to dig through acres of code to find out where the data it was using was supposed to come from.

          [Malcolm’s Comments – this is one of many patterns that can leave a team with fragile tests. Fragile tests will break just because someone changed code in another part of the system, but not actually breaking the system, it’s just breaking the tests. Fragile tests are a common reason for teams to abandon TDD and declare it be a waste of time. Learning TDD is like learning a new development language, it takes 3 months to get to a level of “incompetent” and another 6 to get to something resembling “competent”]

          The Slow Poke
          A unit test that runs incredibly slow. When developers kick it off, they have time to go to the bathroom, grab a smoke, or worse, kick the test off before they go home at the end of the day.

          [Malcolm’s Comments – Unit tests need to be able to run in under a minute, preferably under 30 seconds. At one test ever 0.01 seconds that should allow for 6000 tests to be run. I personally will label any test that runs over 0.1 seconds “an integration test” and put it on the build machine rather than on the developer machine. Integration tests are useful and needed, but many teams have build a huge suite of “integration tests” and have very few “unit tests” this again leads to teams abandoning TDD as “too expensive and provides no value.”]

  131. Pingback: Architecture and Agile: a Plan | Dev Recipes

  132. Thanks for your opinion, I can see many people agree with it. I dare to say that for me that’s the proof that agile systems/apps/etc. may be sometimes regarded as ‘magical things that will work without our efforts’. They will not. Sometimes it’s useful to look at some – short and simple but not obvious – instructions how to use this system efficiently. Personally, I like http://kanbantool.com/kanban-library/introduction that is quite short and clear. Of course,many consulting companies tend to offer introducing Agile in a perfect way and they don’t meet our expectations but it doesn’t mean Agile isn’t useful at all. Let’s don’t throw the baby out with the bathwater 😉

  133. Finally someone put it all into words and explained thoroughly all the confusion and frustration a lot of people feel about Agile! Excellent article!

  134. Pingback: Five Blogs – 7 December 2015 | 5blogs

  135. Great post! Unfortunately I don’t think this theme will be in a software dev process book any time soon. Would be great if you could introduce it to some authors just in case they add a paragraph on criticisms of agile/scrum.

    • I would love to see a book in the topic that has a grounded, practical, honest point-of-view that is orthogonal to that of all the PMBOK/PMP/PRINCE2/Agile/Scrum (marketing) materials missing out on big chunks of both engineering and ethical reality.

  136. Seems like you have made the common novice error of confusing what scrum is and what agile is.

    Agile represents a workplace culture.
    Scrum represents a development methodology.

    And the confusion over scientific method and agile? If anything, agiles achilles heel is similar to the downsides of transformational leadership.

    As soon as I get around to doing a blog, I’ll write a counter.