BY Mahesh Singh | April 22, 2019

[Total: 2    Average: 4.5/5]

Having been a product manager for a long time, running Digité’s Product Management since we started till about a couple of years ago, I have been passionate about putting the focus on all the work that the product management function at a product organization must orchestrate in order to ensure that the organization as a whole is working on the right things at the right time, AND making sure that that work is getting to Dev teams with the right level of detail so they can work on them without any doubts on priority of the work or the requirements of the product features to be developed.

Part of Upstream Kanban focuses on this aspect – and I have spoken on this topic in a number of conferences, as has my colleague, Sudipta Lahiri, who wrote a very good blog post recently focusing on the details of backlog grooming to ensure sufficient detail for the dev team.

However, the other critical aspect of Upstream Kanban is the alignment between strategic/ portfolio objectives and their corresponding program and project/ product level execution.  This has to be ensured even before Product Management can begin to work on a prioritized set of epics to build the groomed user story backlog.

Kanban – Naturally Scalable

By it’s very nature, Kanban can be applied to any process at any level in the organization. At the same time, it doesn’t matter where you start – you can start at the very top, the very bottom – or somewhere in the middle.

The Kanban Method is very clear – and simple – in its principles – start with where you are (your current process), agree to pursue incremental, evolutionary change (nothing disruptive) and respect current roles, titles and responsibilities.  A fourth principle added later says, encourage acts of leadership at all levels.

The 6 core practices then explain exactly how Kanban can be applied to any process.  Explaining all of them would take up too much space in the article – and superfluous.  For the full details, you can refer to this article. It is the first 3 principles that are worth mentioning here in brief – visualize the flow of work (both the process and the actual work currently happening), Limit Work in Progress and Manage Flow.  It cannot get more elegant than that!

Think of any – ANY – process!  How about a complex strategic portfolio management process, including financial and technical analysis, prioritization and approval of various strategic initiatives? Check.  How about a business critical process of evaluating RFPs – evaluating costs and feasibility – and arriving at a Go/ No Go decision? Check.  How about a Program Execution process, going through various phases or stages, each with it’s own gating criteria?  Check!  What about a run of the mill Epic or a User Story development process? Check.  A help-desk ticket management process? Check!

Work Flow

Think of any process at any level in any part of your organization.  If it manages or handles repetitive work – at appropriate levels (think multiple strategic initiatives over multiple quarters, multiple RFPs each week/ month, scores of epics, stories, support tickets, the works – it can be managed using a Kanban board.

Hierarchies – A Naturally Occurring Phenomenon

The other aspect of all work is that one can think of work to be done in terms of a hierarchical work breakdown structure (the traditional WBS!).   Don’t think of tasks but think of scope (deliverable) breakdown.

Think of the various hierarchies in your context – they can be Initiatives, Programs, Projects. Or, they can be Themes, Epics and User Stories.  They can be Epics, Features and User Stories (if you are a SAFe practitioners, you recognize a Portfolio SAFe hierarchy!).  They can be a Hydroelectric Power Plant, Multiple “modules” of the plan such as the dam, the electric systems/ substation, etc. and then various sub-modules under that.

SwiftEASe Configurable Hierarchies

Think of them as “Big Hairy pieces of Scope”, “Manageable Pieces of Scope” and “Deliverable on a regular basis pieces of work”!

One thing common about these hierarchies is – they are connected.  Linking them makes it possible for anyone viewing their description to easily understand the hierarchy of these items and interpret that the progress of the items at the top is a bottom-up rollup of the progress of various leaf-level (bottom level) of work items.

Kanban Boards can be – and are – Linked!

Combining the above, it is clear that you can manage any – and all – levels of work using a Kanban Board.  And, more importantly, because the work items are connected in various hierarchies, so are the Kanban boards!

In the Kanban world, it is the most natural thing to think of Kanban boards at multiple (unlimited) levels of hierarchy.  Klaus Leopold’s paper on Kanban Flight Levels – and his earlier articles, including a webinar he did with us – explaining how you can start with Kanban at any level; and wherever needed, drill-down to a more detailed visualization in a “lower-level” Kanban board put this aspect of Kanban very elegantly.

Kanban Board Hierarchy

Once you link work in multiple Kanban boards, you can then start to make use of them in two important ways –

  1. To define, breakdown and manage work in upstream and downstream processes. This would mean Product Management/ Owner to Product Dev Team, Sales to Order Fulfillment to Finance, Recruitment and Human Resources, the list is endless. This is what Sudi covered in his article on Backlog Grooming.
  2. To establish the alignment of work at ANY level to a HIGHER level strategic/ tactical objective by simply linking them. You might call this “Portfolio Management” or any other name; but you are ensuring that work done at any level in any part of an organization ties into the strategic objectives of that organization for a month, quarter or year or any other business-critical purpose.

Link your Kanban Boards to Align Strategy to Execution

Depending on where you are starting to use Kanban, you can choose to abstract up or drill-down to trace the work on your Kanban board to higher-level initiatives or themes or epics; or lower level epics and user stories (or features and requirements, whatever you call them in your context) so that everyone from senior stakeholders to the junior-most developer working on a breakthrough technology to deliver a feature of your product is clear on why they are doing what they are doing!

The week before last, I was fortunate enough to lead a weeklong SwiftKanban training, implementation and rollout workshop for one of our newest customers, along with the Lean/ Agile coaching leadership of the organization.  To my mind, it was one of the best Kanban implementation examples that I have ever seen – for one simple reason – their focus on aligning execution to company strategy – and their use of the concepts of Upstream Kanban and Kanban Flight Levels to explicitly identify corporate Objectives and Key Results – and link them to Program-level Initiatives and Epics which then result in User Stories for different teams in the organization.

Within a very short time, they went about setting up a Portfolio Kanban board to track corporate objectives, a Program Kanban board to drill down into strategic initiatives against each objective, and expand them into epics that needed to be built or done for each initiative, and several team level boards to plan and develop user-story level functionality.  In a matter of days they had a complete tracking mechanism for understanding what was being done against each corporate objective or initiative OR what corporate objective was any piece of work being done, in any part of the organization, tied into.

Then, last week, I was at another company where I worked with a high-energy bunch of people, led by a Kanban enthusiast, who worked on a set of complex team-level boards to track highly technical product development and ensure that each part of that process was fully visualized and understood and each part of the work was tracked.

Having done that, they simply discussed and experimented with “portfolio level lanes” in their own boards to tie down their work to a higher level “work package”.  This was just the beginning of Portfolio Kanban for them.  Hopefully, before long, they will have others, especially senior leadership, also in the fold for managing their work visually, powerfully!

In both cases, the need to align the strategic to the operational was very clear; they are just following different paths to get there!

Top-down or Bottom-Up – Either way Works!

In summary, Upstream/ Portfolio Kanban helps you understand why you are doing what you are doing, and ensures that your work gets to you in the right level of detail, in the right order/ priority and at (just) the right time!

Get started today to ease the challenges your dev teams face understanding the importance of what they are being asked to do.  AND, get started to ease the challenge leadership has in understanding what, if anything, is being done against the strategic objectives that the whole organization agreed to at the start of the quarter!

If you have any questions or would like to share your experience with Upstream/ Portfolio Kanban, I’d love to hear from you.

Mahesh Singh
Co-founder/ Kanban Trainer & Coach

PS: If you’d be interested to learn how our customers are using the Upstream Kanban and Portfolio Kanban features of SwiftKanban to effectively manage their Portfolio and Backlog Grooming processes, simply get in touch with us. Or, read up more about SwiftKanban here.  And, then sign up for a FREE 30-day trial of SwiftKanban!

Other Recommended Articles:

The Value of Upstream Kanban for Backlog Grooming

Using SwiftKanban for Customer Portfolio Management

Portfolio Lane: Revolutionizing Portfolio Kanban!!!!

Leave a Reply

avatar
  Subscribe  
Notify of
Top