22 October 2014

Agile software development creates change

In my research, I defined agility as:

"...a software development team’s ability to create change, respond to change and learn from change so that it can better deliver value."

Someone commented to me that the "create change" part of this definition was unusual: what does it mean?

Agile software development actively encourages the customer to change the requirements of the product being built – to maximise the value they get from the product – with the development team "embracing" this change. As the customer sees (and hopefully uses) the evolving product, they become confident that they can refine and add new (high priority) requirements that maximise the value they get from the product, rather than  pulling new requirements from a bucket of preconceived ideas. Agile development gives the customer confidence that changes can be made successfully and easily. In contrast, traditional development methods discourage change by making change difficult.

 While not specifically talking about agile software development, the author Donald Gerwin defined creating change as: "...driving new change that would never have occurred were it not for the entity’s actions, e.g., creating more uncertainties for rivals, thus establishing a powerful competitive advantage." (*) 

While responding to change is the crucual part of the definition of agility, creating change and learning from change are also important.

(*) Manufacturing Flexibility: A Strategic Perspective, Donald Gerwin, 1993. (Sorry, not available for free.)


  1. You are right in your research, but you are not first who said it i think. We used similar principles in our web development company http://www.nixsolutions.com/ without researches, intuitively.

    1. Hi James,

      Thanks for your comment. You are absolutely correct - I am not the first to say this. All these findings are based on the stories of my research participants. My role as a researcher was to analyse, interpret and explain what is going on over all cases. This explanation is not simply retelling anecdotes or experience reports from single contexts, but attempts to explain all situations, including negative cases and outliers. The research can help teams understand why what they do works and perhaps give them ideas for improvement or for different situations.

      I'd be interested to hear your stories if you'd like to share.