In his seminal work, ‘Flow: The Psychology of Optimal Experience‘, Mihaly Csíkszentmihalyi (1990) argues that individuals achieve peak productivity when immersed in a state of ‘flow’ – a profound concentration and focus on the task at hand.  This state, often colloquially known as being ‘in the zone,’ is intrinsically linked to motivation and a deep engagement with the work.

This concept of ‘flow’ resonates strongly with the Scrum value of focus.  The underlying principle is to empower individuals within an Agile team to concentrate on their work, thereby fulfilling the commitments they have undertaken.   To be predictable.   In frameworks like SAFe, these commitments manifest as ‘Team PI Objectives’ and the more granular ‘Iteration Goals,’ which serve as stepping stones.  In non-scaled contexts, the ‘Sprint Goal’ fulfils a similar purpose.

However, the daily reality for many developers, testers, and other development team members often starkly contrasts with this ideal.  Throughout a sprint or iteration, they frequently find themselves pulled into disparate conversations and tasks, leading to context switching that severely diminishes productivity.  The cost isn’t just the time needed to mentally re-engage with a new priority.  There’s also the cognitive load of suspending the previous task, closing relevant files and tools, and then navigating and setting up the environment for the new work.  Evidence from developers suggests that even brief, unrelated discussions can trigger a significant ‘ramp up’ time to regain that crucial state of ‘flow,’ a phenomenon Kersten eloquently describes in his book Project to Product  (2018) as ‘thrashing’ leading to a detrimental impact on productivity and predictability.

Thus, we see dedicated professionals starting their day with focused intent, only to be repeatedly diverted, preventing them from bringing their initial previously planned work to completion.

When training or coaching, I often remark that, when it comes to productivity, the three most dangerous words in any organisation are “Can you just…?”, often followed by “It’ll only take a few minutes!”.

It rarely does!

Sometimes these types of requests are lovingly known as the JFDIs [for those who don’t know…Just…F…Do it!].    JFDIs are in my view the most insidious form of the internal denial of service attack.  The service being denied of course being the team’s ability (and ultimately the organisation’s ability) to deliver a continuous flow of commitments to customers within planned predictable timeframes.

The Tangible Impact: eroding focus, diminishing value, and poor predictability

The cumulative effect of constant disruption manifests in significant ways:

• Loss of focus and reduced value delivery: Frequent context switching shatters the delicate ‘flow’ state, leading to fragmented work and decreased individual and team efficiency.  The more time spent switching between tasks, the less time is dedicated to deep, focused work that generates actual value.  This ultimately results in a lower output of completed, high-quality deliverables.
• Poor predictability: The inability to shield development teams from a barrage of interruptions makes accurate forecasting and reliable commitment delivery exceedingly difficult.  This erosion of predictability damages trust with stakeholders and severely hinders effective roadmap planning – if your teams are not predictable, your roadmaps are merely a nice wish list!  In scaled environments, where numerous teams have interdependencies, this lack of predictability can create a cascading effect, jeopardising the delivery of entire value streams.

Mitigations: reclaiming focus and improving predictability

To effectively counter this internal DoS and cultivate an environment conducive to both focussed work and predictable delivery, consider implementing the following strategies:

1. Confronting the “Can You Just…?” (or JFDI) culture: Empower Scrum Masters and Product Owners to act as crucial gatekeepers, thoughtfully questioning the urgency and impact of every “quick” request.  A simple yet powerful response is, “Can this wait until after the current iteration goal is achieved or perhaps in the next PI?” or “What should we deprioritise to accommodate this?”  Making current team commitments visible on physical or digital boards and asking requestors to identify what existing work should be displaced can often highlight the true cost of these seemingly minor interruptions.  Crucially, diligently track and report the cumulative capacity consumed by these unplanned JFDIs in iteration reports to foster data-driven conversations about their impact and the need for change.
2. Proactive management of “Known unknowns” – support and ad-hoc requests: Recognise that support work and small, often urgent, client requests are often a reality.  Instead of treating them as completely unexpected disruptions, proactively allocate a buffer of team capacity within each iteration or PI based on historical data.  This transparently acknowledges these demands in planning and safeguards the capacity needed for planned commitments. If these allocated buffers are not fully utilised, the team can pull in planned work, leading to early delivery – a far more desirable outcome than consistently missing commitments.   If your teams have stories always bouncing to the next sprint/iteration, this is a red flag.
3. Optimising the ‘Continuous Delivery Pipeline’: Even the most focused development team will struggle to deliver value efficiently if the continuous delivery pipeline is a bottleneck. A slow and cumbersome process for deploying code (a.k.a. high transaction cost) negates the benefits of rapid development and quick fixes. Therefore, investing in and optimising the delivery pipeline to reduce cycle time is a critical systemic improvement.
4. Strategic application of service level agreements (SLAs): For organisations dealing with external clients, clearly defined SLAs regarding response times for support requests can be a valuable tool.  These agreements provide a framework for managing expectations and planning for necessary support work without completely derailing planned development activities.
5. Prioritising the completion of Work in Progress (WIP): Encourage a culture of finishing tasks before starting new ones.  Spending the necessary time to bring a set of related stories or even a feature to completion before context switching to an entirely different area of the system is significantly more efficient than constantly starting and stopping multiple tasks.  Implementing and actively enforcing sensible Work in Progress (WIP) limits on team boards visually reinforces this principle and prevents teams from overcommitting and multitasking.   Stop starting, start finishing!
6. Enhancing visibility of expedited requests: Implement a dedicated swimlane on the team’s Agile board specifically for genuinely urgent, high-priority items that require immediate attention.  This visual distinction clarifies when breaching established WIP limits is truly necessary and provides transparency regarding the impact of these exceptions on overall flow.
7. Adaptive scope management: When the volume of unplanned work consistently exceeds the allocated capacity buffers, it’s crucial to have mature conversations about potentially de-scoping planned work to maintain realistic commitments for the iteration or PI.  Failing to do so often leads to missed deadlines and frustrated teams. Regularly review and adjust the capacity allocation for unplanned work during pre-planning for subsequent increments to ensure a more accurate reflection of the team’s true capacity.

Conclusion: Cultivating focus for predictable value delivery

The pervasive issue of unmanaged interruptions and the “JFDI” mentality creates a hostile environment for teams and individuals, severely hindering their ability to achieve flow and deliver predictably.  By adopting controlled intake mechanisms for new work and diligently implementing the mitigation strategies outlined above, organisations can foster a culture of focus, empower their development teams to concentrate on delivering value and ultimately achieve a more reliable and consistent flow of high-quality products and services to their customers.

In your experience, how prevalent is the “internal DoS” in your organisation? 

Is your organisation predictable in the commitments it makes?

What other innovative strategies have you found successful in minimising distractions and enabling your teams to consistently and predictability meet their commitments?

References:

Csíkszentmihalyi, M. (1990) Flow: The Psychology of Optimal Experience. New York: Harper & Row.

Kersten, M. (2018) Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. Portland, OR: IT Revolution Press.