Agile is a Sham

To me, agile is essentially common sense. sprints, story cards,scrums are not nonsense, but discipline. I don't care what these are called, but they have served as a good set of tools to bring in discipline to the team. It helps a lot, when your team is not full of self-driven, talented developers. While that may point to an issue in hiring, we all know how difficult it is to hire and retail such people.

The problem with Agile development is the same problem that has affected many modern revolutions: The revolution against the current ruling class gets co-opted by the current ruling class[1]. The revolution then ends up changing nothing more meaningful than the colors on the flag.

Agile was supposed to help developers escape the obstacles of poor management and poor managers. It's really about developers owning the development of the software, and being given more creative authority. Non-developers play a support role, if they're present at all. That part is all fine and dandy, and it's The Good Part® of agile. Let the guys who make software be responsible for making software. Brilliant!

Managers, of course, don't want to get marginalized. If they see a movement towards Agile, they would rather bring it in themselves, so that they can control how it's implemented. And they implement it in a way that a) fits their existing biases about software development b) doesn't marginalize themselves[2]. Both of those goals are met by taking the agile process, and turning into The Agile Process (engraved on stone tablets, up on a pedestal).

Agile should be less process, but when the transition is implemented by process guys, it just ends up being different process rather than less. And naturally, the one role in agile that ex-managers can step into (aforementioned support role) is more important in this set-up, because it's about owning and managing the process. So the revolution happens, and nothing changes. Instead of developers having more freedom, the old managers just have a new title. That title still comes with the authority to make developers fall in line, except that "in line" now refers to a different set-in-stone collection of steps and rules.

tl;dr Meet the new boss, same as the old boss.

[1] I'd rather not derail this thread into history and politics so I'm avoiding details.

[2] b) is actually a subset of a). One of management's existing biases is that management and process is an important part of software development.

This isn't a knock of managers; everyone thinks the same about themselves. Hell, Agile itself basically originates from developers having the same bias. They just happen to be more correct ;).

I disagree that craftsmanship is a replacement for agile. To me, being a software craftsman is more about how you write and structure code. Agile is about figuring out what the end product should be and how you get there.

I hate that term cowboy programmer. Very effective rhetoric, though. Let's take the archetypical example of people who get stuff done without our process, and call them cowboys! Now, anytime someone points out a dumbass process-driven decision that could have been avoided by using our brains, we can just disparage them as a cowboy.

Note, we're using small-a agile at my shop and it's working well, but that's because of good people, not because of blind adherence to a process and eschewing individual thought.

I've been using scrum for about ten years at several companies. Each time I do it, I explain to everyone that the process has nothing to do with getting people to be more efficient or work harder. It has everything to do with helping me estimate when stuff will get done so that I can let all the dependent parts of the company know well ahead of time.

If the work being done doesn't get re-prioritized, I can pretty accurately judge about 3 months out and very accurately judge a month out. That lets the rest of the company plan fundraising, PR, sales, etc.

This is where I disagree with the author. You do get fairly predictable output out of a group of engineers regardless of their ability as long as they are consistent in their estimates for how long something will take (it doesn't matter if they over or underestimate, just that they do it consistently). You just won't like the results if they are mediocre.

I really want to stress how important the whole self-learning and re-adjustment part of the process is (if someone doesn't scream at least once during a retrospective, they're probably just going through the motions.) While I've run "scrum" for 10 years, the details of how each worked were pretty different depending on the teams involved.

That said, I tend to hire self-managing, self-learning engineers which scrum works beautifully for. I also am completely comfortable with delegating away large amounts of authority especially given the type of people I hire.