Saturday, December 01, 2012

"Being Agile" versus "Doing Agile"


I was reading a discussion on the Linked In's Agile Transformation and Organizational Change forum on whether the Agile community stop focusing so much on "being Agile" versus "doing Agile".

This led me to ask the following question: What does "doing Agile" really mean?




Does it mean adhering to the principles in the Agile Manifesto? Does it mean adhering precisely to a particular methodology (Scrum, XP, Feature Driven Development, Crystal, etc.)? Or something else?

I have met a number of people who say, "We are doing Agile" and then they describe some home bastardized Scrum implementation that includes any number of agile anti-patterns. Note: Adam Weisbart's blog has a fun example of this topic called Go Fish.

From these discussions, it seems that is common for organizations to deviate from the core Agile principles in many ways including: absence of self-organizing teams, inability or unwillingness to deliver working software at the end of a iteration (i.e. they have a skewed definition of what done means at the end of an iteration), lack of commitment from product owner, and more.

Because of this, these teams have not realized the performance gains of well implemented agile. Note: Jeff Sutherland created several videos where he describes the type of performance gains that can be achieved when Scrum is properly implemented.

It's almost as if these organizations are fixated on a tree (i.e. focused on "doing Agile", because everyone else is) and are unable to view/understand the forest (i.e. understanding what "becoming Agile" entails).

I always thought that if you follow a well-thought out methodology properly (such as Scrum, XP) and adopt its intent, you will become Agile. But, if you do not understand what becoming Agile entails, you may end up becoming one of those oft-cited failure statistics.



Post a Comment

0 comments: