Agile Transformation – A Basic Framework

“Change is not mandatory. Neither is survival”.

W. Edwards Deming

Agile Transformation is a means to an end. Agility is an enabler of superior business outcomes. Organizations expect that Agile Transformation will enable accelerated delivery cycle times, reductions in operating costs, improvements in product quality, faster strategy pivots and more satisfied customers. However, many transformation initiatives become protracted, expensive, and ultimately stall with little of real value accomplished. Many large agile initiatives not only miss their goals but also cause organizational disruption and adversely impact product development programs. Reasons for failure include lack of organizational alignment on goals and strategy, insufficient skilled change agents to support the initiative, lack of accountability, and inadequate or inconsistent governance.

An Agile Transformation may be one component of a broader Digital Transformation (or technology modernization initiative) which includes things such as switching to a cloud infrastructure, AI-driven sales improvement, and automation of manual processes like customer service. No two transformations will be exactly the same, but their overall business objectives will be fairly common: accelerate financial growth,  gain market share, and become a faster, more responsive organization.

Whatever the specific goals of any transformation, the application of agile principles to the transformation process itself is much more likely to deliver successful outcomes. This means employing an incremental, iterative approach to manage risk and maximize goal achievement.

Transformation is an expedition into the unknown. At the outset, we don’t know what we don’t know. A transformation strategy built on the empirical pillars of inspection, adaptation and transparency makes a lot of sense. That is:

• The transformation approach is adaptive in contrast to following a fixed plan.
• Progress is made in small increments followed by inspection with adaptation for the purpose of learning, risk-reduction and course-correction.
• Inspection is enabled by transparency, that is, problem-solving and decision-making is based on facts and data.

This makes an agile approach to any type of transformation more flexible and reduces the cost of failure. This enables an organization to learn fast and make real progress.

A Framework for Change.

 Basic elements of an agile transformation fit within a PDCA (Plan-Do-Check-Adjust) framework – a four-step iterative approach for change management and continuous improvement. 

Plan:

• Define the vision and objectives for the transformation. A compelling vision helps inspire employees at all levels to commit to the transformation. Objectives should be stated in terms of measurable business outcomes. Leaders play a critical role in defining and communicating the vision for the transformation and helping to ensure that transformation objectives are strategically aligned with business priorities.
• Devise a strategy/plan for the transformation. A strategy/plan, in the form of a Transformation Backlog, communicates a high-level plan for how to achieve the objectives. This is an ordered list of everything needed to realize the goals for the transformation. Progress can then be measured in terms of how much of the transformation backlog has been implemented by each team.
• Organize. A governance framework (Roles/Events/Artifacts) is needed to steer the transformation. This includes defined roles/responsibilities, a cadence of events for planning, progress reviews, and making adjustments, with key artifacts/data for use in decision-making. Skilled change agents are needed to lead this process. 

Do:

• Execute. Execute incrementally. The Transformation Backlog can be implemented incrementally across the organization Different teams may proceed at different implementation rates depending on their current capacity and capabilities.

Check:

Collect transformation data:

• Operational Metrics: Cycle time, throughput, flow efficiency, defect rate.
• Business Agility Metrics: Time-to-market, customer satisfaction, revenue growth.
• Agile Maturity Metrics: Team autonomy, backlog health, predictability.
• Cultural Metrics: Employee engagement, leadership participation, collaboration.

Learn & Adjust:

• Learn and Adjust. Assess progress, challenges, lessons learned from each Transformation Increment. Make adaptations as necessary.

The general approach can be summarized as follows:

Each item in the Transformation Backlog is modeled as a ‘story’. All stories have unique Acceptance Criteria, and there is a Definition of Done common to all backlog items.

For example:

Story: Agile Delivery Framework Adopted

Acceptance Criteria:

• Team trained in Scrum/Kanban
• Roles in place: PO. SM, Developers
• Events & cadences established: Sprint planning, Daily stand-ups, Sprint reviews. Sprint retrospectives
• Work tracked in agile delivery tool: Jira/ADO
• Team working agreement plus DOD

Definition of Done:

• Agile coach verifies story meets Acceptance Criteria
• Story accepted as complete by coach.

The table below summarizes key elements of each part of the framework:

The following sections elaborate these steps in more detail with some examples.

Step 1: Plan & Align

Establish Clear Transformation Goals & Priorities

The organization needs to be able to answer the why for change. What problems are being solved and what is the overarching outcome being sought? Leadership alignment on goals and priorities is an essential first step.

• What outcomes do we want from the transformation? What is the “value” of the transformation? This typically includes things like:
  • Improved Operational Performance: Delivery Cycle Times (Release in weeks vs. months), Predictability, Quality, Productivity.
  • Higher Customer Satisfaction: Superior customer experiences, improved customer growth & retention rates.
  • Better Employee Engagement: Higher levels of autonomy and growth opportunities. Improved retention rates.
  • Ability to pivot faster to avail of new opportunities.
• What changes or new capabilities are needed to enable these outcomes?
• What is the current state of the organization – major strengths and weaknesses.
• What problems do we need to solve?
• How will we measure progress?

For each target outcome, identify the enabling capabilities and practices needed. Also identify KPIs that will be used to measure progress. For example:

Enabling Practices should be prioritized on a Transformation Backlog. These items can be written in User Story format with acceptance criteria. Teams will implement these practices at their own pace and if an agile tool like Jira is used, it should be straightforward to measure progress.

Layout a Transformation Roadmap for the Organization

Not everything can be worked on at the same time. A roadmap communicates a strategy for how the overall transformation vision will be pursued via a series of intermediate goals. Its a great way to visualize the strategy. Strategy can be captured on a Transformation Roadmap as a sequence of objectives. (Outcomes, not Solutions).

• Objective: Reduced Development Cycle Times by 50%.
• Solution: Test Automation.

That is, “Test Automation” belongs on a delivery backlog, not on a transformation roadmap. A transformation roadmap communicates:

• The transformation strategy as a sequence of prioritized objectives.
• Opportunities for learning and adaptation as the transformation proceeds.

The timeframe horizon should cover at least the next 12 months, with objectives defined for each quarter. Roadmap ‘dates’ are simply guidance on priorities. They could also labelled as Now-Next-Later. A roadmap is a communication tool for visualizing strategy and helps keep stakeholders and transformation teams focused and aligned.

Roadmap items can be  captured as OKRs – a goal-setting framework for driving measurable results.

Each target outcome/objective on the roadmap can be captured as an OKR:

Objective: 10X Reduction in Delivery Cycle Times
Key Result 1: Average Pull Request reduced from 500 lines to 250 lines by end Q1
Key Result 2: Static Analysis tools (Lint) deployed in build pipeline by end Q1
Key Result 3: Build Regression Test automation coverage increased from 50% to 90%, Q

Objectives in the roadmap define “what” needs to achieved to support the vision. Product Teams supply solutions to achieve those objectives and add them to their Product Backlogs. Each team may need different solutions for individual transformation objectives. (A product marketing team will need a different solution to “reduce lead times” vs. a software development team). Thus each team’s backlog items may be unique. Backlog items represent specific actions to be taken to realize an objective – for example, adoption of specific practices and tools.

Each backlog item should be aligned with an objective in the Transformation Roadmap. Backlog items should be tied to business KPIs, and should have a measurable impact on an objective. The OKR goal-setting framework is an excellent way to approach this.

All Key Results should have owners.

Build the Transformation Backlog

Whereas the transformation roadmap is expressed in terms of business outcomes and major objectives to be achieved, the transformation backlog represents all of the specific actions needed to implement those objectives. We want to ensure a focus on outcomes rather than just process adoption, and that all proposed process/method/tool adoption are directly aligned with business objectives.

Step 2: Organize

Transformation Governance

A transformation Governance framework is needed to steer the transformation to a successful outcome.

1. Roles and Responsibilities

Of course everyone in the organization must contribute to the transformation, however we need a group of people dedicated to leading and sustaining the change. This team may referred to by names like: the Transformation Steering Team, Lean-Agile Center of Excellence (LACE), the Lean-Agile Transformation Team, or simple, the Agile Center of Excellence.

Leadership plays a critical role in any transformation. The leadership team not only owns the outcomes, they must play an active role as mentors, coaches, problem solvers, and must invest time and resources accordingly. To do this, they must understand what needs to be done and how to get it done.

 — W. Edwards Deming

 — W. Edwards Deming

There are many ways to organize a transformation, but generally speaking, we need 3 basic roles: business leadership/sponsorship, transformation governance, and transformation delivery teams. We will keep the role names as generic as possible.

• Executive Steering Committee:
  • • Generates organizational support
    • Participates in planning
    • Empowers teams
    • Removes barriers and impediments
    • Reports progress to the CEO/Leadership Team, highlighting issues and decisions for resolution.
    • Constant communication and encouragement to the broader organization on the vision, strategy and progress. (Shift “Have To” to “Want To”).
• Agile Transformation Office (ATO)
  • • Individuals within the organization who advocate for Agile Transformation.
    • Help teams understand and adopt Agile values, principles and methods.
    • Guides the organization through Agile adoption.
    • Provides coaching, training and mentorship to teams and leadership.
    • Ensures alignment between Agile practices and business objectives.
    • Identifies roadblocks and helps remove them.
    • Accepts Transformation Backlog items as meeting a Definition of Done
• Agile Delivery Teams
  • • Implements the Transformation Backlog (Agile practices).
    • Works closely with the ATO to implement change.

2. Governance Events and Cadences

Eating one’s own dog food in matters of governance signifies conviction in the basic pillars of agile delivery; small batches of work delivered in short time boxes, with feedback loops built in to support regular inspection and adaptation. All of which should operate at a sustainable pace to avoid overloading teams and creating excessive stress and fatigue.

Governance of the transformation process is required to ensure a consistent and systematic approach. This includes formalizing accountabilities to ensure that the right people are involved in the transformation process and that there is accountability for outcomes.  Progress can proceed empirically, based on a recurring set of events where evidence or data from recent changes is inspected and the next steps defined based on the results of those inspections. The events (reviews), evidence needed (data/artifacts), and accountabilities (roles) collectively represent a ‘governance model’.

Each event in the transformation governance framework is a formal opportunity to inspect and adapt transformation artifacts. These events are specifically designed to bring transparency to the state of transformation. Transparency enables inspection which in turns enables adaptation. Transformation governance events operate on a regular cadence to reduce overhead and complexity.

Transformation governance is provided via a series of events designed to support the following activities:

• Planning. For example plan in 90-day increments. Each increment will have a set of objectives (or OKRs) for what is to be accomplished. Inputs to each transformation increment are derived from the transformation roadmap and transformation backlog. If you are already doing some kind of ‘Quarterly Planning’, or ‘PI Planning’, ART Backlogs should contain transformation activities as deliverables for the next PI.
• Bi-Weekly/Monthly progress checkpoints. These events should be highly data driven – use Burn-Up/Burn-Down charts to help visualize the state of the backlog. Make adjustments to plans based on what is learned at each checkpoint.
  • Team Retrospectives. Teams check progress vs. any specific goals for their iteration.
  • Coach Syncs, facilitated by team coach. Review progress vs goals for current iteration/increment. Help with impediments.
  • Leadership Syncs, facilitated by ATO. Monthly progress check vs goals set for the transformation increment. Assist with impediments or issues escalated from the delivery teams.
• Inspect & Adapt Workshops. Review/Demo transformation objectives achieved at end of each transformation increment.

Here is an example of a transformation governance framework:

4. Measurement

It is critical to have a measurement system in place as early as possible. Build in metrics for success. Flying blind is not the situation we want to be in. At least not for long. Don’t be one of the many failed transformations simply because you are unable to demonstrate progress, or worse, are unable to see that you are heading in the wrong direction.

Having clear, outcome-based KPIs is essential. There must be solid integration with the transformation plan.

Ideally, we will have a transformation dashboard that will provide a transparent picture of the state of the transformation, and can be used to communicate progress to the organization, and also as a basis for making adaptations throughout the journey.

Getting a good measurement system in place is not a trivial task, and may require significant effort. It is advised to get this underway as early as possible.

Step 3: Plan & Execute

Each organizational unit undergoing transformation will likely operate as follows:

Planning. Identify objectives for the next 90-day increment and build the associated transformation activities into the Increment Backlog. Use a single backlog for improvement activities and normal operational deliverables, this way any effort or capacity needed for transformation work can be accounted for in the overall plan.

Execute: Teams, or teams-of-teams implement transformation initiatives, for example experimenting with various CI/CD practices and tools. The impact of these actions on transformation KPIs can be measured and tactics adapted as necessary.

Inspect and Adapt. At the conclusion of each increment assess the impact of transformation actions. If any initiative results in no measurable improvement, make sure you understand why, and make any necessary adjustments or adaptations to strategy. This may translate into new items for the backlog for the next increment.

Understanding Your Starting Point

Once you have decided the target outcomes for the transformation, you will next need to define how to measure progress. To do this, progress must be measurable. But first, an organization must understand the baseline state of anything it wants to improve. The table below provides an example of baseline values and targets for an organization that wants to improve its software delivery performance. (You might recognize these as the DORA Metrics from the book Accelerate, by Forsgren, Humble and Kim).

Other corporate functions such as marketing, supply chain, finance and HR must design similar plans specific to their operations. In large enterprises it is very likely that different parts of the organization will have differing baseline starting positions. Some teams may have grabbed the initiative much earlier and pushed ahead with implementation of practices like Scrum or Test Automation. Others may be operating with legacy methodologies and may have much more work to do in their transformation quest. Transformation plans will need to take these factors into account. Progress measurement will also need to account for starting baselines. Hence a first step is to understand the starting point for each unit of the transformation. This can be based on a simple assessment of current capabilities, practices and tools.

The results of these assessments can help set priorities for next steps, and can provide input to an Agile Maturity Model that can be used as the basis for measuring progress.

Step 4: Learn and Adapt

Don’t wait until you think you know everything about transformation before you start. Also, don’t copy and paste what has been done elsewhere, even if successfully – it it is unlikely to work in your own context. Agile transformation is a journey of experimenting and learning, and solving your own problems. Your organization, people, culture, challenges and opportunities are unique. Above all, learning should not be an ad hoc process. Learning must be built into the transformation framework at all levels via a built-in set of formal learning events.

Transformation means evolving an organization where people want to constantly improve. To do this we need to provide people with the skills and tools of improvement, and incentivizing them to apply these skills every day. Everyone in the organization must contribute to improvement. Everyone must be trained in improvement, and empowered to improve. This requires new patterns of thinking – a complete mindset change. An agile transformation must not be only about the tactical gains of adopting a set of tools and methods, but must primarily be about re-engineering the culture to where continuous improvement is a way of life. Tools and methods come and go. The goal must be to install a continuous improvement machine within the organization in which everyone plays a part.

Knowledge of agile values, principles and methods is a necessary but insufficient skillset to participate in any successful agile transformation.  Leadership and relationship skills are also necessary at all levels of the organization. The ability to make sound decisions, solve problems, resolve conflict, get buy-in and build consensus is  going to be instrumental in getting to a successful outcome.

Fundamental organizational transformation can be perceived as an existential threat to members of leadership teams, and middle management. All change is accompanied by conflict. Expect it. When we say “conflict” we simply mean different points of view about strategy, tactics, or how to solve various problems that emerge along your journey . Even when the organization is broadly aligned behind an overarching vision, conflict is still likely in areas of strategy and implementation tactics. However if we expect everyone to be a Change Agent, we also need to equip them with some basic skills for leading change, which means working continuously on alignment,  solving problems, resolving conflict, and influencing others.

Conclusions

Agile Transformation need not be a risky adventure through uncharted waters. This article provides a basic framework based on an incremental, iterative approach designed to minimize risks and ensure steady, measurable progress.