As OCM practitioners, we live and breathe change. We're the ones that help define it, provide the education that makes it not quite so scary, and get employees excited to embrace it. We're very comfortable navigating through changing environments. Or at least we think we are, until the shoe is on the other foot, and we're the ones forced to change.
More and more, it's becoming an Agile world, and like everyone else, OCM is trying to adjust to meet the needs of this faster, iterative environment. Often this means merging Agile principles like Scrum and Kanban with change management methodologies like ADKAR. But for change management practitioners, the fundamental challenge may be the realization that some trusted, familiar tools simply are not compatible with Agile. For me, that meant saying goodbye to my old Excel-based communication plan.
This was a lot more difficult than I anticipated-my spreadsheet helped me to plan, allowed me to maintain a sense of control, and served as my North Star. Frankly, it was just a nice warm security blanket. However when I presented my communication plan in my first Agile project, which laid out activities over a six-month period, the team's collective reaction was something along the lines of, "I agree that we will want to do all this stuff, but we have no idea when we'll be ready, or what the functionality will be in the first release."
What?! How can you not know that? What am I supposed to tell end users? When can I train people? You're rendering my spreadsheet obsolete!! It was an eye-opening experience to say the least.
After the initial shock wore off (and I was able to appreciate the irony of a change management practitioner struggling to change his change management thinking), I knew I was stuck in an old paradigm. As the OCM lead, I was working under the notion of a single, go-live event. While this often means end users have to wait longer to get access to the application, change practitioners have a major milestone to build detailed communication plans around and the time to sequence events out over several weeks or months. As a result, the communication planning spreadsheet becomes their day-to-day management tool.
Agile projects don't really have a single go-live-rather, Agile's iterative development model uses multiple releases to deliver the application in smaller segments. End users get to experience functionality faster and in more manageable pieces, which ultimately leads to a shorter learning curve. The flip side is change practitioners cannot forecast what the impacts and communication needs will be for end users beyond more than two to four weeks. The speed and unpredictability of each Agile sprint make the spreadsheet method of managing communication impractical.
This realization was a sea of change for someone like me-what I learned can be summarized as follows:
- Treat each sprint as its own mini communication phase-sprints move very quickly so whatever planning you do has to be focused on exactly what is in front of you. Don't worry about potential dates or activities beyond this sprint.
- Embrace the ambiguity-there's nothing wrong with communicating what you know, what you don't know, and what the issues are.
- Get a clear understanding of what constitutes a Minimum Viable Product (MVP)-this will allow you to establish a baseline of what end users will need to know.
- Maintain close contact with the product owner and the scrum master-the development teams will be extremely busy, so the product owners and scrum master are key sources for better understanding the stories for the sprint.
- Use the team's sprint planning tool as the de facto communication plan-not only does this reduce the amount of time consuming documentation, it also is an efficient way to provide visibility to the rest of the team on the OCM workstream.