How to get started with Agile Portfolio Management
Most references to portfolio management I’ve come across in the Agile / Kanban space just cover scaling software development practices. My experience in the field is that software delivery is often one aspect of a broader portfolio of work that needs orchestration and more often than not managed by a centralised Programme or Portfolio Management Office (PMO). The amount of change in medium and large businesses these days is phenomenal – and for good reason. The world is evolving at such a pace that portfolio management reaches beyond software delivery. Using Kanban practices and principles to just manage your portfolio of software deliveries has the potential to cause local optima by reenforcing silos.
The first place I start when working at the portfolio level is figuring out what I need to visualise and why. Do I need to include absolutely everything:
- Website / product incremental enhancements
- New website product development
- Data centre moves / hardware refresh – even more so given the move to cloud based services
- Network and infrastructure upgrades
- Telephony projects
- Business change, for example expanding a contact centre
- Marketing campaigns
- Events
- Internal IT such as desktop / laptop upgrades, etc.
- Other stuff
Where are the pain points? Do we need to start with just software development and then incorporate more areas? How are the other areas currently being covered off? Will visualising an area of work open up opportunities for learning about how the work works?
There are many more examples of ‘work’ undertaken within organisations but I think it’s safe to say it is a complex issue with no simple or easy solution. A constant trait I’ve observed across the many approaches PMO’s take is to attempt a centralised, one size fits all, control mechanism for all work undertaken in the org. The reality is, a network upgrade project is FUNDAMENTALLY different from a software project. Therefore a different approach is required for each, commonly leading to silo’d structures within orgs such as Dev and Ops. Counterintuitively we need to decentralise control of work and encourage the formation of autonomous, self-sustaining work cells with clear purpose aligned to core revenue streams or objectives.
One of the fundamental principles of Kanban, which I totally subscribe to is start with what you do now and evolve. I posted last year on Kanban Portfolio Management which reflected some work I was doing at the time. That particular board design has evolved since in response to constant learning and discovery. Whatever way you chose to visualise the portfolio I’ve found a few principles useful:
- Make all work visible. I don’t mean by logging it all in an electronic tracking tool. I mean by using the physical space around you – walls, windows, whiteboards. I still regularly come across orgs that operate a ‘clean walls’ policy. “How we visualise the world dominates how we perceive the world”, Karl Scotland. Only when you start to visualise the work can you start to understand how it works systemically.
- Plan for the unplanned. Build a mechanism into your Kanban system(s) to deal with unplanned demand.
- Prioritise the project backlog by what you want to finish next rather than what you want to start next.
- Get away from rolling up detail into abstract entities such as Projects. One way to do this is to treat everything as Business As Usual!
- For software projects, accelerate learning by shipping features in smaller incremental batches rather than all at once to get faster feedback. Could this same approach apply to other, non-tech areas of your business?
- Organise by value, not by function as discussed in previous post. Aim to create autonomous, self-contained teams free from constraints and dependencies on other teams, aligned to core revenue streams or purpose.
- Do not time-slice staff across multiple pieces of work or attempt to run projects in parallel using the same staff pool. If you focus on one at a time when using the same staff then they will finish both much quicker.
- Pull system: only start work when you have both the capacity (internal staff or outsourced) and capability (you may need to extend the architectural runway to quote Leffingwell) to complete the work.
- Acknowledge there are multiple sources of demand placed on delivery streams and work to eliminate or reduce contention and ensure your kanban system(s) have a selection mechanism to deal with such.
- Aim to make staff working lives better, first, followed by company profits second. Anywhere you have unhappiness is a signal from a systemic problem.
Using card walls to visualise abstract concepts such as projects or portfolios of work is all good. But! it’s important to remember these visualisations are not real work. They are simply pointers to where you can find the work being done. No amount of reshuffling cards on these abstract walls is going to change anything on the ground unless you open up capacity and capability, affecting change on the ground. Even dependencies between work items should be managed at the level of the delivery streams.
It’s absolutely ok to have multiple visualisation boards to represent demand from strategic aspirations, tactical work, architectural work, etc. In fact, I’d like to see more enterprise architecture type card walls in organisations separate from the delivery streams. Shit? did I just really write that??! I’ll quantify that statement in a later post.
ok, enough theoretical fluff. Apologies, I’m trying to avoid fluff on my blog so tomorrow let’s look at how the above manifests itself in the real world.
