Why do some developers consider Agile development to be nonsense?

We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's been about six months now and productivity has basically ground to a halt as we spend more and more meeting time endlessly sorting tasks into different little arbitrary piles instead of actually making forward progress. It's made communication with the non-software part of the company much more difficult, because they keep getting hung up on the jargon; we have to slice up tasks arbitrarily to get them to fit into "sprints," which go out of date minutes after the morning standup when the first non-planned bug report lands. Sizing is frequently an exercise in post-facto book-cooking: 'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass. The short timeframes encourage everyone to twiddle around the edges of things instead of doing real feature development; the arbitrary milestones serve mostly to make everyone feel like they're constantly falling behind.

I've discussed this with a bunch of people. Everyone seems to agree that we're doing Agile wrong, but even the strongest proponents of the methodology seem to be in complete disagreement on what the "right" way to do it is, or how that would be an improvement over the way we were doing things before.

So yeah. Not a fan.

Historically, most software development methodologies are excessively top-down, so people somehow still expect that from agile. Most devs are the sort that couldn't stand doing group projects in school, so the idea of organizing with teammates to produce something bigger and better than I could on my own is totally foreign.

If you don't explicitly name your development methodology, you still have one: you're practicing something called ad-hoc development. Unless you and your entire team are superheroes, there's an awful lot of knowledge being leaked away.

Here's the secret: software development isn't really about making computers work, it's about organizing knowledge. If your process focuses more on making the computers work than your institutional knowledge you're making a critical mistake.

Don't confuse some company's crappy engineering practices for agile just because they call them that. Stand ups are short. Period. If it feels like a "permanent PIP" your team could use some improvement. If it feels like a surveillance state it's probably not a very good implementation of agile.

Agile development is about making connections to your team members: individuals and interactions over process and tools. It sounds like the author's experience (as well as many other devs') is unfortunately in an organization that doesn't pay heed to that very first, most important agile principle.

Scrum-English Dictionary:

* "sprint": artificial crisis

* "end of sprint": abandonware

* "Scrum master": resume credit for my planned escape to a new company

* "stakeholder": someone you can't get away with externalising your costs onto

* "simplified": doesn't implement any of the actual business requirements

* "lightweight": doesn't implement any of the actual business requirements, but does so much more elegantly than the version that works

* "easy": project was born circling the drain (and doesn't implement any of the actual business requirements)

* "legacy": the version that works and implements the actual business requirements, even if no sane human wants to touch it

* "velocity": a speed with a direction, so skittering about following marketing's random hairpin turns counts

* "retrospective": blamestorm incoming!

* "stand-up": getting the blamestorming in early

* "We'll put that on the backlog": hahaha fuck you

I do enjoy some of the jargon. "empowered": do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that yourself."

Seriously: every good idea is turned into a bad one by the relentless management quest to Taylorise clue.

The saving point of Agile is breaking tasks into reasonable sizes, long enough to actually get something done and short enough to rearrange as needed sooner rather than later, and to delay interruptions until they can be evaluated and other tasks completed. I can't get to what I need to do if the relentless onslaught of self-important "do this _now_!" interruptions are handled as they occur; Agile provides a sane way to say "get in line" such that important issues are addressed in a timely manner relative to other issues and without compromising other stuff that also needs doing (those that never reach the top of the interrupt stack, but without which long-term progress won't happen).

You can twist Agile, based on your vision of good team is. So you have to get the right people to implement it. You have to approach it from the idea of it being a collaborative, friendly, no blame etc for it to work.

I've only ever used estimates in story points to prioritize things(That's why its so abstract), not to monitor and push developers. If I wanted that, i'd use actual time.

The idea of everyone is junior is also bad implementation. It means even the most junior person is capable of contributing using their solution over a senior persons solution. The right idea wins, not the right person. I can understand why this pisses of senior people though.

Every company has "cowboy" programmers who break shit and ruin their coworkers' lives with massive 1am check-ins, and a lot Agile seems designed specifically to put up road blocks to prevent this from happening. Managers love it because it provides an escape from dealing with problem employees directly. Most of the vehemently anti-Agile people I've worked with were grossly overconfident in their abilities and difficult to work with, which I think supports this idea.

Unfortunately, the only way for this non-management technique to be effective is to do it dogmatically with no deviations (otherwise the cowboys will always have some excuse for why it shouldn't apply to them), and this is where things start pissing off the actual talent.

If you feel too good, or too senior for a programming methodology like Agile, then you are bound to not like it. Is that a fault with Agile, or a fault with your attitude?

A cowboy coder is not micro-managed, does not seem to need atomized tasks, does not need a direct line with the customer and decides on the complexity of the problem and the solution all on his own. They are also terrible to manage and hit-and-miss when it comes to actually shipping something with business value.

Bluntly spoken, Agile is there for the project managers, not the project developers. Agile should be implemented for as long as productivity increases, customer feedback loops create desirable features, and iteration cycles become tighter and shorter. If you know a way to increase those stats without Agile, then write your own methodology (http://programming-motherfucker.com/ is taken) and join management. If you don't care about those stats, and feel too good/senior for Agile, then start your own company and proof it to yourself. You don't start to measure a project's success by first counting the number of developer complaints. You could probably keep the complaints at zero, and never ship anything of impact.

1) Attack the lowest-priority and easiest stories to shoot for quantity, not for quality. This way you'll be closing stories in no time, pleasing the scrum master and product owner during the daily standup. Leave the largest and most complex problem for last - if nothing else, you can kick the can down the road by claiming it's tougher than it seemed, requires more points and should be moved into the next scrum.

2) Do not worry about the quality of your work. In fact, the lower it is, the more stories you'll have to fill in the next scrum - "widget for feature X" with some effort can become "fix bug Y with feature X", "improve widget performance when more than 1 user uses the product", "improve logging and monitoring of widget X" and tons of other, lower-priority, but higher-quantity stories (see point 1 of this). You'll likely be closing a story a day, earning points way ahead of the other suckers who choose to focus on long-term critical design/architecture issues.

I think the number 1 misconception is the sprints. He seems focused on 2 weeks as being the requirement, when it's on the recommendation. Some team have gone as long as 4 weeks. The whole point to a sprint is that dedicated time to a delivery with fast feedback from the customers. It's mainly so you can fail early, ail often. It's much better to spend 2-4 weeks building the wrong product than 6 months.

Second, his claims that product development, research and design, and architecture don't belong in a sprint are also misinformed. The focus on user stories to remind people that they need to focus on users, not gold plating. In any technical project, there are a plethora to improve on the design. People can (and have) sat down and refactored and "rearchitected" for days and days. At the end, they build beautiful systems that don't offer any advantage to the customers, or have implemented a number of features the customer didn't want, or have fixed a series of concerns the customer wasn't concerned with. There is give and take of course, as the engineers needs to give feedback to help the customer understand the benefits of the feature or risks of not fixing the issue, but those need to happen first before people go off and construct digital masterpieces.

Third, micromanagement. If you have endless meetings in agile, you're definitely not doing it right. The 3 big meetings, planning, retrospective, and demo, are ones that take the most time. Standups take no more than 15 minutes. The other tasks, meaning, backlog grooming and prioritization should not involved your sprint team. Those need to be done offline by the product owner. Agile may be about teams, but you still need strong leadership.

The only point of his that has any relevance is the last one, where consultant firms have made big bucks spinning out variations of agile because people just can't understand how simple it is.

I see right away one Agile defect: It prefers near-term "user story success" over long-term investments like creating debuggable architecture.

Why spend time now making things easier for the rest of the cycle if it's not a priority in this iteration?

Why write "gdb" when "gcc with printfs" will work fine, even if it simply requires more sprints?

Holy crap, how wrong can some orgs go? The team should own the process. If there is R&D that does not match with scrum then the team should have a) a r&d framework or agreement in place b) the authority to say this is r&d.

The process does not own the team. The team owns the process.

We have found, for instance, that the 3 questions of standup are pretty useless. They make each person feel like they are justifying their existence at the company. By dropping those questions and framing it in terms of a deliverable we found the meetings to be far more productive and better for morale.

We've decided to give ourselves 1 day into the sprint to better guage progress so we can define achievable sprint deliverables, as we don't often know enough information during sprint planning.

Each of these is set up as an experiment, designed to solve an identified problem with our workflow. And the results are great.

For starters, a very significant part of the article relates to performance anxiety over story points. Over 6 years of doing this, I've had two instances where people were called out for not putting points on the board, both of which came from outside managers not familiar with Agile.

Besides that, one of the core tenets of Agile is that you adjust the processes to work for the people involved. Trying to enforce some arbitrary subset of Agile processes on a team is a recipe for failure and frustration.

This reads to me like "bad managers are bad at managing Agile processes".

The most problematic part of SCRUM (and the first thing to start killing productivity) are the interminable meetings it facilitates. The SCRUM master is constantly trying to gauge scope on this or that feature, and everyone feels like they need to bring up what they've been working on during the standup in order to feel like they're not appearing to be slacking off.

I've abandoned SCRUM in favor for a Kanban approach that puts the onus on the Product Owner to manage and estimate scope and deadlines, thereby leaving us developers alone to focus on our work.

I've written more about my approach here: https://medium.com/@glenelkins/agile-is-good-for-managers-bu...

The original (rather long) title is "Why do some developers at strong companies like Google consider Agile development to be nonsense?", and it seems it was shortened. There's a spurious "at" left in there now which breaks it.

Fully understand that process is a technology.

If Agile is so bad, what's better?

Give it a watch: http://www.thoughtworks.com/talks/the-death-of-agile

Blog post version: http://pragdave.me/blog/2014/03/04/time-to-kill-agile/

(1) Company decides to devote resources to a feature.

(2) Developer writes code and submits patches upstream (e.g. to the Linux kernel).

(3) Upstream takes some indeterminate amount of time to get patches into a release.

(4) Company defines a downstream (i.e. commercial) release based on a particular upstream release.

(5) The possibly-pristine but also possibly-unrecognizable code from (2) is pulled from the upstream release into the downstream tree.

(6) More testing, debugging, tweaking, etc. on the downstream tree yields an actual release.

Just in (3) we see one part of the problem: upstream quite likely isn't agile/scrum themselves. Often they don't care about a particular vendors' release schedules; if they do, then someone would argue they're "dump and run" fake open source, and not a true independent upstream. They're almost certainly not going to give a crap about sprints or story points or anything else about the local agile/scrum process. These methodologies pretty much don't work unless everyone is completely committed, and with separate upstream/downstream that's just not the case.

Even with everyone on board, the disconnect between (2) and (4) is a problem. Pushing code upstream and pulling it downstream are two separate tasks, even if they're done by the same person, and there's this big gap between them. At best, this makes scheduling more complicated. More often, it makes agile/scrum style fine-grain scheduling and tight coordination impossible. Measuring "velocity" and all that isn't possible when there's so much externally imposed variability.

For something that's long term and systems-oriented and open source, these methodologies are practically useless. Actually they're worse than useless, as they misdirect effort and interrupt useful work. YMMV.

Let's face it. There is no methodology that will make all software development projects around the world go smoothly and fun to work on. If you work with, or for, a bunch of dicks, you won't enjoy what you will be doing all day. No methodology is going to change that.

I would like to go as far to say that "any" methodology used by great people will automatically result in great things.

As to the specific points:

1. Here, the claim is: There is no place for an actual senior engineer on a Scrum team. The only way to move up is to become a "Scrum Master", a bullshit management role that involves responsibility without power.

There are several errors in this description: First, "Scrum Master" isn't management role, its a facilitation role focusing on expertise with making Scrum work in the particular organization. The only quasi-management role on (or related to) a Scrum team defined in the Scrum Guide [0] is the Product Owner (which does have authority to go with that responsibility.) Either of those is a role a team member could develop into; the idea that the SM role is the only "way up" on a Scrum team is incorrect even within the narrow bounds that are defined by Scrum.

OTOH, Scrum itself intentionally -- to support its use in organizations using Agile practices -- defines only a narrow slice of practice, particularly, a basic model for operation of individual development teams. It does not prevent having different roles outside of the defined interactions within the Scrum guide for members of different seniorities or specialties, it only requires that for the purposes of the interactions it defines, only a narrow set of roles ("Team Member", "Product Owner", "Scrum Master") matter. So, consistent with Scrum, there can be room for moving up on a team. And real organizations using Scrum on projects greater than a single 3-9 member team use complementary practices like the Scrum of Scrums [1]; being a Scrum team's representative on the Scrum of Scrums and thus playing a larger role in the coordination of the overall work of the project is one way for a technical contributor on a Scrum team to move into a role with broader scope and exposure.

2. Here, the claim is "It's aggressively short-term, by design" and "if you carry this way of working on for months or years, you get a lot of technical debt and you get low morale."

It is certainly the case that Scrum, specifically, largely addresses tactical-level, short-term processes. This is because Scrum isn't a full-stack methodology, its a narrow set of practices designed to adopted as part of a larger set in an organization working in an Agile manner, and to be relatively neutral to the other practices. Certainly, if you apply Scrum alone with no higher-level strategic processes that set standards that constrain the definitions of "done" for work done in sprints to avoid technical debt, there is a lot of potential for an organization applying only what is in the Scrum guide to lack long-term focus and development technical debt.

3. The claim here is "It has no regard for the programmers' career needs or desires."

Agile, as a set of principles, certainly does; Scrum, as a particular set of practices, does not, for much the same reason addressed in the previous point. Largely, though, this seems to be a restatement or alleged further consequence of the first complaint about lack of a way to move up (it essentially seems to be, "because of #1, Scrum leaves me nothing interesting to put on my resume"), and so the response to the first complaint above largely addresses it.

4. There's a lot here that deserves separate responses, so I'm going to break this one up.

> "It's micromanagement."

No, Scrum is the opposite of micromanagement, since the "management" is done almost entirely by the team.

> "User stories and backlog grooming are there to control what the engineer works on."

Sure, those things exist to define work, but they are done by the team, so can hardly be viewed as micromanagement of the team.

> "The absurdly frequent meetings (and so many different kinds of status meetings!) are to intimidate him into not slacking."

Scrum defines four kinds of meetings: the Sprint Planning meeting, the Daily Scrum, the Sprint Retrospective, and the Sprint Review. Of them, the Sprint Review is the closest thing to a "status meeting", though even their the focus is demonstrating the concrete deliverables for the Sprint rather than status reporting. All of the rest are primarily action/planning meetings. "Status" of a sort plays a role in those meetings as an input to the planning aspect, but if they become status-focused meetings rather than planning-focused, you've definitely lost the defined purpose of the meetings in the Scrum guide.

> "The story points are there to track productivity (in some superficial, inaccurate way)."

Story points (in methodologies where they are used; they aren't part of Scrum) exist as a planning tool for the team, not a productivity measure.

5. The claim here is "At identifying low performers, it has an unacceptably high false-positive rate."

Scrum (and, a fortiori, Agile) is not a process for identifying low performers, or for performance evaluation at all -- its completely out of scope. Its not that it is good or bad at it, it doesn't even address the issue.

6. The claim here is "It punishes R&D, and it hurts the best engineers the most" because "Agile and Scrum [...] single out and humiliate anyone who works for 2 weeks and doesn't have something to show for it."

Research is a separate domain than product development, and there is no reason that the use of Scrum as a product development methodology should have any impact on how research is done. Of course, Scrum is a generic enough process that you could use it to manage research efforts as well, but the backlog items, associated definition of "done" for those items, sprint length, etc., would all likely be very different for a research effort than a product development effort. You could mix research items into the backlog of a team also doing product development, but then you probably have a problem defining work items that are appropriate for the product development sprint length. (This is less of a problem for non-Scrum methods that use a flow method for backlog management rather than a timeboxed Sprint cycle, because then its easier to mix items that have a longer-than-usual time involvement into the same backlog; the sprints used in Scrum place an effective upper bound on the size of work items.)

7. The complaint here is "I have actually seen it kill companies" backed by a single non-specific anecdote and the assertion that it generalizes. From the description, this appears to be a top-down all-at-once conversion to a new defined methodology. If one has processes in place, for the same reason one adopts incremental change to a software system where you've got an existing, functional system unless there is some reason you can't do incremenetal change, the same thing should be done to a software development organization. Failure of an organization (or many organizations) to manage a big-bang change rather than incremental change doesn't invalidate the methodology they sought to change to any more than failure of an organization to manage a big-bang software system replacement invalidates the technology they sought to change to.

[0] http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US...

[1] https://www.scrum.org/Blog/ArtMID/1765/ArticleID/12/Resurrec...

"It's aggressively short-term, by design" - The whole post talks about 6 week projects. Scrum is terrible for that as it imposes far too many meetings. Scrum works for the complex space where you say "12-36 months" as your gut feel estimate. It is a reaction to the waterfall world where you'd discover 2 years in you weren't building what the business wanted.

"It has no regard for the programmers' career needs or desires" - Stories make for excellent opportunities for juniors to "own" bits of work from initiation to completion. Old school projects provided very little opportunity for juniors to work on requirements gathering and thus a big chicken and egg problem for promotion. It also offers plenty of opportunity to interact with your customers, which is almost always a good way to get promoted.

"The story points are there to track productivity" - Oh noes the people paying you want to know how long the project is going to take to be done. The talk of many status meetings seems decidedly anti-Scrum and is an excellent example of the sort of thing that people should be screaming about in retrospectives.

"It punishes R&D" - Ironically it can be a really useful opportunity to conduct R&D. Scrum makes you have something measurable and a time frame in which to conduct it, which makes for an easier sell than an open ended request. I think what annoys some is when they get shut down too quickly, or are forced into taking a less technically interesting approach that delivers enough business value. Scrum isn't there for pure research into the theoretical, but then no-one is claiming it is.

Killing businesses - Much like every tabloid headline everything can kill you. Value destroying mergers exist in abundance, and poor leadership/management is a real killer. Plenty of companies do very well out of Scrum, especially when they are in a cost centre environment.

I might sound rather "no true Scotsman" when it comes to Scrum but there are only a few things you need to do to be "doing Scrum". What it does give you is a powerful question to ask, and a regularly mechanism to raise it via the retrospective - "why are we doing X when it isn't in Scrum?".