Harnessing Kanban for Improved Developer Experience

A Practical Guide


Developer Experience (DevEx) is an emerging concept garnering substantial attention in the software development landscape. It encapsulates developers' feelings, thoughts, and values about their work. This approach acknowledges that developer productivity extends beyond code quantity and task completion speed, instead being shaped by a sophisticated mix of technical and human factors.

At its core, DevEx aims to elevate developers' overall satisfaction, engagement, and productivity. It rests on the premise that satisfied developers are typically more productive and innovative, leading to superior software products and boosting organizational success.

Understanding DevEx's complexities is made easier through a three-dimensional model: Feedback Loops, Cognitive Load, and Flow State. Feedback Loops pertain to the pace and quality of responses to performed actions. Cognitive Load measures the mental exertion needed to perform a task, and Flow State describes a state of deep immersion in a task, marked by energized focus, full involvement, and enjoyment.

Parallel to this, Kanban, a method for defining, managing, and improving services that deliver knowledge work such as software development, offers a complementary perspective. It promotes a "start from what you do now" approach, acting as a catalyst for rapid and focused organizational change. One of its notable practices is visualizing work via a Kanban board, partitioned into columns that represent work flow.

Instead of viewing the board as a segmented workspace that merely represents work steps or personnel functions, Kanban encourages viewing it as a knowledge discovery process. Each column denotes a different learning phase in an interconnected journey.

KEDE (KnowledgE Discovery Efficiency) is a novel metric that proves instrumental in optimizing software development processes. KEDE quantifies the knowledge gap developers encounter when embarking on tasks. This knowledge gap directly influences developers' experience, affecting their happiness, productivity, and overall satisfaction with their work.

KEDE scores range between 0 and 100, with higher values signaling a better standing. KEDE serves as a unique and potent metric; however, it doesn't aim to supplant all other metrics. Instead, it operates akin to an organizational thermometer, mirroring the efficiency with which developers are able to garner and apply knowledge. It thus gauges happiness, productivity, and levels of collaboration among software developers.

The thermometer can provide a reading of your organization's "temperature," but not diagnose the reason for a fever, so to speak. To understand the cause, organizations need a physician - someone who can delve inside the black box, like a manager or coach. Therefore, just like a physician is crucial for diagnosis and treatment, agile coaches and engineering managers are key for interpreting the readings and implementing beneficial changes.

In this article, we will explore how the principles and practices of Kanban can closely align with DevEx's three dimensions. Additionally, we'll investigate how KEDE aligns with, and can be used to measure, these DevEx dimensions: Cognitive Load, Feedback Loops, and Flow State. This understanding will provide insightful guidance on how KEDE can serve as an effective tool for integrating the Kanban method and DevEx approach within your organization.

Understanding Developer Experience (DevEx)

The concept of Developer Experience (DevEx) embodies the perceptions, values, and sentiments that developers harbor towards their work. It is influenced by more than 25 sociotechnical factors, such as interruptions, unrealistic deadlines, and friction in development tools that can negatively affect DevEx[1]. Conversely, clarity in tasks, well-structured code, and seamless releases can improve it. Human factors, like having clear project goals and feeling psychologically safe on a team, also have a substantial impact on developers' performance. Improving DevEx not only increases productivity but also boosts satisfaction, engagement, and employee retention.

Three Dimensions of DevEx

The framework distills developer experience into three core dimensions: feedback loops, cognitive load, and flow state:

  • Feedback Loops: Shortening feedback loops, essentially the speed and quality of responses to actions executed, is crucial to improving DevEx. Fast feedback loops allow developers to complete their work quickly with minimal friction, while slow feedback loops interrupt the development process, leading to frustration and delays. Thus, organizations should strive to shorten feedback loops whenever possible.
  • Cognitive Load: Developers' cognitive load corresponds to the mental exertion required to complete a task. High cognitive load due to problems like poorly documented code or systems requires developers to devote extra time and effort to complete tasks without errors. Minimizing cognitive load can bolster the developer experience (only up to a point, as we shall see later with KEDE). This can be accomplished by eliminating unnecessary roadblocks in the development process, crafting well-organized code and documentation, and offering easy-to-use, self-service tools.
  • Flow State: Flow is a mental state in which a person performing an activity is fully immersed in a feeling of energized focus, complete involvement, and enjoyment. Frequent experiences of flow state at work lead to higher productivity, innovation, and employee development. Creating optimal conditions for flow state, like minimizing disruptions and creating positive team cultures that grant developers autonomy and challenging tasks, can improve developer experience.

Measuring DevEx

Measuring developer experience is critical for identifying opportunities for improvement, detecting trends, and understanding the impact of investments. The key is to focus on developers and their lived experiences in delivering software. This includes their workflows in the various systems and processes involved in their work, and developers' perceptions of these systems with which they interact. Social factors such as collaboration and culture are important to capture as well[1].

Multiple data sources, including issue trackers, source code repositories, CI/CD tools, and survey responses, can be utilized to measure DevEx. Surveys are particularly crucial in measuring DevEx and gleaning feedback from developers about friction points in the software-delivery process. To augment surveys, organizations should also collect data from various systems and processes involved. Methods for analyzing these data sources range from simple descriptive statistics and visualizations to more advanced quantitative approaches[1].

Overview of Kanban principles and practices

Kanban is a method for defining, managing and improving services that deliver knowledge work. It can be characterized as a "start from what you do now" method, a catalyst for rapid and focueed change within organizations[20].

Originating from Lean Manufacturing, Kanban is designed for managing knowledge work that culminates in intangible, virtual goods, and services

Kanban's principles are two-fold: Change Management Principles and Service Delivery Principles. The Change Management Principles, integral to all Kanban implementations, include:

  • Start with what you do now
  • Agree to pursue improvement through evolutionary change
  • Encourage acts of leadership at all levels
The service-oriented principles are:
  • Understand and focus on customer needs and expectations
  • Manage the work; let people self-organize around it
  • Regularly review the network of services and its policies in order to improve outcomes

The general practices of Kanban are:

  1. Visualize: Effective visualization is key to collaboration and identifying areas of improvement.
  2. Limit Work in Progress (WIP): Manage the number of work items in progress at a given time.
  3. Manage Flow: Aim for smooth and predictable work completion at a sustainable pace.
  4. Make Policies Explicit: Detail policies visibly and understandably, ensuring they are consistently applied and easily adjustable.
  5. Implement Feedback Loops: Establishing context-appropriate feedback loops strengthens the organization's learning capabilities and fosters its evolution through managed experiments.
  6. Improve Collaboratively, Evolve Experimentally: Use models and the scientific method to design experiments.

Remember, Kanban is more than just a board. It is about refining processes by making data-driven decisions based on system feedback. For example, recurrent bottlenecks in a workflow section signal an impediment requiring attention.

Kanban advocates viewing the board not as a segmented workspace representing work steps, roles, or handoffs, but as a knowledge discovery process[22]. Each column denotes a different phase of learning in an interconnected journey[24] The workflow is perceived as a sequence of information discovery activities[22] This perspective transforms the Kanban board from merely partitioning the process into phases, into a map outlining the dominant steps in uncovering new knowledge[23]. This viewpoint allows us to capture the essence of Kanban, as a method designed to enhance learning and information acquisition in our work processes.

Through the Kanban lens, we discern the true nature of software development as a progression from some knowledge about an idea to full comprehension of a finished product ready for delivery. Essentially, software development is a process of knowledge acquisition and ignorance reduction[21]. It's a journey to identify and close knowledge gaps, reduce our uncertainty, and increase our knowledge iteratively. This way, we model the software development process as a knowledge discovery process.

Knowledge Discovery Efficiency (KEDE): An Overview

Defining KEDE

Knowledge Discovery Efficiency (KEDE) is a potent metric for optimizing software development. By examining source code repositories, KEDE measures the knowledge gap developers grapple with when initiating tasks. This gap directly influences developers' experiences, impacting their happiness, productivity, and overall job satisfaction.

KEDE is anchored to the natural constraints of maximum possible typing speed and the capacity of the cognitive control of the human brain. This association permits comparisons across varying contexts, programming languages, and applications.

The computation of KEDE is based on a scientific method for evaluating the capability of software development organizations and constitutes patented technology[2][3].

KEDE is calculated for each developer individually and signifies the knowledge that they lacked before beginning the task. A low KEDE score implies that the developer did not possess the requisite knowledge to tackle the task, while a high KEDE score suggests that the developer was adequately prepared.

The mathematics underlying KEDE dictate that its values can range between 0 and 100. When KEDE approaches 0, it signifies situations where the missing information is virtually infinite - a common scenario when creating new knowledge. Examples include figures like Albert Einstein or startups like Paypal that were pioneering completely new technologies. On the other hand, a KEDE value near 100 signifies a situation where there is no information gap, analogous to an omniscient entity...like God! KEDE will be higher if you're primarily applying prior knowledge instead of discovering new knowledge.

The Utility of KEDE

Knowing your organization's KEDE score offers valuable insights into the human capital of your organization, allowing you to gauge happiness, productivity of and collaboration levels among your software developers.

Here are a few practical ways you can utilize KEDE to gain a competitive edge:

  • Comparative Analysis: KEDE enables you to compare among different functional areas within your company, and even your company's capabilities with industry averages.
  • Impact Analysis: KEDE helps in evaluating the effectiveness of significant changes within your organization. Are you curious if the latest restructuring enhanced your company's capability? Or if the new hires have actually bolstered your team's potential? KEDE can provide you with objective answers.
  • Transformation Analysis: If your team has recently undergone an Agile transformation, KEDE can help you measure if the transformation has actually increased your team's capability.

In summary, KEDE provides you with clear guidance on necessary adjustments in a software developer organization to boost and leverage its capability, thereby enhancing productivity.

How Kanban enables quick and quality Feedback Loops, and how KEDE can measure these

Every general Kanban practice integrates feedback loops into the software development process, serving as the foundation for swift evolutionary change. From a DevEx perspective, we're particularly interested in the shortening of these Feedback Loops. This act increases the speed and quality of responses to actions performed and is facilitated by the six general Kanban practices.

Below, we provide a brief description of how the implementation of the general Kanban practices can improve Developer Experience (DevEx) by shortening the Feedback Loops:

  • Visualize: Visualization of workflow on the Kanban board provides instant feedback on the status of tasks, identifies bottlenecks, and shows progress in real-time.
  • Limit Work in Progress (WIP): By limiting WIP, teams can quickly identify issues, respond, and adapt. Too many tasks in progress can delay feedback as developers are spread thin.
  • Manage Flow: By observing and managing the flow of work items, teams can monitor performance metrics such as lead time and cycle time. Shorter cycle times equate to quicker feedback loops.
  • Make Policies Explicit: By clarifying policies, everyone understands what is expected at each step, enabling immediate feedback if a step deviates from the policy.
  • Implement Feedback Loops: This essential Kanban practice directly emphasizes the value of feedback in the process. Kanban Cadences refer to a network of regular meetings that promote effective bi-directional communication at all necessary organizational levels. These seven cyclical meetings drive evolutionary change and "fit for purpose" service delivery[25].
    There are 10 feedback loops on this diagram showing information flow and change request flows between the different meetings.
  • Improve Collaboratively, Evolve Experimentally: This practice fosters feedback at an elevated level. The act of making improvements based on learnings from executed experiments cultivates a culture of rapid and continuous learning.

By incorporating its principles and practices, Kanban provides a framework wherein feedback loops are seamlessly integrated into the software development process. Furthermore, these loops are optimized to be as short as possible, contributing substantially to an enhanced DevEx.

Implementing KEDE to Measure Feedback Loops

Shortening feedback loops is a common goal in many software development methodologies, such as Agile and DevOps, as it leads to faster detection of issues, quicker implementation of changes, and overall improved efficiency.

Collaboration involves the active engagement of multiple individuals or teams to achieve a common goal. It allows the sharing of unique perspectives, experiences, and skills, thereby facilitating a more diverse and comprehensive problem-solving approach. In software development, for example, collaboration could involve developers, testers, designers, project managers, and clients working together to deliver a successful product.

Collaboration and feedback loops are interconnected, each influencing and enhancing the other in a kind of virtuous cycle, as explained here. Effective collaboration leads to shorter, more efficient feedback loops, and efficient feedback loops enhance the effectiveness of collaboration. This cycle, when facilitated and managed properly, can greatly enhance team productivity and the overall quality of the end product or service.

Collaboration can be measured

Software development is a complex process that requires the collaboration of multiple team members. Measuring the efficiency of this collaboration, however, is not straightforward. It's a multifaceted task that can't be reduced to a single metric.

There are tools available that, from 'inside the black box', measure the efficiency of practices— such as Continuous Integration/Continuous Deployment (CI/CD), Pair Programming, and Code Reviews— that are designed to facilitate and enhance collaboration and shorten feedback loops in software development. However, it's also crucial to remember that it's both possible and valuable to gauge the effectiveness of collaboration from outside this 'black box'.

One way to do this is by examining the efficiency of information acquisition in relation to the number of active contributing software developers.

The number of contributing developers can be determined by counting those actively participating in a project over a certain period of time.

The efficiency of information acquisition, on the other hand, can be understood in terms of how rapidly and effectively missing information is acquired and integrated into the team's work. This can be reflected in the time taken to incorporate missing information, the completeness or accuracy of the understanding of new information, and the impact of the new information on the team's productivity or the quality of their output.

Missing information can be acquired from two types of sources[19]:

  • Personal Sources: Those that communicate information personally including insights, experiences, and skills of team members. When people collaborate, they share and combine their knowledge, skills, and experiences, leading to a more effective problem-solving process and achievement of shared goals. In this sense, collaboration amplifies individual contributions by creating a collective intelligence that exceeds the sum of its parts.
  • Impersonal Sources: These are non-human sources that communicate information to broad audiences, including books, research papers, digital databases, API documentation, StackOverflow responses, coding libraries, and online audio and video. This type of information is vital as it provides a broader, often more objective viewpoint, and can provide data and insights that may not be available within the collaborating group.

In a well-functioning collaborative environment, both personal and impersonal sources of information are considered and used to acquire knowledge, solve problems, and make informed decisions. It's important to note that when we measure the efficiency of information acquisition, we are considering both these categories of sources. This means we account for all channels through which new information can be gained, thereby providing a comprehensive view of the organization's level of efficiency of information acquisition.

Knowledge Discovery Efficiency (KEDE) is a metric that can be used to measure the efficiency of information acquisition in software development. We will refer to an organization's efficiency of information acquisition as its 'capability.'

Practical examples of KEDE being used to measure feedback loops

Consider the time-series diagram below, which illustrates the interplay between an organization's size and its capability over time.

The x-axis represents the quarters, while the y-axis on the left displays the 'capability' in terms of Weekly KEDE values. The dark blue line in the diagram represents the average Weekly KEDE for all developers who contributed to the company's projects in a given week, calculated using Exponential Weighted Moving Average (EWMA). This line offers a visual representation of how the organization's capability fluctuates over time.

The right y-axis showcases the size of the company, depicted by the number of developers who contributed to the company's projects in a given week. The green line represents the company's size over time, with each point marking the count of contributing developers for that week. A detailed construction of the diagram can be found here.

The diagram displays a notable period where there is an inverse correlation between the company's size and its capability. Over the span of more than two years, the company size surged from 20 to 44, a substantial 120% increase. Conversely, during the same period, the capability steadily declined from 3.6 to 1.3, indicating a 64% decrease. The diagram illustrates a trend wherein the efficiency of information acquisition decreases as the number of contributing software developers increases.

Another way to visualize the relationship between the efficiency of information acquisition and the number of developers is through a histogram. This chart shows the frequency distribution of the company's 'capability' against the number of contributing developers over time.

The x-axis displays the number of developers who contributed to any of the projects in a given week, while the y-axis represents the weekly KEDE values. Each individual developer's aggregated Weekly capability is presented as a light blue dot on the diagram, while the dark blue line represents the average weekly capability for all developers calculated by arithmetic mean. A detailed explanation of how this diagram was constructed can be found here. Analyzing this histogram, we once again observe that the efficiency of information acquisition tends to decrease as the number of contributing software developers increases.

Interpreting these two diagrams together, we might suggest potential issues with the level of collaboration in the organization. Challenges could arise in terms of communication, coordination, knowledge silos, individual contribution, or even information overload. While more contributors are generally beneficial, managing the complexity requires effective strategies, clear communication, and robust systems. However, it's crucial to remember that we are observing these trends from 'outside the black box'. The actual cause could be a combination of these factors, or even something entirely different. A more accurate understanding would require 'looking inside the box' to ascertain the underlying reasons.

How Kanban practices can help manage and minimize Cognitive Load, and how KEDE can quantify this

Below, we provide a brief description of how the implementation of these Kanban practices can improve Developer Experience (DevEx) by minimizing Cognitive load:

  • Visualize: By providing a clear visual representation of the workflow, developers can understand and process the state of the project more easily. This reduces cognitive load by allowing developers to focus more on their tasks and less on understanding the project's status.
  • Limit Work in Progress (WIP): By limiting the number of tasks a developer or team is working on at any given time, we're helping manage cognitive load. This practice prevents task switching, which can be cognitively demanding.
  • Manage Flow: By managing the flow of work, Kanban can help ensure that tasks are evenly distributed, avoiding overloading certain team members and thereby managing cognitive load.
  • Make Policies Explicit: By making policies explicit and clear, developers don't need to spend cognitive resources on figuring out what needs to be done. This clarity reduces ambiguity and uncertainty, thus reducing cognitive load.
  • Implement Feedback Loops: Regular feedback can help guide developers and reduce the cognitive load associated with decision-making. Feedback helps to clarify expectations and correct misunderstandings early, preventing wasted cognitive effort on unproductive paths.
  • Improve Collaboratively, Evolve Experimentally (Kaizen): This practice encourages continuous learning and improvement, which can help developers become more comfortable and efficient in their roles, reducing cognitive load over time. By encouraging an experimental mindset, it fosters an environment where it's safe to make mistakes, which can also lower cognitive load by reducing fear of failure.

The application of the Kanban principles and practices can contribute to the effective management of cognitive load, supporting developers in focusing their cognitive resources where they matter most, thereby enhancing the overall Developer Experience (DevEx).

Implementing KEDE to Measure Cognitive Load

Cognitive load refers to the total amount of mental effort required for a task, such as software development[6]. Rooted in cognitive psychology, this concept is closely related to cognitive control, the processing capacity of the conscious mind, and working memory capacity.

The processing capacity of the conscious mind refers to the amount of mental resources that are available to process and understand information. While a great deal occurs below the threshold of our awareness, and this has an impact on how we feel and what our life is going to be like, in order for something to become encoded as part of your experience, you need to have paid conscious attention to it[14].

Working memory, often referred to as the "mental scratchpad", is a cognitive system that allows individuals to temporarily store and manipulate information in their minds. It plays an important role in a variety of mental tasks, including problem-solving, decision-making, and learning.

In 1956, cognitive psychologist George Miller proposed that the number of items humans can actively hold in their conscious awareness at once is limited to about seven[9]. However, more recent research suggests that the limit may be closer to four or five items[13]. This has been interpreted to mean that the human brain can hold about 2 to 3 bits of information in working memory at a time, where each bit represents a binary decision.

The precise limit is determined by each individual's memory capacity, with activity from low-capacity individuals reaching this plateau sooner than that from high-capacity individuals[10]. Cognitive capacity is directly related to cognitive ability[11][12].

The capacity of working memory is limited to a few items, with estimates ranging from three to seven items.

The cognitive load can increase significantly when individuals are presented with a large number of options, a phenomenon known as "choice overload" or the "paradox of choice."[16]. This leads to hindered decision-making and a reduced likelihood of selecting rational and objective options[7][8].

The number of bits in the working memory is not only determined by the number of alternatives but also by other features of the choice set, such as the number of attributes that alternatives are differentiated upon[15]. In addition, there are limits to the cognitive processing capabilities of the mind and limited working memory.

To quantify how a large number of options affects cognitive load, we can consider the "search space" of options contributing to the "perplexity" of the decision task. The larger the search space (i.e., the more options there are), the higher the perplexity, and the more cognitive resources are required to make a decision. This can increase cognitive load and potentially lead to choice overload.

Perplexity, commonly used in natural language processing and machine learning, refers to the uncertainty or unpredictability of a model's output. In a broader sense, perplexity can be understood as a measure of the complexity, difficulty, uncertainty, or unpredictability of a problem or task. A person might be in a state of perplexity when trying to solve a difficult puzzle or find an object in a large search space. A more complex or difficult task might have a greater number of possible states or options to consider, which might increase the feeling of uncertainty or confusion.

In this context, perplexity might be thought of as a measure of the search space i.e. average number of possible states, in the sense that a more complex or difficult task might have a greater number of possible states or options to consider, which might increase the feeling of uncertainty or confusion. For example, if one is trying to find a specific item in a large room or warehouse, the search space would be the number of potential locations where the item could be found.

The size of the search space refers to the number of potential solutions or answers that are available within a particular domain.

To quantify perplexity, we need to know how many options a software developer sees when looking at a work item before starting the work. This task can be challenging, if not impossible, since it involves understanding the individual's thought process!

However, we can measure the knowledge discovered after completing the work. This knowledge equals the difference between the prior knowledge a software developer had and the knowledge required to develop the work item.

Knowledge Discovery Efficiency (KEDE) measures the discovered knowledge. From KEDE, we can assess the perplexity a software developer experienced while working.

Taking into consideration how KEDE correlates with perplexity, we can say that::


For instance, if a knowledge worker has KEDE=100, it means she had to find a coin in only one box.


This situation reflects a perplexity of 1, indicating there was only one possible answer to the question: "Where is the gold coin?" This is the minimum value.

However, if a knowledge worker has KEDE=20, it implies she had to find a coin among 16 boxes, indicating a tolerable perplexity level.


But if a knowledge worker had KEDE=1, equivalent to answering 99 binary questions, it means she had to find a coin among approximately 6.3x1029 boxes!


To contextualize, there are an estimated 1022 to 1024 stars in the Universe[5]. The number of boxes was significantly greater than the number of stars in the Universe! We can infer that the software developer faced an exceedingly high level of perplexity.

In essence, KEDE provides a robust mechanism for quantifying cognitive load in software development tasks. By calculating the knowledge gap that developers must bridge to complete tasks, we can gauge the complexity of these tasks and, in turn, gain insights into the cognitive load placed on developers. Such insights can be invaluable in optimizing development processes and improving overall developer experience.

Practical examples of KEDE being used to measure cognitive load

In order to assess the cognitive load of a developer, it's important to examine their KEDE over time. The diagram below provides a time series of KEDE of a developer for a selected period across all projects.

The x-axis displays the week dates, while the y-axis represents weekly KEDE values. The blue dot on the diagram for each week represents the developer's KEDE. The dark blue line on the diagram represents the average weekly KEDE for the developer, calculated using EWMA. To compare the developer's KEDE with the average of the company, you can view the Weekly KEDE for all developers who contributed code to any of the company projects during the selected time period. Each individual developer's weekly KEDE is presented as a light gray dot, and the black line represents the average weekly KEDE for those developers, calculated using EWMA.

When inspecting a developer's KEDE over time, it's also useful to see the underlying frequency distribution of their averaged values. A histogram can show how often each different value occurs. The diagram below presents such a histogram for a selected period.

On the x-axis, you have the Weekly KEDE, and on the y-axis, you have the percentage of each particular value. First, the developer's summarized KEDE is presented by the histogram in color of the Weekly KEDE frequency for the selected period. The blue vertical line is the average weekly KEDE for the developer for the selected period, calculated by arithmetic mean. The median weekly KEDE for the developer for the selected period is presented by the green vertical dashed line.

To gain a better understanding of a developer's KEDE, it's important to inspect how it is distributed across projects. The diagram below presents a stacked bar chart that allows for a detailed analysis of numeric values across two categorical variables. In this case, the first category is the developer's weekly KEDE, and the second category is the projects the developer worked on during the selected time period.

On the x-axis, we have the week dates, and on the y-axis, we have the weekly KEDE. Each bar represents the weekly KEDE of the selected developer divided into a number of boxes, each corresponding to the fraction of the weekly KEDE that the developer contributed to a particular project. This allows for a clear visualization of the developer's KEDE distribution across different projects.

How Kanban supports achieving a flow state, and how KEDE can identify that

Here are some main points on how the Kanban principles and practices can support achieving a flow state, mapping to the DevEx dimension of "Flow State":

  • Visualize: The visual representation of tasks, their progress, and dependencies can help developers focus on their current tasks. It reduces the need to keep mental track of these details, allowing deeper immersion in the task at hand.
  • Limit Work in Progress (WIP): By limiting WIP, Kanban encourages developers to focus on a single task until it's complete, thereby promoting deep work and enhancing the likelihood of reaching a flow state.
  • Manage Flow: By smoothing the flow of work, Kanban minimizes disruptions and delays, allowing developers to maintain focus and stay in a flow state for longer periods.
  • Make Policies Explicit: Clear, explicit policies reduce ambiguity and the need for decision-making about process-related issues. This supports a flow state by minimizing interruptions to a developer's cognitive process.
  • Implement Feedback Loops: Regular feedback and reflection can help refine the process and reduce future impediments, making it easier for developers to achieve and maintain a flow state. Immediate feedback on work also allows developers to make corrections as they go, helping them stay engaged and immersed.
  • Improve Collaboratively, Evolve Experimentally (Kaizen): A culture of continuous learning and experimentation contributes to mastery, one of the prerequisites for achieving a flow state. The opportunity to learn and apply new skills can increase enjoyment and immersion in work.

Remember that the environment must also support a state of flow. Interruptions and context switching are major enemies of flow, so it's important to ensure that developers have the conditions they need to achieve deep focus and full involvement in their tasks.

Implementing KEDE to Measure Flow State

As software development is a highly cognitive and mentally demanding activity, it's important to understand how to measure the happiness of developers. A state of "flow" is a key indicator of optimal experience and happiness in work.

Flow states are commonly referred to in many ways in society, such as "wired in," "in the groove," "in the moment," and "the zone."

To achieve flow, one must find a balance between individual capability and work complexity, with a slight inclination towards challenges.

To enter and maintain a flow state, the following conditions should be met[17]:

  1. The opportunity for action, with a clear and attainable goal. That doesn't meant having an overall goal for the activity, but knowing what to do next from moment to moment[18]
  2. An action with a balance between skill level and challenge, meaning that the activity is neither too easy nor too difficult.
  3. Clear and immediate feedback, so that successes and failures are apparent and behavior can be adjusted as needed.

In order to have an opportunity to act, a developer needs to have a clear proximal goal[17]. In order to have a clear and attainable proximal goal, a developer needs to:

  • Know what to do
  • Know how to do it
  • Know where to go (where navigation is involved)
These three conditions ensure that the developer has a clear proximal goal.

After the goal is established, the developer needs to subjectively evaluate if their capabilities are in balance with the work complexity. If that is the case, then there will be a balance between:

  • High perceived challenges
  • High perceived skills
And this balance will facilitate the developer to be in the flow state.

By balancing each task, we can create the conditions for entering flow for each set of tasks, each feature, and ultimately, for the scope of the project.

Quantifying Flow State

In order to determine whether a developer was in a state of flow, it's essential to assess the balance between their perceived individual capabilities and the complexity of each task they worked on. This assessment demands precise and dependable information regarding both factors.

From a knowledge-centric perspective, we define the developer's perception of the complexity of the task as the "required knowledge." Similarly, we refer to the developer's perception of their individual capabilities as the "prior knowledge". Prior knowledge is known to facilitate the learning of new information. Estimates suggest that between 30% and 60% of the variance in learning outcomes can be explained by prior knowledge[11]. Additionally, prior knowledge of different domains can jointly support the recall of arguments[12].

The difference between the prior knowledge a developer possesses and the required knowledge needed to complete a task is what we term as the knowledge to be discovered, which we measure in bits of information.

Imagine a scale: on one side is the required knowledge and on the other is the prior knowledge. They will be balanced if they are equal, implying that the knowledge to be discovered equals zero bits. However, maintaining a state of flow requires a slight leaning towards challenging tasks, meaning the knowledge to be discovered should be one or two bits.

Therefore, even if we can't quantify the prior knowledge and required knowledge in bits of information, we can indeed express their difference in terms of bits of information.

To quantify this balance, we need to assess how a developer felt while working on a task. This is difficult, if not impossible, to achieve accurately as it involves tapping into the individual's cognitive process.

Alternatively, to ascertain if the developer's capability and the task complexity were balanced, we can measure the knowledge discovered after successful task completion. We can employ Knowledge Discovery Efficiency (KEDE) for this measurement, as explained in details here..

The balance between individual capability and work complexity can be quantified by measuring the knowledge discovered after successful work completion.

If KEDE=100 then there was no knowledge discovered i.e personal capabilities were superior work complexity. If KEDE=0 then work complexity trumped personal capabilities. The best is when individual capability and work complexity were almost equal, with a slight inclination towards challenges.

For calculating the balance we use Shannon's formula:

Balancep1, p2=-i=12pilog2pi

In this context, p1 = KEDE and p2 = (1-KEDE) and the Balance function of one variable is:


This function exhibits positive values throughout, presents a concave or downward curve, and peaks at 1 when KEDE equals 1/2. Importantly, the function returns zero at both KEDE = 0 and KEDE = 1, denoting maximum imbalance.

Figure below shows the function Balance(KEDE).

Balance as a function of KEDE

Typically, KEDE values less than 50 indicate an imbalance leaning towards anxiety, while values greater than 50 suggest an imbalance leaning towards boredom. In both scenarios, the level of balance is less optimal than when the KEDE is at 50.

Interestingly, KEDE measurements propose a somewhat counterintuitive relationship between efficiency and developer happiness. The most efficient developers, those who require less discovery of new knowledge, may also be the ones who are most prone to boredom.

To ensure practicality and clarity in our analysis, we won't use balance values within the range of [0,1], but rather, we'll express them as percentages, falling within the interval [0,100]. By doing so, we can effectively gauge the degree of balance achieved. For instance, if the balance function returns 0.4, we would express this as a balance of 40%, indicating that the state of balance achieved is 40% of the maximum possible balance or conversely, we are 60% off from achieving perfect balance. This adjustment allows us to more intuitively comprehend the balance status in relation to developer flow state.

By implementing the Knowledge Discovery Efficiency (KEDE), we can assess whether a balance was struck between a developer's abilities and the complexity of the work.

More information about how KEDE measures this balance can be found Here. Real-world data on developer happiness is available here), and on project happiness here.

To practice measuring developer happiness, you can try the Knowledge Discovery Game. This game simulates the knowledge discovery process, enabling you to evaluate the balance between developer abilities and task complexity.

Practical examples of KEDE being used to measure

Consider the time-series diagram below, which illustrates developer's happiness for a selected period across all projects.

The x-axis of the diagram displays the dates of each week, while the y-axis shows the weekly happiness values. Each week's happiness level is represented by a blue dot on the diagram, giving you a clear visual representation of how the developer's happiness changes over time. Additionally, the dark blue line on the diagram represents the average weekly happiness for the developer, calculated using the Exponentially Weighted Moving Average (EWMA) method. By analyzing this line, you can gain a better understanding of the overall trend of the developer's happiness levels over time. But to gain a deeper understanding of a developer's happiness levels, it's important to compare them with the company averages. Each individual developer's weekly happiness is represented by a light gray dot, while the average weekly happiness calculated using EWMA is represented by a black line.

Along with the time series of the happiness it's very useful to see a histogram of weekly averaged happiness values, which displays the frequency distribution of happiness values over a selected period. The histogram below presents the weekly happiness values for a selected period, with the x-axis displaying the Weekly happiness and the y-axis showing the percentage of each particular value.

The histogram is presented in color for the developer, with the blue vertical line representing the average weekly happiness level for the selected period and the green vertical dashed line representing the median weekly happiness level. To gain a deeper understanding of the developer's happiness levels, it's important to compare them with the company averages. The same histogram can be generated for all other developers who contributed to all other company projects during the selected time period, with the histogram presented in gray. The black vertical line represents the average weekly happiness level for all other developers, while the red vertical dashed line represents the median weekly happiness level.

Understanding how a developer's happiness is distributed across different projects can provide valuable insights into how their work environment affects their mood. The diagram below presents a stacked bar chart that allows you to look at numeric values across two categorical variables. The first category is the developer's weekly happiness, and the second category is the projects that the developer worked on during the selected time period. Each bar on the chart represents the weekly happiness of the selected developer, divided into a number of boxes, each one corresponding to the happiness that the developer felt on a particular project.

The x-axis of the chart displays the dates of each week, while the y-axis shows the weekly happiness levels. By analyzing the chart, you can gain insights into how a developer's happiness levels vary across different projects and identify any patterns or trends that may be affecting their mood.


Throughout this article, we delved into the multifaceted domain of Developer Experience (DevEx), exploring its central dimensions: Feedback Loops, Cognitive Load, and Flow State. Acknowledging the importance of human factors in software development, we presented a new way of enhancing DevEx through the adoption of Kanban principles and practices and the utilization of the KnowledgE Discovery Efficiency (KEDE) metric.

Kanban practices can help manage and minimize Cognitive Load, allowing developers to focus their mental efforts more effectively. Meanwhile, KEDE, by quantifying the knowledge gap that developers need to bridge while undertaking tasks, provides a reliable measure of this cognitive load involved in software development assignments.

Kanban also supports achieving a flow state by smoothing the flow of work and reducing disruptions. KEDE can identify this by monitoring the discovered knowledge after successful work completion, providing an effective measure of whether developers are in a flow state.

Furthermore, Kanban enables quick and quality Feedback Loops by integrating them into the workflow and making them as short as possible. KEDE complements this by measuring the efficiency of information acquisition in relation to the number of active contributing software developers, which facilitates an understanding of how rapidly and effectively new information is assimilated and employed in the team's work.

By integrating the principles of Kanban and employing KEDE as a measuring tool, organizations can significantly enhance DevEx. This combination aids in optimizing development processes and task allocation, improving overall satisfaction, engagement, and productivity of developers.

Despite these promising advancements, there remains room for further exploration and improvement in this field. Software development is a complex and ever-evolving landscape. We urge organizations and teams to continue seeking innovative ways to enhance DevEx. The use of KEDE and similar metrics, along with methods like Kanban, should be considered a part of an ongoing journey to better understand and improve the conditions that foster productivity, satisfaction, and overall happiness among software developers. As the adage goes, a happy developer is a productive developer, and the amalgamation of Kanban and KEDE provides us with powerful tools to realize this goal.

Works Cited

1. Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler. 2023. DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. Queue 21, 2, Pages 20 (March/April 2023), 19 pages. https://doi.org/10.1145/3595878

2. Bakardzhiev, D., & Vitanov, N. K. (2022). KEDE (KnowledgE Discovery Efficiency): a Measure for Quantification of the Productivity of Knowledge Workers. BGSIAM'22, p.5. Online: https://scholar.google.com/scholar?oi=bibs&hl=en&cluster=1495338308600869852

3. Bakardzhiev, D. V. (2022). U.S. Patent No. 11,372,640. Washington, DC: U.S. Patent and Trademark Office. Online: https://scholar.google.com/scholar?oi=bibs&hl=en&cluster=3749910716519444769

4. Wu, T., Dufford, A. J., Mackie, M. A., Egan, L. J., & Fan, J. (2016). The Capacity of Cognitive Control Estimated from a Perceptual Decision Making Task. Scientific Reports, 6, 34025.

5. How many stars are there in the Universe? (n.d.). Retrieved January 11, 2022, from https://www.esa.int/Science_Exploration/Space_Science/Herschel/How_many_stars_are_there_in_the_Universe

6. Sweller, J. 1988. Cognitive load during problem solving: effects on learning. Cognitive Science 12(2), 257–85; https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1202_4.

7. Besedeš, T., Deck, C., Sarangi, S., & Shor, M. (2015). Reducing choice overload without reducing choices. Review of Economics and Statistics, 97(4), 793-802.

8. Deck, C., & Jahedi, S. (2015). The effect of cognitive load on economic decision making: A survey and new experiments. European Economic Review, 78, 97-119.

9. Miller, G. A. The magical number seven, plus or minus two: some limits on our capacity for processing information. Psychol Rev 63, 81 (1956).

10. Vogel EK, Machizawa MG. Neural activity predicts individual differences in visual working memory capacity. Nature. 2004 Apr 15;428(6984):748-51. doi: 10.1038/nature02447. PMID: 15085132.

11. Fukuda K, Vogel E, Mayr U, Awh E. Quantity, not quality: the relationship between fluid intelligence and working memory capacity. Psychon Bull Rev. 2010 Oct;17(5):673-9. doi: 10.3758/17.5.673. PMID: 21037165; PMCID: PMC3050565.

12. Unsworth N, Fukuda K, Awh E, Vogel EK. Working memory and fluid intelligence: capacity, attention control, and secondary memory retrieval. Cogn Psychol. 2014 Jun;71:1-26. doi: 10.1016/j.cogpsych.2014.01.003. Epub 2014 Feb 14. PMID: 24531497; PMCID: PMC4484859.

13. Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87-114. doi:10.1017/S0140525X01003922

14. Levitin, D. J. (2015). The Organized Mind: Thinking Straight in the Age of Information Overload (Illustrated edition). Dutton.

“120 bits per second This estimate derives independently from Csikszentmihalyi (2007) and the Bell Labs engineer Robert Lucky, who made an independent estimate that regardless of the modality, the cortex cannot take in more than 50 bits/second—within an order of magnitude of Csikszentmihalyi’s. Csikszentmihalyi explains his estimate: “As George Miller and others have suggested, we can process 5–7 bits of information in one apperception; each apperception takes at least 1/15th of a second; hence 7 × 15=105 bits/second. Nusbaum has calculated that understanding verbal material takes on the average 60 bits/second.”

15. Greifeneder, R., Scheibehenne, B., & Kleber, N. (2010). Less may be more when choosing is difficult: Choice complexity and too much choice. Acta Psychologica, 133, 45-50. doi:10.1016/j.actpsy.2009.08.005

16. Schwartz, B., & Schwartz, B. (2004). The paradox of choice: Why more is less.

17. Schaffer, O. 2013. Crafting Fun User Experiences: A Method to Facilitate Flow. Human Factors International Whitepaper. Retrieved from: https://scholar.google.com/scholar?cluster=9760324565241258858

18. Csikszentmihalyi, M. & Nakamura, J. (2010). Effortless Attention in Everyday Life: A Systematic Phenomenology . In Bruya, B. (Ed.), Effortless Attention. (pp. 179- 190). Cambridge, MA: MIT Press.

19. Choo, C. (1994). Perception and use of information sources by chief executives in environmental scanning, Library & Information Science Research, Volume 16, Issue 1

20. Anderson, D. J., & Carmichael, A. (2016). Essential Kanban Condensed. Lean-Kanban University.

21. Armour, P.G. (2003). The Laws of Software Process, Auerbach

22. Anderson, David J. 2011 “Understanding the Process of Knowledge Discovery”. DJAA blog: http://www.djaa.com/understanding-process-knowledge-discovery

23. Anderson, David J. https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/

24. Anderson, David J. 2013 “The Kanban Lens”, DJAA blog: https://djaa.com/the-kanban-lens/

25.Anderson, David J., 2015, Kanban Cadences, https://djaa.com/kanban-cadences/

How to cite:

Bakardzhiev D.V. (2023) Implementing the DevEx Approach Using KEDE https://docs.kedehub.io/kede-manage/kede-devex.html

Getting started