First, this is a five-year-old article. And a dupe.
Second, let's get definitions straight. Agile is best practices around iterative and incremental development. The word is a marketing term and can cover all sorts of different (and contradictory) concepts. Scrum is a certified way to manage Agile projects. You write a check, there's a board, a class, and a nice little certificate you get.
So it's really hard to jump up and down and yell too much about "Agile" -- the term is just too slippery. (I note he includes a picture of a ScrumMaster class) Or to put another way: ten years ago companies hired me because I was really good at running iterative and incremental projects and could not only do it well, but help train project managers and teams. Now the same companies hire me for the same reasons, but the word "Agile" is attached. If you want to slam all external consulting as being a waste of money, that's fine, but let's be clear what you're ranting about.
Second, because it's best practices, not all of them are going to work for you. And as you grow, you'll find out how to use some (and ignore others). Hell, I'm still struggling with TDD. But I grok pair-programming: it's the same kind of coding you did in college where a couple of people would sit around figuring out a problem. It combines the code review and the code creation into one step -- brings the review as far forward as possible, so there's no wait. Would I do pair programming all the time? Shit no, but does that mean I should make fun of it? Not unless I want to sound like an idiot in ten year's time.
The biggest point to be made here is that Agile adoption is not the same as Agile principles. Agile adoption sucks -- it's full of zealots, religious wars, highly-priced seminars, and feel-good happy talk. It can be just another way for management to micro-manage your project. The terms can mean different things to different people. Consultants make lots of money and provide very little value. And so on. Trust me, I know this: http://www.whattofix.com/blog/archives/2010/09/agile-ruined-...
But all of that is just a study in how screwed up most organizations and movements are. Agile as a set of best practices is awesome. If I want to learn about data modeling, I'm buying some kind of book with a title like "Agile data modeling" because I know it's going to have an incremental and iterative context -- I won't have to do as much mental gymnastics to fit it into what I'm doing. (Disclaimer/shameless plug: I just published the first in a series of e-books to try to teach people without them having to pay so much for consulting. http://tiny-giant-books.com/scrummaster.htm)
Agile adoption has generated a lot of hate. That's a shame, because as Steve points out, there's good in there too. (Although he's not hitting on a lot here, the article is nicely done)
Second, let's get definitions straight. Agile is best practices around iterative and incremental development. The word is a marketing term and can cover all sorts of different (and contradictory) concepts. Scrum is a certified way to manage Agile projects. You write a check, there's a board, a class, and a nice little certificate you get.
So it's really hard to jump up and down and yell too much about "Agile" -- the term is just too slippery. (I note he includes a picture of a ScrumMaster class) Or to put another way: ten years ago companies hired me because I was really good at running iterative and incremental projects and could not only do it well, but help train project managers and teams. Now the same companies hire me for the same reasons, but the word "Agile" is attached. If you want to slam all external consulting as being a waste of money, that's fine, but let's be clear what you're ranting about.
Second, because it's best practices, not all of them are going to work for you. And as you grow, you'll find out how to use some (and ignore others). Hell, I'm still struggling with TDD. But I grok pair-programming: it's the same kind of coding you did in college where a couple of people would sit around figuring out a problem. It combines the code review and the code creation into one step -- brings the review as far forward as possible, so there's no wait. Would I do pair programming all the time? Shit no, but does that mean I should make fun of it? Not unless I want to sound like an idiot in ten year's time.
The biggest point to be made here is that Agile adoption is not the same as Agile principles. Agile adoption sucks -- it's full of zealots, religious wars, highly-priced seminars, and feel-good happy talk. It can be just another way for management to micro-manage your project. The terms can mean different things to different people. Consultants make lots of money and provide very little value. And so on. Trust me, I know this: http://www.whattofix.com/blog/archives/2010/09/agile-ruined-...
But all of that is just a study in how screwed up most organizations and movements are. Agile as a set of best practices is awesome. If I want to learn about data modeling, I'm buying some kind of book with a title like "Agile data modeling" because I know it's going to have an incremental and iterative context -- I won't have to do as much mental gymnastics to fit it into what I'm doing. (Disclaimer/shameless plug: I just published the first in a series of e-books to try to teach people without them having to pay so much for consulting. http://tiny-giant-books.com/scrummaster.htm)
Agile adoption has generated a lot of hate. That's a shame, because as Steve points out, there's good in there too. (Although he's not hitting on a lot here, the article is nicely done)