Kanban

Kanban is a method for defining, managing, and improving services that deliver knowledge work such as software development. It promotes a "start from what you do now" approach, acting as a catalyst for rapid and focused organizational change. A hallmark of Kanban is the use of a kanban board to visualize work, partitioned into columns that represent workflow. Kanban encourages viewing the board as a knowledge discovery process, with each column denotes different knowledge discovery activity that a work item passes through.

However, the typical Kanban practice advices on limiting work in progress (WIP) by the number of cards, which controls the flow of tangible work items rather than the flow of intangible knowledge. In knowledge work we need to limit the missing knowledge a team needs to discover. We adopt the Knowledge-centric perspective and limit not the number of cards, but the amount of missing knowledge.

The Knowledge-centric perspective does not contradict the principles of Kanban. Instead, it substantiates the claim that a Kanban board maps a knowledge discovery process.

Here’s how you can apply a Knowledge-centric perspective to your Kanban practices starting next Monday:

1. Refine Your Kanban Board: Begin by viewing your Kanban board as a map of your knowledge discovery process. The board not only segments work into stages but also acts as a navigational tool that guides through the steps of gaining new knowledge. The differentiation between the discovery and delivery parts of the Kanban board highlights the management of work items from initial exploration to the commitment of delivery, emphasizing the critical role of experiments and the pull system in managing work in progress effectively. This helps you and your team visualize where knowledge is discovered and where bottlenecks might occur.

   In our Knowledge-centric approach, WIP limits are set at the top of each column, but the numbers reflect the minimum bits of missing information that need to be present in a column at any time.

   It's essential not to think of the Kanban board as segregating 'discovery' and 'delivery' into distinct phases. Rather, discovery and delivery are concurrent processes; we are always discovering as we deliver, and vice versa, ensuring a continuous flow of knowledge and tangible work.

2. Categorize Work with a Complexity Profile Matrix: Use a Complexity Profile (CP) matrix to categorize work items based on the missing knowledge they require to be disoevered. This classification will guide you in prioritizing tasks and managing workflows more effectively.
3. Implement the Knowledge Discovery Funnel: Integrate the Knowledge Discovery Funnel into your daily routines. This tool acts as a dynamic guide for filling in gaps in understanding and ensuring that every task is aligned with the team’s skills and project goals.
4. Use the Pull System: Emphasize experimenting with new ideas and solutions within the discovery stages of your board. Utilize the pull system to manage work in progress by ensuring tasks are only moved forward when they are truly ready and the necessary knowledge to do so has been acquired.
5. Merge Knowledge-Centric and Flow Metrics: Finally, integratte the Knowledge-Centric Metrics with traditional Flow Metrics to provide a holistic view of the process. While Flow Metrics quantify tangible logistics, Knowledge-Centric Metrics address the intangible aspects, offering insights into the knowledge gaps, cognitive load, and overall efficiency of the knowledge discovery process. Together, these metrics provide a comprehensive framework for understanding and improving practices, bridging the gap between tangible logistics and the intangible aspects of knowledge work.
6. Track Learning Curves: Monitor the cumulative growth of knowledge within your team using learning curves. This approach to measuring and analyzing the rates of knowledge discovery provides valuable insights into project complexity, team adaptability, and the overall project lifecycle, thereby enabling more informed decision-making regarding resource allocation, training, and process adjustments.
7. Adopt Probabilistic Forecasting: Replace traditional project forecasting methods with a probabilistic approach using Reference Class Forecasting (RCF). This uses historical data about rates of knowledge discovery from similar projects to better manage the uncertainties of project timelines, considering both past outcomes and current learning rates.

By integrating these practices, your team can start improving your workflows right away. This practical, knowledge-centered approach to Kanban will help you manage complexity more effectively and make more informed decisions about your projects and resources. This isn't just theory—it's a set of actionable steps that can transform the way your team works.

getKanban Game Overview

getKanban is a popular simulation game, invented by Russell Healy It has since become a standard tool in Kanban training workshops.

The game is designed for teams of four to six players, with one game set per team. Each team is provided with a playing board that simulates a Kanban board and a set of tickets that represent work items to be completed. Tickets are moved through different stages—typically Analysis, Development, and Testing. Each ticket is marked with several white dots divided into three sections: Analysis, Development, and Test. These dots indicate the amount of work needed to complete the task. Teams must clear all the dots in one column to move a ticket to the next.

A team has two Analysts, represented by two red dice, three Developers represented by three blue dice, and two Testers represented by two green dice. During gameplay, dice are allocated to tickets to represent work efforts. Dice can be assigned to tasks outside their specific roles. For example, an Analyst might work on a Development task. However, when a die is used for a non-specialized task, its value is halved and rounded up to the nearest whole number. Once all dice are placed, they are rolled to progress the tickets. After being rolled, the dice are considered "spent".

A Knowledge-Centric Interpretation

What does “work needed” mean? Is the work to write the source code? Or the effort to think about and decide what to write? It is not clear what is being "spent" - is that physical, manual effort or something intangible like knowledge?

Here is the Knowledge-Centric Interpretation:

1. Each white dot on the game's tickets symbolizes a unit of required knowledge.
2. Each section on a ticket represents a type of knowledge. Analysis represents mostly "what to do" knowledge. Development represents "how to implement the what to do" knowledge. Testing represents "what to do" knowledge.
3. Each pip (dot) on a die represents a unit of prior knowledge. Sometimes the die will roll 1, other times it will roll 6. That represents the likelihood of a team member possessing the required knowledge for a task. .
4. Using a die outside its specific function halves its value, illustrating the challenges when a person's prior knowledge doesn't perfectly align with task requirements. and probability to have the required missing knowledge decreases.
5. The difference between the required knowledge and the prior knowledge is the knowledge to be discovered. That simulates a real world situation where people need to discover new knowledge on top of their prior knowledge.

For instance if we say that the ticket S12 is to be worked on and the team has rolled their dice and got:

• 6 pips on 1 read die
• 2 pips on 1 blue die
• 4 pips on one blue die

Categorizing work items by knowledge to be discovered.

"In knowledge work the key question is: What is the task?" ~ Peter Drucker [9]

A service is a system composed by the people, who will deliver and the people, who define what to be delivered. We shall call the former group Capability and the latter group Client. Capability is represented by the delivering organization's knowledge, skills and experience. The Client is responsible for defining the task i.e. "what to do". The Capability is responsible for defining "how to do the what".

In knowledge work, the value lies in knowing “What” customers need and “How” to satisfy their needs via products or services.

In Kanban we don't use "task" but "work item". A Work Item is a deliverable or a component thereof resulting from the demand placed at the system that will be worked on by a service. A Workflow is a series of activities that results in products or services being delivered. The workflow or a selected part of it is represented on a Kanban board by a set of sequential columns showing the knowledge discovery activities that the work item passes through. In Kanban, a Work Item Type is a grouping of work items that behave similarly and follow the same workflow. Examples of work item types are information requests, campaigns, incidents, defects, product features, whole products, or projects.

We will categorize work items by the amount of knowledge to be discovered i.e. by the amount of missing information. All work items can be broadly categorized into three types:

• Having Knowledge to be discovered on what to do: This pertains to the overall problem definition of the work item.
• Having Knowledge to be discovered on how to do it: This involves the specific solution or methods required to complete the work item.
• Having Knowledge to be discovered on both what to do and how to do it: This encompasses both the overall problem definition and the specific solution or methods needed to complete the work item.

When a work item is a whole project we will use the process explained in detail here to find the amount of missing information in bits.

It's essential to note that the observed missing information is subjective and conditional. The same work item could have different observed missing information for different observers, depending on their prior knowledge, understanding, and perspective.

Prior knowledge significantly influences the knowledge to be discovered, as it provides a foundation upon which new information is built. Additionally, prior knowledge of different domains can jointly support the recall of arguments[5].

Complexity represents the gaps in understanding or information that a team or a person believes they lack and need to learn.

It is more convenient to represent the three types of knowledge to be discovered in order to deliver a work item in a matrix, which we will refer to as Complexity Profile (CP) as presented on the figure below.

The vertical axis in the matrix represents whether the team has a clear and distinct understanding of the work item, that is, whether they know what to do. The horizontal axis represents whether the team knows how to complete the work item. Here knowing is represented as a binary variable, where the team either knows or does not know.

The green quadrant represents a state where the team has a complete understanding of both the problem definition and the solution, and according to our definition of knowledge this means that no new questions need to be asked. No alternatives, only one clear problem-solution combination to deliver the work item.

The orange and amber quadrants represent states where multiple alternative combinations of problem definition and solution exist.

A Complexity Profile (CP) is context dependent.

We subdivide each of the two dimensions into three ranges of the amount of knowledge to be discovered in bits of information:

• Clear. There are no alternatives. It requires zero questions to be asked. There are zero bits of missing information.
• Complicated. There are up to 16 alternatives and it requires at least 1 and up to 4 questions asked in a row, in sequence, linearly. There are between 1 and 4 bits of missing information.
• Complex. We have just a vague idea about what we don't know i.e. there are unknown unknowns. They'll have to explore many alternatives before picking one. It requires: at least 5 and up to 99 questions asked, but not in a row, not in sequence and non-linearly. That is, there are between 5 and 99 bits of missing information.

Below is the same presented in a table format:

We split the amber and orange boxes based on the number of Questions.. That will make the number of boxes nine instead of four and give us the operational Complexity Profile (CP) of our project as presented below.

In order to make the x- and y-axes tidy we will put “O” for Clear, “A” for Complicated and “C” for Complex.

Now we can color the nine boxes and omit the number of questions for convenience.

Importantly, when we're considering the combination of alternative problems and solutions for a work item, the total number of alternatives multiplies. However, the total bits of information is the sum of the bits of information for each individual alternative.

The rules are as follows:

• If a work item is Complex either from "How"" or from "What" perspective, it is considered Complex.
• If a work item is Complicated either from "How"" or from "What" perspective, it is Complicated.
• Clear are only work items which are Clear in both perspectives.

The Learning Curve

Recall, that software development is a process of knowledge acquisition and ignorance reduction[8]. It's a journey to identify and close knowledge gaps, reduce our uncertainty, and increase our knowledge iteratively. During each and every step, we discover and accumulate more knowledge about the work item. Upon delivery the process of knowledge discovery is completed. This dynamic can be represented by a learning curve.

The learning curve in software development encapsulates the accumulation of the knowledge discovered about "what to do" and "how to do it". Adopting a Knowledge-Centric approach, we measure this accumulation in bits of information, treating knowledge as the fuel that drives the software development engine.

The learning curve can be visualized by tracking the cumulative amount of knowledge discovered over time. For instance, consider a diagram illustrating the knowledge growth in bits for a specific project.

Over the given period, the total knowledge discovered accumulated to 1.2*109 bits or 1.2 terabits (Tbits). The blue line marks the cumulative knowledge growth, reflecting the team's advancement in the project.

To facilitate meaningful comparisons across projects with varying scales of knowledge acquisition, normalization of data is essential. Direct comparisons based on raw knowledge values, measured in bits, can be misleading due to differences in project scale.

Learning rate measured in bits of information discovered per unit of time, is a critical aspect of this curve. The higher the learning rate, the faster the knowledge discovery process. It assigns an improvement value to gauge the efficiency rate as engineers learn and become more knowledgeable[4].

We employ the cumulative growth rate (CR) of knowledge discovered, measured in bits of information discovered per unit of time, as a key metric for measuring normalized growth. CR effectively normalizes growth by taking into account variations in project sizes, durations, and initial knowledge levels. This approach transforms CR into a relative measure, enabling fair and equitable comparisons across diverse projects. The methodology for calculating CR is presented here.

In the diagram below, the x-axis represents the timeline (in weeks), while the y-axis denotes the cumulative growth rate. The lines trace the cumulative growth rate for two projects over a period.

There are three different types of learning curves. We present them visually on the below diagram.

Each type provides insights into the dynamics of knowledge discovery and application, reflecting different project environments and stages of development.

Here's a short description for each of the three learning curve types measured using the Cumulative Growth Rate (CR) of knowledge discovered, along with insights into what each type might reflect about a project environment:

1. Increasing learning rate:
   • Description: This curve shows a consistent increase in the learning rate over time, indicating that the rate of knowledge discovery is steadily growing.
   • Project Environment Implication: This scenario might reflect a highly innovative environment where continuous experimenting and discovery are encouraged, and new challenges or technologies are frequently introduced. It might also indicate challenges or obstacles that are hindering learning and growth, such as ineffective knowledge sharing and collaboration, resource constraints, loss of key personnel, or a shift in project goals. For knowing the real cause we need to look inside the organization. Here is a case study of a blockchain company.
   • Example scenario in real-world projects: A startup working on an innovative blockchain project. In the early stages, the team has a basic understanding of blockchain but needs to rapidly adapt to emerging technologies and methodologies. As the project progresses, they continuously encounter new challenges requiring novel solutions, leading to a consistently increasing learning rate.
2. Learning rate Levels Off:
   • Description: The learning rate initially increases but then reaches a plateau, indicating that the rate of new knowledge discovery slows down and stabilizes.
   • Project Environment Implication: This pattern is often seen in projects with a clear development, growth, and support phase, such as technology implementation projects. The initial fast growth represents a phase of rapid learning and low productivity, where there is accumulation of new knowledge. The slowdown indicates a phase of working on already well understood tasks, probably with high productivity. Finally, the project matures, and the rate of encountering new knowledge stabilizes. The leveling off suggests that while new knowledge is still being gained, the rate of learning has decreased, possibly due to the team becoming more experienced and encountering fewer unknowns. This pattern is typical of a mature project environment where the team has acquired substantial knowledge and established stable processes. This could also reflect a shift in focus away from exploration and towards optimization or routine work as the project goes into support mode.
   • Example scenario in real-world projects: A software development team working on a long-term enterprise resource planning (ERP) implementation. Initially, there's a steep learning curve as the team familiarizes itself with the client's unique requirements and how they could be implemented with the specific ERP software. Over time, as they gain expertise, the learning rate stabilizes, and the team becomes more efficient in applying their knowledge.
3. S-shaped learning rate:
   • Description: The learning rate curve starts with a slow knowledge growth, accelerates to a peak rate of knowledge discovery, and then slows down again, forming an S-shape.
   • Project Environment Implication: This pattern is also often seen in projects that go through distinct stages. The initial slow growth of knowledge discovered represents working on routine, well understood tasks, leading to higher productivity. That could probably be done to make a good impression of high productivity. The acceleration indicates a phase of rapid learning and low productivity. As the curve progresses and the learning rate increases, this could indicate a phase where the team is encountering the real challenges of the work to be done, requiring more learning and potentially experiencing a temporary dip in productivity. Finally, the slowdown occurs as the project matures, and the rate of encountering new knowledge decreases. From a project management perspective, this is a wrong way, because they tried to deny the reality, which is a constant acquisition and application of new knowledge.
   • Example scenario in real-world projects: A software development team is tasked with creating a new mobile application. Initially, they focus on basic functionality using familiar technologies, leading to a low learning rate and high productivity. However, as they start integrating advanced features like machine learning for personalized user experiences, the learning rate accelerates and productivity lowers. Eventually, as the major challenges are addressed and the team becomes proficient, the learning rate slows down and productivity improves again.

Each of these learning curve types not only reflects the rate of knowledge acquisition but also provides insights into the project's complexity, the team's adaptability, and the overall project lifecycle. By analyzing the learning rate, project managers and teams can better understand their learning environment, identify areas for improvement, and make informed decisions about resource allocation, training, and process adjustments.

The Learning Curve as a Leading Indicator

Project managers are encouraged to use the learning curve of their current project as a benchmark against a reference class of past similar projects. Unlike traditional metrics such as throughput and lead time, which are only measurable after work items are completed and delivered, the shape of the learning curve becomes visible just a few weeks into the project.

This early visibility allows managers to anticipate problems well before any deliverables are affected. If a team is not acquiring knowledge at an expected rate, it may indicate underlying issues within the project. Conversely, if a team acquires the necessary knowledge at the expected rate, the process is considered predictable. This insight allows managers to investigate and address the root causes proactively.

The below diagram provides a comparative view of six project learning curves:

The x-axis of the diagram represents the timeline, measured in weeks, while the y-axis indicates the cumulative growth rate (CR). Reference Class Curves are in blue. These curves represent the learning trajectories of similar past projects. They serve as a benchmark for expected knowledge growth. The red curve illustrates the learning rate of the current project. How the diagram is prepared is explained here.

In this example, we observe that the CR of the new project is not aligning with the trend seen in the reference class. This discrepancy suggests potential areas within the new project that may require closer examination and intervention.

Meetings

In software development, the journey from an initial concept to a finished product involves continuously filling in gaps in knowledge about "What" needs to be done (the requirements and goals of the project) and "How" to do it (the technical and strategic implementation details). Meetings play a crucial role in this process by facilitating the exchange of information among all parties involved, such as developers, managers, and clients.

Here's how meetings help address these two foundational areas based on the Purpose of Meetings:

1. Understanding "What" to Do (The Requirements)
   • Requirement Gathering Sessions: These meetings involve stakeholders and developers and are crucial for capturing the detailed needs and expectations of the client. The main goal is to transform vague ideas and business needs into clear, actionable requirements that the development team can work on.
   • Planning and Prioritization Meetings: During these sessions, the team discusses and decides on the features and tasks that are of the highest priority based on the requirements gathered. This includes breaking down large tasks into manageable pieces, estimating timelines, and setting milestones.
   • Progress Updates and Stand-ups: These are shorter, regular meetings where team members report their progress on the tasks assigned. This helps ensure that the project is on track and aligned with the 'What' that was defined. Any deviations or misunderstandings about the requirements can be quickly addressed.
   • Client Review Meetings: These meetings are held to show progress to clients and confirm that the development aligns with their expectations. They are crucial for validating that the team's understanding of 'What' needs to be done matches the client's vision.
2. Understanding "How" to Do It (The Implementation)
   • Design Discussions: Once the requirements are clearly understood, these meetings focus on the technical aspects of how to implement those requirements. This involves selecting technologies, defining software architecture, and discussing design patterns that best fit the project’s needs.
   • Code Reviews: These meetings are technical sessions where developers critique each other’s code. The primary goal is to ensure that the code not only functions as intended but is also well-structured, clean, and maintainable. These sessions help disseminate best practices and shared understanding of the implementation details. These meetings are essential for ensuring that the code being written aligns with the project's standards and best practices. They help identify potential issues early on and maintain code quality throughout the development process.
   • Retrospectives: These meetings are held after a project phase or sprint to reflect on what went well, what didn't, and what can be improved. They are crucial for learning from past experiences and continuously refining the development process. By discussing the 'How' of the project, teams can identify bottlenecks, inefficiencies, and areas for improvement.
   • Knowledge Sharing Sessions: These meetings are focused on sharing expertise, best practices, and lessons learned among team members. They help disseminate knowledge, foster collaboration, and ensure that the team is aligned on the technical aspects of the project. By discussing the 'How' of the project, teams can identify bottlenecks, inefficiencies, and areas for improvement.
   • Problem Solving and Debugging Sessions: When developers encounter technical hurdles or bugs, these meetings are used to pool collective expertise and find solutions efficiently. This collaborative approach can significantly speed up the problem-solving process.

By organizing and conducting these various types of meetings, software development teams create a structured approach to both discovering and disseminating knowledge. Meetings act as critical nodes where information is exchanged, decisions are made, and consensus is reached. As such, they are essential for systematically reducing the unknowns in both the 'What' and the 'How' of software projects, thereby driving the project from an idea to a deliverable product with minimized risks and maximized efficiency.

Synthesis

Synthesis is the intellectual process of combining different ideas to form a new, comprehensive understanding. It involves:

• Objects: The basic entities that make up reality, having properties that define their nature and identity.
• Properties: Attributes of objects, such as color, shape, and size, that distinguish them from one another.
• Relations: The connections between objects, or between objects and properties, like causality and spatiotemporal proximity.

Synthesis begins by viewing individual elements as part of a larger whole, focusing on the system rather than its components. This approach follows the principle that the behavior of a whole system explains the functions of its parts. Synthesis makes complex systems understandable by explaining parts through their roles in the whole, thereby simplifying the creation of comprehensive solutions.

Synthesis is the process of making complex things complicated.

For instance, in developing an e-commerce website, recognizing the relationships between products, customers, orders, and payment methods is crucial. A synthesized approach could lead to features that enhance user experience, such as easy access to purchase history or recommendations based on product relations.

Analysis

Analysis is the process of systematically examining an object to break it down into its manageable parts, understand their interconnections, and identify underlying patterns and relationships.

In software development, analysis involves dissecting a problem or system to grasp its essentials—requirements, constraints, and design considerations. This foundational understanding guides the creation of solutions that more accurately address the needs within a problem domain.

Analysis means obtaining answers to known questions.

Using analysis we make the complicated work items clear or pick one of the good alternatives.

Essentially, analysis is about answering specific questions to clarify complex scenarios or choose the best alternative. For example, in the context of an e-commerce website, analysis would entail examining the properties of "Products" and "Customers" and their interaction ("A customer can purchase one or more products") by asking:

• What are the properties of products (e.g., name, price, category)?
• What are the customer properties (e.g., name, email, purchase history)?
• How does the customer-product relationship influence the website's design and features?

This detailed inquiry leads to informed solutions that enhance the user experience, such as a navigable product catalog, efficient customer account management, and a streamlined checkout process. Through analysis, software developers can construct a website that not only aligns with customer needs but also optimizes their interaction with the site.