Comments on: Why Agile isn’t enough (and why it doesn’t work)

By: Zacharias Beckman

Zacharias Beckman — Mon, 10 May 2010 21:32:13 +0000

Yes, spot on target. (Although, re-reading my article, I see a few spots where I wrote “agile” and really should have written “agile methodology.”) The Agile Manifesto is a wonderful philosophy — one that I’ve applied since it’s inception almost a decade ago. But, it’s just a philosophy, more of an approach that can be applied to any situation. In that regard it’s much like Zen philosophy — it’s simple, it strives for simplicity, and it remains largely unconcerned with the minutiae of implementation. That minutiae is left to the implementor to settle upon and therein comes methodology and process.

The Manifesto is, I think, overstated by the agile community and the Manifesto authors. This is where I break from the Agile Manifesto. Whether employing a methodology or development, each situation calls for the right set of tools. My concern lies with the over-emphasis on an over-simplified philosophy that is applied too broadly. This philosophy works well when taken merely as a guideline to live by, but when applied too vigorously it seems — at least in my experience — to result in over-simplified development methodology. Quite often that means missing quality assurance, incomplete or late-cycle structured testing, a lack of appreciation for user acceptance criteria, or poor requirements management.

So, yes, I agree with you: The real problem is people adopting an agile methodology without understanding what the broader concept of agile development is all about. I think you can take agile principles and apply them to old-fashioned waterfall projects to gain really impressive benefits (and I’ve done so several times). You can also take those principles and, without the right structure and guidance, end up with an “agile project” that lacks the maturity to deliver. Unfortunately, “agile” seems to have become nearly synonymous with “lacking as much ceremony, artifact and process as possible,” and that, I feel, is in large part due to the over-emphasis on simplicity coming from the Manifesto and the Scrum Alliance (as well as other sources).

By: josh milane

josh milane — Fri, 07 May 2010 23:13:03 +0000

You are talking about agile methodologies, not Agile development. Agile development would have you use whatever artifacts fit the bill. The real problem is people adopting an agile methodology without understanding Agile. The rest of you speak of Product Owners, etc.. These are entities within a defined methodology. You have to think more Agile than that. May I suggest you read the Agile Manifesto, then think about a time you played a team sport (or a game like chess) and then revisit these issues?

Best,

Josh

By: Samad Aidane

Samad Aidane — Thu, 29 Apr 2010 06:17:49 +0000

Zac,

Your post is spot on. It is highlighting a conversation that needs to take place about how to scale agile to tackle large and more complex projects. If agile is going to grow up, then it needs to continue to evolve beyond its current practices that are optimized for software development projects.

For example, the idea of a product owner is unfeasible in a complex ERP upgrade project. To continue to insist that the business nominate a single person, in such projects, ignores the reality that no one person in today’s complex organizations can be the chief of answers. The reality of organizations today is that they don’t come in a very neatly packaged configuration to which we can apply a single methodology. We need to adopt, adapt, and apply whatever practices can help us deliver projects successfully.

In my view, there is nothing wrong for an agile project to incorporate waterfall methods when it makes sense. We shouldn’t worry too much about keeping agile pure when what some projects need is a hybrid of agile and waterfall practices. What really matters is the results. When a project is delivered successfully, does anybody from the customer side really cares what methodology or practices were used? This is one of the key principles behind what I call Guerrilla Project Management that I write about in my blog. It is a mindset that believes that when it comes to delivering successful projects, any practice that will help the team get to the finish line is fair game. Call it agile or waterfall or a combination of both.

Thank you.

By: John Bowen

John Bowen — Sat, 24 Apr 2010 06:12:19 +0000

You sum up the problem well. I have a couple of clients who suffer from Agile addiction and are starting to hit problems 12 – 24 months down the road from having used Agile as a stand alone approach. In my role supporting their operational side the impact has been significant in terms of firstly the initial quick fixes that inspired them that they had found the holy grail of software development, and now the nightmare of not having mixed Agile with some strategic thinking and a more structured approach.

Effectively we are having to take them back to where they started and do it all again for some activity streams and that is a painful process when transaction levels are at about 600% of what they were at the beginning.

Thanks for a great item.