Hacker News Reader

Comment by jmccree | Hacker News Reader

It seems like you are invoking the No true Scotsman fallacy. There's a lot of companies that do "Agile" and "Scrum" that are exactly like he describes. When Feature X has to be done this sprint because it's already been sold to (Board|Client|Investors|Other Dept), there's not much time to think about "How?", it's more like "If I'm going to be working Sat and Sun again?".

I'm sure there are organizations out there where Agile/Scrum is working fantastic for them in practice, and developers are happy with their work and career prospects. I just have yet to encounter one in the wild personally.

View on HN

In what possible way is that a No True Scotsman fallacy? Do you think you can slap a "Scotsman" label on a fish, and it magically turns into a Scotsman? What Agile is, is described in the Agile Manifesto. What Scrum is, is described in even more detail. When what you're doing is not that, you're not doing that, no matter what you call it.

I totally agree that there are a lot of companies that claim to be doing Agile or Scrum, and often it just means they picked one element, pulled it out of its context, and applied it in a situation that has nothing to do with Agile or Scrum.

Years ago I worked for a company that claimed to be doing Scrum because they started each day with a stand-up meeting. The meeting was fine, but what they did really wasn't Scrum by any stretch of the imagination. No sprints, no backlog, no retrospective, no well-defined stories, and no clue what our pace of development was. And even if you do have all the trappings of Scrum, it's still not Scrum if you ignore the underlying principles.

Words have meanings, or they are useless. So, let's define "agile". It doesn't mean "apply a label to any process that you already have". So, where do we find a definition for agile? Probably the best candidate is the Agile Manifesto. But there's not much concrete process there, so now what?

I worked in an agile (and, in fact, XP) environment for a while. The rule there was that the product manager owned the decision of what stories went into the project, but the technical team owned the estimates. That's kind of agile-y (we're doing stories and estimates, yay for us!), but it's also just good engineering management.

If you're in a situation where "Feature X has to be done this sprint because it's already been sold to (Board|Client|Investors|Other Dept)", you're in trouble whether or not you call your process "agile". The trouble you're in doesn't have much to do with whether you're agile or not, either - it has to do with management that doesn't listen to engineering reality. (However, it is a violation of at least one of the principles from the agile manifesto - sustainable pace.)

> So, where do we find a definition for agile? Probably the best candidate is the Agile Manifesto. But there's not much concrete process there, so now what?

So, now we recognize that "agile" doesn't describe the elements of a software-development process, it describes a set of priorities which are used for determining what process is adopted, and how the processes adopted are applied, in a particular organization (a set of priorities which specifically calls for consideration of the particular people involved and how they particularly interact.)

Fair enough. But that means that the complaints about agile don't really have much to do with agile, they have to do with bad processes that are trying to implement agile. (Scrum is more concrete, though, and can be more validly criticized or defended without as much confusion over the definition.)

> But that means that the complaints about agile don't really have much to do with agile

Well, yeah, that's usually the problems with complaints about agile -- they aren't about agile, they are about a specific set of processes (usually ones developed, adopted, and applied by an organization not applying the principles in the Agile Manifesto) which that particular organization, or the consultant selling them, called "agile" as a way to hook on to the popularity of the buzzword.

> Scrum is more concrete, though, and can be more validly criticized or defended without as much confusion over the definition.

In principal, sure, Scrum is subject to process-based criticism, although lots of criticism of Scrum are about "what I've seen organization X, that claims to be using Scrum, do" rather than "the framework defined in the Scrum Guide".

One of the principles of the Agile Manifesto is "People over process". While that doesn't mean process is not important, it does mean people are more important. Whatever your process is, it should be focused on people, working code, customer collaboration and the ability to respond to changing requirements. Even if you try that, it's still possible to have a process that does these things badly. But I still have to see someone argue that these principles themselves are a bad idea. (Well, responding to change can be harmful when driven to extremes.)

Scrum is the most process-oriented process that's still pretty agile. But one of the most essential aspects of it is that you refine your process based on how it works. In an organization with multiple Scrum teams, eventually every team will have a slightly different way of doing things, because that's what works for them.

Reply on news.ycombinator.com