The most common misunderstanding about adopting agility, or any new way of working, is the belief that it can be adapted to the environment already “here.” The point of adopting a new technique is to get different results, which means changing “here” into “there.” People resist change, so they prefer to believe there is something you can add to “here” that lets it stay “here,” but perform like “there.”
People often say, “Agility means we are flexible and can adapt the framework to the way we already work.”
That is not what agility means. Agility means the organization becomes flexible because it has fast feedback loops created by short cycle times. Short cycles enable rapid learning, which supports faster decision making and changes in direction. Agility is maneuverability. No framework improves performance if you skip the practices that challenge how you work today.
There is no enforcement mechanism for every rule in Scrum or the Kanban guides. Before dismissing careful adherence as “agile purism,” recognize that these practices are intended to create specific system effects. Those effects enable early and continuous delivery of valuable software and improve customer satisfaction.
Those system effects include:
- Cadence
- Constrained work-in-process (WIP)
- Reduced utilization
- Short cycle time
- Short planning horizons
- Small batch work
- Decentralization
- Job sequencing
- Transparency
These are the things that lead to the ability to run fast feedback loops, from which you learn and adjust sprint to sprint, week to week, or day to day. This is where agility comes from.
People want to believe that by adding ceremonies, creating a backlog, and using Jira they will get results. What results are they expecting? The more useful question is, “How will we measure whether we have become more agile?”
Start here:
- What is your typical time to market from idea to feedback? Is it days, weeks, months, half a year, or longer?
- How frequently can you deploy or release? Hourly, daily, quarterly?
- What business value measures were defined for recent work? Did those measures show that the product improved?
Often, the answer to those questions is, “I do not know.” That tells you where to start. Establish a system for gathering flow and outcome metrics. Then observe whether they change. If the measures do not change meaningfully, the system did not change meaningfully.
When people say, “That did not work here,” what I often hear is, “We reshaped the airplane until it looked like the bicycle we already had, and then it did not fly.”
The principles that make agility work are universal; they are not unique to local concerns. The specific practices you use to implement them may vary, but you must do something that enacts the principle or nothing changes. Selecting only the parts of a framework that feel comfortable and discarding the parts that challenge existing behavior is often the opposite of what improvement requires.
Organizations must abandon the belief that agility can be achieved by adapting a framework to fit current ways of working. Different results require different behavior. Rather than asking how the framework can fit the present environment, leaders should ask what must change in the environment to produce different results.
Last updated 2026-02-21