On the tenth anniversary of the Agile Manifesto, the Agile 2011 conference held last week in Salt Lake City, UT was an important milestone. With about 1,600 visitors from around the world, this conference is testament to the extraordinary growth of Agile as a development framework. If the number of large-scale, global enterprises in attendance is any indication, it’s safe to say that Agile is rapidly gaining mainstream acceptance.
With the benefits so clearly delineated, why is it still “gaining” mainstream acceptance? Why isn’t it already the de facto standard?
I would posit two related reasons for this:
- Agile education (including the sessions at Agile 2011) is too theoretical;
- There is an overabundance of focus on the people and project management aspects of Agile and little on the engineering disciplines that must be implemented.
I made it a point to engage with as many attendees at Agile 2011 as possible, and in so doing I gained a broad (if unscientific) consensus that as smart as the presenters were, and as compelling as their ideas were, many were lacking in practicality. It’s not that the ideas themselves were invalid or not useful. It is just that the ability to put those ideas into practice was not there. Or as one participant said to me, “When I get to the office on Monday morning, how exactly, do I take advantage of what I learned?”
Stepping back from Agile 2011 and looking at Agile education in general, you might see the same criticism about the ScrumMaster, Product Owner and other certification classes. They teach you the theory, but not (in most cases) the practical application of that theory.
I understand that Agile is a framework that can be applied to many disciplines – it is not just software engineering. I’ve seen marketing and sales teams that benefit from practicing Agile, but for this blog, I’ll just concentrate on the core use-case of Agile – Software Engineering. I would argue that software engineering teams doing iterative development of any kind must employ underlying disciplines and technologies to make it successful. The human and project management aspects must have the underpinning of Agile software engineering crafts like continuous integration, pair programming, test driven development and others.
One of the primary criticisms I heard at Agile 2011 was the lack of such sessions. The handful that were offered were standing-room only, attesting to the demand from the delegates.
In future conferences (Agile 2012 amongst others) I am hopeful that we will see sessions that directly address these two concerns. For the former, I hope to see case studies, presented by the users themselves rather than the vendor or consultant who assisted in the implementation. The difficulties and problems are just as important to understand as the solutions, and it isn’t necessarily in the interest of vendors and consultants to highlight these. For the latter, I am hopeful that we will see more “hard-core” technical sessions which will help delegates adopt the underlying disciplines more effectively.