Whilst we have grown accustomed to receiving software updates on our personal devices regularly and with little fanfare, the idea of implementing regular changes in our daily business environment is often an overwhelming prospect for change-weary staff.
There is a significant challenge in realising a continuous flow of value within organisations that are used to linear operations in their regular financial and performance reviews. How do we encourage businesses and their teams to embrace change in Agile settings? Can people adapt to a business environment where change is delivered in small, iterative increments in which digital products are now developed and released? Can business change truly be fully Agile?
In a world where siloed work prevails, we work together to implement business change enabling people to adopt new ways of working. By integrating traditional waterfall elements of business change with Agile principles, organisations can attain the required level of flexibility to respond to changes and navigate uncertainties. This approach prepares organisations to plan, manage and deliver transformational change effectively.
One might ask, "How can we design an Employee Engagement Plan if we don't know how the end product will behave?
What is NTT DATA’s Change Runway?
At NTT DATA, we implement our Agile Business Change Framework across our clients to help them successfully engage staff, execute change, and achieve the intended benefits. The framework’s adaptability is supported by three key principles which can be applied in any context, even outside Agile delivery.
The Change Runway is our approach to guide the integration of business change activities within the iterative Agile framework, orchestrating the sequence of preparatory activities for individuals affected by change to align with each release.
This paper proposes an Agile approach to implementing business change and provides examples of common issues encountered by change-makers, which include:
- Implementation of internal systems, such as Customer Relationship Management (CRM) and Enterprise Resource Planning (ERP) platforms.
- Development of customer-facing digital products and services.
- Implementation of data science and Artificial Intelligence (AI) solutions.
Not fully utilising an Agile delivery methodology? Look no further, our principles and framework are applicable to change management in any discipline.
Our three key principles not only provide a strong foundation for Agile Business Change delivery, but also facilitate a mindset shift to support your delivery.
1. Borrow the Agile mindset.
Agile mindset is people-centric at its core, lending itself perfectly to Change Managers. Even if an organisation is not yet delivering in Agile, we can borrow from the Agile methodology without falling into the trap of a blended ‘wagile’ delivery where one seemingly utilises Agile terminology or ways of working but falls back on waterfall stage-gated delivery. Agile is often reduced to ceremonies and governance, while in fact the principles of Agile go far beyond these practices. As depicted in Figure 1, Agile values are aligned with those of business change, providing a shared foundation that Change Managers can leverage to motivate and inspire Agile teams, through a shared understanding of the importance of change.
Agile values align with change values
Figure 1 Alignment of Agile and Change Management Values
2. Empower integrated, self-organising teams.
Agile teams are inherently cross-functional and self-organised around value. The business change function should collaborate closely with the Agile team to ensure a balanced approach that considers both the solution and its adopters.
For instance, collaboration between business change and technical specialists can lead to better release schedules and increased user satisfaction by providing users with early access to prototypes, involving them in testing, and offering a consistent training environment.
Furthermore, the partnership between design and change functions in product development is crucial. A dedicated design capability is essential for fostering collaboration within Agile teams. Regular coordination between these functions strengthens stakeholder interactions with the program, reducing the burden on them. When Business Change and Agile teams collaborate, remarkable results can be achieved, as demonstrated in our work with a Public Sector client where high stakeholder engagement was maintained during the development of a new system through close collaboration and meaningful consultation meetings.
3. Test and learn.
Agile delivery’s “fail fast” culture can be daunting for organisations with high levels of change-fatigue and hesitant staff. However, embracing a transparent test and learn culture is pivotal for building stakeholder trust.
Embracing an iterative, adaptive approach to change means involving the change audience, particularly the “early adopters” and “early majority” (Rogers, 2003), in the journey by showing early mock-ups, prototypes, and providing access to systems for user feedback. This practice ensures continuous user consultation and involvement throughout the process.
Additionally, the test-and-learn principle goes beyond just product development. For example, the Business Change team should work closely with subject matter experts (SMEs) to review the learning journey and learning materials to develop these iteratively before each release. Utilising sprint “show and tells” enables stakeholders to familiarise themselves with the product’s look and feel before it is released so the initial learning curve feels more manageable.
Of course, this principle generally does not work if we demand fully built and tested systems to design and develop learning content, along with communication and engagement material. One of the biggest tensions we experience on our programs is the point at which a system is stable enough to commence user familiarisation and training. In constrained delivery timelines, testing and training often end up overlapping. In recent engagements with our clients, we have applied our “Playing Field” mechanism to resolve this challenge. This makes use of a “preview” environment with drops of functionality at the end of each sprint, giving real users access to stable features to incrementally design and develop training content, alongside the learning and development function.
Ultimately, adopting Agile values and involving users early on for testing and learning sets organisations up for successful change implementation, regardless of the delivery methodology. These principles form the foundation of NTT DATA’s Agile Business Change Framework, integrating seamlessly with the standard elements of Agile SAFe methodology.
Integrating business change into Agile delivery efficiently
Using our experience in guiding clients to achieve transformative change, our Business Change Practitioners and Enterprise Agilists have developed NTT Data’s Agile Business Change Framework. This framework enables us to deliver business change with more agility, in smaller, more manageable increments while accommodating the standard business change waterfall sequences. This framework aligns with the principles of Agile delivery , complementing the Agile mindset, and adheres to the governance and ceremonies to support large scale Agile development whilst aligning with SAFe terminology.
Incorporating our three principles discussed previously, the key tenet of this framework is our novel concept of a “Change Runway” (Figure 2) which runs in parallel to the SAFe Architectural Runway, evolving in support of changing business needs “to deliver a continuous flow of value” resulting in good adoption.
1Scaled Agile Framework
2SAFe Lean-Agile Principles
Figure 2 Change Runway Aligned to SAFe Architectural Runway
NTT DATA’s Change Runway
NTT DATA devised the concept of the Change Runway to guide Change Managers in orchestrating the sequence of activities for individuals affected by change, aligning with iterative releases. The adaptable concept encompasses five core phases:
- “Assess” identifies the drivers and impact of the change through activities such as stakeholder analysis and change planning.
- “Enable” builds partnerships and equips individuals with the tools for change, addressing concerns such as: ‘What’s in it for me? What does this mean for our customers? What does this mean for my team? How do I do this?’
- “Ready?” ensures thorough consideration of impacts, risks, and benefits before proceeding with the change.
- “Release” introduces the change in a safe and controlled manner supporting adoption and preparing for post-release support. Change tools utilised here would include adoption management and baselining adoption metrics, conducting training sessions, planning for post-release support and preparing the business change support model.
- "Post-Release Support” focuses on proving the benefits of change and ensuring its lasting impact. Some tools related to post-release support include delivering stakeholder engagement and communication, positioning dedicated support teams, establishing feedback mechanisms to gather user comments and views etc.
The Change Runway is customisable based on the delivery roadmap, as demonstrated in NTT DATA’s Public Sector implementation of a new case management system. NTT DATA released the product to different services across the business in Program Increments (PI) - agreed fixed time periods within which the product is designed, developed and demo’d. In this case, the sequencing in the change runway ran incrementally to account for the different audiences that each increment was targeting.
In our operational principles, we acknowledge the necessity of functioning in an iterative environment and dealing with uncertainty. However, users require regular touchpoints and visibility of key milestones to ensure their awareness and commitment to the change. Similar to the architectural runway in Agile, the Change Runway operates as both intentional and emergent, ensuring the program maintains the integrity of its change guardrails while retaining flexibility.
The intentional lane of the Change Runway may involve scheduling updates to critical systems at specific times of year or dictating the sequence of service releases. Adhering solely to an intentional Change Runway could lead the program down a path resembling a waterfall change plan fragmented with an Agile cadence.
The emergent lane of the Change Runway facilitates informed decisions about what is presented to the business based on the insights we get from Agile delivery – such as user feedback, adoption behaviour, and the size and priority of the backlog.
By adjusting our release approach, we can pace the adoption, reconsider requirements, and strengthen or modify change interventions, ultimately enhancing satisfaction. For instance, we can prioritise early release of new features to address common user errors or work arounds, ensuring maximum value from a new product. Additionally, we can tailor our communications according to the release schedule and align them with prevalent themes in user feedback.
In another recent delivery for a Public Sector client, we employed the Government Digital Service (GDS) Agile Delivery Model. During the Alpha phase, we minimised broadcast communication, recognising that the full impact would manifest during the Beta phase. Subsequently, in the Beta phase, we escalated change activity to cultivate a deeper desire for the change and comprehension of how the product would complement established methods of business operation.
NTT Data Agile Business Change Framework Key Elements
We believe effective change can be delivered by taking into consideration the waterfall requirements of a business whilst accommodating the need for agility in delivering digital value. Now that you are familiar with our concept of the Change Runway, we will explore the other elements of the NTT Data Agile Business Change Framework (Figure 3): the case for change, PI Planning and the epics, features, enablers, stories.
Figure 3 NTT Data Agile Business Change Framework Key Elements
Our NTT DATA Agile Business Change Framework begins with the ‘Case for Change’, focusing on delivering value in program iterations or increments and how these align with the overall change vision, expected benefits and roadmap.
3Government Digital Services (GDS)
Case for Change
The ‘Case for Change’ considers change adoption and stakeholder management while aligning with the iterative cycles of Agile delivery. The entire team – including the leaders, the Agile teams, and the Business Change functions – work together to identify opportunities or needs for change that aligns with the future Vision. The Case for Change acts as a constant component for all program communications, stakeholder management, and benefits measurement.
Equipping people to realise the benefits of change requires a compelling vision that outlines why people should embrace it. This vision should extend across the entire change environment, with everyone being able to articulate the benefits for the users of the solution or product. In an Agile delivery context, this should flow into the product vision, PI objectives and sprint goals that everyone works towards. The Business Change function must take this vision and construct the change narrative in a language and context that resonates with the users and is promoted through leadership.
For instance, NTT DATA successfully convinced a central government office to embrace hybrid working six months before the global pandemic hit. There was no foreseen urgency for this task, especially at the leadership level who operated the business face-to-face. This involved, creating a vision and case for change, gathering metrics and detailing the benefits, and planning practical enablers for change. The solution needed to work seamlessly. Therefore, support needed to be planned and on hand through multiple channels, and coaching was required on new ways of working. The core ingredient for success here was the need to research and deliver measurable quick wins as the engagement progressed, aligned to the case for change.
Change adoption is often thought of as an activity closer to the end of the project. However, in an Agile environment, change adoption can be managed in smaller, quicker increments. In reference to our previous example, by identifying the stakeholder groups impacted by the change and planning interventions proactively, we were able to receive feedback and make timely adjustments. This iterative approach allows for a larger impact by catering to specific stakeholder needs, separate from the project delivery as a whole.
Program Increment Objectives and Iteration Goals
Our framework emphasises that PI planning is a collaborative activity done with Business Change Practitioners. From our experience, PI objectives should bring to life both business change objectives and product delivery objectives. Similarly, sprint goals should be prioritised in line with the business and product ambitions. The business change team provides valuable insights on user feedback and can highlight the dependencies and impacts on the item outside of the current sprint or increment. For example, in our Public Sector case management system implementation, a new service quickly requested a specific feature. After prioritising and delivering this request within two weeks, trust in the product and Agile process was strengthened.
If programs, projects and activities are part of a linear delivery environment, these can translate into epics, features and stories in the Agile delivery world.
We have established the importance of integrating change goals into increments and sprints, but what about identifying and gathering business change requirements alongside product requirements? There is no one-size-fits-all solution - it is about aligning with the program’s needs and the depth of Agile mindset within the organisation. Business change and product requirements are interconnected and therefore they shouldn’t be considered separately.
In organisations with a strong Agile culture, it might make sense to encode and prioritise business change outputs using Agile terminology and processes. For example, the design, configuration, and deployment of e-learning products can naturally be defined in user stories, features, and epics.
However, in organisations where Agile is confined to the product level and traditional structures prevail elsewhere, rigidly applying Agile methods to manage business change may create more friction than value. A pragmatic compromise is often necessary to ensure the pace of the product development aligns with the pace of change management to suit the structure prevailing in the business.
In our example of a Public Sector implementation of a new case management system, we chose not to exclusively manage our business change outputs in an Agile manner. We used the program roadmap and Change Runway to outline our change plan, considering the linear nature of business operations and the need for target dates to prepare for system launches. However, where our business change interventions were dependent on the Agile team for delivery, for example, configuration of prototypes and deployment of training environments, these were managed within the Agile team backlog as epics, features, and stories. In this example, the Business Change team functioned as an enabling team in the SAFe framework.
Where relevant, business requirements can be captured as epics, features, or stories – but only if the value of maintaining this approach outweighs the cost of it.
How the Change Runway charts a new direction for Agile Business Change methodology
Our NTT DATA Agile Business Change Framework fosters an environment where Agile teams and Business Change Specialist(s) work collaboratively to keep the user at the heart of change delivery. This synchronised collaboration allows for early identification of challenges and opportunities, as well as flexibility in taking corrective actions. It not only promotes collaboration across different specialities and disciplines but also highlights the significance of managing business change as a dependency when embedding successful products and services across the impacted audience. The Change Runway provides defined stages of change coupled with incremental delivery, allowing for regular course corrections based on regular user feedback.
In essence, Agile delivery methodologies, inherently user-centric, offer ample opportunities for Business Change Practitioners to engage, interact with, and guide users to be ready to realise the benefits of change. However, irrespective of Agile delivery methodologies, or any methodology for that matter, well-planned and executed end-to-end business change should not be constrained. Our experience has shown that, when guided by our principles and framework, Agile delivery context can facilitate successful implementation while embedding lasting change.
If you’re looking for further information or support with your Agile business transformation, get in touch with us to set up a free consultation.