Warning Signs that Agile Is Declining

And honestly, there's no great reason to believe Agile consultants. Most of the market for software process improvement is in helping the clueless and/or terminally lazy. (And there's often even better money in not helping them, but instead just making them feel special.) Plus, a lot of the benefit from particular practices depends on the existing code, the business conditions, and the people involved.

I think the right way to deal with Agile techniques is the same way one deals with new tools or new languages: try 'em for a while and see. E.g., I tried out TDD for a while and ended up liking it a lot. As does the rest of my team, such that they all were specifically looking for test-driven shops when I hired them. But even we tend to only use it on core code; test-driving most UI just doesn't pay off.

Just because some snake-oil salesmen are selling it, doesn't mean it's snake-oil, it just means that opportunists smell an opportunity. The altruists who are trying to improve the state of the art are still out there, if you know where to look.

People have written automated tests for decades. People have been testing at the interface level since the dawn of OO and before. Put those together and you've got what is now called unit tests.

People have been making small changes to improve the design of code without changing its behaviour forever, too. Fowler published Refactoring in 1999, but even then it was common practice among experienced programmers to work that way. I assume you're not seriously going to suggest that no-one thought of doing things like moving a method up and down a class hierarchy or splitting a long function into a higher level control function using lower level functions for the details before the book was out. (I'm not disputing that Fowler did a good job of pulling a lot of common knowledge together in a way that is helpful to those just starting out.)

I also assume you're not seriously going to dispute that long-term projects have been managed using shorter-term milestones for a very long time. That's hardly unique to software development, never mind to Agile processes.

Every project I've ever worked on professionally has seen developers naturally pair up or form small teams around the same computer or whiteboard to work through difficult problems or review each other's solutions.

People have been doing what is called continuous integration today for as long as there have been source control systems with check-in hooks.

I first had the idea of organising a big project by keeping a pool of little projects and picking out the most important one to do next when I was about 13 or 14, so I rather suspect that plenty of managers were using the same idea to prioritise long before anyone called it a backlog and worked through it in sprints.

I could go on, but I think you get my point.

Now, there are plenty of other practices required by various Agile processes that weren't (in my experience) almost universal among good programmers before Agile came along. They include:

- TDD

- Full-time pair programming (same computer, two keyboards)

- Collective code ownership (everyone owns everything)

- Forcing short-term milestones into periods of exactly the same length

- Frequent meetings (daily in some processes)

- Relying on organic designs that evolve through arbitrary refactoring by individual developers rather than a carefully planned architecture and smaller-scale designs that are peer reviewed by multiple people

If you want to claim those as the gifts Agile has given us, you're welcome to them. As I said before, most of the good practices were already in use, and the consultants mixed in a bunch of unproven ones later.

The book is very short, perhaps 20-30 pages. I make no apologies about that. The point is to be direct and provide lots of instruction. So if you're looking to pay for your book depending on it's weight, not it's usefulness, probably not for you. I know some of the best hacking books I've owned have been short. I'm hoping to make this book more like them and less like those huge encyclopedia monsters I have on my shelf.

For anybody who wants to see some sample pages and the TOC, just shoot me an email. Happy to help out. Also for more book information, check out the landing page I made for it, http://tiny-giant-books.com/scrummaster.htm

Me? I'm trying to help teams of smart, well-intentioned people. Which is why I'm happy to share what's worked for me and encourage people to try those things if they're interested. That's what motivates the early Agile people I know.

But consultants are mostly in business to make money, and the bulk of their audience is clueless, so most of what gets sold as Agile today is tuned for them. I go into more detail on that here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...

> Also, experts will evolve a workable process for any given project without needing to follow any particular Agile process to start with. That's one of the reasons they're experts.

True, but that ignores the people who aren't experts yet. They're the ones I care most about. And it ignores the substantial costs of learning all the important lessons yourself; it's often better not to reinvent the wheel.

> [..] teams within a large organisation [...]

Personally, despite 10 years of looking, I have never seen teams within a large organization successfully adopt what I would consider a serious Agile approach. I have seen a lot of large organizations adopt Agile jargon and get nothing out of it, though.

The problem is that Agile methods require a shift in power relations from top-down to bottom-up. Their approaches and values are basically antithetical to a lot of American business culture and MBA dogma. And successful exploitation requires deep change on the business side as well.

I think Agile failed for the same reason that Lean Manufacturing failed here: the important part wasn't the easily observed rituals, but the cultural differences. And the vast majority of the people who are "doing Agile" (whatever that means) would not accept deep cultural change.