What did you do on your last ski vacation? In 2001, 17 programming practitioners met at a ski resort in Snowbird, Utah, and came up with four guiding principles of “agile” that became the foundation of a worldwide software development movement. This makes that triple-black-diamond run seem pretty tame, doesn’t it?

These four agile principles are as simple and impactful as the Golden Rule. It is because of their simplicity that any of us, as change practitioners, can adapt these principles and some key practices of agile and apply them to improve our change efforts.

What Is Agile?

Let’s establish a common understanding around what we mean by agile (communicating with a common language being an underlying practice of agile). Most definitions of agile refer to the iterative and collaborative nature of the process—collaboration that extends to the customer and business owner as well as to members of the software team. For example:

Agile software development is a lightweight software engineering framework that promotes iterative development throughout the life-cycle of the project, close collaboration between the development team and business side, constant communication, and tightly-knit teams.

Remove the references to software and software engineering and this sounds like an ideal environment for a successful change implementation!

The Principles of Agile

The original authors of “The Manifesto for Agile Software Development” articulated four succinct principles of agile in one paragraph and a qualifying sentence.

  • “Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

. . . while there is value in the items on the right, we value the items on the left more.”

As an organizational change practitioner, I would have a difficult time arguing with any of these principles. They are solidly people- and customer-oriented, which was the intent of the original manifesto—working to deliver to the customer the product and functionality that is expected.

Isn’t that what we are about as a profession—attending to the people side of change; setting expectations appropriately and then delivering to those expectations?

One caveat to these principles is avoiding the temptation to focus on “the items on the left” and totally disregard “the items on the right.” This was not the intent of the Manifesto’s authors. The goal was to plan, use a process (agile being a process), negotiate, and document to the extent that each item facilitates work being accomplished but not to let each item become the focus instead of the work itself.

That can happen.  When the Software Engineering Institute at Carnegie Mellon developed the first Capability Maturity Model, documentation set upon documentation set was produced to shape the details of the process.

The value of CMM is undeniable as evidenced by all of the next generation maturity models—Process Maturity Model, Project Management Maturity Model, Enterprise Maturity Model, Change Management Maturity Model, and many more.

But it was the concept of a maturity model as a way to define and measure stages of capability, not the documentation that embodied the value.  And so it can be with agile change management—just enough of “the items on the right” to enable the effectiveness of “the items on the left.”

In another blog, we will look at look at some agile practices that can help us reshape our change management practices.

Are you trying for more agility in your change management practices? Share what you’ve learned about this process on the Change Management Review Facebook page, or leave a comment below.