Why “Agile” and especially Scrum are terrible

Note: My first novel, Farisa’s Crossing, will be released in spring 2022.

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,899 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 …

        • I am sorry, but I just cannot agree with you. I have been using scrum quite successfully for several years. In my opinion it always gets a bad name from those who tried it but didn’t fully commit and ultimately failed. If it didn’t work it was mostly down to mangers who have been ‘in the industry for years’ torpedoing and poo posing it at every oppurtunity. Many afraid to loose the reigns for fear of being associated with something that they are not sure about.

          Any process, done poorly and not allowed to flourish by scared middle managers will fail.

          As managers of engineers in an agile world, I believe it is our jobs to empower the talent in our teams and to make sure they remain creative by giving the room to do so. Also, by doing simple steps such as defining your DoDs you can certainly tackle aspects such as technical debt. If we do this well, we can use the data and the successes in order to plan for the near term future.

          Maybe I’m brain damaged, maybe I’m not, but I am certain that the sooner the older never change a running system advocates move on, the better 🙂

          • You claim that defining Definition of Done will ensure no activities are compromised? Sprint is ending but the forecasted stories are not; I’m certain functionality is never compromised (“Yay, we did it!”), but certainly tests, performance, and refactoring sure are.

            The artificial sprint deadline creates a persistent pressure that is unhealthy for the product and the development team.

            As a manager, if a developer said to you “This story is going to take longer than we thought because there is a benefit of refactoring the code.” how likely are you to honor that? Consistently? Customer functionality and deadlines don’t concern themselves with code quality.

            • If the sprint is ending, then either cut scope, or let it slip. As a manager one shouldn’t be encouraging bad practice. Also if doing TDD, the tests would be the first thing you write.

              The sprint deadline is for the team, no one else. It’s something to aim for but based off vahue estimates, so if you’re treating it as a strict, hard deadline, that’s the source of your issues.

              As a manager it’s not my place to say if they should refactor or not. I would leave that decision with the engineer rather than dictate it myself. Also refactoring is part of the work, not something extra. Obviously one needs to apply appropriate scoping though so they don’t end up down a rabbit hole. Code quality is massively important, keeping it flexible, adaptable, readable is hugely important for maintaining speed of delivery.

          • I have worked in AGILE and SCRUM as a software developer and found it really stifling and fun robbing. It REALLY sucks working in AGILE, even when done by Americans who invented the damn term and process!

            • “I have worked in AGILE and SCRUM as a software developer and found it really stifling and fun robbing. It REALLY sucks working in AGILE”

              My experience is exactly the opposite. I’ve been on scrum teams that were exceptionally fun and rewarding. In fact, the most enjoyable and successful project I’ve been on over the course of several decades has been on a scrum team.Without question.

              The point being that Scrum is not a silver bullet, and neither is it evil or a destroyer of fun. It is a way of thinking about and solving problems. It’s especially good when you are building something you’ve never built before, and for which there is a lot of uncertainty. However, like anything else, when done poorly it will yield poor results.

              In other words, in some sense you get out of it what you put into it. If you found it stifling and fun-robbing, that wasn’t because of scrum but because of the people involved in the project.

              • “If you found it stifling and fun-robbing, that wasn’t because of scrum but because of the people involved in the project.” I can*t confirm that. We worked with the same development teams under “classic” project management and later under SCRUM. Same teams, same people, same projects. SCRUM removed every little bit of motivation. You always got only your little piece of work, you never got an insight into the whole thing. Before, the team happliy worked together, with SCRUM, everybody just worked on his part of the project, no synergies. Before, we even had fun working overtime, with SCRUM everybody just did his 8 hours and not a minute more. We did that for a year, then the company went out of business. SCRUM was not the only reason for that, but the final shot, which could have been avoided.

                • What I don’t like about breaking the projects into small pieces is that no-one can see the big picture. They just build their little piece their way. Well what if you get all of the pieces together and none of them fit together, because no-one knew what the end result was supposed to look like, or how it was supposed to work together. Having access to the big picture and being able to collaborate and sync their ideas is a huge part of development. This is taken away when you use things like Agile, Scrum, etc. Don’t get me wrong, documenting processes, showing work, and sharing it is great. It is actually preferred, but not at the level that these processes demand.

                  Another issue is that you have management that have no clue about development making decisions for the developers and telling the devs to just make it happen, or you are fired. This leads to sloppy coding, and eventually leads to farming out to those coding farms in India. Good luck ever figuring out how to break fix/debug anything from them.

                  • There is nothing about scrum or agile in general that prevents teams from seeing the big picture. Every scrum team I’ve been on did release planning and regular backlog grooming, and had a full understanding of the bigger picture. We never had problems where pieces didn’t fit together. We also didn’t have problems with sloppy coding (well, any more than you have with any team with any methodology), or farming the code out to offshore teams.

                    Like almost all of the other complaints in this crazy long set of comments, what you’re complaining about isn’t the fault of scrum, it’s the fault of bad management. With bad management, you’re going to have problems no matter what methodology you use.

            • I am so glad to see others that feel the same way as I have been so miserable and continue to agonize over this “agile” movement that has permeated to every corner of the tech world. This article is great and is so correct. What amazes me is the amount of people who will insist how great agile is!!! What I see is that this generation of folks coming into Dev/Devops have no idea what it was like without agile and how it has sucked the life out of being creative and designing truly great things.

              I cant find a company that is not trying to shove agile down everyone’s throat and of course they are doing it “the right way” lol. It goes right along with the “lets make everyone feel special while making sure you cant focus on anything but the mundane garbage out of sprints. This has led to the rampant under skilled engineers but that bite is that they think they are fantastic because agile makes everyone feel special with this consensus driven non-sense…

              Typical idiocies pushed by agile :
              Open office plans because it helps to collaborate (get real!!)
              many meetings daily to discuss total garbage and nothing of real value
              meetings to further discuss the above meetings because the solutions to all problems are just more meetings. (just ask any Scrum Master)
              and here is my favorite…. An entire army of people getting paid lots of money with new titles like ScrumMaster, Agile Coach, and the old project manager re-invented as a “Product Manager”

              When will this non-sense end? or are we at a point of no return and the generation of permanent junior skills will just drive the robot armies until it takes 15 people 6 weeks to do something that 2 could do in 1 in the not so distant past.

              • Jason, I absolutely agree with you!! Just add all this time spent in daily stand up meetings. It is supposed to be 30 min, but very often it goes over because people ask questions and often complain about something, Add up all this time and you loose from 3 to 6 hours a week!!!

                • You think one hour and fifteen minutes a week synchronizing with your team is too much? The scrum guide very plainly states it should be time-boxed to 15 minutes. If you’re doing longer than that, you’re doing something wrong.

                  You shouldn’t be blaming scrum if you’re not following the guidelines. Instead, blame your scrummaster if you have one, or whomever is responsible for keeping the standups brief.

                  Better than blaming someone or something, work with your team to improve your stand-ups. If you think you’re taking too long, bring it up during the retrospective. That’s exactly what the retrospective is for: to identify ways to improve the way the team works.

                  • ‘Work with your team’ was mostly considered to be insubordination, usually led to an early exit from the company if you persisted.

                  • The last place I worked also included +1 hour grooming, 1 hour “technical grooming”, 20 min picking tickets at start of sprint. Then every 2 weeks it was retro + sprint review.
                    So I reckon an average of 4 hours 35 per week. Of course that didn’t cover other non-scrum meetings.

                    • You might as well give up. Every protest against the cancer that is scrum has the same template – “xxx is not correct, you must be doing scrum wrong”. In other words, every person who sees scrum for what it is “does scrum wrong”.

                • Because it’s the dog and pony show where people try to show value and seem as though they are productive. I found that, in those meetings, image was very much more important than substance. They were all for show.

                  • It sounds like you had a very bad experience. That’s unfortunate. I’ve worked on three different scrum teams at three different companies, and in al cases the stand-ups and retrospectives were very productive, and usually much shorter than the associated time-box.

                    Like with many things, success depends a lot more on the people than other single factor. If you have bad managers or selfish team members, you’re doomed to fail no matter what methodology you use.

                    • Bryan, glad to hear you fared better but I still think scrum is toxic. Here’s why:

                      1) I started in software before the days of the ‘orange Bible’ that Yourdan wrote on structured design. This history has exposed me to many different methodologies, all with their different niches and flaws. Never, in over 30 years did I hear such an outcry from the developer community about bad experiences with a design framework. This blog, for example, has been going for over 6 years and the discussion is as heated as ever.

                      2) The “you aren’t doing it right” argument could be applied to almost any methodology as all account, in some manner, for user requirements, design, design changes, time boxing, testing, etc. Waterfall, done correctly, worked. Iterative development (my favorite), done correctly, worked. It seems that there is some toxicity about agile/scrum that allows (or encourages) the misuse and corruption that is leading to what many are calling a proliferation of horribly flawed software development environments.

                      I have more thoughts, but it’s late so I’ll call it a night. If you can get past the “you’r doing it wrong” for a minute, please tell me why you think scrum is so easily corruptible? I have seen good waterfall and iterative development teams (means it likely isn’t the people, at least the developers) ruined by management dictating scrum training and adherence.

                • You know there are more than just 2 software development methodologies right? What was wrong with spiral? Also, what was wrong with hiring good people and just legitimately letting them self-organize and have some autonomy over their work?

            • Correction
              First: It was not darn Americans who invented Agile. It was actually a consortium of professionals from many countries.
              Second: The ability to be Agile is not something that you invent but it is something that is inherent in all of us.
              Third: Agile is a set of guiding principles; each one of them proven to be effective if used properly.
              Fourth: Software development teams do not work in Agile, instead they use a framework such as Scrum which in turn uses Agile principles – As such your comment indicates that you do not have a comprehensive understanding of the subject matter and I will encourage you to learn more about it before posting comments.

              Perhaps you did not succeed as a developer while participating in project that sought to utilize Scrum – That is not the fault of the framework but how it was not properly implemented.

              • “Fourth: Software development teams do not work in Agile, instead they use a framework such as Scrum which in turn uses Agile principles”

                People use the terms “scrum” and “Agile” interchangeably. The very first paragraph of the blog makes it clear the author does not believe they are and his complaints are with Scum and not Agile. I’ve argued in previous comment that not only are they not the same thing but that Scum completely violates one of the major principles set out in the Agile Manifesto which says, “Individuals and interactions over processes and tools”. Scum is process on steroids and management tries to treat engineers as interchangeable cogs in that process.

                In another comment you state, “If you feel that way, then enlist in projects that use the waterfall methodology.” You really do need to go back and read the paragraph of the blog which calls “waterfall” a straw man practice. One that was largely invented by Scrum promoters to make their own methodology look good.

                “Perhaps you did not succeed as a developer while participating in project that sought to utilize Scrum – That is not the fault of the framework but how it was not properly implemented.”

                In a comment posted two years ago, the blog’s author answers this by saying, “If the human condition were described by business people, we’d all be immortal. The problem is that everyone Does Immortality Wrong.”

          • You are a middle manager. Scared or not, we all know you love scrum.

            ‘I believe it is our jobs to empower talent…’
            The only time I’ve felt empowered by middle management is when they agree to leave me alone and that is rare, so just continue trying 63 different types of PM software with the hope appearing relevant.

          • “Maybe I’m brain damaged, maybe I’m not, but I am certain that the sooner the older never change a running system advocates move on, the better 🙂”

            Is that a reference to the article talking about how this system is hostile to older developers who’ve developed a small amount of self-respect and expect their development processes to not be completely dysfunctional? If so you are definitely brain damaged.

            1. MOC never advocated for never changing a running system.
            2. That is a complete strawman of what software development is like outside of a scrum agile environment.
            3. The people most likely to be afraid of changing a running system are the series of revolving-door juniors you keep replacing your good people with. That’s because the juniors don’t understand how the system works, and even if they do they often don’t have the skills to fix a hairy problem.

            Chasing off the top end of the experience/skill range because you feel threatened by employees who know how to do their job is the reason companies end up with “senior” developers who’ve been in the business for 5 years and can’t do FizzBuzz.

        • I’m 20+ years in the industry and 10+ years as manager and so far, I did not have heard so many useless opinion yours. To prove my point, I quote yourself “ts religious adherents are at best brain damaged useful idiots” – That means a lot about yourself and your management style. A bit of politeness, education and awareness would be good for you. I can teach you somethings, for free, if you want. Maybe you’ll change your 1950’s mind.

          • wow that literally added nothing to the conversation, for a manager you sure dont know how to make things clear and your points understood… pitty the poor souls that have to deal with you ona daily basis

          • You’re barely even literate, and you’re preaching about education? BTW 20/10 years in the industry doesn’t mean much. Some people have 20 years of experience, and some people have the same year of experience twenty times in a row. There are plenty of middle and senior managers who don’t have their heads screwed on straight in the slightest but get by due to nepotism, office politics, and other games.

            • It clearly does not even occur to you that someone might have a different first language than you do. It must be a very strange experience to be so thoroughly egocentric.

      • 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.

                  • You’re asking for studies showing that no studies have been done (producing no evidence)? The burden of proof that this stuff works lies on the people advocating for it. If someone tells me sticking a knife in my eye will double my productivity, the onus is on them to prove it, it’s not up to me to stick a knife in my eye and see what happens.

                • Good point. I’ve seen instances where Agile and Scrum have worked very well. I’ve also seen times when it hasn’t been helpful. I think its good to have a range of approaches that you can use where appropriate

            • “ad hominem” means that someone said “your conclusion is wrong because you are a terrible person” or “because you went to a crappy college” or “because you were wrong about other things in the past that have nothing to do with this thing”. It means that you are saying that an idea is wrong because of who is putting it forth.

              If you’re going to quote a fallacy, then try not to abuse another one?

          • 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?

              • No it gives them the limited right of self-organization within the very narrow confines of scrum. This is what the author was saying: The right of self-organization within the narrow confines of scrum results in a trending toward the low-hanging fruit, basically what little bits of code can I cherry-pick from the backlog to get my sprint points up. It’s a practice that breeds mediocracy is his point. A self-respecting engineer would not voluntarily adopt Scrum due to the coercive effect that hit has on the engineer and the engineers ability to truly hone his craft versus honing the scrum craft which is really no craft at all but a huge amount of process, ceremony and tooling thrown on the heap. From what I’ve observed, it takes far more software engineers to get projects completed in a scrum shop. Did you hear this one: “Q: How many Scrum engineers does it take to screw in a lightbulb? A: It can’t be done! That’s a job for the hardware team!”

                    • As I remember, people with high sprint point totals were declared to the the most productive and meaningful team members. And this statistic was always a part of your annual review. Thus, the most useless were rewarded while engineers that actually tackled difficult issues were put on improvement plans. Reminded me of stories about people drowning on ships found with the heel marks of the survivors on their shoulders and the tops of their heads.


                    • To me, sprint points or story points is the most noxious part about Scrum. Scrum coaches will tell you not to use them to rate people, but tools like Jira make it easy and managers routinely use them.

                      The person who is the best at figuring out which stories are over-pointed is the one who will get the highest rating. Not the person who is the best or goes the extra mile and does more than what is in the ticket.

                      Those things that do not have story points such as mentoring or writing documentation or just answering teammate’s questions will fall by the wayside.

                      When I interviewed this was one thing I asked about. If I got a sense they were using story points to rate people, that was a big red flag.

              • In what world? Every shop I’ve been in that did Agile, the tickets and priorities were set up by nontechnical managers and assigned by technical managers. “Well they were doing Agile wrong” is the usual retort to any criticism of Agile-in-practice but so… I think every shop in the world must be “doing Agile wrong”. If it can’t actually be implemented in the real world it’s not a very useful system.

                I’ve had managers scold me for reassigning my teammates’ tickets to myself because they were sick/had another higher-priority ticket that dragged on longer than expected and I was ahead and had nothing to do. Because it made it harder for them to objectively measure that person’s performance in terms completed “points”, even when it was clear in retrospect that those assigned points didn’t accurately reflect how much effort each feature required. How is that for agility and self-organization?

                • “I think every shop in the world must be ‘doing Agile wrong’. If it can’t actually be implemented in the real world it’s not a very useful system.”

                  If the human condition were described by business people, we’d all be immortal. The problem is that everyone Does Immortality Wrong.

                • Why are they using points to measure an individual’s performance? I think Scrum is flawed, but using points to measure performance or preventing reassignment of tickets are not a part of Scrum. You have a control freak manager, but are here blaming Scrum for their behaviour.

                  • Because managers need to be able to measure an employee’s performance somehow, and most managers are so disconnected with their teams that they need to look at “objective numbers” even if the numbers don’t mean anything. It also logically follows that if points are a measure of useful effort, then someone with more points has put forth a greater amount of useful effort. The problem is that points don’t work very well as an objective measure of useful effort, because nothing does. But this is how managers think, and the way Scrum is set up absolutely causes this. It is far too tempting to give managers a number representing the amount of useful effort each task takes, and then tell them not to use it as a measure of useful effort accomplished. It’s like expecting a 3 year old to pass the marshmallow test, except that in this case failing the marshmallow test will turn the entire workplace toxic.

                    • The key problem here is “rank and yank” also known as doing evaluations on a curve. If you’re company has regular layoffs of a fixed percentage – usually 10% annually – they are practicing “rank and yank”. This is a practice originated at GE. It got so bad that no one wanted to work at GE. They had publicly announce they would no longer be doing this and in fact would no longer have annual reviews.

                      Ten percent doesn’t sound like a lot of people, but if it’s done every year, by the third year they are no longer laying off the bottom, they are laying off the middle and everyone is nervous.

                      How do managers select these unlucky individuals? It’s hard, The first layoff usually gets rid of the dead wood. After that, it’s not easy to differentiate between good employees, so it become very tempting to use story points.

                      It heavily discourages people from helping their fellow employees. The practice incentivizes office politics. I was criticized for “only” accomplishing 80% of the points of the team average by one manager. I told him I was getting more than my share of tickets involving Selenium. Our Selenium code was being underpointed and was crap that should be rewritten. When I left the company for another job one of my fellow employees admitted to me that they were avoiding Selenium tickets!

                      In my opinion rank and yank is nothing but management by intimidation. I’ve heard that tin the 1930s managers were told to go down the assembly line and fire a fixed number of employees. This is no different.

                      Up until the 1990s the prevailing management philosophy could be found in the writings of Edwards Deming. He advised that most problems in a company were caused by bad process and not bad employees. Process is controlled by managers so it was their responsibility. Rank and yank focused the spotlight back on the employees. It freed bad manager from taking responsibility for their own part of the problem.

            • The logical fallacy is you presume distrust, that an expert in an area of code will not be believed when he or she had a bright idea or perceives urgency in a significant refactoring. At a recent scrum/agile team I worked at, we explicitly allowed programmers to plunk tickets up in the top of the queue. If you had sound reasons, you were likely to easily find allies without any fuss or raised eyebrows. The Product Owner may “own” the queue in terms of pedestrian day-to-day management, but the team as a whole takes responsibility for everything important, including the process of prioritizing and follow on effects on velocity. Shared responsibility actually means shared responsibility.

              I understand that sometimes companies adopt agile-like practices where there is no trust. It is not surprising that the classic bad habits get recreated. What process theory can protect you from managers that insist on being overly controlling? Are layers of process obfuscation really likely to be sufficient? Agile may not automatically be better under poisoned conditions, but it is not automatically worse either.

        • 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.

            • Since you are rating the solution by the hardness to apply it: Have you ever written code that needs to provide deterministic outcome, but is fed with random input data? If so: How did that work out? What did you do to verify it’s reliability?

              • I have written code that takes random input and produces determinisitic output, with bounds on space and time requirements. It was a function called “sort()”. I verified its reliability both with formal methods, and by testing it with large (and small) amounts of random and not-so-random data. I’m pretty sure it works.

        • Name one logical fallacy in what he said. Maybe there is lack of palpable evidence for some statements but nothing is illogical

      • 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.

              • Well, we need to differentiate: Is the refactoring a necessary task on itself (e.g. does it provide value to the product itself, e.g. reducing long term support costs, increasing productivity of the developers, fixings bugs et cetera) or is it providing value when working on another (prioritized) backlog item?

                If the latter is true, e.g. the refactoring affects code that will be touched for a certain backlog item, then it’s not “under cover” to do the refactoring as part of that backlog item. It’s perfectly in the realm of the development to decide upon this and reflect that decision in their estimation (so that PO can properly prioritize it).

                Remember, in Scrum there is a distinction between “what” and “how”. The PO decides what has to be done with priority in order to satisfy customer demands. But the team decides HOW it is done and if this involves a need for refactoring that’s the way it is.

                BUT with respect to the first case: It might be that the PO has a hard time to see it’s priority for the business value of the product. Maybe the refactoring work is not even estimatable, which makes it even harder to prioritize it. I wonder if the development team tried to work with him to make sure it get’s the priority it deserves. Perhaps with the help of the ScrumMaster who is supposed to clear impediments.

                But I guess no, since it’s easier to complain than actually work on issues.

                • “The PO decides what has to be done with priority in order to satisfy customer demands.”

                  Rendering the development team servants to functional implementations, fighting for refactoring and technical debt. This makes those executors powerless to make their situation better.

                  How can you prioritize refactoring priority when the rebuttal is always “But we have customers willing to pay for this next feature”?

                  The part I loathe the most is when pointing and someone adds the complexity of a refactor, claiming a 13, instantly the question becomes “Why so big?”, but the other outlier who showed a 1 is never interrogated.

          • If you can “bake” it into estimates, and do work not intended to be done for stories, and nobody sees this, then its flawed and is not accurately projecting how long the project took. You’re spending company time/money, or in some people’s opinions, wasting them. How dare you!

      • 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.

        • why do you think that this methodology put pressure..? At every sprint devs decide how much story they can work on, so they do the estimate and they are the one who says if they can do it or not. In theory no one should say to the devs how much they can afford. One of the pillars of Scrum is transparency so the devs says to the PO how much they can produce and PO says to the client how fast they can go. The author says that scrum and agile is stressful… it is not if you apply it correctly, it is much better than using non methodology at all. Everything is clear to everyone in the scrum (devs, SM, PO, Client) and if everyone respect the rules of the game no stress comes up for devs or any one else. As someone else have wrote, if the management doesn’t understand the agile/scrum philosophy they should NOT use it in their company because it becomes a really big problem and the company become less and less productive.

          • Ok, the first problem is having a task that can be divided into smaller tasks without losing coherence and it takes more time than 1 sprint. So basically the person taking it up will have nothing to show at the end of the sprint. Second most of the complex stuff that needs to be written have a great variation of how much they will take. Something that seems it will take 1 day may take 1 month to complete and something that looks it would take 1 month may take a day. Third problem is that the client wants something he can see but when working on backend many times something like this is not possible for many tasks. For instance if you build a house the foundation is not important to the client but you can have something reliable without it. So all work goes to write incomplete features full of bugs rather than building a sturdy base because you need to show the client something. And yes Agile is stressful because software devs do not work in divisions of time so small. For instance a 10 minutes meeting to a manager/scrum master is a 10 minutes time loss. For a dev is often a half a day time loss.

          • Agree with you. Many of these problems come from Scrum Master is not a Scrum Master at all and he/she does not set up framework correctly and finally Scrum is perceived as a waste of time. Therefore everyone using scrum wrongly will be perceive as a waste of time and they will be right.

            • You could make the same comment about any methodology. I. E. if you do it wrong it won’t work and people will be unhappy.

    • 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.

        • I agree JS, but programmers get bugged down w/ all this bullshit processes. I totally agree w/ the comment in this article that there is no space for architecting, research and development, and the like. I’m used to having a design when I go into a project and no one ever knows; this designed in buried in User Stories. I prefer writing a design from requirements and implementing in Sprints or whatever anyone wants to call it. As a programmer, I hate this Agile BS. Damn, tell me what you want, I’ll design and build.

        • It is ironic that you are actually referring to the first principle listed in the “Manifesto for Agile Software Development”

          * People and interactions over processes and tools.

      • 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.

        • > 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

          It might be worth actually reading the Agile Manifesto (agilemanifesto.org/) before making claims like this. Submission is the key word of waterfall, and if you actually read the Agile ethics and principles, it’s goal is *exactly* the opposite. Despite the OP’s claims to the contrary, waterfall was the main development methodology in corporate IT at the time of the Agile Manifesto was drafted. This has been well documented by Eric Raymond in ‘The Cathedral and the Bazaar’ and elsewhere. What the OP is describing is waterfall management clothed in the language of “Agile” and especially “Scrum”, and using bastardized versions of certain Agile practices within a waterfall workflow. To blame this on the creator of the Agile practices thus abused is just bizarre.

          • It’s not bizzarre, it speaks to how deeply psychologically wounded people like the author of this article have become by bad corporate management practices. He has decided to make Scrum the object of his wrath, and I don’t think anyone will be able to change his mind.

          • He didn’t blame it on the creator, he blamed it on the practices. Which he has said in a bunch of places are useful in some situations but which are basically an abuse of your people in most places where they are being used. I am not sure where you got the idea that this was a personal attack.

            And Eric Raymond is frankly neither much of a programmer nor much of a philosopher, and he certainly doesn’t know all that much about management. It is a mystery to me why people quote him the way they do, except that he became a guru by … becoming a guru.

    • 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.

        • > For about 3 years I had the unique opportunity to pick anything we like fro Agile and do or not do.

          This is *exactly* what the Agile manifesto encourages you to do, to be agile in your practices, use what works and discard the rest, as long as you deliver working software. All the cargo-cult stuff done in the name of Agile is like people claiming that democracy means making every single little thing in everyday life subject to a majority vote.

    • 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.

      • I too am a Certified Scrum Master (scrum.org PSM I) and I understand the values that Scrum tries to instill.

        The process is a failure because of it’s ease of corruptibility which was designed by software engineering leaders who (naively) believed that it was empowering but turned out to be enslaving. This is anecdotal from my experiences at 100% of the last 3 companies I worked at, all attempting Scrum.

  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.

          • It’s a process that was hypothesized and experimented with but clearly does not hold up to the rigor of the real world.

            Psychopaths are not the only ones that co-opt these processes – it is done many times by well-meaning individuals who want to “optimize” or “iterate” or “fail fast and often”. In trying to improve they look towards and try to control the measurable output, many times to the detriment of those doing the work.

            Many could attest to managers (non team member) examining Velocity or trying to “fix” a burn-down chart or enforce WIP limits; these are all meant to be tools _for the team_ yet this “transparency” enables judgment on how they operate.

            It doesn’t take much to turn this tool against its creators and that is where it fails.

      • 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.

      • It’s the norm because the people who sign the paychecks are social animals, not intellectuals. They care far less about merit than they do about being social animals. Agile never solved this problem nor did it intend to. So it was crushed by the social animal all the same.

        I could write another horror story on here about how the Agile transition was a vehicle for less qualified people to call the shots over more qualified people. Or how those unqualified people were promoted. Or how the company hit the skids. You all know because you’ve seen it.

        The only environment that will suffice for intellectuals and true developers out there is unbridled autonomy even at the expense of pay.

  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.

              • Even there, with processes like ISO 26262/8 for safety critical software development (with a prescribed V model), nothing in the V model precludes iterative development or insists that ALL the requirements have to be reified, designed etc before ANY code can be written. Once interfaces are defined and so on, individual module implementations can be written independently. Similarly whether in some V model or iterative development, conceptually one writes tests against requirements. But in practice, whether they be manual tests or automated, the tests have to be written against the design or implementation to be able to test it.: the proof of test coverage becomes a transitive one, because there is a mapping from requirements to design to implementation, and so one can test at a more-detailed level and infer that the higher-level requirements are satisfied

                Nothing in the V model prevents iterative development, the ISO requirements simply say that here are the deliverables for each work item, and so what? You can use an existing implementation, nobody forces you to write everything from scratch as the strawman “waterfall” aargument always seems to imply. I’ve done several jobs writing requirement specs etc for existing code to meet ISO 26262, i.e. the code was already functional and specified but not to the ISO standard. You don’t have to reinvent the wheel every iteration, nor avoid using library code (if you can test it…)

                There are also provisions to allow deviations from the requirements, although understandably the process is quite onerous. I’ve been doing safety-critical work (amongst other things) for over thirty years and I’ve never known the requirements to be set in stone as “waterfall” implies, there is always a well-defined mechanism for deviation.

          • Straw man. Not “could never” change. Only that such things will not be changed without an adult standing up and stating coherent reasons and be willing to take some heat for it. Since programmers browbeat into being cogs was invented looooong before Scrum, such shifts rarely happened.

            Very Waterfall projects certainly did exist. Whether they were True Waterfall or True Scotsmen is really unimportant.

      • 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.

      • Think of this when you hear “waterfall”: a logical process of interdependent activities. To do B, you must first do A; to do C you must first do B; etc etc. If this rather makes you think “Scrum” or “Agile”, you’re not wrong: they are also using (albeit small and fast) waterfall processes.

        The biggest flaw is that while traditional software development projects (and not Waterfall itself) are managed by Project Managers, Agile and Scrum projects have abandoned PMs to get rid of all the seemingly unnecessary management (administration, meetings, prioritization, planning, estimation, risk management ets etc).

        I cannot see that Agile or Scrum are giving less “unnecessary management”. Scrum have even introduced the “Agile Project Leader” together with PMI.

    • 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.

      • You might be thinking of “The Surgical Team”, chapter 3 of “The Mythical Man-Month” by Fred Brooks Jr, written in 1974 (but documenting practices from earlier). A must read for any software engineer, I should think.

    • “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.

        • Are you under the impression that most workplaces have cut the status review meetings and change management meetings, rather than just adding the agile meetings on top of what was already there? Stakeholders don’t bother to show up to standup so you have to communicate progress with them somehow.

      • 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.

    • Yikes. Slopping up technical debt caused by poor management practices is not anyone’s idea of a hackathon they’d want to attend, and if you’re forcing people to attend hackathons you’ve missed the point…. again. “Business partners” don’t always have 100% perfect insight into what’s needed to create a good product and if you leave it to them you end up with a pile of junk, because they will always dictate corner-cutting in favor of speed.

  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.

              • Quality is not about meeting requirements but about meeting expectations, stated or not. Requirements are fundamentally incomplete. Code is an exact documentation of the requirements. The computer interprets the code/requirements and executes them exactly as written. Human language “requirements” are inexact and quire creative interpretation. If they were exact, we could make a computer perfectly interpret and execute them.

            • “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.

        • “Agile maturity model”?

          Then you can say “Look, we have standardized agile. Now we have this scale ranging from 1 to 10, with this set of rules you must follow if you want to go from 3 to 4.” And you don’t want to do that just on a single developer or on a team, but you want to take every team following agile principles in the whole world and *put a number label on them*!

          If you don’t trust the people, no process can fix that. That’s the first agile principle: the people over the process.

  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.

      • “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.”

        Scrum does not “constantly interrupt” a team. Quite the opposite: the team is pretty much left alone during the course of the sprint.

        I’m guessing you’re thinking of the daily standup, but that’s not for finding out what the team is doing so much as it is an opportunity for the team to sync up internally before starting the day. The standup is purely for the team. It’s more of a way to make sure everyone has what they need and aren’t being blocked than it is anything else. If you were on an agile team that treated the standup as a status meeting, you weren’t using scrum properly.

  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.

        • Thanks for bringing that up. I really think that “Capitalism” is the missing word in this very interesting article.

          As I see it, a sincere application of Agile principles is totally incompatible with capitalism. And that is why the author is always using expressions like “Agile as it is commonly implemented”.

          To my point of view, Agile manifesto just came up as another observation of the forever going fact that the most productive worker is the autonomous one, the one that has true power on its own work and the way he is doing it. But this autonomy will always be merely an illusion as long as the company belongs to its stock owners and not to its workers, or within a inequal client-provider relation.

          Then, the “product owners”, “scrum masters” and any other you could find will always be what they are not meant to be : “chiefs”, intermediate stages of a hierarchy which has stock owners at its top. And these will always have as first priority the conservation of their own power, over anything else : actual purpose of the work done, effects on society and environment, actual productivity. Even some times, profitability can be sacrificed as long as the actual control on the company is not lost.

    • +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.

    • If a large percentage of workplaces that attempt Agile/Scrum end up with the anti-patterns described in the article, it’s ridiculously precious to claim that this has “nothing to do with” Agile/Scrum. If a system isn’t designed to account for the common failure points of human beings and human organizations, it’s a bad system. Or at least one in need of improvement. Nobody these days would accept a car built without seatbelts because the manufacturer said, “just don’t crash the car and everything will be fine.”

      • Personally, I think the fact of the matter is: Scrum and/or Agile (no, they’re not the same, and no I don’t think it matters to this point) work in good workplaces and fail in bad workplaces. That is, if you have intelligent, cooperative and motivated developers, and a management team that respects them and protects them from BS, Scrum and/or Agile will work when implemented. If you don’t, then it won’t.

        The problem is, the same could be said for any other system of development on this earth. Partially because no system works 100% of the time and a team of intelligent, cooperative and motivated developers will flex the rules of any system when needed — so long as they are allowed to do so.

        Unfortunately the high-velocity, shallow-depth development culture encouraged by Scrum/Agile means that if there are any slipups at all when implementing the system, everything goes straight to hell. If you overwork your developers they will eventually become burned-out. Unmotivated, too busy to communicate any more than necessary and effectively stupid. I don’t think Agile-as-implemented (AKA the real-world likely case, not the ideal-world case) makes 3’s into 5’s. I think it makes 5’s into 3’s.

  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.

    • As I said earlier, if you build a car without seatbelts and say that the perfect drivers do fine without seatbelts, it’s still your fault for building a car without seatbelts. Perfect drivers will do fine in just about any vehicle. Does agile actually have anything special to offer, or is it just a case of everyone dismissing the workplaces that do agile imperfectly (the vast majority) and taking credit for the ones who do it perfectly (which would succeed regardless of methodology)?

      • Precisely. The same applies to other methodologies; manufacturers brag about ISO 9001 compliance but can still produce awful products. ISO would certainly take credit for those that make high quality products. But the companies who’s _practicing_ values (not those on paper) are aligned with those individuals that have the most impact on their product are successful without these communal-formalized processes (e.g. Toyota).

        It was made with good intentions, but you know what happens with that…

  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.

      • IOW there’s no place for a person who won’t act like cattle. I’m not going to pretend I’m some 10x developer, but I’ve worked with them before and it’s much, much more productive to let them go off and do their thing and let the other developers learn from them and to some extent work around them, than try to micromanage them. (This is, of course, assuming we are talking about actual genius developers and not average or below-average developers who think they are geniuses or have “played the game” well enough to be perceived as geniuses.)

        There is no room in the agile/scrum system for individual developers with curiosity or innovation. You need to sell your idea to others before doing any experimentation, because your time is preplanned down to a very small increment.

  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.

    • I’m glad to hear your current job is working out well and I hope things are still going well for you 2 years later!

      I’m sorry, but you are not doing Scrum! Scrum mandates the team sits together at the same table, in-person, five days a week. Working remote is not allowed! If your team would bring in a real Certified Scrum Master, the first order of business would be to tell you to either get into the office or get fired.

      • This is nonsense and your attitude is exactly the problem described here!

        Read the agile manifesto! It clearly states “*Individuals* and interactions *over* *processes* and tools”. What part of “over processes” did you not understand? To clarify this again for you: It means, you must adapt your processes to your team!!! Forcing a team member who does a good job to change his life or even firing this person is exactly the opposite!

        Thanks to people like you, who didn’t understand the underlying core ideas and instead blindly follow the hollow letter of some process (without its spirit), talented developers suffer! And this is not only the case with scrum but with every methodology.

        I’m a very experienced developer (20++ years of experience) and I did it many projects with scrum in the past. And many of them, I did remote, too! It all worked perfectly, because we did scrum in spirit: With mutual respect, fun and high productivity, we developed high-quality-software (and yes, we invested quite some time in cleaning up technical debts, i.e. improving the quality without implementing new features).

        Btw. I never experienced failed scrum as described by the author of this blog-post! But as already said: If people like you rather fire a good employee than adapt the process to the team, then every methodology, including scrum, leads to disaster! People like you should never become in charge over any team — neither in software development nor anywhere else!

        • You could very well be right. Scrum/agile could even be the long heralded cure for warts and flatulence, however Sky Coders post is almost verbatim one of the speeches I heard at a major HCIT company. No remote! All in the same room! Orders will be obeyed! And our once ‘best of breed’ product started it’s long downward spiral into a bug infested disaster. Managers and scrum masters loved it because they could tell exactly when our useless software would be ‘finished’.

          So it seems to almost universally be a disaster as implemented in the vast majority of companies if I read both my experience and most posts here correctly. Many, including myself, have never seen a company that has implemented this methodology correctly. So it’s time to move on and find something that not only works but that can be correctly adapted to a higher percentage of companies. Because it is chasing a tremendous percentage of experienced developers out of the industry and software quality is suffering. I would point to the Windows 10 Creator update as a good example of ‘scrummed down’ software.

          And I have to ask this. Are you a scrum master? The only developers I remember loving agile/scrum were junior level or experienced developers that weren’t all that useful.

          I still say iterative development was the absolute best way to develop mission critical software. At least it worked for me. I could produce functional, compliant, well documented code on time with an extremely low defect ratio and when I did fix defects, I had a count of 0 (that’s zero) rejected by QA in testing over my 13 year tenure at my last company. I had over 30 years total experience when I retired and I NEVER saw a disaster like agile/scrum in all that time.

          • No, I am not a scrum master. And I’m definitely not a “junior level or experienced developers that weren’t all that useful”. I’m one of the best architects and software developers on this planet — all my customers are happy to confirm this 😉

            Btw. the last time I did scrum in a really well-working way was at the ENBW (a large German energy provider) in the winter of 2014/2015. This was non-remote, btw. But it shows that even large companies can implement scrum correctly.

            I did scrum many many times in many different companies (both remote and in the office) and it always worked fine. However, I never encountered such a poisonous atmosphere as it is described here so often. And I truly believe that this kind of poisonous atmosphere destroys every kind of team no matter what methodology they try.

            Trying to switch to a different methodology, because some idiots obviously cannot implement it correctly, does not help. The problems I read here are problems of capitalism (i.e. disrespect and greed) + incompetence (primarily on the managers’ side). You can’t fix these problems with any process — after all, incompetent people in powerful positions is not a problem of the methodology.

            And blaming the methodology like so many of you (especially the author of this blog-post and cyp) do, is totally counterproductive, because it distracts from the actual problems — and they are not scrum and especially not agile.

            Btw. what seems to have happened here to most of you (and fortunately never to me) is the same that happened to liberalism, conservatism and the leftists: They became NEO-liberalism, NEO-conservatism and NEO-leftists, having nothing to do with the original ideas:

            Liberalism is about liberty while neo-liberalism is about exploitation of people, i.e. constraining the freedom of nearly everyone — giving place to big-money’s liberties only.

            Conservatism is about conserving the old, while neo-conservatism is exactly the same as neo-liberalism and does actually destroy the old — thus again having mutated to the exact opposite of what its name implies.

            And while leftism is about defending the poor against being exploited, the neo-leftists only care about insignificant nonsense like genderism and the like, while totally neglecting the poor — actually even directly betraying them.

            Seems to me that while agile preached “individuals … over processes” with scrum being a concrete implementation of this principle (among the others of course), the neo-agile does exactly the opposite.

            If you tell me that a “Scrum Master” kicks out a good developer because he wants to work remotely (and this works fine), then he betrays scrum like a neo-leftist betrays the left. And if you tell me that this “Scrum Master” is a “Certified Scrum Master”, it only shows that the certification process has been hijacked by the big-money just like neo-liberalism, neo-conservatism, neo-leftism and many more. We live in Orwellian times! That’s newspeech!

            And if you want to fight this, it really does not help to blame scrum! It does not help to blame agile! It does not help to call me a “not useful developer” (everyone working with me and knowing me better could only laugh about you!), but the only thing that helps is to clearly stand up and say “NO, THIS IS NEITHER SCRUM NOR AGILE!”

            If you don’t do this, but instead look for yet another methodology, the exact same thing is going to happen to this — and suddenly you’re going to hate your new methodology — which again is the wrong approach.

            It’s just like a bad developer writing shitty code in C++ — switching to Java or C# or Scala or whatever won’t help. Unless this bad developer starts learning from his mistakes, he’s going to repeat them in no matter what new fancy language he’s going to use.

            • You type fast!

              I guess we will just have to agree to disagree. I’ve seen many methodologies come and go but have never seen the destruction to careers that agile/scrum has caused. I have personally experienced and seen this. To disagree with the mandated implementation of agile/scrum was to be out the door ‘like shit through a goose’. The methodology is too easily corrupted and bastardized, much more so than any of the others that I have been exposed to. To continue to promote this form of ‘development in the face of this does not, and never will, fix the issues. I would hold the experiences of my fellow posters as proof of this.

              • Well, honestly I didn’t take this blog-post and the commentators serious — I have seen too many bad developers searching for scapegoats to blame for their own failures, before. And I have seen many methodologies, too — and Scrum worked best in my personal experience.

                But then I read an interesting article published by a large German union. I just looked for it again — I think it’s this: http://www.blog-zukunft-der-arbeit.de/die-zwei-gesichter-der-agilen-scrum-methode/

                For the non-German speaking: The title says “The two faces of the agile scrum methodology”.

                That’s when I started to think that you might be right in that there really are a lot of idiots out there doing the opposite of agile, but label it this way — even though I fortunately never encountered them.

                Well, I’m born in a so-called “socialist” country and I can tell you: This country had nothing to do with socialism and even less with communism!!!

                Still, I’m a convinced communist and didn’t fall for the idiots who abused this term to make me spend the first part of my life in a prison (until we finally escaped it). I understood very well, that the usual evil-doers (everywhere) driven by greed abuse everything — be it the most beautiful imagineable — and turn it into their tool, thus usually turning it into its opposite.

                And having seen the same happen many many times everywhere, I drew the conclusion that the analogy of the euphemism-dreadmill you’re propagating is not helping. The people in favour of euphemisms do exactly the same: They say “don’t say ‘negro’ — say ‘black'” or “don’t say ‘prostitute’ — say ‘sex-worker'” and what happened? A few years later, the words introduced due to euphemism were burnt and had the same connotations as the old words, before.

                This approach is nonsense! Rather than accepting that idiots abuse words for different things, you should stand up and say “no, that’s not it” and proudly continue to use the old words and the old methodologies which you saw work fine. Btw. there’s proof that this approach works very well: The term “nerd” was a cussword, until we nerds started to use it proudly for ourselves. Today, most people wouldn’t think of it as a term of abuse, anymore (at least in Germany). The same happened to the German word “Hure” (prostitute) btw. — there’s a union of prostitutes who proudly use this former cussword to refer to themselves.

                And sorry, I cannot confirm that anyone is kicked out for criticizing the way Scrum was introduced. In all companies where we used Scrum, we discussed in the retrospective what went bad — and believe me: I’m very well known for saying bluntly what I think — nobody ever fired me! …and neither anyone else who criticized the Scrum implementation (or any other part of the work).

                • 1. Hure I think it means whore not prostitute . And sluts everywhere still seem to find it offensive. So bad analogy.
                  2. negro and black are not the exact same thing. negro comes from negroid and is characteristic feature are things like shape of the skull, thick lips, squashed nose. Due to inter-racial babies during the centuries there are a lot of black people that do not have negroid features and white people that do have them.
                  3. there is no way to put into practice what Agile preaches without reaching to slavery for the software developers.

                  • 1. No, good analogy, because languages don’t fit each other 1-to-1.

                    This is the union I talked about: https://de.wikipedia.org/wiki/Huren_wehren_sich_gemeinsam
                    (the german legal form is a “Verein”)

                    And yes, you can translate “Hure” to “whore” and they use this word to refer to themselves. So it is a really good analogy to illustrate the right approach: Take pride in whatever you do, stand up, and break through the dishonest euphemism-treadmill.

                    2. Negro comes from the latin “niger”. That’s why, today the Spanish word for “black” is: “negro”! Consult a dictionary, if you don’t believe me!

                    3. Nonsense. The agile manifesto has exactly the opposite goals: Empowering instead of slavery! And as soon as anything contradicts this, it is by definition not agile. That’s the very purpose of a manifesto — it serves as a definition and thus a measurement tool. Scrum is a concrete implementation of agile. And following the Liskov substitution principle, a concrete implementation must obey the same rules (behave the same as) the abstract “parent”.

                    Rather than being pissed and saying “I cannot open my mouth because I’m afraid to loose my job”, you should proudly slap the agile manifesto into the face of the next pseudo-“scrum master” who prioritizes processes over individuals!

                    • 1. Really? Call a woman a whore and will see how she reacts. Even those that have the 1000 c stare will feel revolted.
                      2. negro indeed means black … I do know my own language. But the way it was used in relation to black people has a more complex history. The first usage to designate a group of people was used by muslims and the word meant literally slave. (in arab is abed) . Then when the racial theory first appeared (which I mentioned) it came under the form negroid. https://en.wikipedia.org/wiki/Negroid If you read you will see that skin pigmentation is the less important and the less significant to the term. Most of the negro slur came from comparing the average black person skeleton to that of a monkey/ape and saying it looks more similat than a caucasoid skeleton.
                      3. the road to hell is paved with good intentions!!! But you cannot maintain order when you offer too much power to childish people. Customers being non-technical they often behave as children as they cannot understand why task A can be done in 5 minutes and task B takes 2 months. And Scrum is a bit like someone that want 9 women to produce a baby in one month.

                • I stopped listening to you when I realized you were writing leftist, liberal typical bullshit lies. Please just go away and stfu. Agile/scrum seems to be your religion.

                  As a pastor once told me “You can get down in the mud and argue with a pig if you want – but only the pig will enjoy it”

        • I will not try to debunk any of your claims. I did this in other comments but Scrum zealots will just ignore any arguments. I am just going to ask you to give me one example of a complex software product that was created using scrum at which you worked on you feel proud of. Then we can see the customers reviews and performance specs and see if it is a quality product or the usual bug riddled turd agile environments usually produce.

          • Yes, of course, cyp. Everyone having different experiences and opinions is a “Scrum zealot”. That’s because you are the only one in possession of the absolute thruth 😀 😀 😀

            And btw. you did not debunk any of my arguments in any of my previous posts! You only doubted my experiences and if I remember correctly (without reading it all again) my competences, too.

            You should slowly read my long previous post again — especially the part about the neo-isms — maybe you then start to understand that we talk about totally different things: I talk about agile, scrum, liberalism, leftism and the like — you talk about neo-agile, neo-scrum, neo-liberalism and neo-leftism. And I can again only highlight that you fight against your own goals as long as you focus your hatred on a methodology instead of denouncing the underlying problems poisoning *every* methodology imaginable.

            I totally agree that the poisonous atmosphere you and others here describe is a disaster. But I totally disagree that this is a scrum-made problem. And as I already said a few times: Fortunately, I never encountered such thing in my life, despite having worked for much longer than 20 years for many companies — any many of them doing scrum.

            If you want to see any of these complex software products I contributed to using Scrum, your only way is likely to apply at the companies I worked for. It is ridiculous to expect that a large publishing house like Haufe or one of the biggest German energy providers like ENBW (or any of the banks, insurances, car manufacturers, …) is going to give you access to their source codes, just because you doubt their quality or my word 😀 😀 😀 I think you see yourself as more important than you are.

            • I never asked access to their source code. I asked for the name of a piece of the software you designed that is both complex and you feel proud of. I would only need access to customer reviews not to source code. For instance I worked on a multidesktop application for Hercules UMPC’s . You are twisting my words and this shows your lack of honesty.I have read your previous post. You are losing yourself in non-arguments and phylosophy moving away from the point of the conversation. Typical con artist behavior. Also saying that I see myself more important than I am is not a way to prove your point. I asked for one example and you could not provide one. So basically you admit to my statement. Agile and Scrum only work in theory. That is because they ignore reality and human nature and limitations.

              • No, I do not admit to your argument!

                Most software in this world (a long time ago I read a number of > 80 %) is written for internal use — i.e. the “customers” are departments within the same company. You don’t get access to any feedback from the users, if you don’t work within the company.

                I have written a lot of software which I’m proud of, but most of it either disappeared by now (because the companies were dissolved — I shut down my companies years ago and emigrated into the tropics) or is not publicly available. And no: They don’t even sell this software, but they use it internally. If you don’t know: ENBW (one of the examples I mentioned) is an energy provider: They sell energy — not software! But they use heaps of software (most of it written themselves) inside their organisation.

                • So there is no external person to review the quality of the code… nice example… generally internal software is not that high quality because there are not enough people to test it. Can you at least what the software for that energy company did? Also if all the companies you worked for dissolved does it not mean that the quality of their products was substandard?

                  • Oh my god, you write more and more nonsense with every post 😀

                    The project I contributed to in ENBW was one of the cleanest codebases I’ve ever seen — with hundreds of automated test cases running on every check-in (and thousands every night).

                    And with every post you write, you expose more of your lack of experience in the business world: When we sold our companies, our competitors primarily wanted the customer relations. Nobody in this world really cares about high quality software except for the software developers themselves (just like all good craftsmen take pride in their *good* work). If a big business buys a smaller business (e.g. we were number 2 in the market), they don’t even review the software. They don’t give a shit if our software was much better than theirs (the customers told me so, after they were forced to migrate). They have their staff, they have their own products, and if their own software is barely usable, people are going to use it — even if they curse it every day.

                    Why do you think, people use Oracle DB (IMHO together with DB2 the worst DB on this world)? Why do you think, people use Windows? Because it does the job! It’s really shit and most people having to deal with it know very well that e.g. postgresql is much better than oracle db or gnu/linux is much better than windows. But nobody really cares about quality — as soon as the product is usable. Sad but true!

                    • 1. postgres is not as good as Oracle db sorry to burst your bubble.
                      2. People use windows for two reasons: a). a lot of commercial software is designed just for windows
                      b) except for debian based linux most other flavors have a very user unfriendly system especially when coming to installing software.
                      3. People do care about quality believe it or not. That is why Window8 and Windows 10 are both flops no one wants to deal with.
                      4. most of those big business you talk about will eventually fail as they are as a house build on sand. Especially since most are supported just by constant loans from banks. The economy is close to crash due to this.

                    • cyp – I love your posts and replies – you make a lot of sense, but I think I am through with encouraging ‘macaroni’, i. e. the troll. Yes, I misspelled his name on purpose.

                      Just for my own curiosity. You seem to know quite a lot of early, especially European and Christian history. Was this a field of study in college or is it one of your hobbies/passions?

                    • When I was young I thought about becoming a priest. I did not want the responsibility but I still continued to research in the area of theology (both christian and non-christian) in my free time. About european history being from the Balkans it was part of the curriculum during 5-12 grades. And since my country was under Ottomans for some time that part of history was seen as most important.

              • And btw. if you don’t understand and condemn me talking about philosophy, then you seriously should widen your horizon. If anything made life for humans better, it was philosophy. It’s the underlying foundation of our civilization and brought such important things as human rights and democracy (even though what we currently have is IMHO more an ochlocracy).

                You ignoring and even condemning philosophy shows that indeed, you are a zealot, for zealots (in this case Christians) burnt the libraries of Alexandria and fought philosophy for hundreds of years.

                • 1. What made life for humans better where roman & christian ideas and morals not phylosophy.
                  2. Human rights concept is mostly liberal bullshit. And is just a mask for abusing the masses as the ruler elite see fit. How come human rights fight for abortion? how about the rights of children?
                  3. democracy is a failing idea. Is the rule of the mob. And if you allow someone that does not contribute a certain minimum to the welfare of the group to make decisions (which unfortunately happens today) chaos and anarchy follows. The roman republic was an example of working democracy. Only those that served in the military or owned property had the right to vote because they were the ones that suffered most of the decisions being taken were bad.
                  4. Phylosophy for the sake of phylosophy is dead and useless. is like a tree that produces no fruit.
                  5. the destruction of Alexandria you attribute to christians yet the records are rather confusing and more than likely there where more than one libraries in Alexandria during the centuries. The first and the most famous was apparently destroyed in 48-49 BC Almost 100 years before christianity even started. Second library was subject to damage during the 3d century during Aurelian reign (who persecuted christians). Most books that survived were taken to Constantinople where they will be later destroyed by the ottoman muslims. The Seraphum building destroyed by the Coptic church at the time based on evidence we have did not house a library as we know that before most books were moved to Constantinople. So stop lying and accusing christians of something they never did!

                  • Haha! I really miss the time to continue this, but I must set this right:

                    Christianity does not have any ideals of its own except for the holy war! What you think are Christian ideals are not! They originate mostly from the Stoa! And the old philosophers tried very hard to submarine them into Christianity when they saw that Christianity destroyed the ancient civilisation.

                    Read: https://en.wikipedia.org/wiki/Stoicism
                    And most importantly: Karlheinz Deschner, Kriminalgeschichte des Christentums
                    (sorry, you likely have to learn German first)

                    If you think “human rights concept is mostly liberal bullshit”, I recommend you go to a place where they give a shit about them (e.g. Saudi-Arabia) and get your personal torture experience. Have fun!

                    • Holy war? You are confusing christianity with islam. Islam has holy war. If you mean the crusades they are mostly reconquista actions of territories occupied, destroyed and pillaged by muslims. And funny you mention Saudi Arabia which is a muslim country. I know about stoicism but is different from christianity. Anyway believe what you will your bias is evident.

                    • (previous post was not published — trying again — sorry, if the other post still pops up and this becomes a duplicate)

                      Judaism, Christianity and Islam are the very same religion in all relevant aspects. The philosophic differences between Mahayana Buddhism and Hinayana Buddhism are far bigger and still both groups are Buddhism.

                      The only reason why Judaism, Christianity (Jesus was a Jewish rabbi!) and Islam are differentiated is their extreme dogmatism and hatred.

                      And yes, you’re right: To be absolute precise, the holy wars started with the Jews — again: read Karlheinz Deschner, Kriminalgeschichte des Christentums! The first known holy wars were the genozides in Canaan — committed by the Jews.

                      However, Christianity took holy wars to a totally different level. They destroyed our entire culture in Europe. Burnt every pagan temple — including the priests. You should really do some research about Christian atrocities — it’s far more than you can imagine.

                      And since you likely don’t speak German and thus can’t read Karlheinz Deschner’s excellent work, here’s an English list of Christian atrocities:


                    • Yeah, the poor pagans being executed for committing human sacrifices… me thinks we have laws against that now. Do you want to return to that time?
                      And what culture was destroyed in Europe? Care to explain? I am from Europe and that did not happen. Unless you consider yearly orgies and human sacrifices culture then no culture was destroyed.

                    • Of course, Europe had no culture before Christianity at all — absolutely ridiculous 😀

                      The pagan Greeks didn’t build the Akropolis, or did they??? Ah probably, this is not culture in your opinion… But for sure, this was knowledge destroyed by Christian zealots, so that buildings of this type could only be built again, over 1500 years later!

                      And of course, there was no 12 meter high Aphrodite statue in the Roman Senate, made of pure gold, molten by Christian Zealots.

                      And all the Celtic relics found by archeologists documenting that not only Romans had a high culture (long before Christianity came into existence) of course don’t exist — they are only hallucinations of the archeologists — probably they were too long in the sun — oh wait, that’s in the northern parts of Europe, where it’s not so sunny… hmmm…

                    • I forgot you consider pagan statues culture. If you mean that every culture destroyed the artifacts of the previous culture they conquered. More than that in that age anything that was no longer used was recycled. Does the concept sound familiar? why would they keep the statue? And I did mention the roman culture did I not?

                    • Do you know that for 300 years, every single day, at least one pyre was burning in at least one European city — burning innocent people alive?!

                      Btw. I totally agree that Islam is a very dangerous religion, too. As said: It’s the same as Christianity in all important aspects.

                      And yes, of course, I know that the crusades were just a defensive reaction (a counter-offensive so to say) after a long Islam invasion. This is the best short (5 minute) presentation about this topic, I know: https://www.youtube.com/watch?v=I_To-cV94Bo&feature=youtu.be

                    • what pyres do you mean? If you mean the Inquisition it was a very small thing with very few people condemned by the state for crimes that we still condemn people today to death in many countries. The only difference is that the crime weapon as they call it was magical. Some info about the spanish inquisition: https://strangenotions.com/spanish-inquisition/ . Also please note that pagan were committing human sacrifices usually kidnapping children. So do you think death sentence for killing a child is not a fair sentence?

                    • Sure, burning at least 50000 innocent people alive after heavily torturing them is really a “very small thing”. You are disgusting!!!

                      Look at this: https://www.hexenbrenner-museum.com/

                      I’m sure this is as much a “very small thing” in your opinion as the crimes committed against the Native Americans in the name of God. These uncivilized people had it coming, right?!

                      Btw., most of the people being burnt in Europe were women with knowledge about natural healing (using herbs) and therefore were competitors to the Christian monks who didn’t like healthcare competition outside their monasteries.

                      And some people burnt were like Giordano Bruno: Their only crime was to do science. Better known is Galileo Galilei — he only avoided being burnt by first publicly denounce is previous proclamations and finally publishing his most significant works after his death.

                      And you obviously are in favour of the death penalty. You are not civilized! I stop discussing with you. There’s no point in it, anyway. *PLONK*

                    • 1.the estimate is between 3000 and 5000 (not 50000) over a 300-400 years period . And I do not know how innocent they were.
                      2. Native americans already were close to extinction by the time europeans arrived mostly due to inbreeding and disease. Also you make it seem as they were one homogenous group that were oppressed when in fact there where many groups each takes sides in wars between various colonists. they had no rights because they were nomadic people and they attacked the colonists when they could not produce food for themselves because they knew little about farming.Also not sure where you get it was in the name of God. It was in the name of their own wealth or in the name of a non religious ruler of europe.
                      3. those women used to do a lot of harm by selling abortiforms, poisons and mind altering potions to people. the harm they did was great.
                      4. Giordano Bruno was not burn because of science. It was far from it. It promoted pagan believes especially related to astrology (do you consider astrology science?) and made several direct attacks as an instigator against the Pope. While I am against papacy instigation to violence against powerful people usually gets you killed. The Galiei story is even more complicated. Of course you only know the anti christian propaganda and 0 history.
                      5. I am not necessary for the death penalty. There are very few people I would be for that sentence usually for mass serial killers like the doctors that perform abortions.

                    • Again utter nonsense. I had the number from the German wikipedia, but I saw that https://en.wikipedia.org/wiki/Witch-hunt#Early_Modern_Europe estimates even higher: “Current scholarly estimates of the number of people executed for witchcraft vary between about 40,000 and 100,000.”

                      And according to the Hexenbrenner-Museum (see link above), even the Catholic Church today admits 60000 victims in Germany alone (not yet counting in the rest of Europe)!

                      Also, what you write about the Native Americans is utter nonsense — but as said: Don’t want to waste more of my precious time — was too much, today, already.

                      Btw. mother nature does natural abortions in far more than 25 % of all pregnancies. You sound like an ideologized redneck — but being European, you might be a Catholic Italian maybe?

                    • cyp & marcongui, I am asking both of you respectfully.

                      Could you both please stop polluting a heated but otherwise previously meaningful conversation with all your personal attacks towards each other and some other utterly boring and embarrassing cock fight? Seriously, what you are doing now is nothing more than spamming.
                      Please spare the rest of us the time of dealing with notifications etc.

                      Thanks in advance.

                      PS: Despite all your differences it seems to me like you have more in common than what you think.

        • Could the Adminstrator please put both these … Contestants … on a short leash? There’s more than enough heat here without bringing in specious and unrelated arguments.

        • I’m skeptical of Scrum because I’ve seen it too often abused. If implemented properly it may be a good thing, but the temptations to implement it poorly are strong. For example, it is tempting to use the story points to rate programmers. There are no story points for mentoring or helping others, so you can imagine what happens to those activities. Not all story points are the same. People tried to avoid stories that involved Selenium because we knew the story points were not adequately estimated.

          I had a coworker who was one of the best UI guys I’ve ever worked with. One day we were informed he had been fired because “he didn’t fit our process”. As you said above, it’s stupid to fire a good engineer because he doesn’t fit the process. And I know that we had a manager who refused to adjust our process.

          • Andy – I have seen (and heard of) the same sort of thing and that’s one of my arguments for moving on. Too many good engineers are being/have been ruined by this process no matter how good it may be ‘when done properly’. It may have a niche in web based development for html applications but the rest of the industry needs a better framework. Even if it was the holy grail it’s too easily bastardized into a career ending cancer.