Change management meets Agile development

I just hung up the phone with a friend and colleague and he shared his insights and observations from a recent change management management conference he attended. He noted that that one of the participants at the conference raised the question,

Are Agile processes and principles applicable to the ever increasing velocity of change and the field of change management?

The answer is yes and let’s look at why. In the past few years, Agile processes have not only gained increasing adoption levels; they have also rapidly joined the mainstream of development approaches (Forrester Research, 2010). Let’s first look at the Manifesto for Agile Software Development (my comments are in blue).

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
  (Processes and tools are a means to an end and the end result and the people involved are what matter.)
  
• Working software over comprehensive documentation
  (Successful change over comprehensive change management templates and assessments.)
  
• Customer collaboration over contract negotiation
  (Engagement and collaboration over “resistance management”—GenY will demand this.)
  
• Responding to change over following a plan
  (Sometimes you need to be able to say, “We’re going in a new direction because that’s what makes sense now.” This doesn’t mean you shouldn’t plan—that’s a worthwhile exercise. Plans more than a few pages, however, waste time and become extinct quickly. Decide what you’re going to do this week and figure out the most important thing to do now given where you are today.)
  

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

Next, let’s look at the principles behind the Agile Manifesto.

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  (Yes! Does your change management factor in the need for iteration? Lead Change by Design does.)
  
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  (This is precisely why having a ’separate’ change manager doesn’t make sense. Projects are far too dynamic to NOT have skilled people on all teams that understand how to lead change. Leading change is not a change manager’s role. Leading change is a requirement for all leaders.)
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  (With the exception of Lead Change by Design, again, what change management methodologies out there today address the iterative nature of project?)
• Business people and developers must work together daily throughout the project.
  (Leaders at all levels must have change management skills to implement continuous change every day on every project. Leading change is not the “change manager’s role. Leading change is key to the success of any project. Any time. Any where.)
  
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  (Spot on! How many of your change management methodologies include filling out a “resistance management plan”? Seriously. What could be more of a waste of your time? Focus on the cadre of motivated people and support them.)
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  (Yes, and this is a bit unrealistic with global teams-especiallly now that there’s so much technology out there making it easy to bring people together online. Plus, this is how GenY works.)
  
• Working software is the primary measure of progress.
  (Continuous adoption of change is a measure of progress and a sign of an innovative, agile organization.)
  
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  (Leading change is not an “event”—maintaining a constant pace of change, indefinitely, is how companies at the forefront operate every day.)
• Continuous attention to technical excellence and good design enhances agility.
  (This is why I titled my book/toolkit, Lead Change by Design.)
  
• Simplicity—the art of maximizing the amount of work not done—is essential.
  (How many BIG binders do you have filled with change management templates and assessments? Not practical. Not useful. Not productive.)
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So yes, Agile processes and principles are applicable to the ever increasing velocity of change and the field of change management.

Tagged as: Agile, Agile development, Change Management, development process, Leadership, leading change, Management, managing change, methodologies