The Agile Paradox: Instigating Change Without Managing It Well
The Agile Paradox: Instigating Change Without Managing It Well
Agile teams are focused on building, creating, and improving in order to bring new or different things into the world. They’re creating change. And as with software development, successful change initiatives require agility, a relentless focus on empathy, and good storytelling.
Agile seems like a perfect fit, then, for managing change – and many companies are beginning to use this framework in an effort to either seamlessly keep track of the change work related to their digital transformations or to discuss the change work in a way more familiar to technology teams. However, two fundamental characteristics can make Agile an ill-fitted framework for managing change. First, change is not a standalone product. Second, change management doesn’t just benefit from agility; it demands it (especially at the beginning).
Let’s say you are leading a team that is doing Agile, and the stories your team writes must follow a specific formula, “As a ___, I want ___ so that ___.” Though this is a great and widely used formula, we know that to adhere to the procedure without adhering to its purpose decouples it from the context that gives it value.
The purpose of the shift to user stories from developer-centric requirements was to shift our mindsets away from merely describing the work to be done toward the desired outcomes we were hoping to achieve from the user’s perspective. When we learned more about our users and constraints, we could change course and let go of our assumptions. It was a shift from box-checking our preconceived notions toward empathy and desired behaviors. It enabled us to leave the details to the design and development experts and made space for adapting to new learnings.
But the hype around Agile methodology, for both software and change management, has led to a focus on process over purpose. Say I wrote a story: “As a developer responsible for authentication, I want to leverage existing SSO capabilities for this new app so that it’s easier for the user to navigate between platforms seamlessly.” You can still build the product in a way that achieves its intended aim, despite the story completely missing the point of what a user story is supposed to be.
Once we commit user stories to a development sprint, Agile tells us not to allow that sprint’s scope to creep, so we may then sprint to the finish line on those commitments. This works (for the most part) when you’re building discrete pieces of a concrete whole. In fact, this focus and two- or three-week cycle is part of what fosters agility for Agile teams.
But this is where software differs from effective change management.
To manage change, you cannot afford to accidentally get lost in the paperwork of describing the work to be done or to prioritize output over the outcome. That may mean you are not able to write specific or detailed acceptance criteria that describe the work itself before the work begins because, so often, working yourself to that answer is the work. And you can’t get precious about specific deliverables or individual story commitments. Change work changes.
This is the paradox: If you commit more fiercely to the process than to its values and principles, the Agile method becomes ironically rigid.
Managing change can easily be described and directed using the values outlined in the Agile manifesto: “Individuals and interactions over processes and tools, [what works] over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.” The key is sticking to the principles, not necessarily the process.
How to avoid the Agile paradox
When using stories to document and organize change work, keep them relentlessly focused on the outcome. This is particularly important at the feature or epic levels. Approach your backlog with more of a Kanban mindset to allow the flexibility required to respond to the ever-shifting landscape that comes with change.
Like everything else with Agile, the best results are achieved when the initiative is built around motivated individuals. You realize optimal outcomes when the team commits to the Agile principles and values, reflects and tunes, self-organizes, and focuses on excellence and sound design. You excel when there is plenty of regular collaboration and conversation between the business and the change team.
Software is change– the sheer pace of technology instigates so much transformation for organizations, and every software project has an element of change. Change practitioners, particularly in the digital transformation space, would do well to understand how to best leverage the Agile methodology and speak the language of software teams.
Though software is change, change is not software and cannot be managed as such, so when it comes to a framework for managing digital transformations from the change perspective, lose yourself in the Agile values rather than getting lost in its methods.
Want to learn more?