I am a big fan of anything that will get quality, innovative, market-killing products out the door more quickly.

Sincerely. I would even trade in my extensive work wardrobe of jeans for a pile of business suits if it would improve product quality. I would even stop swearing if it would speed up development and reduce the number of half-finished features.

But alas, my casual, semi-profane lifestyle is hardly threatened, despite my company's move to Agile (specifically Scrum) two years ago.  Thanks to Agile methods, our products (and my life as a product manager) are slightly better now, but not that much.

Shocking, right?  Because Agile and Scrum are so FASHIONABLE, that speaking of them in anything but the MOST obsequious "Agile-is-the-absolute-BEST" manner is unusual and may be preceived as an act of heresy.

From where I sit, the very reasonable concept of Agile has evolved into a pseudo-religion. It has a Manifesto and a bunch of zealots and everything. (gack)  In posts I've made about Agile in the past, I've seen the comments section degrade into serious bashing and name-calling of anyone who is not 100% worshipful of the Agile philosophy.

This cannot be good. I believe firmly in the separation of Products and Religion. So let me take a more balanced view than most of what you'll see written about Agile these days:

Sure, Agile makes some things (ok, many things) better.

But Agile also makes some things -- IMPORTANT things -- worse.

Yes, Agile can speed up the development and improve the quality of small features. But it's too often at the expense of the Big Important Work -- the heavy lifting, multi-month market analysis and architectural work that lead to REAL customer value and REAL competitive differentiation.

Yes, Agile can do wonders to improve product usability. But the results are often incremental in nature. Opportunities to come up with innovative user interaction models that put the user experience on a different plane are not explored. Not enough time.

Yes, Scrum can improve the speed of decision making by requiring a "Product Owner" make on-the-spot decisions. But because it does not allow the Product Owner the customer face-time to intimately understand the market, it too often results in products that address the verbatim enhancement requests of one or two specific customers (whoever spoke to the Product Owner last) while missing the real market opportunities. (See footnote 1.)

Yes, Agile can reduce the size of the development team. But instead of cutting costs, it moves the resource bottleneck to the product management and project management teams which are usually understaffed for the greater demands Agile places on them.

Yes, Agile is good at holding developers' feet to the fire and jacking their lines-of-code-per-day rate through the roof. It helps them fix bugs faster too. But because Agile keeps them in an always-on, semi-panicked state, it also leads to burn-out and prevents developers from doing the deep thinking required to solve the really thorny problems and to truly innovate.

Further, the War Room atmosphere and pair programming practices require a different, more outgoing personality than many developers naturally possess.  Granted, his research might be dated, but Tom DeMarco (author of Peopleware) found productivity was highest when developers had private offices with actual walls, windows, and doors that shut -- the very antithesis of today's War Room. In the War Room, the ideas of the more quiet, introverted, and thoughtful developers are too often drowned out by their louder, more obnoxious, and less gifted brethren.

So, despite the massive amount of hype currently surrounding Agile / Scrum, please remember the immortal words of Fred Brooks — There Is No Silver Bullet.

Agile is NOT the end-all-be-all for software product development. It is NOT the second coming. It is an improvement to be sure, but it has some big flaws - just like ALL software development methodologies.

There is no one-sized-fit-all solution. There is no room for dogma and zealots. There is no silver bullet. Not now, and probably never.

  1. I know that many Product Management bloggers believe that this problem is solved if you separate the market / customer-facing Product Manager role from the development-facing Product Owner. However, I remain unconvinced.  How can the Product Owner gain the perspective to make the best product decisions without regular customer contact?