Agility is one of the older industry buzzwords. Older? Well consider that by definition a buzzword is “often an item of jargon, that is fashionable at a particular time or in a particular context” The concept of agile development methods is rooted in 2001 with Evolutionary Model of Software Development Methods and the Agile Manifesto. If you accept Scrum as a form of Agile, than it is 30+ years old based on the creation of Scrum by Hirotaka Takeuchi and Ikujiro Nonaka .
Ten years, in terms of the software development industry, can be several product life-cycles. As a buzz word, in the terms of software development, agile became very common after 2010. In some contexts, it is a mature concept and practice. Without a doubt, at the moment being agile is very fashionable.
Agile software development and project management
According to a 2014 InfoQ poll, “most organisations are using agile techniques for at least some software development projects” with a smaller group having adopted it as their primary development framework. As can be expected, due to the strong linkage between software development and project management, project management practitioners quickly recommended adopting agile principles. In 2004, Jim Highsmith translated agile software concepts into an Agile Project Management methodology. Agile has since been incorporated into project management certification such as PMI Agile Certified Practitioner® and PRINCE2 Agile® .
Current reports indicate that those organizations embracing agile methodologies and practices are more likely to be successful. Although, according to Geneca up to 75% of software projects will fail, the potential good news is that, according to PMI`s 2017 Pulse of the Profession report project success rates are rising.
Agile change management
Agile frameworks have many factors that contribute to increases in project and product delivery success. Agile processes promote more frequent communication and collaboration with the client, a strong feedback loop and by breaking large items into smaller tasks and deliverables, issues are identified and addressed quickly. “Failures” when they occur, occur faster, have smaller impact due to smaller scope of each task/deliverable and can be resolved quicker. So how does this relate to change management?
The (2011) ITIL v1 definition of change management is “the process responsible for controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.”
What would have to change
To complement agile frameworks for software development and project management, the change management framework has to adopt similar agile principles while continuing to contribute to overall risk management. Change management practitioners can still apply same or similar strategies and tactics previously used for mitigation but must accommodate risk management that is now in real time as clients and sponsors are engaged earlier, more frequently and churn is constant.
The Manifesto for Agile Software Development states:
-
Individuals and interactions over processes and tools
-
Working software over comprehensive documentation
-
Customer collaboration over contract negotiation
-
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
In other words,
- more communication and collaboration, supported by appropriate tools and processes;
- quality software, which meets the functional needs of both the individual and enterprise, with just enough documentation;
- evolving scope, which may not be defined right the first time, but will be come right over time and
- have a plan which flexes with and accommodates change because that is the ultimate purpose of change management.
Will embracing agile principles make change management simpler
The v2 and v3 ITIL definitions for change management, while evolving from Service Management to Service Transition, still has three components: controlling changes, minimizing disruption to IT Services and enabling beneficial changes. That is still good and appropriate for those who managing the IT environment but that is not what clients ultimately want. They are looking for results not a process. Particularly if working the process is delaying getting results. Intuitively they understand return on investment and in some cases have a better appreciation of risk management and service delivery than IM and IT staff.
I believe that in theory, embracing agile principles will not actuality make change management simpler but change management will be perceived by clients as being simpler through its contribution to realizing results. I am also cynical enough to realize the inertia and power dynamics present in many large organizations, and the desire for instant success, makes it far from simple to implement. But I am more than willing to be wrong.
What if you do not embrace agile principles
Agile is a mind set. Is your organization adopting agile philosophy, methodology and framework? If it is and your change management practice is not then your change management is not, then either through passive or active resistance, your change management will become or will gain a reputation of being more complex. At a minimum, the complexity is a result of a widening gulf developing within your culture. Agile changes the definition of success.