Programme Level Kanban

I was recently asked

I’m looking for pointers and experience of running programmes with Agile, particularly topics such as:
– team structures
– communication and coordination processes

Rather than Mike Cohn’s Scrum of Scrums, my answer is to use a master Kanban board to visualise the progress of the projects within a programme, which in turn will naturally enhance the communication and coordination process.

The programme board has cards for each of the sub projects or sub feature sets (MMFs) only. The detail for each of these is broken out on each of the teams Kanban boards, not on the programme level board.

This approach visualises what is going on at a higher level, and enables the various representatives from each of the sub teams to collaborate, understand what is coming their way that could affect them, and facilitate synchronisation.

A daily standup is still held, but the rhythm is around:

  1. what is blocking your team, or about to block another team
  2. what work is in progress
  3. bottlenecks (either current or impending)
  4. are priorities clear on what gets pulled next
  5. what needs to be expedited

The standups still run from right to left on the board, in other words upstream; from what is about to released, back all the way to analysis.

Each team records Lead Time and Cycle Time in elapsed working days (some sub project teams may still use points but augment these with LT and CT). This enables those at the programme level to be able to compare teams. Those sub teams with longer Lead Times are asked if they needed more resources, assistance in removing bottlenecks, if we have to go and work on the System conditions etc etc. The only caveat to this is keeping managers in check so that they dont start using these metrics for pointing fingers (at “slow” teams) rather than continual improvement opportunities.

As Dr Peter Middleton says the usual constraint for programme visualisation is the ability of the human mind to handle complexity, this is why tools struggle, as you get to see all individual work items for its sub-projects, too complex! There is no need for one gigantic board/tool visualising everything in fine detail.

9 thoughts on “Programme Level Kanban

  1. This is an excellent article; thanks for posting.

    I’d suggest the following as well…

    If you use colors and/or vertical placement for business priority and also use some item (I suggest a colored stick-note that states the reason) to annotate items with blockages you easily see patterns across the program level items in work. This is great for then having program level retrospectives focused on looking for ways to improve.


  2. Great post,

    We are setting up something like this next week, except we will also be tracking specific investigative, issue management, and other work items needed to support the various teams

  3. Thanks for the topic.

    My 5″, I think that SoS isn’t really applicable in such a case. The Craig Larman’s approach, MetaScrum and Agile EVM is a bit more concerned.

    KanBan at the Program Level: why not? In theory that makes sense blocking points could be:
    – Business Alignment
    – Project Coordination

    Utilization of KanBan depends, on my side, on time-2-market speed: if your delivery cycles are short (less than a week) then KanBan makes sense (eg Support). If your Program needs more complexity in development, more time, then you can keep it for task management.

  4. Comparing teams might not always be positive. Each team has its own circumstance as dedicated by the sub-system of the overall product they focus on. For example there is difference in features, technology, skills required, back-end/front-end/interfacing, dependencies on other external parties, and others. Therefore, while a feature can take 5 days from a team, a similar size feature can take 25 days from another team.

    I think we can also replace programme level management by overall product level management. Each sub-system of the product has its own team and a representative from each attend the extended size stand-up meeting.

    This is currently my area of focus in the current contract work on.


    • Indeed. We should visit a team to understand what they are working on, and what method they are using. We shouldnt blindly just compare, we should test assumptions.

      • Thanks for your reply.

        My fear hear is the ignition of comparison of oranges and apples. How this can impact the team morale. The board serves to make everything available on the air for everyone and this is compounded when you make it available for the whole company.

        Thank you for your interesting post.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s