10 Years of Agile

Alistair Cockburn has been organizing a 10 Years of the Agile Manifesto event in Snowbird this coming weekend.

A majority of the discussion is anticipated to revolve around three questions:

  1. What problems in software or product development have we solved (and therefore should not simply keep re-solving)?
  2. What problems are fundamentally unsolvable (so therefore we should not keep trying to “solve” them)?
  3. What problems can we sensibly address – problems that we can mitigate either with money, effort or innovation? (and therefore, these are the problems we should set our attention to, next.)

Here are my thoughts on this topic.

I think we’ve solved many of the more micro mechanics of agile software development (on paper anyway). The challenge remains in regards to application.

In regards to question number 3, I think we need to start having more of a systems thinking perspective to scaling agile development.  The issues in this area are usually not related to process and tools of the agile space itself but rather human, organizational and change dynamics in the application of agile.

The agile community needs to evolve people who think beyond the current application of  the basic tenets of the Agile Manifesto and apply them and additional thinking to the challenge of agile at scale, IOW, Agile in the Real World.  For instance, perhaps applying a change framework such as the one presented in the Heath Brothers’ book “Switch” to the problem of scaling agile.  I have written before about coming up with a framework that purports “using agile to scale agile”

Agile coaches, for instance, should be able to not only instruct and coach teams on agile practices, but also coach on crafting change programs based on situations that exist in specific organizations.  This requires longer-term relationships and interaction with clients.

One of the more disturbing trends I see with the rise of things like Kanban is that organizations expect a silver bullet with their agile initiative, and when that doesn’t work, they run to what they think the next silver bullet will be. Don’t get me wrong, I find Kanban and its premises very useful, however, not exclusive of other agile practices.   We need to get organizations that are moving to agile project management to expect some failure and also help them learn what continuous process improvement is.  For some reason folks don’t seem to realize that this is a team skill like anything else, you don’t do it well just because you allocated time for a retrospective.

In this same vein of systems thinking, the agile community originally did a poor job factoring in how to integrate existing PMOs, legacy project management and governance systems into agile change initiatives, even agile pilots.  It was foolish to not have a well thought out plan for how to make allies out of those that would turn out to be one of your most significant “enemies”…look to Sun Tzu, “The Art of War”.  Perhaps now enough has been learned by failure and some success to provide patterns that can be leveraged to help ally such groups early on.

Whether these problems will be seen as sensible or unsolvable I’m not sure, but IMO they are the ones that will impede the success of agile in the real world. If they are seen as unsolvable then we risk seeing limited application of agile in organizations, and by limited I mean both within the IT side and beyond.  Agile thinking can be extended well beyond developing software.

This entry was posted in Agile Development, Agile Software, Agile Teams. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>