Portfolio Kanban

In 2011 we implemented our first Portfolio Kanban system. Since then we’ve continued to evolve and learn, fine tuning the practices required to run a successful portfolio.

In this free practical guide to Portfolio Kanban we guide you through getting organised to help you to deliver software and services at scale.

We cover the specific practices and elements of a Portfolio Kanban and how to implement them, and share relevant case studies from our clients. Here’s your chance to see Portfolio Kanban in action!

What problems can Portfolio Kanban help you to solve?
Basic concepts for Portfolio Kanban
The importance of queuing
Lead Time and the relentless pursuit of improvement
Portfolio Kanban Case Studies
Don’t forget the teams level!
Operating Portfolio Kanban
Requirements Management at Scale
Eek! We’ve visualised our portfolio and we’re in a right mess. What do we do?!

What problems can Portfolio Kanban help you to solve?

Here’s some common themes we’ve come to recognise when working with large portfolios of work and how the techniques described in this article can help you:

Maintaining strategic alignment whilst scaling
The more we scale the more complex our dependencies become
The complexity and overhead of resource management increases as we scale
Governance, Risk and Control is ever more challenging as we scale
The bigger we get the longer it takes to get anything done
We are unable to change direction quickly due to our size
Balancing BAU with strategic work, planned vs unplanned work
Accelerate delivery across the entire enterprise

Basic concepts in Portfolio Kanban

Portfolio Kanban is best represented as a flow of value from left to right. All work tends to go through some kind of governance approval process to approve the expenditure of money.

Work items on the left-hand side of this flow can be initiatives, large features or for organisations still using projects as a vehicle for delivery these can be projects. They break down into smaller chunks of value the further right you go.

The general idea is that you take a large piece of work and break it down if necessary. The pieces of the work then flow through one of more delivery teams to completion.

Throughout this process you need to manage tracking, sequencing of work, manage dependencies and blockers.

At Solutioneers we have pioneered a number of very subtle mechanisms when implementing Enterprise Portfolio Kanban to meet the specific needs of our clients, and we share them here with you now. Just for clarity, we each board in this section represents a single Portfolio Kanban system. Some are configured differently to meet the specific needs of the organisation implementing them. The numbers are used to highlight specific “features” that you may pull out to implement within your own portfolio kanban:

1) This is a general catch-all hopper. Consider it the widest end of the funnel to capture and prioritise new work requests

2) When a work item is selected from the enterprise hopper column and moved to the What column, a small amount of activity is undertaken to understand what is being requested. Some organisations use this as a triage step in the flow.

3) The why column is to understand the purpose and perceived value in doing the work. Note these columns can have min and max wip limits placed upon them.

4) The How column – High level architecture, high level identification of Epics, high level planning in terms of understanding which team(s) will support the delivery of these work items.

5) Work items in this column are in a queuing state. They mustn’t be classed as work in progress yet. You may have a hill to climb in educating your stakeholders about the this. Work items are laid out in rows at this point by team with a WIP limit applied per row.

6) Project In Progress (PIP) – a post-it note in this column represents an entire project or feature a team is working on. This single post-it note could explode out into hundreds of stories or tasks on the team level board. Therefore, it’s critical to limit projects in progress to 1 per team.

7) Blockers are bubbled up to the portfolio Kanban as a form of escalation and represented by magenta post-it notes in this example.

8) The team capacity column is used to raise gaps in the teams capacity by listing out the names of each team member. Apply red dots to individuals who are shared across multiple teams. If you have vacancies in a team then list them here also. This raises awareness of team gaps and provides focus to resolve the issues.

Portfolio Kanban

Take a deep dive into Portfolio Kanban on our instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.

9) Business demand is listed by strategically aligned streams or swim lanes on the board. The top five requests of each theme is listed. There will undoubtedly be more demand than five work items but this constraint should drive out the true priorities.

10) The Next column is used as a selection column for when you have more than 3 strategic themes to choose from. Limit this column to facilitate a healthier discussion around priorities.

11) The Incept column is used to run a mini-inception or elaborate the requirements further. During the inception the inception team works out which teams will be required to deliver the business solution. IMPORTANT NOTE: this is where strategic themes translate/map into team capabilities. A single work request on the demand board (aligned by strategic theme) could explode out into a project/epic for each delivery team.

12) Work is queued here awaiting team capacity to deliver.

13) The Embed column is used when a team needs to keep an eye on a recent release in case of any issues. How long a release stays in this column should be decided by each team individually.

14) Some teams keep the work items on the board whilst they measure the benefit delivered by the release.

15) On this board we can see a really simple portfolio Kanban. Projects are queued up for each team to provide visibility of upcoming work.

16) For each work item in progress (PIP column) stakeholders really want to know when it’ll be finished so they can get the team started on the next work item. The tracking area displays forecasts of when work is expected to complete. This can be represented as Burn-up/down charts, cycle time distribution histogram with an associated percentile confidence level specified.

Portfolio Kanban

17) The portfolio Kanban is sometimes used to visualize release management. In this example we can see teams 1,2 & 3 are all working towards Release Train 1 (RT1) and team 4 are working towards Release Train 2 (RT2). The Release Mgmt->Ready column can be limited or unbounded as can the Release Mgmt->WIP column.

Even though there are many different ways to blend all the above mechanisms they should provide you with a common set of characteristics:

They clearly represent the flow of work from left to right
Provide a transparent mechanism both org-wide and at the team level for balancing demand and supply with a clear prioritisation mechanism.
They visualise blockers and impediments to flow
Use an empirically based approach for forecasting and tracking to improve stakeholder engagement
Maximise return on investment by identifying and tackling sources of variation in throughput.
Amplify org learning by ensuring adequate feedback loops are in place.
Get a better operational focus in the teams, rather than just delivering new features and chucking them over the wall?
Get people excited about delivering small, evolutionary changes (not just the big ticket stuff)?

Introduce the concept of Queuing to your stakeholders

A critical element of Portfolio Kanban that is commonly missing from portfolio views is the idea that work queues before it is started. Just because someone raises a request for work to be done, doesn’t mean it’s actually started. A common phrase you may hear is “I raised that request with you months ago and I still haven’t got it”. The assumption here is that because the work was raised it was started but taking a long time to complete. It’s critical that you set expectations correctly and share with the requestor how work flows through the organization, especially in terms of how it queues awaiting capacity. The portfolio visualisations in the rest of this article can help to facilitate healthier conversations.

Portfolio Kanban

Lead Time and the relentless pursuit of improvement

Lead time is a critical metric to help you understand the health and performance of your enterprise delivery capability. For every portfolio item raised you should measure and track how long it takes for the work item to flow across the entire value stream to completion.

Sounds easy in theory yet very few enterprise portfolios do this.

Why track lead time? When you plot lead time on a control chart you will see visually how much variation you have in your lead time. Lead time can be used as a diagnostic tool to look for ways to improve flow across your delivery capability and in turn improve throughput.

The are many reasons why the flow of work across your organisation could be disrupted, here are just a small selection of examples:

Environments Contention – when more than one delivery team are sharing environments such as QA environments
Slow response to team level blockers
Lack of accurate forecasting
Lack of prioritisation – everything is a priority
Too many projects in progress (PIP) causing teams to context switch or multitask
Weak Dependency Management resulting in lengthy delays
Staff Contention – individuals shared across multiple teams
Too many approval gates introducing unnecessary delay
Lack of visibility both in terms of where things are at and data to support decision making
The illusion of control – heavyweight deterministic planning and destructive metrics like “staff utilisation” giving a false sense of security
A focus on starting new work instead of finishing work
Conway’s Law creating real problems for how work flows (or doesn’t) across the value stream
Release Contention – when multiple teams are working on the same release cadence and tightly coupled architecture
Code Base Contention – when multiple teams are working on the same code base resulting in overly complex branching strategies and leader to merge hell
The Leaky Bucket – when the portfolio plan doesn’t account for business as usual (BAU) or incident / support work.

A well-designed Enterprise Portfolio Kanban system should tackle most of these sources of variation, or at least reduce the impact to flow.

In the following sections we explore a small selection of client case studies to show how we’ve evolved our thinking and to show you real world implementations to inspire you. Each of these case studies is a snapshot in time, therefore we would hope they have each morphed or evolved into something completely different by now. I suspect some may have completely disappeared, but the learnings should still be shared.

Portfolio Kanban at AutoTrader (2011)

This implementation marks the very first time we felt the need to bring a single view of all teams together and start experimenting. The department had 8 x delivery teams (each with their own Kanban board) and 7 x 3^rd party suppliers. The WIP column and 3^rd party WIP column was used to visualise what each team was working on in terms of projects. The abstract WIP column was organised by strategic theme and used to breakout projects across delivery capabilities. It was a rudimentary implementation, but it served well in facilitating some great conversations which led us to reduce Projects In Progress.

Portfolio Kanban

Portfolio Kanban at MBNA (2014)

The MBNA implementation of Portfolio Kanban organised project work across 6 teams. Each team was fairly big 10-20 people in each. Teams members within each team were distributed across several time zones for added complexity. The column definitions are as follows:

Triage – this is where new project requests are assessed.
VROOM – Very Rough Order Of Magnitude estimates are calculated based on relative size against historical data.
Pre-define – further work is carried out in order to build the business case
EBE – can’t remember what this stands for but it’s essentially where the work is approved and some high-level planning undertaken.
Ready-to-go – doesn’t correlate to the purpose of the column but this was used to breakout the work into the delivery teams queues on the right.
Roadmap – work is queued up awaiting capacity in the WIP column. The numbers on the tickets at this point are a Jira reference.
WIP – actual number of projects in progress. You can see some teams have project tickets stacked. We coached them towards one piece of work in progress per team.

Portfolio Kanban

Portfolio Kanban at Sky (2015)

An important phase in implementing Portfolio Kanban is exploring the many ways in which to design your Portfolio Kanban system. The photos here show the just a few of those aspects such as

how investment themes align with delivery streams?
how to plan and track progress of work items across a complex network of teams at scale?
how decisions are made in terms approval to start work (governance)?
how to balance business as usual work with strategic work?
can Woody still see properly with one eye covered?

Portfolio Kanban at MoneySupermarket.com (2015)

Portfolio Kanban

Portfolio Kanban at CDL (2015)

CDL provide the backbone to many price comparison websites in the UK. On one of their software engineering floors at The CodeWorks building we implemented the following portfolio Kanban to orchestrate work across 10 teams. The board was built in conjunction with Michael Lambert.

Note the backlog says “top 5” for each team but I guess some people just couldn’t help themselves!

The teams were organised into squads with each squad separated by a wall of whiteboards. Within each squad there were anywhere between 6 to 12 team members. Below is a photo of the floor.

The Wall of Work was eventually relocated to another board as more squads were added to the portfolio – 12 in total.

Portfolio Kanban

Portfolio Kanban at JCB (2016)

Portfolio Kanban

Portfolio Kanban at Sky Betting & Gaming (2017)

This board was built with Neil Whiteley who significantly influenced the evolution of how the portfolio was managed. The Core Tribe at Sky Betting & Gaming in Sheffield used the following portfolio Kanban to orchestrate work across 8 squads – Account, Payment, CustOps, CUI, NGA 1, NGA 2, SPAM, ACE.

The left most column containing 8 rows contains the strategic themes to be met. The work flows across the incept column and splits out into the appropriate team for delivery. Once complete the work recombines back into the embed column where it waits for a period of time in production to ensure the teams can give the release full focus should anything go wrong.

The key point on the above portfolio Kanban is how the work translates from business initiative to team delivery capability to ensure true alignment with strategic goals. Initiatives don’t always cleanly align to delivery teams so this mechanism provides a good way to manage this.

Portfolio Kanban

Portfolio Kanban at Arco (2018)

Credit to Steve Motley who championed the use of the board across the business.

The left-hand side of the portfolio board acts as a funnel to support the project approval process. This provides clarity and visibility to the senior leadership team on how projects are initiated and approved. Once work passes approval it is queued up for delivery against the appropriate team in the demand column. This joined up view acts as a roadmap for delivery.

Appropriate limits need to be set for each column on the board. Additional teams can be added to this view to scale.

Through the use of red dots on post-its, the right most column shows how many people were shared across teams and gaps in terms of vacancies. This prompted some really good conversations and provided a constant focus for resolving the issues.

Portfolio Kanban at Rolls Royce (2018)

Portfolio Kanban

Portfolio Kanban at a Digital Agency in Manchester (2019)

Running a digital agency at scale is a tough gig. The importance of managing the business end to end cannot be stressed enough. From sales pipeline through to delivery and invoicing, everything must run extremely smoothly and avoid any bottlenecks in delivery.

The portfolio board above aims to balance supply (through the use of limits) against customer demand visualised by the sales pipeline. The client streams act as a buffer to ensure a pull system is possible across the agency. Teams are organised by client so that long term relationships can be built along with domain expertise. Most teams “own” a stable of clients and balance WIP accordingly across them using limits. Each team has their own Kanban board to help which links back up to this one.

One very interesting learning from this engagement – find a way to allow the client to see the Client Streams column and participate in prioritisation. Limit the client demand to say their top 4 or 5 priorities.

We’ve since introduced this model to a number of digital agencies with brilliant feedback.

Portfolio Kanban

Portfolio Kanban in 2020 & Beyond

We are currently working across a number of clients helping them to implement Portfolio Kanban. We are not yet in a position to publish any learnings but join our 2 day Portfolio Kanban online course to find out the latest techniques we’ve mastered in 2020.

Don’t forget the teams level!

Just a quick reminder at this point that the Portfolio Kanban board is just one part of the portfolio Kanban system. The team boards are also a part of this portfolio Kanban system. Think in terms of the team boards connect to the portfolio board.

However, this is NOT a hierarchy where all teams boards report into the portfolio board. You need to consider the portfolio board a source of demand for the teams.

In the photo above you’ll see a typical team board. The backlog rows could represent different sources of demand. The bottom two rows in this example could represent a single PIP at the portfolio level. The remaining rows represent other demand such as Business As Usual (BAU), technical debt, and incidents.

Portfolio Kanban

Operating Portfolio Kanban

There are a number of ceremonies that you should establish. These will improve flow and stakeholder engagement and are a critical activity to ensure smooth operation of your portfolio Kanban system.

Delivery Planning meeting

This meeting is used to operate the portfolio Kanban end to end. The portfolio Kanban board isn’t a glorified form of a report. It’s an interactive, operational tool to drive collaboration and manage a business.

Facilitate conversations about what work items can be pulled from queues, walking the board from right to left.
Attack blocked work.
Discard stale work items from queues.
Look at forecasted delivery dates and share with interested stakeholders.
Ensure stakeholders are completely aware of where all work is up to and where they can find regular updates from outside of this meeting (the board!)

In the photo below a large-scale telco software house holds a Delivery Planning meeting and walks the board from right to left. The projected screen on the right is used to drill down on any specific information not detailed on the portfolio board upon request.

The frequency of this meeting depends on the overall maturity of your organisation in terms of lean thinking. An organisation that focuses on reducing lead time (becoming more responsive) will need to meet more frequently.

Risk Review & Blocker Clustering meeting

If your portfolio visualisation contains a section on staff allocation and capacity, then review this area of the board. Look for gaps in the team in terms of vacancies and focus on plugging those gaps. If you have many individuals shared across more than one team then assess if that’s a problem and then find ways to resolve the issue.

Collect all unblocked blocker post-it notes and analyse them in line with our guidelines on managing blockers here.

Flow Review

The flow review meeting is a weekly opportunity to analyse data from all delivery teams and find opportunities for improvements. You may need to divide and concur for larger organisations.

Portfolio Kanban

Requirements Management at Scale

When operating at scale you will inevitably hit the challenge of how to manage the requirements hierarchy across teams. It will be extremely tempting to impose a one size fits all organisational design in terms of ways of working in the vein of simplification. Mistakenly this one size fits all ends up suffocating teams by locking down their team level workflows, naming conventions, imposing stage gate approvals, and governance by tick boxes.

You need to empower delivery teams with the autonomy to optimise their ways of working, this includes making changes to their own Jira/DevOps configuration. The only caveats should be as follows:

Team improvements must not increase overall portfolio lead time. Teams should be free to experiment but any negative impact to lead time should be reversed.

It’s ok to impose conventions, i.e. all teams follow a similar requirements hierarchy or agree a tagging / labelling convention to track work items across multiple teams.

The capabilities of tools like Jira and Azure DevOps are very limiting. Some teams have managed to bodge together a rough working model in these tools without plug-ins. There are plug-ins available but most of them don’t come close to enabling true enterprise portfolio Kanban.

In the age of COVID19 we would strongly recommend the use of online tools like Miro or Mural to visualise your portfolio. These tools provide a collaboration space that allows you to visualise your portfolio with ease. You can link areas of the Miro board to custom queries in tools like Jira where you would store the detail. This allows you to quickly navigate around your enterprise landscape and drill down where needed.

Eek! We’ve visualised our portfolio and we’re in a right mess. What do we do?!

If you find yourself in this situation don’t panic. You’ve taken the first important small step towards Enterprise Portfolio Kanban. Follow these steps to unpick your portfolio:

Introduce a queuing column just before your wip/pip column.
For each team, urgently review all current projects and ask the question…”which project do we want to finish next”. Place that project in the PIP (Project In Progress) column and focus the team on finishing it. Adopt the mantra “stop starting, start finishing”. Place all other projects for that team into the Queued for Delivery row in priority order.
Ensure teams are limiting their work in progress on their local Kanban boards.
Always start from the right! and pull across the enterprise.
Bubble up team blockers to the portfolio level.
Engage all stakeholders in the portfolio view.

Summary

Portfolio Kanban is an interactive, operational tool to drive collaboration and manage a business. It visualises a network of interconnected value delivery teams ensuring alignment to strategic themes.

In this article we have only scratched the surface of Portfolio Kanban. In our two day live online course you’ll have an opportunity to dive deeper into this article hearing first hand experiences around the challenges of implementing Portfolio Kanban and how to overcome them.

In addition to this we also cover: