Behavioral Lag: When Practices Change But Patterns Don't

Last week I introduced three patterns that signal agile transformations have plateaued: Behavioral Lag, Value Lag, and Momentum Lag. This week focuses on the first—the gap between adopted practices and unchanged behaviors that undermines transformation progress.

Behavioral lag emerges in Kotter’s stages 7 and 8 of organizational change (1) Stage 7 focuses on consolidating gains and producing more change. Stage 8 addresses anchoring new approaches in culture. organisations successfully adopt new practices—teams restructure, ceremonies get implemented, tools get deployed. Then, under pressure, everyone reverts to behaviors that feel natural regardless of what they’ve adopted intellectually.

This reversion doesn’t always come from explicit resistance, though resistance certainly exists. More commonly, it emerges from adherence to old habits—patterns that worked successfully for years and have become organisational muscle memory. When stress increases, people reach for what’s familiar. The question “how long will this take?” The response pattern of providing a date even when the new way of working makes that date meaningless. These behaviors persist not because people reject agile principles, but because under pressure, familiar patterns feel safer than newly learned ones.

A financial services company I worked with demonstrates this pattern. Their development organization had adopted agile practices years earlier—sprints, retrospectives, velocity tracking, proper implementation of the Scrum ceremonies. The business organization continued operating on quarterly planning cycles, coordinating across multiple functions as they’d done for decades.

Under pressure, both organisations reverted to old patterns. Business asked “how long will this take?” because that’s the question that had always enabled their planning. Development accommodated by attempting to answer, translating their velocity metrics into Plans and dates. Even though their new way of working made those predictions unreliable (more so than they were years ago). Neither side paused to acknowledge that the question, in the form being asked, no longer matched how development actually operated.

Both perspectives held validity from their vantage point. Business genuinely needed coordination mechanisms for quarterly planning across marketing, sales, customer success, and operations. Development genuinely needed to plan their work using velocity and capacity, which better reflected the uncertainty inherent in software development. The behavioral lag existed not in either side being wrong, but in communication patterns that hadn’t evolved alongside development’s new practices.

Development had learned new practices but maintained old communication habits — accommodating questions that their new system couldn’t answer accurately, rather than explaining why the question itself needed reframing. Business had never learned the new language that would work with development’s evolved approach. The gap between them persisted because no one facilitated the evolution of how these organisations talked to each other.

The visible symptom appeared as quality issues. Development absorbed the pressure created by this communication gap. When asked for dates, they provided them. When dates proved optimistic, scope pressure overrode sustainable pace. Testing got compressed, refactoring got deferred, technical debt accumulated. The quarterly plan demanded completion, and completion happened, but at costs that surfaced months later as bugs, instability, and reduced delivery capacity.

This is squaring circles—forcing incompatible systems into alignment through pressure rather than acknowledging they measure different things and building explicit translation between them. Development tracked throughput and capacity. Business needed coordination points and timeline visibility. Without translation mechanisms, someone had to absorb the incompatibility. That someone was the development teams, and what they absorbed was quality and sustainability.

The right kind of external help understands this isn’t about one side needing to change. It’s about communication patterns that serve neither side well. In that example, I worked with the development organization to build a data source that could answer duration questions objectively. Using historical delivery data, and with enough data, story points and duration tend to correlate. Because software is inherently intangible, uncertainty was a part of hte model and both organisations learned to work with uncertainty.

As suchy, I worked with the business organization to build scope flexibility into quarterly planning through MoSCoW prioritization. Epics got categorized as Must Have, Should Have, Could Have, Wish to Have This Quarter. This built explicit scope buffer into plans, acknowledging that development’s actual velocity would vary and that variation needed accommodation.

The intervention was contextual—shaped by this organization’s specific constraints, existing systems, cultural patterns, and where leverage existed to make changes. Different organisations with different constraints will need different interventions. The pattern, however, appears consistently: behavioral lag emerges when communication/culture doesn’t evolve alongside practices, and closing that lag requires facilitating new patterns of interaction that match new ways of working.

Behavioral lag persists because the behaviors themselves aren’t inherently wrong. They’re patterns that worked successfully in previous contexts. “How long?” is a reasonable question for coordination. Providing an answer is a reasonable response to leadership requests. The lag exists because these patterns no longer match current reality, yet under pressure, everyone reverts to them.

New practices don’t automatically create new instincts. 

organisations need enough successful experiences with new approaches that those approaches start feeling natural, and systems designed to make new behaviors easier than old ones even under stress. Without that anchoring work—Kotter’s Stage 8—transformations stall exactly where this financial services company had stalled: practices implemented, behaviors unchanged, communication patterns frozen in the past.

Closing behavioral lag requires diagnostic capability that recognizes when communication hasn’t evolved alongside practices. That diagnostic work benefits from external perspective—someone positioned outside the dynamics that keep both sides repeating familiar patterns, with experience recognizing these mismatches across contexts, and ability to facilitate new communication without either side feeling blamed for the gap.

Next week addresses Value Lag—what happens when organizational focus shifts from delivering business outcomes to conforming to process, gradually disconnecting agile practices from the business value that justified their adoption. The week after explores Momentum Lag and why early transformation wins don’t automatically compound into sustained capability.


While understanding behavioral lag conceptually is straightforward, diagnosing where communication patterns haven’t evolved alongside practices requires examining your system from outside it. That’s where evidence-based coaching accelerates progress—identifying where old behaviors persist despite new practices and facilitating communication evolution that serves current reality. Explore how to diagnose behavioral patterns blocking your agile ROI. Reach out today to examine which communication patterns in your organization need evolution to match your transformed practices.


Discover more from The Software Coach

Subscribe to get the latest posts sent to your email.

Leave a Comment

Your email address will not be published. Required fields are marked *