TiER1 Performance Long before the Agile Manifesto was penned in 2001, software developers everywhere were questioning their existing methods. The shared realization was that the traditional waterfall approach to software development was cumbersome and not responsive to the ever-changing needs of the business.
Fast forward to 2020: Most IT departments run some version of Agile (whether Agile SaFE, Lean Software Development, Scrum, or something else). While these development methods vary in focus, steps involved, and ceremonies conducted, they all share a grounding in the key principles of the Agile Manifesto. Embedded within these principles is structure and guidance on how to create and respond to change and uncertainty related to the technology—but what about the people using the technology? There’s little guidance on supporting the adoption of new software or assisting people with the uncertainty that results from changing the tools required for their work.
At its core, software enables the work done by people, so we must ask…where is Change Management’s place in Agile? Based on TiER1’s experience working with agile development teams, we’ve found the following integration points for Agile and change that can drive significant value.
Within the Agile construct, the role of Product Manager acts as a liaison between the business and the software development team. Traditionally, the Product Manager serves as the voice of the customer. They understand the business case for the change and their role in driving value for end users. They are also domain experts who can relay detailed user requirements to the development team.
In other words, the Product Manager is the sponsor of the change, which also means they assume accountability for driving adoption of the changes being developed at their request by the Agile software development team.
In addition to their business acumen, to be truly successful Product Managers should also possess a foundational understanding of change leadership. Unlike change management, which focuses on the tools and methods needed to plan and execute the change, change leadership focuses on the driving forces, visions, and processes that ignite and continuously fuel new ways of working. Change leadership requires effective communication and influence skills as well as knowledge around how internal and external performance factors promote or detract the key behaviors the change is trying to achieve.
Product Managers and Change Managers must work alongside one another to drive adoption for the changes both incrementally and holistically. This goes beyond initial communications and training to teach end users about new features and how they enable the work being performed. It extends to communicating a compelling vision; engaging the head, heart, and hands of those performing the work; removing barriers that prevent new ways of working; and having data-driven ways of measuring and monitoring adoption.
Typically, software features are scoped and prioritized based on the level of effort required to build them in relation to the value they create. What is often not accounted for is the complexity of the effort required to implement the changes.
By taking a technology-centric perspective, IT organizations often miss impacts on the broader performance ecosystem and what it will take to align everyone around new ways of working. Remember, technology enables work, so changes to the technology (no matter how big or small) impact the ways in which people perform their work. At times, something that seems like a small effort, high-value technical change on the surface can impact the organization in a more dramatic way and require greater effort or additional time to resolve.
Changes that affect mindsets, behaviors, or interpersonal connections often require a greater level of alignment, clarity, and support. When assessing impact, map the individual employee or employee groups to the changes being implemented and the broader organizational factors that directly or indirectly drive behavior:
Understanding the degree of impact at even the highest level allows the Product Manager and development team to have a more holistic, informed discussion about what it will take to implement the change and drive new ways of working that allow for adoption and realization of ROI. To create a high-level scope for the implementation effort, it’s important to:
Agile development offers “iterative” or “incremental” waves of change as new features and functionality is built, bundled, and released. Often these incremental features form the building blocks for a larger transformation. However, many times they are not planned, managed, or communicated that way, and can leave the end user feeling overwhelmed and disoriented. It also increases cognitive load, as everyone is left to decipher why the change is occurring and what success will ultimately look like.
Two important aspects of this work include:
1. Leveraging an overarching change strategy and detailed release-based change plans.
A change strategy outlines how the transformation journey will achieve stated outcomes and provides direction and purpose for the holistic adoption efforts. It also outlines general guidelines for how support will be provided and what success looks like for the overarching program. Finally, it provides an adoption framework to measure the degree of adoption of incremental changes being released. This allows for real-time remediation and ensures ongoing performance support is available.
Alternately, a release-based change plan identifies the specific audiences, impacts, change tactics, and adoption metrics for each release. Change plans should incorporate the end user’s journey through change and design moment-of-need solutions to provide users with the right support when they need it most. It should also align with the overarching change strategy.
You can think of it like a jigsaw puzzle. The change strategy provides the pattern of the puzzle (the general shape, the image), whereas the change plan is the detail that is visible in the individual pieces (how they fit together so perfectly to allow the image to appear). Each one individually will not create the desired outcomes for the transformation. But when they align, they complement each other and lead to fully adopted new ways of working.
2. Continuously reinforcing the big picture with each release of new functionality
Without sharing a vision for the broader transformation and a roadmap showing how successive waves of change will support the achievement of it, features being released on a frequent and iterative cadence can begin to feel like “death by a 1000 paper cuts.” Over time, this can lead to change fatigue, apathy, and disengagement.
As a rule, features that impact the employee or customer experience should first be grounded in the overarching vision for the transformation, as well as share how those specific features enable it. Journey maps and other visualization tools are useful for showing the path to a future state and what it will take to get there. The bottom line: The more that end users can see how their efforts contribute to the broader transformation and understand the incremental steps to get there, the more they see how their work contributes to achieving that, and the more committed they will be.
There is no question that Agile has revolutionized software development. The benefits of sensing and responding to customer feedback and achieving ROI quickly far outweighs previous methods. Just remember that it is not all about the software, but rather it is about the value driven by the people using the software.
Like these insights and want to read more? Check out the following insights on: