Learn how the Portfolio Kanban technique helps you deliver projects or initiatives faster by visualizing and limiting work at the portfolio level.
One of the first questions that experienced project managers or program managers usually have when attempting a Portfolio Kanban implementation is “What to do with WIP Limits on the Portfolio Kanban level?”.
Unless your company or department is intentionally limiting work in progress, you will most likely see many long-running initiatives that never seem to end.
Moreover, the portfolio will be spreading itself thin across different initiatives or investment areas, and that’s not how you create impact. The Portfolio Kanban technique will help you achieve your goals faster by concentrating resources and energy only on key initiatives and will transform your teams from being motionable to being actionable.
The long-term average number of customers in a stable system L is equal to the long-term average effective arrival rate, λ, multiplied by the average time a customer spends in the system, W; or expressed algebraically: L = λW.
Kanban borrows this principle and transforms it as the following:
The long-term average number of Kanban cards in a stable system (WIP) is equal to the long-term average throughput multiplied by the average cycle time a Kanban card spends in the system or expressed algebraically: avg. WIP = avg.Throughput * avg Cycle Time or also avg Cycle Time = avg. WIP / avg. Throughput.
Given that your system is stable (the average arrival rate is roughly equal to the average departure rate and WIP age is not growing), you can claim that the average WIP and the average Cycle Time are proportionate.
This is a powerful concept because the lower your WIP is, the faster you will deliver. Let’s keep this in mind for the rest of this article!
Most often, Kanban starts on the team level as a more flexible delivery method and not directly as a Portfolio Kanban implementation. While this is a necessary first step, it might be a risky move, especially if the organization is siloed and team communication is hindered.
Why is that? The answer is quite simple – if a team works in isolation, but deploys new methods for productivity and efficiency, such as Kanban, then in certain cases, the team might be contributing to starting a lot of work on the company/department level, which the rest of the teams cannot catch up with.
Let’s take as an example the features that a product company has to deliver. Assuming the typical team structure that most enterprises today have, at least 20% to 30% of the features will require engagement from two or more teams.
Then, if team A is much faster than team B, you will see the following picture over time:
That is why you need a way to control how many features you have in progress and how many new ones get started. This is a compelling concept that brings Lean to the entire organization.
If you take the same “feature management” example, the right thing to do would be to impose a global Portfolio Kanban WIP Limit. It will essentially prevent new features from being started, even if team A has the capacity to do it.
In this case, you might have team A being blocked or idle, but it is crucial to understand that having one idle team is a smaller problem than having a whole company stacked with started but not finished work.
There is no team out there that has a perfect architecture or perfect test automation. Just give them the time to improve these. It would be a much better investment than keeping everyone busy on the local level while doing damage on the global.
Whenever you have cross-team dependencies, it is good to start looking into a Kanban Portfolio visualization. It will give you:
During the 30-day trial period you can invite your team and test the application in a production-like enviroment.