Agile workflow work-in-process (W.I.P) limits specify the maximum amount of work at any given time. Inefficient workflows can easily be identified when teamwork is limited. Identifying bottlenecks in team delivery pipelines before they become crises is manageable. Having W.I.P limits improves throughput and reduces work “nearly done” because it forces the team to focus on smaller tasks. At the most fundamental level, W.I.P limits foster a “done” culture. Furthermore, W.I.P limits make blocking and bottlenecking visible. As soon as it is clear what existing work is causing a bottleneck, teams can swarm around it to resolve, understand, and implement it. When blockages are removed, the team shares workflows again. Agile development relies on W.I.P limits partly because they ensure value increments sooner.
Kanban starts by visualising and plotting a work item’s stages in the software development life cycle (S.D.C). A user story resides in the leftmost column of the workflow stage, while the other columns show how to break it down. Adhering to the agile spirit by breaking down work items daily / frequently, i.e., effort spans should be at most a day or a maximum of two days, is vital. Information radiators can depict the workflow, including the Big Visual Chart (B.V.C), a whiteboard, or an agile life cycle management tool like Leankit Kanban. Kanban boards and Scrum boards are often used interchangeably. Although Kanban boards may look like Scrum boards with more columns, they are differentiated by their W.I.P limits. Since Scrum boards have three columns – Ready, In the Process, and Done – the team commits to delivering all work pushed/selected in time-boxed iterations, so tracking the process in more detail is not helpful. Once the workflow is in place, a team’s most difficult challenge is deciding on the W.I.P for each stage. This must be done based on the team composition and the project’s internal constraints. Kanban is based on a pull system, which is essential to understand. Work items can be pulled from the previous stage once the number of items in the column falls below the defined W.I.P limit.
In the case of a work item that cannot proceed to the next stage due to a constraint, this item will still be included in the Work in Process limit and will stymie the workflow. Workflow can be stopped entirely if all work items are blocked. In such a case, the team must eliminate the blocker. Through Kanban practices and maintaining a disciplined policy of not exceeding work in progress, the team could reduce multitasking and increase collaboration/team interaction. By defining explicit policies based on historical execution patterns, the team can ensure they do not sit idle and revisit breach instances that breach the W.I.P limit. Teams must mutually agree to the WIP breach policy. Otherwise, pulling tasks beyond the expected WIP is easy, leading to Kanban system failure.
In a Kanban team, the real challenge is determining the work in process (W.I.P) for each workflow stage (column), the same enigma scrum teams face when deciding on the velocity to commit to in the first sprint. Traditional SDC teams usually plan to begin parallel tasking, anticipating that more work items will speed up the process. On the other hand, Kanban is geared toward reducing work items in the process. This is so that a work item moves towards completion faster and is easier to track down.
The lower number of work in the process is bound to be viewed with scepticism when a team begins using Kanban as they attribute it to a lower level of productivity. Initially, you may have considered choosing a smaller amount of work. This makes the work in process approximately equal to the number of people in the team who work on the stage. Nevertheless, that is unlikely to result in the most effective Kanban system. Distributed agile teams working in different time zones often move work items to the ‘wait’ state rather than blocking them. Although a lower work in process will allow the team to focus on completing a task and keep it moving more quickly, it will also reveal workflow dysfunction very quickly. As a result, stakeholders should be comfortable making changes and addressing them as soon as possible.
Most teams are tempted to choose a higher W.I.P number since this will allow them to take on upcoming work items even if the task they are working on is blocked. As they say, the show must go on! Think again. High W.I.P can lead to scenarios where team members do not need to interact. Knowledge silos would result from this, and any changes in the team would result in knowledge loss. This would prevent the team from delivering the work item on time and to an acceptable standard. Additionally, many works-in-process (W.I.Ps) can cause congestion at one stage, such as a test-in-process (TIP). It may result from a skewed team mix, where testers are less than developers. The time taken to complete development and testing may also differ, so the amount of work completed will likely be slower than the amount of time it takes to complete testing. As a result, work items will accumulate during the Test Ready stage.
Using the theory of constraints (T.O.C), the team can concentrate on the process/task in the chain, resulting in delays in overall processing and low throughput. The team should identify bottlenecks in this phase: What causes delays, underutilisation, and resource waste? The team should brainstorm solutions to overcome low output constraints. There may be several reasons, including time-consuming design reviews, complicated systems and a new team, additional time required by a new team member, inability to access systems, downtime during specific periods, and participation in too many activities, which can help the team arrive at a viable solution to weed out waste. However, they must focus on these solutions and improve system output.
Identify the system’s constraint(s); for example, these may include an idle testing team, localised knowledge, pending access to the system, and waiting for clarifications. Decide how to exploit the system’s constraint(s) (how to get the most out of the constraint); for example, the testing team should share production support tickets when idle. The team should receive cross-training on tickets if knowledge is localised: 1) Subordinate everything else to that decision. 2) Elevate system constraints. 3) Continue to improve
To answer our customers’ questions, we must track these flow metrics. The flow metric Cycle Time most accurately answers the customer’s question, “How long does it take to complete?” Customer questions such as “How many added features will I receive in the next release?” are best addressed by the flow metric Throughput. Work In Process (W.I.P), the third metric, does not directly address any specific customer question but significantly impacts the other two. It is essential to track Work In Process for two reasons. First, W.I.P is the most accurate predictor of overall system performance. Cycle Time and Throughput will be defined as a function of W.I.P. However, defining W.I.P can be difficult because the work-in-process concept encompasses “work” and “in process”. Second, to determine the process, we must first identify the boundaries of your process, which can be represented in a simple queue.
To summarise, to properly define a process, your team must determine at which point it considers the work to be in the process. In addition, it must determine when it considers itself out of the process. The definition of those two system boundaries is the crucial starting point in predictable process design. Once you have made those choices, all work items between those two points will count as Work In Process. W.I.P is measured by counting the discrete number of items within your process boundaries as defined above. That is it. You need to count each item within your process boundaries to calculate WIP.
You may object, “Don’t you have to make all your work items the same size?” After all, the work items that flow through your process may have varying durations and complexities and require varying levels of resources. It is reasonable to ask how one can account for this variability and create a predictable system simply by counting work items. Although this is a valid question, it is not something to worry about.
Queue, Push, or Pull?
Work arrives at processes and departs from processes in a queueing system. To determine whether a particular task or process is in process, the system’s first aspect to be considered is what it means for something to be “arrived” in a system. As a result, your team needs to establish a specific point at which a unit of work transforms from just an arbitrary idea into a legitimate work item that needs to be addressed and completed immediately. An item not reaching this point is considered a candidate for work. After this point, the item is considered a work in process.
When a team uses a pull-based system, entry (or boundary) points are relatively straightforward to define and is because, in a pull system, a team only starts working when it is capable of doing so. Work items can only be considered Work In process if they have been voluntarily incorporated into the process by the individuals, teams, or organisations responsible for running it. Therefore, the “arrival point” of the system refers to the time at which the first pull transaction is conducted on the team’s work. Once an item has been pulled, it is considered WIP until it leaves the process after the first pull transaction.
Determining the entry point for push-based systems is much more challenging because the team’s capacity is not considered when determining when work should be started. As part of a push system, work is considered underway when any stakeholder has a reasonable expectation that work has been committed to (whether the team responsible for performing the work knows about or agrees to it or not). The reasons for this expectation may include requests for work, funding for the project, or the opinion of a supervisor that a start is advisable, regardless of the resources available.
There must be a specific point at which the work item ceases to be considered work in process. It could be considered a departure if delivery to a downstream team or process is viewed as a departure. It may be the case, for example, that a development team considers an item left after deployment to production. Alternatively, a team not in charge of deployments may consider an item departed once it has been reasonably handed off to a downstream operations team, who would then be responsible for deployments. In both pull and push systems, the definition of a point of departure is the same.
In summary, Kanban teams need to balance and understand the relativity of higher and lower work in process, along with gains and losses in project execution. Upon reviewing the throughput and considering the training/skilling contingency for the individual who recently joined the project, the team can decide whether to accept work items. Once the team becomes familiar with the nature of tasks, efforts, inflow, and team constraints, they move from being a “forming”, “norming”, and “storming” team to becoming a “performing team”.
