Agile transformed how software teams build products. It replaced rigid planning with adaptability, empowered developers with autonomy, and shortened feedback loops between idea and release.
But for many engineering organizations, Agile has quietly plateaued.
CTO at DeskTime
Sprints are running. Ceremonies are happening. Teams are “busy.”
Yet delivery remains unpredictable, estimates drift, and burnout appears without warning.
The missing ingredient? Evidence.
“As a CTO, I see this pattern constantly,” says Jānis Akmentiņš, CTO at DeskTime. “Teams are doing everything ‘by the book,’ but leadership still can’t explain why outcomes vary so much from sprint to sprint. That’s usually a sign that decisions are being made without enough factual input.”
As development becomes more distributed and work increasingly invisible, Agile teams need more than rituals and retrospectives. They need a factual understanding of how work actually happens. This is where development is shifting from Agile alone to data-informed development.
Why Agile teams struggle to see reality
Agile assumes transparency. Stand-ups, boards, and retrospectives are meant to surface progress and blockers. But in modern development environments, much of the real work (and friction) happens between those touchpoints.
Developers context-switch across IDEs, browsers, chat tools, ticketing systems, and meetings. Focus is fragmented, time leaks into unplanned work, and none of this is visible in Jira tickets or sprint burndown charts.
“As soon as work moved beyond a single office and a single tool, visibility broke,” Akmentiņš explains. “You can’t manage what you can’t see, and in engineering, much of the important work is invisible by default.”
As a result, teams plan based on perception:
- How busy people seem
- How long tasks felt
- What blockers were remembered
This subjective lens creates blind spots. Velocity drops without explanation and sprints overrun despite “realistic” planning. As a result, managers compensate by adding processes, while developers feel increasingly constrained.
At the end of the day, Agile gives teams structure, but not visibility.
The cost of intuition-driven development decisions
When engineering decisions rely primarily on gut feeling, small inefficiencies compound into systemic problems.
Leaders may assume missed deadlines are caused by poor estimation when the real issue is constant interruption. Teams may push harder during crunch periods, unaware that sustained focus time has already collapsed. Developers may feel underperforming, despite spending a significant portion of their day on non-development tasks.
“These are not performance problems, they’re system problems,” says Akmentiņš. “But without data, it’s very easy to misdiagnose them and apply pressure where it doesn’t belong.”
Over time, this leads to:
- Inaccurate capacity planning
- Misguided performance conversations
- Burnout disguised as “normal sprint pressure”
Without objective data, even well-intentioned Agile teams struggle to diagnose what’s actually slowing them down.
What “data-informed development” really means
Data-informed development doesn’t replace Agile. Instead, it completes it.
Instead of relying solely on meetings and memory, teams use objective activity data to understand how work flows through their system. The goal isn’t to track or micromanage employees, but rather to understand and analyze patterns.
Knowing how your employees work makes all these questions answerable:
- How much uninterrupted focus time do developers get per day?
- Where does work fragment across tools and meetings?
- How does real capacity differ from planned capacity?
- Which activities consistently delay delivery?
This shift changes the nature of improvement. Conversations transition from opinion-based debates to a shared understanding, and processes are tested against real evidence, not assumptions.
Why automatic time data matters
The biggest barrier to better insight is simple human error. Manual reporting is usually incomplete and biased. Developers forget to log time, round numbers, or adapt entries to expectations. In the end, the data looks clean, but in reality, it’s unreliable.
Automatic time tracking solves this problem by capturing activity passively and consistently, showing reality as it is.
This is where tools like DeskTime play a central role in data-informed development.
DeskTime automatically records how time is spent across applications, tools, and workflows, without requiring developers to log their day manually. Over time, this creates a factual baseline of how engineering work actually unfolds.
Not who worked “harder,” but:
- Where focus was possible
- Where interruptions dominated
- How workloads shifted across cycles
This type of data gives teams a shared, neutral source of truth.
Redefining productivity for engineering teams
Traditional productivity metrics often fail to translate well to software development. Hours worked, tasks closed, or lines of code produced ignore the cognitive nature of engineering work.
Data-informed development reframes productivity around conditions for effective work:
- Sustained focus time
- Reasonable context switching
- Balanced workload distribution
With DeskTime’s focus-time and application-usage insights, teams can see whether their environment supports deep work or actively undermines it.
Often, productivity issues aren’t caused by lack of effort, but by excessive meetings, reactive communication, or fragmented toolchains. Identifying these patterns allows teams to fix systems instead of pressuring individuals.
Planning and estimation backed by evidence
Sprint planning remains one of Agile’s most fragile moments. Estimates are shaped by optimism, recent experiences, and incomplete memory.
Historical activity data changes this dynamic. By analyzing past work patterns, teams can:
- See how long similar tasks truly took
- Understand how non-development work impacts delivery
- Account for real, not theoretical, capacity
DeskTime’s long-term activity insights help teams move from speculative planning to evidence-based forecasting. Estimates won’t become perfect, but they’ll become grounded in reality.
The result is fewer surprises, calmer delivery cycles, and greater trust between engineering and leadership.
Transparency without micromanagement
One of the biggest fears around time data is control. Developers worry about surveillance; managers worry about misinterpretation.
In practice, the opposite often happens.
When teams lack visibility, managers add check-ins, reports, and meetings to regain control. When visibility exists, many of those controls become unnecessary.
DeskTime’s aggregate, pattern-focused insights support transparency without targeting individuals. Teams can discuss trends, not personal metrics. Developers gain insight into their own work rhythms, while managers gain confidence without the need for constant oversight.
Autonomy is preserved and reinforced by trust and clarity.
Turning data into meaningful improvement
Data alone doesn’t improve teams. Interpretation does. The most effective teams use data selectively:
- To identify recurring friction points
- To validate whether process changes worked
- To protect focus time intentionally
DeskTime acts as an early-warning system, surfacing inefficiencies before they become crises. Instead of reacting to missed deadlines, teams can address the conditions that make delays likely.
This turns continuous improvement from a vague goal into a measurable practice.
The future of Agile is empirical
Agile was never meant to rely on guesswork. Its principles emphasize inspection and adaptation, but modern teams need better signals to inspect.
Data-informed development provides those signals.
“Agile taught us how to change,” Akmentiņš concludes. “Data shows us where change is actually needed.”
For engineering teams navigating distributed work, rising complexity, and constant pressure to deliver, that shift isn’t optional. It’s the next stage of maturity.
Related Categories