Change Management & Agile Project Management-What We’ve Learned (a Retrospective)

by Gina Giannitelli and Andie Wafzig

Project Management understands the role change methodology, tools and deliverables like the Microsoft teams project management play in the overall project success– check!
 We will be using agile methodology to quickly develop and migrate by business area – newer territory, but still feeling good.
 Change Management will be expected to use Jira, an agile project management tool, for the first time. We will participate in sprint planning, daily stand-ups, and retrospective “ceremonies” – let’s discuss.

We knew the hallmarks of our change methodology, tools and deliverables would still apply. But, we also knew we would need to adapt to a more iterative approach. Looking back at the work to date, we found some lessons and tips to share.

Tip #1 –Time Investments Shifted
Very early on we realized we were investing time in ways we didn’t anticipate.

 Heavy Upfront Time Investment for developing, testing and revising our communication and training toolkits with our pilot group; efficiencies were then gained with subsequent rollouts

 Front-loading Strategic Resources became necessary to support the initial CM tasks mentioned above with the ability to taper resourcing once we got into managing execution of a repeatable cadence

 Managing Change Tasks in Time-Boxed Periods or Sprints, we invested in participating in Jira through sprint planning, daily stand-ups, reviews and retrospective ceremonies. Early on this felt like an ineffective use of our time and a duplication of our planning deliverables. With time and compromise, we shaped meetings to address stakeholder relevant topics first, and we agreed to leverage Jira reports to meet components of our stage gate documentation requirements.

Tip #2 –CM and PM Collaboration Takes on New Meaning
While adjusting to the Jira ceremonies was challenging at first, we came to crave the predictable meetings with the Project Manager, Developer and Business Analyst.

 Rigor and Routine Matter – Because of the iterative nature of the development process, we became very reliant on ceremonies and additional core team meetings to further our work; if a new requirement was uncovered for instance, we wanted to know if it was something that would cause resistance or excitement with the user group in order to understand how it might inform communications or training

 Checkpoints to Stay on Track – Regular opportunities to converse with the full core team(developers and the Business Analyst) improved our end product; we learned with time that requirements and testing sessions may provide helpful checkpoints with our Change Agents, allowing us to be more responsive to their unique stakeholder group needs

 Balance Big Picture with Current Priorities – Our focus on the ultimate stakeholder experience and their need to be ready, willing and able to change created an interesting dynamic: we often kept our eye on the longer-term view, planning back from Go-Live for stakeholder needs, while the Project Manager was focused on the current sprint.  This created a healthy tension that our PM acknowledged as very valuable.

Tip #3 – Responsiveness and Planning Each Play a Role
Early on our PM would tease us that we couldn’t put a timeline together, that there was no point in planning for months down the line. This was a paradigm shift for us, realizing we might get just a few weeks of notice for an impacted stakeholder group! As we lived through the project, both responsiveness
and planning have a role in success.

 A Dynamic Plan – Through pilot and early migrations we were able to determine our “clone” tasks, the predictable alignment, communication, training and adoption tasks that we expect to execute with each business group; this became our living plan document

 Stay Nimble – While we start each business unit from this “plan,” we have adjusted our approach in some way with almost each sprint / rollout; we must be rapidly responsive to the needs of the business unit, modifying and executing our approach in the matter of a few weeks. Also, with each business unit rollout there are discoveries that may lead to design changes and we must respond accordingly

 Continue to Look and Listen – Each sprint / rollout deserves fresh eyes. For instance, our early groups weren’t attuned to the agile approach, so shifts in details or dates caused concern; our communications and training need to respond to this need

What we have learned overall is that it is indeed possible to effectively manage change within the Agile project environment, however, it takes a willingness to invest time strategically, collaborate effectively, and react nimbly while maintaining a balanced focus on both long-term goals and short-term action.