Agile works in very fast, iterative sprints, implementing a Minimum Viable Product (MVP) as quickly as possible. It is an excellent way to develop a system or product; but can present a challenge on the people side of such fast-paced change. People impacts need time, once the changed state is known, to analyze, plan, and transition the people into the new changed state. So, as an Organizational Change Management (OCM) professional, how do you prepare for the people impacts with an unknown future state, working with iterative bits and pieces of critical information, and only weeks or days between the finished end product and a release date?

I can tell you it's not only possible, but for me, it was my most rewarding and smoothest OCM rollout in all my years of OCM project work. The end-users were so prepared and informed, Day One saw less than 10% user errors; by Day Two supervisors were owning the problem solving on the floor; and by the end of Week One it felt like BAU on the floor, with complete ownership of the system and processes and the next group eager to get access!

How Did We Do It?
Admittedly, the Agile approach began to work only after my own struggle to change. I didn't realize how strongly my way of thinking was tied to a Waterfall plan-then-execute approach. I was used to starting with an understanding of the end state, analyzing the impact, putting together a plan, then executing against that plan.
With Agile, there isn't a solid understanding of the end state until well into the development process. It is revealed iteratively, as each development sprint completes. You have to work with what you know at the time, and be okay when it all changes after the next sprint. Let me repeat that part: You have to be okay when it changes after the next sprint. The approach has to be flexible enough to constantly evolve with each sprint. You know, Agile!
This product release was customer-facing work. So the OCM effort was absolutely critical to building strong stakeholder and organizational readiness before the first release rolled out. I had to move forward with what (little) we knew and start leading change!


Kickoff
First, we kicked off the project by standing up the teams of training, communications, and HR partners. These teams were the brains and brawn to getting the OCM work done concurrently in a divide-and-conquer team approach. We set up work sessions with SMEs to understand "as is" and "to be" impacts sprint by sprint, daily stand ups to stay on the same page and push through impediments, and weekly status reports to update managers and program leaders.
We also set up a group of Beta Users, with representation across all operational areas thought to be receiving the new application (of course that representation grew as we moved forward). This group became critical to such a successful release. They were shown the new functionality after each sprint, and provided important feedback for system, communications, operations, and training needs. They also became co-instructors in the classroom, and floor monitors at Go Live.
We launched a candid "What we know, what we don't know, and how we're doing." communications strategy with proper venues and cadence for keeping all stakeholders (known at the time --of course it would continue to change) informed, and a one-stop-shop intranet site for posting information and soliciting feedback.


Each Sprint
After kicking off the project, progressive iterations within each sprint provided a strategy to execute the OCM work through to the first release.

After each sprint's stories were planned and groomed (we did not attend these sessions), we quickly assessed the stories that were pulled and their impact to people, processes, operations, and the system. If we had questions, we worked with the team leads or Product Owner for clarification. Then we updated the training, communications and procedures, scooped in any new stakeholders identified, and addressed any new organizational impacts or risks revealed. At the end of the sprint, we attended the playback like an iterative review session, verifying and validating what we had assessed to what was actually developed. We repeated this cycle with each development sprint.


Release Rollout
Being customer-facing, the first release group was decidedly a smaller control group. During the testing sprint, or sprints, we ensured beta users were involved in User Acceptance Testing, finalized our training and readiness materials, delivered Train the Trainer, and user training. We also supported the Command Center during the week of and after Go Live. Beta Users were on the floor providing side-by-side support, and the training, communications, and operational partners stayed on top of changes to materials as applicable prior to releasing to the remaining group.


Lessons Learned: Top Ten Takeaways
What started for me as chaos, ended with my new favorite way to approach OCM work. In summary, here's what I wish I'd known from the start.
1. Simplify, Simplify, Simplify
Keep outputs and ideas simple. You won't have time for big or fancy. Don't get bogged down in documentation and formal written plans. The more complex and formal the output, the more work it will be to maintain through constant change. You can do a lot with one slide!
2. Assess, Don't Analyze
You will have bits of information at a time. It will never be a complete picture to analyze until near the end when it's too late. Do a quick assessment of the new information and impact. Then approximate (course correct) the solution and update your plan. Rinse and repeat next sprint.
3. Smaller is Better
Keep the training and communications development & delivery team sizes to a minimum without sacrificing capability. Rollout to a small control group first and expand when ready. Keep small windows of time between reviews to help keep content moving forward.
4. Be Open and Transparent
"What we know. What we don't know" will create an honest partnership in building the end state.
5. Allow Yourself to Change Too
You won't have everything you need up front to analyze and make a plan. The readiness plan will reveal itself well into the development. So build a strategy that can flex with last-minute change. And when the plan completely changes after the next reveal that is progress! Use the basic OCM principles as your bumpers and execute creatively between them (Lewin's 3-step Model anyone?). Trust your OCM instincts and act!
6. Go With What You Have, Not What You Think You Need
Remember Apollo 13? You probably will never have exactly what you need when you need it. So, improvise using what you have! This forces creative problem solving and a "can do" leadership style. You will be surprised what can happen.
7. Collapse Anything Sequential
Get out of email and huddle up. Work sessions are much more productive and result in completed tasks plus a cohesive working knowledge across the group. This might take time the first round or two, but will result in quick iterative reviews down the road, with less rework required at the end.
8. Engage Early
Don't wait until the end state is all figured out or it will be too late. Engage stakeholders early, and keep them with you along the journey to provide critical information flow, shared decision making, and a mature audience at rollout.
9. Stay Together
You're in this journey together. Everyone needs to stay informed and engaged. Have daily tag ups with your training developers. Keep a weekly cadence with SMEs and decision-making stakeholders. Share with stakeholders what was learned after each Sprint. Celebrate successes together! These are the ties that bond.
10. A Picture is Worth a Thousand Words
So use them and save time! Make visual and hands-on a priority. Demonstrations at focus groups, town halls, working sessions and reviews will result in more solid feedback than briefing slides. Using hands on training in a "live" test or training system also improves readiness by making mistakes in a safe learning environment. Don't just show and tell. Show and do!