Agile & Transformation Glossary
76 terms defined by practitioners who've completed 100+ enterprise transformations. No textbook definitions. Real-world context from the Organization, System, and Team levels.
Frameworks & Methodologies
Scrum
A lightweight framework for managing complex work in short cycles called sprints (typically two weeks). Scrum defines three roles (Scrum Master, Product Owner, Developers), five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Retrospective), and three artifacts (Product Backlog, Sprint Backlog, Increment). It works well at the team level, but most organizations discover that Scrum alone doesn't address the system-level and organizational-level changes needed for enterprise transformation.
CSM CourseKanban
A method for managing work by visualizing the flow of items through a process, limiting work in progress, and measuring flow metrics like cycle time and throughput. Unlike Scrum, Kanban doesn't prescribe roles or time-boxed iterations. It's particularly useful for teams with unpredictable incoming work (support, operations, maintenance) or teams transitioning away from traditional project management. Kanban and Scrum are not mutually exclusive; many teams use elements of both.
Kanban TrainingSAFe (Scaled Agile Framework)
A framework for applying agile and lean practices at enterprise scale. SAFe organizes teams into Agile Release Trains (ARTs), synchronizes planning through Program Increment (PI) Planning events, and addresses portfolio-level concerns like lean budgeting and value stream coordination. It provides structure that many large organizations need, but implementing SAFe without addressing organizational change management is one of the most common reasons enterprise transformations stall.
Leading SAFe CourseLeSS (Large-Scale Scrum)
A scaling framework that applies Scrum principles to multiple teams working on a single product. LeSS keeps things minimal: one Product Owner, one Product Backlog, one Sprint, and a shared Definition of Done across all teams. Where SAFe adds structure and roles, LeSS adds rules for simplification. The tradeoff is that LeSS requires more organizational maturity and a willingness to restructure around products rather than projects.
Extreme Programming (XP)
A software development methodology emphasizing technical excellence through practices like test-driven development, pair programming, continuous integration, and frequent releases. XP is where many of the engineering practices that make agile delivery sustainable actually come from. Organizations that adopt Scrum or SAFe without XP's technical discipline often find that their teams can plan and review work, but the code itself doesn't get better.
Lean Software Development
An adaptation of lean manufacturing principles to software development, organized around seven principles: eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and optimize the whole. Lean thinking underpins most agile scaling frameworks, particularly SAFe's approach to portfolio management and value stream optimization.
Design Sprint
A five-day structured process for rapidly prototyping and testing ideas with real users. Originally developed at Google Ventures, design sprints compress months of debate into a week of focused work: map the problem, sketch solutions, decide on one, build a prototype, and test it with customers. Useful when an organization needs to validate a direction before committing engineering resources.
DevOps
A set of practices that integrates software development and IT operations to shorten the delivery lifecycle and provide continuous delivery of high-quality software. DevOps is about removing the wall between "the people who build it" and "the people who run it." In practice, this means automated testing, continuous integration, infrastructure as code, and monitoring. Without DevOps practices, agile teams can plan and build faster but still wait weeks for deployment.
SAFe DevOps CourseAgile Manifesto
The foundational document of the agile movement, written in 2001 by seventeen software practitioners. It defines four values (individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan) and twelve supporting principles. The manifesto remains relevant, but enterprise transformation requires going beyond these team-level values to address organizational structure, governance, and change management.
Scrum Alliance
A nonprofit membership organization that promotes the adoption and effective practice of Scrum. Scrum Alliance offers a certification path from Certified ScrumMaster (CSM) through Advanced CSM (A-CSM) to Certified Scrum Professional (CSP) and Certified Enterprise Coach (CEC). Agile Velocity is a Scrum Alliance education partner and offers CSM, CSPO, A-CSM, and A-CSPO courses.
View Scrum CoursesScaled Agile, Inc.
The organization behind the Scaled Agile Framework (SAFe). Scaled Agile provides training, certification, and tooling for enterprises implementing SAFe. Their certification path includes SAFe Agilist (SA), SAFe Practitioner (SP), SAFe Scrum Master (SSM), SAFe RTE, and SAFe Practice Consultant (SPC). Agile Velocity is a SAFe partner offering the full range of SAFe certification courses.
View SAFe CoursesPath to Agility Framework
Path to Agility
An outcome-driven continuous improvement framework developed by Agile Velocity. Unlike traditional agile approaches that start with practices and hope for results, Path to Agility starts with 9 measurable Business Outcomes and works backward to select only the practices that will move those specific outcomes. The framework organizes 9 Business Outcomes, 26 Agile Outcomes, 100 Capabilities, and 400+ Practices across three organizational levels (Organization, System, Team) and five stages of maturity (Align, Learn, Predict, Accelerate, Adapt).
Explore the FrameworkBusiness Outcomes (Path to Agility)
The nine measurable results that every enterprise transformation should produce: Speed, Quality, Predictability, Employee Engagement, Customer Satisfaction, Innovation, Market Responsiveness, Productivity, and Continuous Improvement. In Path to Agility, these outcomes drive every decision. Rather than asking "are we doing agile correctly?" the question becomes "are the business outcomes improving?" This distinction is why outcome-driven frameworks succeed where practice-driven ones stall.
See the 9 Business OutcomesAgile Outcomes
The 26 intermediate improvements that connect day-to-day agile practices to business results. Each Agile Outcome maps upward to one or more Business Outcomes and downward to specific Capabilities. For example, "Predictable Delivery Cadence" is an Agile Outcome that drives the Business Outcome of Predictability. Agile Outcomes give teams and leaders a clear line of sight between what they're doing and why it matters.
Framework DetailsCapabilities (Path to Agility)
The 100 skills, behaviors, and structural elements that organizations need to achieve their target outcomes. Capabilities are assessed at three levels: Organization (40 capabilities covering leadership, governance, and change management), System (26 capabilities covering cross-team coordination), and Team (34 capabilities covering delivery practices). Assessing capabilities reveals specific gaps, which is far more actionable than a generic maturity score.
Framework DetailsPractices (Path to Agility)
The 400+ specific actions and techniques that build capabilities. Practices are the "how." The critical insight is that not every practice is right for every organization. Path to Agility selects practices based on which capabilities are weakest and which outcomes need the most improvement, rather than implementing a standard playbook.
Five Stages (Align, Learn, Predict, Accelerate, Adapt)
The maturity progression in Path to Agility. Align: connect the improvement initiative to measurable business outcomes. Learn: establish foundational practices and a culture of learning. Predict: achieve a sustainable, predictable cadence of delivery. Accelerate: optimize the value delivery system and reduce time-to-market. Adapt: embrace organization-wide agility and respond quickly to market changes. Most stalled transformations are stuck between Learn and Predict because they addressed team practices without changing organizational structure.
See the 5 StagesThree Levels (Organization, System, Team)
Path to Agility operates across three organizational levels simultaneously. Team: individual team practices, roles, and delivery cadence. System: how collections of teams coordinate, manage dependencies, and deliver value together. Organization: leadership alignment, governance, funding models, and operating model design. Most transformations fail because they only address the Team level. The Organization level is where transformations succeed or fail, and it's where most agile consultancies don't go.
See the 3 LevelsChange Management
Organizational Change Management (OCM)
The discipline of preparing, supporting, and helping individuals and organizations through change. Traditional OCM runs alongside the work as a separate communications and training track. The problem is that approach treats change as a messaging challenge rather than a structural one. Effective OCM is embedded into the operating model itself, so structural change (governance, funding, team design) and behavioral change (adoption, resistance, culture) happen together rather than in parallel tracks that never integrate.
Our OCM ApproachEmbedded Change Management
An approach where change management is built into the transformation work itself rather than run as a parallel workstream. Instead of a separate change team sending emails about the transformation, change practitioners work alongside delivery teams and leaders to address resistance in real time, adjust governance as new practices take hold, and track adoption through the same tools used to track delivery. This is how Agile Velocity integrates OCM into every engagement.
How We Embed OCMADKAR Model
A change management model developed by Prosci that focuses on individual change adoption through five sequential stages: Awareness (of the need for change), Desire (to participate), Knowledge (of how to change), Ability (to implement the change), and Reinforcement (to sustain it). ADKAR is effective at the individual level but doesn't address organizational structure, governance, or cross-team coordination. Path to Agility picks up where ADKAR leaves off, connecting individual adoption to organizational capabilities and measurable business outcomes.
P2A vs ADKAR ComparisonKotter's 8-Step Change Model
A change management framework developed by John Kotter that progresses through eight stages: create urgency, build a guiding coalition, form a strategic vision, enlist a volunteer army, enable action by removing barriers, generate short-term wins, sustain acceleration, and institute change. Kotter's model is strong on mobilization and momentum but doesn't prescribe how to measure outcomes or connect change efforts to specific business results.
Satir Change Model (J-Curve)
A model of how individuals and systems experience change, developed by family therapist Virginia Satir. The model shows that after leaving the Status Quo, performance dips through a period of Chaos and Resistance before eventually rising through Integration and Practice to a New Status Quo at a higher level. This "J-Curve" is central to Path to Agility's philosophy: the performance dip is normal and expected, not a sign of failure. Organizations that understand the J-Curve set realistic expectations instead of abandoning the transformation at the first sign of turbulence.
See the J-CurveChange Readiness
An organization's capacity to absorb and sustain change. Change readiness is not binary; it varies across departments, leadership levels, and teams. Assessing change readiness surfaces hidden barriers before they derail the transformation: Is leadership aligned? Do middle managers understand their new role? Are teams burnt out from the last failed initiative? The Organizational Health Check measures change readiness as part of its diagnostic.
Take the Health CheckResistance Management
The practice of identifying, understanding, and addressing pushback against organizational change. Resistance is not a character flaw. It's usually a rational response to unclear expectations, past failures, or poorly designed change. Effective resistance management diagnoses the root cause (is it fear, fatigue, structural misalignment, or lack of trust?) and addresses it directly rather than treating all resistance as a communications problem.
Change Fatigue
The exhaustion and disengagement that occurs when people experience too much change, too frequently, with too few results. Gartner found that 73% of employees affected by change experience moderate to high stress, and their performance drops significantly. Change fatigue is often the legacy of previous failed or half-finished transformation initiatives, making each subsequent attempt harder to get buy-in for.
Solving Change FatigueThe Frozen Middle
The phenomenon where middle management becomes the primary bottleneck in organizational transformation. Executives sponsor the change and teams want to adopt it, but directors and managers in between resist because their incentives, metrics, and authority structures haven't changed. The frozen middle is one of the most common reasons transformations stall, and it can only be addressed by redesigning governance and management expectations, not by more training or messaging.
Breaking ThroughChange Adoption
The measurable degree to which individuals and teams actually use new practices, processes, or tools in their daily work. Adoption is different from awareness or training completion. Someone can attend a two-day Scrum workshop and still run waterfall projects on Monday. Measuring adoption means tracking whether behaviors actually changed: Are teams running real retrospectives? Are leaders making decisions differently? Are governance checkpoints outcome-based instead of milestone-based?
Operating Model & Organizational Design
Operating Model
The combination of organizational structure, governance, funding mechanisms, decision-making processes, and team design that determines how an organization creates and delivers value. When a transformation stalls, the operating model is almost always part of the reason. You can train teams on agile practices, but if the operating model still requires annual budgeting, committee-based governance, and functional silos, the practices won't stick.
Operating Model TransformationGovernance
The structures, policies, and processes through which an organization makes decisions and allocates resources. In traditional organizations, governance means stage gates, steering committees, and approval chains. In agile organizations, governance shifts to outcome-based checkpoints, delegated decision-making, and rapid feedback loops. Governance redesign is one of the most impactful and most frequently skipped elements of enterprise transformation.
Lean Budgeting
A funding approach that allocates budgets to value streams or persistent teams rather than to individual projects. Instead of requesting funding for "Project X" and tracking it to completion, lean budgeting provides guardrails for ongoing investment in a product or capability area. Teams then prioritize work within those guardrails based on value, not on what was promised in a business case twelve months ago.
Value Stream
The sequence of activities required to deliver a product or service from concept to customer. Mapping value streams reveals where work flows, where it stalls, and where handoffs create delay. Most enterprise organizations are organized by function (engineering, QA, operations) rather than by value stream, which creates the silos and handoff problems that slow delivery. Reorganizing around value streams is a key element of operating model transformation.
Solving Silo ProblemsCross-Functional Team
A team composed of all the skills needed to deliver a complete increment of value without depending on people outside the team. This typically means developers, testers, designers, and sometimes product and operations people on the same team. Cross-functional teams reduce handoffs, speed up decision-making, and increase ownership. The challenge is that most organizations are structured around functional specialties, so creating cross-functional teams requires organizational redesign, not just a new seating chart.
Team Topologies
A model for organizational design that defines four fundamental team types: Stream-aligned (delivering value directly to customers), Enabling (helping other teams adopt new capabilities), Complicated Subsystem (managing technically complex areas), and Platform (providing internal services that reduce cognitive load). Team Topologies provides a vocabulary for intentional organizational design rather than the ad hoc team structures that most enterprises evolve into over time.
Organizational Design
The deliberate structuring of roles, teams, reporting lines, and decision rights to achieve strategic objectives. In the context of transformation, organizational design means restructuring around value delivery rather than functional hierarchy. This includes defining team boundaries, establishing coordination mechanisms, clarifying decision authority, and aligning incentives. Organizational design is not a one-time event; it evolves as the organization matures.
Capability Assessment
A structured evaluation of an organization's current skills, behaviors, and structural elements against a defined maturity model. In Path to Agility, teams assess themselves against 100 capabilities across Organization, System, and Team levels. The results surface specific gaps rather than generic maturity scores, which means improvement actions are targeted rather than broad. Regular reassessment tracks whether interventions are actually working.
Assessment PlatformRoles
Scrum Master
A servant leader responsible for helping a Scrum team follow the Scrum framework effectively. The Scrum Master facilitates events, removes impediments, coaches the team on self-management, and helps the broader organization understand how to interact with agile teams. A common anti-pattern is treating the Scrum Master as a project manager or status reporter, which misses the point of the role entirely.
CSM CertificationProduct Owner
The person responsible for maximizing the value delivered by a Scrum team by managing the Product Backlog. The Product Owner decides what gets built and in what order based on business value, stakeholder input, and market feedback. One of the most common failure patterns is a Product Owner who doesn't have the authority to make prioritization decisions, turning the role into a proxy for a committee.
CSPO CertificationRelease Train Engineer (RTE)
A servant leader and coach for an Agile Release Train (ART) in SAFe. The RTE facilitates ART-level events (PI Planning, System Demos, Inspect and Adapt), manages risks and dependencies across teams, and works to improve the flow of value through the train. Think of the RTE as a Scrum Master operating at the system level rather than the team level.
RTE CertificationAgile Coach
A practitioner who helps organizations adopt and improve agile ways of working. The role spans teaching (training teams on practices), mentoring (guiding individuals through challenges), facilitating (running workshops and events), and consulting (advising leadership on strategy and organizational design). At the enterprise level, an agile coach works across all three organizational levels, not just with individual teams.
Agile Leadership Team (ALT)
A cross-functional group of senior leaders who govern and guide an agile transformation. The ALT sets the strategic direction, removes organizational impediments, allocates investment, and models the behaviors they expect from the rest of the organization. Without an engaged ALT, transformations lose executive sponsorship and decision-making slows to a crawl.
Ceremonies & Events
Sprint (Iteration)
A time-boxed period (typically one to four weeks, most commonly two weeks) during which a Scrum team creates a usable increment of product. The sprint provides a rhythm for planning, building, reviewing, and improving. Consistent sprint cadence is a foundational capability because it creates predictability, which is one of the nine Business Outcomes organizations need most.
Sprint Planning
A collaborative event at the start of each sprint where the team selects work from the Product Backlog and creates a plan for delivering it. Effective sprint planning produces a clear Sprint Goal and a shared understanding of what "done" looks like. When sprint planning feels like a checkbox exercise, it usually means the Product Backlog isn't well-refined or the team doesn't trust the priorities.
Daily Standup (Daily Scrum)
A brief daily meeting (15 minutes or less) where the team synchronizes on progress and identifies blockers. The standup is for the team, not for management reporting. A telltale sign of a superficial transformation is standups that feel like status updates to a manager rather than conversations between teammates solving problems together.
Sprint Review
An event at the end of each sprint where the team demonstrates completed work to stakeholders and collects feedback. The sprint review is not a presentation; it's a working session where stakeholders see real, functioning product and provide input that shapes the next sprint's priorities. Skipping or formalizing sprint reviews into slide presentations is a sign that the feedback loop has broken down.
Retrospective
A recurring event where the team reflects on how they worked during the previous sprint and identifies specific improvements to try next. Retrospectives are the engine of continuous improvement. When teams say "retros don't produce anything," it usually means the team lacks the authority or organizational support to act on what they identify. This is a system-level problem, not a team-level one.
Continuous ImprovementPI Planning (Program Increment Planning)
A large-scale planning event in SAFe where all teams on an Agile Release Train come together for two days to align on objectives, identify dependencies, and commit to a plan for the next Program Increment (typically 8-12 weeks). PI Planning is the heartbeat of an ART. It replaces months of sequential planning with a single face-to-face event that surfaces risks and dependencies before they become blockers.
SAFe for TeamsBacklog Refinement
The ongoing activity of reviewing, clarifying, and preparing items in the Product Backlog so they're ready for sprint planning. Refinement includes breaking large items into smaller ones, adding acceptance criteria, estimating effort, and reordering based on new information. Teams that skip refinement spend their sprint planning meetings doing discovery instead of planning, which slows everything down.
Metrics & Measurement
Velocity
The amount of work a Scrum team completes in a sprint, typically measured in story points. Velocity is a planning tool for the team, not a performance metric for management. Using velocity to compare teams or pressure them into "going faster" is a well-documented anti-pattern that degrades both morale and output quality. Healthy velocity is stable and predictable, not constantly increasing.
Cycle Time
The elapsed time from when work begins on an item to when it's delivered. Cycle time is one of the most honest metrics in agile delivery because it measures what the customer experiences: how long it takes from "we started working on your request" to "it's in your hands." Reducing cycle time is a direct driver of the Speed business outcome.
Speed OutcomeLead Time
The total elapsed time from when a request is made to when it's delivered to the customer. Lead time includes waiting time in the backlog before work even starts, which makes it broader than cycle time. A large gap between lead time and cycle time tells you that the bottleneck isn't in how fast teams work, but in how long items wait before being picked up.
Throughput
The number of work items completed per unit of time. Throughput is a flow metric that's often more useful than velocity because it counts actual delivered items rather than estimated points. Consistent throughput is a signal of predictable delivery. Erratic throughput usually points to too much work in progress, unclear priorities, or frequent context switching.
Predictability OutcomeWork in Progress (WIP)
The number of work items currently being actively worked on. Limiting WIP is one of the most effective and counterintuitive practices in agile: doing less at once results in getting more done overall. High WIP causes context switching, increases cycle time, reduces quality, and makes everything less predictable. Most organizations dramatically underestimate how much WIP is hurting them.
Solving Prioritization ChaosStory Points
A unit of estimation that represents the relative effort, complexity, and uncertainty of a work item. Story points are deliberately abstract: a 5-point story isn't "5 days of work," it's "roughly twice as complex as a 2-point story." This relative sizing helps teams plan sprints without the false precision of hour-based estimates. Teams that get bogged down debating exact point values are missing the point.
WSJF (Weighted Shortest Job First)
A prioritization method used in SAFe that calculates the cost of delay divided by job size. Items with high value, high urgency, and small size get prioritized first. WSJF provides a data-driven way to sequence work that replaces the loudest-voice-wins approach to prioritization that most organizations default to.
Cumulative Flow Diagram
A visual chart that shows the quantity of work items in each stage of your process over time. The bands represent different states (to do, in progress, done), and the width of each band reveals where work accumulates. A widening "in progress" band means WIP is growing. A narrowing "done" band means throughput is declining. It's one of the best tools for diagnosing flow problems at a glance.
Scaling Concepts
Agile Release Train (ART)
A long-lived team of agile teams (typically 50-125 people) that plans, commits, and delivers together in a synchronized cadence. The ART is the primary value delivery vehicle in SAFe. It includes all the roles and capabilities needed to define, build, test, and deploy value. Launching an ART is often the first structural change in a SAFe implementation, and it requires significant organizational redesign around value streams rather than functional departments.
Program Increment (PI)
A time-boxed planning and delivery period in SAFe, typically 8-12 weeks (usually four development sprints plus one innovation and planning sprint). The PI provides a cadence for planning, integration, and reflection at the ART level. It's the unit of commitment that allows leadership to make reliable plans while teams retain sprint-level flexibility.
Lean Portfolio Management (LPM)
A set of practices for aligning strategy with execution at the portfolio level. LPM replaces traditional project portfolio management (annual planning, project-based funding, stage-gate governance) with lean budgets, strategic themes, portfolio Kanban, and outcome-based metrics. LPM is where the Organization level of Path to Agility intersects with SAFe's scaling model.
LPM CourseCommunities of Practice (CoP)
Groups of practitioners who share a common discipline or interest and meet regularly to learn from each other, share best practices, and develop standards. In a scaled agile environment, CoPs for Scrum Masters, Product Owners, architects, or testers help maintain consistency across teams without imposing top-down standards. They're a lightweight alternative to centralized centers of excellence.
Dependency Management
The practice of identifying, visualizing, and resolving cross-team dependencies that block the flow of value. Dependencies are the primary reason scaled agile organizations can't deliver as fast as individual teams promise. The goal isn't just to manage dependencies but to systematically reduce them through architectural decisions, team restructuring, and organizational design. PI Planning is one of the primary mechanisms for surfacing dependencies early.
Solving Dependency HellValue Stream Mapping
A lean technique for visualizing the end-to-end flow of work from request to delivery, including both value-adding activities and waste (waiting, handoffs, rework). Value stream maps reveal the truth about how long things actually take and where the real bottlenecks are. Most organizations are surprised to discover that 80%+ of their lead time is waiting, not working.
Culture & Team Health
Psychological Safety
The belief that you won't be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. Google's Project Aristotle identified psychological safety as the single most important factor in team effectiveness. Without it, retrospectives are silent, problems stay hidden, and innovation dies. Building psychological safety requires consistent behavior from leaders over time, not a single workshop.
Continuous Improvement
The ongoing practice of making small, incremental improvements to processes, products, and ways of working. In Path to Agility, Continuous Improvement is one of the 9 Business Outcomes because organizations that stop improving start declining. The key is that improvement must be systematic (with regular retrospectives, data collection, and experimentation) rather than ad hoc.
Continuous Improvement OutcomeServant Leadership
A leadership philosophy where the leader's primary role is to serve the people they lead by removing obstacles, providing resources, and creating an environment where teams can do their best work. Servant leadership is foundational to agile, but it requires more than a mindset shift. It requires changing incentive structures, meeting formats, and decision-making authority so leaders are evaluated on team outcomes rather than individual control.
Employee Engagement
The degree to which employees are emotionally invested in and committed to their work and organization. Gallup research shows that only 33% of employees are engaged at work, and disengaged employees cost organizations in productivity, turnover, and quality. In Path to Agility, Employee Engagement is a Business Outcome because engaged teams consistently outperform disengaged ones on every other metric.
Employee Engagement OutcomeTechnical Debt
The accumulated cost of shortcuts, workarounds, and deferred maintenance in a codebase or system. Like financial debt, technical debt accrues interest: the longer it's left unaddressed, the more it slows down future development. Teams spending more time fixing defects than building new capabilities is a sign of unmanaged technical debt. Addressing it requires dedicated capacity, not just awareness.
Definition of Done
A shared checklist of quality criteria that every increment of work must meet before it's considered complete. A strong Definition of Done includes coding standards, testing requirements, documentation, and deployment readiness. When the Definition of Done is weak or inconsistent across teams, "done" means something different to everyone, and quality becomes unpredictable.
Delivery & Execution
Agile Transformation
The process of shifting an organization's structure, culture, and practices to enable agile ways of working at scale. The term is broad, which is part of the problem: it means different things to different people. For some it means training teams on Scrum. For others it means redesigning the entire operating model. 70% of agile transformations fail because they focus on team-level practice adoption without addressing the organizational structure, governance, and change management that determine whether new practices stick.
Stalled TransformationsDigital Transformation
The integration of digital technology into all areas of a business, fundamentally changing how the organization operates and delivers value to customers. Digital transformation is often conflated with agile transformation, but they're different. You can adopt new technology without changing how you work, and you can change how you work without new technology. The most effective transformations address both, but clarity on which type you're pursuing determines what success looks like.
Types of TransformationWaterfall
A sequential development methodology where work flows through distinct phases (requirements, design, development, testing, deployment) in a linear progression. Each phase must be completed before the next begins. Waterfall works well when requirements are stable and well-understood, but it struggles with complexity, changing requirements, and the need for rapid feedback. Many organizations that say they've "gone agile" are actually running waterfall with agile terminology.
Product Backlog
An ordered list of everything that might be needed in a product, maintained by the Product Owner. The backlog is a living document: items are continuously added, refined, reprioritized, and removed based on new information. A healthy backlog has well-refined items at the top (ready for the next sprint), progressively less detailed items further down, and no items older than a few months that nobody's looked at.
User Story
A short description of a feature or requirement written from the perspective of the person who will use it, typically in the format "As a [type of user], I want [some goal] so that [some reason]." User stories are intentionally brief. The detail comes from conversation between the team and the Product Owner, not from the written description. A common anti-pattern is treating user stories as mini requirements documents.
Minimum Viable Product (MVP)
The smallest version of a product that can be released to test a hypothesis or deliver value to early users. The purpose of an MVP is learning, not launching. Organizations frequently misuse the term to mean "phase 1 of a fully planned product," which defeats the purpose. A real MVP is designed to answer a specific question: Will customers use this? Does this approach solve the problem?
Continuous Delivery
A practice where code changes are automatically built, tested, and prepared for release to production at any time. Continuous delivery doesn't mean you deploy every change immediately; it means you could if you wanted to. This requires automated testing, continuous integration, and deployment pipelines. Organizations practicing continuous delivery can release on demand rather than on a schedule, which directly improves Speed and Market Responsiveness.
Frequently Asked Questions
What is the difference between agile transformation and digital transformation?
Digital transformation focuses on integrating new technology into business operations. Agile transformation focuses on changing how an organization works: its structure, processes, culture, and delivery practices. You can do one without the other, but the most effective transformations address both. The key distinction matters because it determines what success looks like and what needs to change.
What is the difference between Scrum, SAFe, and Kanban?
Scrum is a team-level framework with defined roles, events, and artifacts for delivering work in sprints. Kanban is a flow-based method focused on visualizing work, limiting work in progress, and optimizing cycle time. SAFe (Scaled Agile Framework) coordinates multiple agile teams at enterprise scale using constructs like Agile Release Trains and PI Planning. Many organizations use elements of all three.
What does OCM mean in the context of agile transformation?
OCM stands for Organizational Change Management. In agile transformation, OCM addresses the people side of change: preparing leaders and teams for new ways of working, managing resistance, building coalitions, and ensuring that structural changes (governance, funding, team design) and behavioral changes (adoption, culture) happen together rather than in separate tracks.
What is the Path to Agility framework?
Path to Agility is an outcome-driven continuous improvement framework developed by Agile Velocity. It starts with 9 measurable Business Outcomes and works backward to select only the practices that will achieve those outcomes. The framework includes 9 Business Outcomes, 26 Agile Outcomes, 100 Capabilities, and 400+ Practices organized across three levels (Organization, System, Team) and five stages (Align, Learn, Predict, Accelerate, Adapt).
Not Sure Where to Start?
Take our free Organizational Health Check. 18 questions, 4 minutes, and you'll know exactly where your organization stands across the 9 Business Outcomes.