A scrum (Photo credit: Wikipedia)
EDIT: Changed some language so as to not give the impression the Manifesto came before all Agile methodologies.
Before the wide adoption of Scrum, there were a group of very smart developer types who discussed values and principles that, if observed and implemented, would lead to delivering high-quality software more quickly than most approaches that were dominant at the time. These people created an Agile Manifesto and articulated the principles that drove it. It is this body of values and principles that is meant when we talk about being Agile, using Agile, etc.
It is important to note that those writings do not specify any specific practices, implementations, or methodologies. It basically says, “As long as you are pursuing these goals and relying on these principles to help you achieve those goals, that’s being Agile.” By and large, this defined itself over and against Waterfall – a process articulated by Winston W. Royce in 1970 as a hypothetical example of a flawed model that would not work for software development but inexplicably became the dominant model for software development and the undergirding of project management for software projects.
If you look at the Manifesto and the principles behind it, you will find nothing about time boxed iterations, sprint planning meetings, or anything that is a specific technique or methodology. Agile is something that is back of, transcends, and critiques methodologies.
This body of principles is reflected in people taking a crack at implementing these things in their software development. In fact, many of the things reflected in the Manifesto came out of some of these attempts. XP attempts to embody these principles. Lean / Kanban also does. Scrum also does.
That last bit bears repeating: Agile is a set of values and principles. Scrum is one particular methodology among others built around those values and principles.
For reasons that I suppose boil down to excellent marketing, it is both widespread and regrettable that Agile is used as a synonym for Scrum. Sometimes, this leads to very entertaining claims made by people who ought to know better such as Agile being invented seven years ago or “Agile projects always operate within a ‘Time-Box.’”
The cause has not been helped by the fact that when Microsoft uses the word “Agile” for their TFS templates, they inevitably mean “Scrum.” Even the Scrum Alliance shows what it really cares about by frequently using Agile as a synonym for their own methodology in their articles and materials (NOTE: This is borderline reprehensible, because they really do know better, which means this is deliberately deceptive in order to snag more Scrumbots who won’t know any better).
This isn’t just some pedantic issue.
For me, personally, one of the things I bring to the table is – as a developer, a mentor, and an instructor – a belief in Agile principles. I used to do this with Scrum. These days, it’s more the Lean / Kanban variety. Someday, it’ll probably be something totally different. But the principles will be pretty much the same; it’ll just be about finding more effective ways to implement those principles.
As a professional, it’s very annoying when people assume that everything I say or do or put on a profile regarding Agile is actually about Scrum. It’s very annoying to try to market myself to companies that say, “Oh, we tried Agile, and it didn’t work here,” when what they mean is they tried Scrum. This distinction becoming hazy in the marketplace has an economic impact on those of us who are very pro-Agile but do not practice Scrum trying to market our services and expertise to a world that no longer knows the difference and may have antipathies toward Scrum.
The other issue is that the equation of Scrum with Agile means a whole lot of ignoramuses are coming in under the Agile banner.
That is not to say that every Scrum advocate is an ignoramus. There are extremely intelligent people implementing, using, and coaching teams on Scrum and they are kicking butt. However, a phenomenon occurring in the marketplace today is that people learn Scrum and they become Agile Coaches, which is somewhat akin to me learning the recipe for clam chowder and going around telling restaurants the best way to make soup (which, invariably, is clam chowder). These people will comment and blog freely and often, filling the Information Superhighway with epistemological roadkill. They write articles. They give conference talks.
All these things reveal to anyone who knows better that these people have no clue, but this is the public face of Agile, now. Learning Scrum gave them a license to be Agile experts, so that’s how they see themselves, that’s how they market themselves, and that’s how the market encounters them. For every one Agile coach who knows what they’re doing, there are twenty who became Certified Scrum Masters, and their ability to sit in a room for two days has now given them Authority (I am a Certified Scrum Master, incidentally).
I feel bad for anyone who is a real Agile Coach trying to market themselves as an Agile Coach, because 90% of the time, Agile Coach is a nice way to say Clueless Scrum Master. And whenever I read a blog or hear a presentation or see an online discussion that is full of Agile fail, I know the person who wrote it is coming from the Scrum camp. The equivocation of Scrum and Agile has given them a license and a platform to address issues they do not fully understand, which has produced awesome advice such as some things I’ve seen in Agile Coaching blogs the past couple of months: “Don’t have too much interaction with the client because it interrupts the team,” “Make sure you’re updating the Scrum Master in your stand up and not the Product Owner,” and “Don’t use TDD on small projects.”
Any Scrum person who truly understands Agile probably cringes at those statements as much as I do, and that just proves there’s a problem.
Scrum may be Agile, but Agile is not Scrum. If you are going to claim to talk about being Agile, make sure you know the difference.