Why are agile projects generally successful while enterprise agility is so arduous?
This is because they are vastly different undertakings requiring wholly different approaches to change.
In response to the rapid pace of startups and market disruptors like Spotify, Netflix, and Airbnb, many established organizations are adopting Agile1 practices in select projects or programs—and those efforts often work. In fact, a recent survey found that 98% of organizations realize value from Agile projects.2 In stark contrast, attempts to scale these initial successes and develop enterprise agility (e.g. scaled Agile methodologies, DevOps, digital transformations, innovation groups) often run into a cultural brick wall. For example, 80% of those surveyed about attempts to scale toward enterprise agility indicated resistance was “severe.”3 Often, this is what such transformations sound like:4
- “Agile clashes with our culture”
- “We need more management support”
- “The business isn’t bought in”
- “Our people are resisting Agile”
Why are Agile projects generally successful while enterprise agility is so arduous? This is because they are vastly different undertakings requiring wholly different approaches to change.
A single Agile project can be executed in a way that minimizes the impact on business stakeholders outside of IT, while still benefiting customers. You can get started at the Agile project level by adapting proven change management methods to iterative Agile practices.
Scaling to enterprise agility, in contrast, will inevitably defy your organization’s existing rules, traditions, and practices. A thorough and deliberate cultural transformation is required for the new operating model to work. The most successful transformations involve proactive and incremental steps that shift how decisions are made and how leaders lead.
Agile Project Challenges
- Short-cycle communications
- New concept of sponsorship
- Pre-sprint vs. in-sprint change management
- Managing user expectations
- Iterative training
- Sustaining past releases
Enterprise Agility Challenges
- Decentralizing decision-making
- New prioritization process
- Need for new leaders behaviors
- New way of settling objectives & budgeting
- New roles and responsibilities
- Cultural shifts
Nailing the People Side on an Agile Project or Program
Let’s start at the Agile project level.
Pressured by the pace of change, competition, and customer expectations, businesses often adopt Agile for project and program management because waterfall processes are too slow or too disconnected from end users to achieve needed results in time. If you’re in an established organization just introducing Agile practices, you’re likely implementing it on a small scale as the result of a business imperative.
This is where one of our clients—an electric utility—found itself after customer satisfaction scores plummeted for a key customer group. To reverse the negative trend in its traditional organizational framework, it would have had to transform internal processes and train engineers and unionized field workers in entirely new systems, processes, and roles. This would have taken years.
The organization didn’t have years, so it converted its nascent program team to Scrum (an Agile methodology) and, after converting, rolled out a series of meaningful customer improvements after the team’s first one-month sprint.
If you’re in an established organization just introducing agile practices, you’re likely implementing it on a small scale as the result of a business imperative.
The utility’s adoption of an Agile project management approach required adapting its change management methodology as well. This, in turn, required major shifts in thinking. And whether you’re using Scrum or a different methodology, shifting a program to iterative delivery can’t succeed in a traditional organization simply through one-and-done training. It also requires:
1. Beefed up, near-constant stakeholder engagement
- Sell iterative delivery to your program’s business stakeholders—they must see the benefits to themselves5 (not just to the customer) or else they could slow your teams down significantly.
- Give key business stakeholders visibility and input into user stories near the top of your backlog before putting them into your sprint plan—this will help you identify risks and help get your stakeholders on board before your sprint begins.
- Develop a solid relationship with the product owner/project sponsor to solidify their new roles and responsibilities. Ensure the product owner maintains a close connection with business unit leadership so the contents of upcoming releases are never a surprise.
- Replace heavyweight stakeholders and impact assessments with a lightweight means of assessing the impacts of “epics” and stories quickly and through conversations. For example, leverage or stand up an interdepartmental change agent network of individuals you can quickly call on to help you “T-shirt-size”6 the impacts and identify other impacted groups.
2. Dialed in stabilization tracking and planning
To ensure that changes from past releases “stick” with impacted business units, use a portion of your team’s backlog grooming or sprint planning meetings to capture stories and tasks required to stabilize and reinforce changes from past releases, such as:
- Monthly check-in meeting with business unit X
- Quarterly focus group with business units X, Y, and Z
- “Quick bite” webinar training as follow-up to in-person training
- Monthly assessment of solution adoption (e.g. survey, metrics analysis) for three months
3. Iterative, lightweight training delivery
- Stand up a regular training cycle that aligns with your release cycle, so that impacted business units and internal end-users (if applicable) get training on a predictable cadence, whether the changes for stakeholders in a particular release are big or small.
- Work closely with departmental leadership to ensure supervisors, SMEs, and team members that others look up to play an active role in the customization and delivery of release-specific training content, so changes don’t seem like they are being imposed on them from the “outside.”
Our bottom line for change management on Agile projects: Extend your change management efforts beyond the sprint or release cycle to give stakeholders the needed “mental runway” to weigh in on changes before they become committed and to ensure they sustain the changes after a release.
Principles to Guide Enterprise Agility
Enterprise agility requires organizational change efforts to shift from decision-lagging activities to distributed decision-enabling efforts:
- Authentic leadership conversations over scripted talking points
- Distributed decision making over top-down change mandates
- Co-creation of change over stakeholder receipt of predetermined information
- Respect for individuals over crowd management
- Cross-functional prioritization over competing functional perspectives
- Iterative experiential activities to enable change over scheduled communications and training describing change
- A holistic strategic vision over communicating changes as discrete events
These are not absolutes—in some cases the second approaches are needed, though whenever possible we prefer the first approaches as ways to get the behavioral, structural, and cultural changes required to achieve enterprise agility.
Succeeding at Developing Enterprise Agility
When regulatory and competitive pressures became white hot for one of the largest financial institutions in the United States, embracing enterprise agility became an imperative. Leaders quickly aligned behind an Agile framework that shifted funding to Agile teams tasked with frequently delivering customer value. Their efforts began to succeed, but as more departments converted to Agile practices, confusion about the new ways of working put a damper on progress until we partnered with them to implement a clear approach. This is not a unique story.7 Scaling toward enterprise agility brings new challenges that require new thinking. The following considerations should be near the top of your list:
1. Enterprise agility will put pressure on every element of your organization. Strategy, structure, performance, and processes must all be re-envisioned to accommodate a new operating construct.
2. The transformation process will require your organization to operate in at least two separate modes (i.e., Agile and legacy). Leadership behaviors, performance evaluations, decision-making models, and funding models are examples of things that must be done in different ways, sometimes in the same week, day, or even in the same meeting.
3. Since enterprise agility emphasizes self-organizing teams, decentralized decision-making, and openness to change,8 leaders necessarily distribute some control to reap the benefits of agility. In older constructs, leaders could re-draw a new organizational chart and implement by decree, but once set in motion the course was hard to adjust. Transformations toward enterprise agility are more dynamic and organic, and therefore harder for leaders to control.
Herds of Agile coaches and ScrumMasters can accompany an enterprise transformation, but we have found they often bring an IT-centric perspective and do not adequately attend to the organizational change.
To fill this gap, we designed an adaptive approach to organizational change that enables the incremental adjustments necessary for agility that infuses an organization with vibrancy. It starts with the following:
1. Begin a New Story:
- Craft a narrative for your organization that conveys leadership’s clear sense of direction, a compelling vision, and near-term goals. Establish executive alignment around this narrative, what to expect from agility, and how best to steer the organization through these changes.
- Enable leaders to role-model new mindsets and behaviors that favor authentic conversations over scripted talking points, and co-creation of change with impacted employees over delivering pre-determined decisions. Consistently reinforce and celebrate successful demonstrations of these behaviors across your organization.
2. Engage Everyone:
- Develop middle manager leadership competencies to support the new model, which will be a radical shift for those used to command-and-control leadership. Spend time ensuring middle management is reinforcing and supporting both the new processes and the new mindset within their departments.
- Communicate roles, responsibilities, accountabilities, and incentives that will enable the change. Clearly define how responsibility and authority are distributed in the new model.
- Create immersive experiences based on behavioral design11 techniques to overcome human tendencies to procrastinate or stick with the status quo. Since habits of thinking and working can be hard to break, these experiences must be designed with effective triggers to promote the needed changes in decision-making and leadership behaviors.
3. Improve Together:
- Invite impacted employees to participate in writing your organization’s new narrative, creating multiple channels for employees to meaningfully engage (e.g. focus groups, town halls, electronic feedback channels, and cross-functional retrospectives that include employees in impacted business units). Invest the time to loop back on feedback received.
- Promote consistent, fair, and transparent decision-making processes. Give employees easy visibility into the leadership’s top priorities and how those priorities connect to their work.
- Apply a model for building trust.12
- Recognize that leaders will need to support parallel “modes” (i.e., Agile and legacy) during your transformation:
- Delineate what work will remain in the legacy mode and what work will become Agile.
- Define leader behaviors needed to support multiple operating modes (Agile and legacy) and ensure leaders get coaching on how to support employees in both (e.g. directive leadership style vs. servant leadership style).
- Establish leadership learning networks for peers to continuously progress toward the future together, applying learnings quickly to improve.