Tag Archives: programme management

Programme Management: Build capability, Roll it out, and Deliver Business Benefit

What do I do when There is More Than One Product Owner

Posted on by

The product owner defines what the development team is meant to build and the order in which it is built. What should you do when the Product Owner responsibilities lie with more than one person?

The short answer, that works in simple situations, is get the business to pick one. However things are not always so simple and there are situations where you will need more than product owner. I’ll outline a few scenarios, both good and bad, which for the purposes of this post I’ll characterise as Many Kings, Pretender to the Throne, and finally Chief and Indians.
Continue reading →

Programme Organisation for Software Delivery

Posted on by

I thought I’d share the way I organise programme teams. I’m interested in software delivery so I’m talking about programmes that have software development at the core. Non-software programmes would have a different structure and mix of roles. I push Agile but the same organisation would work with a less nimble approach.

There is nothing mysterious or radical about my programme organisation. In fact it is entirely in keeping with the guidance from Managing Successful Programmes (MSP). If you didn’t know Organisation is one of the nine Governance Themes from MSP.

Although I tend to apply the same shape to all of my programmes I do adapt it to local conditions. The size of the team makes a big difference so I’ll show how I have organised large, medium sized and small programme teams. I’ll also take a quick look at a poor structure for a programme team – with role based teams – and explain why I don’t fancy it.

There are obviously other ways of structuring a programme team but this is what has worked for me.
Continue reading →

Agile MSP Programmes with Rigid Projects. Ouch!

Posted on by

Managing Successful Programmes (MSP) is about programmes but it does have something to say about how to run the subordinate projects. And projects in MSP are not meant to be agile in any way. Although agility is encouraged for MSP programmes agility in the projects is viewed as a “disaster”. Given the people who use MSP are most likely to be using PRINCE2 this belief is perhaps not surprising. But it is not a belief I hold to.
Continue reading →

Benefits Map: Impact Mapping for Programme Managers

Posted on by

Gojko Adzic has recently published a great book on a technique he calls “Impact Mapping”. Gojko’s Impact Maps are a visualisation of the business drivers and the associated project scope. This means the people doing the work (developers, UX, testers, etc) know what to build but also why they are building the functionality, how the functionality fulfils the business outcome and and who the functionality is for. Love it.

As it happens Programme Managers already have a very similar tool for a similar purpose. Benefits Maps, like Impact Maps, are used to visualise business drivers and associated scope, in this case programme scope. They answer two key questions:

  • Why are we doing the programme?
  • How will we realise the benefits?

The dual function – showing why and how – make Benefits Map high value documents. It also means a Benefits Map can easily morph into the initial Programme Blueprint. For a simple programme the Benefits Map may be the only Blueprint. And the diagram format means it fits on one page. Even in a world where we value “Working software over comprehensive documentation” that one page is worth having.
Continue reading →

MSP Agility Scorecard: How MSP Shapes up against the Agile Manifesto

Posted on by

Given Managing Successful Programmes (MSP) is for programme management what PRINCE2 is for project management, you’d expect to find a rather rigid process at the heart. So I was surprised to find, when re-reading the 2011 edition recently, active encouragement for agility. Admittedly this is agility in the wider sense rather than specific practices from the Lean-Agile movement but any agility looks good to me.

This post is not about how to make MSP more Agile – although I’ll make a few suggestions – but is merely a commentary on how Agile MSP is coming out of the box.
Continue reading →

The Fallacy of Control within Project and Programme Management

Posted on by

The most liberating day of my career was when I realised that, despite being responsible for the project I was running at the time, I actually controlled very little of what happened. That was the day I freed myself from the “fallacy of control”.

I can’t really control who does what. I can’t really control whether an individual does the work to an acceptable quality. I can’t control whether or not the product owner is going to change their mind about priorities. I can’t control whether the proposed technical solution turns out to be much harder than anticipated or just a dead end.

All I can really do is influence what happens in my programme/project. Spot issues quickly and react appropriately. Lean-Agile gives me the tools to do that.
Continue reading →

A Clear Vision is Essential for Agile Programme Management

Posted on by

Search the Lean-Agile literature and you’ll struggle to find much mention of vision. Agile is all about short planning horizons, releasing stuff early and often, and learning. And a vision doesn’t necessarily help with that.

My direction? Anywhere. Because one is always nearer by not keeping still

The quote is from Engleby by Sebastian Faulks (cited Good Reads) and pretty much sums up the Agile attitude. Movement is the key rather than the direction of movement. Most Agile initiatives (i.e. projects and product development) are simply about building high priority stuff now, so it is no wonder that the Lean-Agile methods are relatively silent about the future.

In contrast a programme is about organisation change and the vision helps define the future state and attract buy-in – it is a “Postcard from the future”. A clear vision is an essential mechanism for staying aligned with business strategy. Alignment is, of course, one of my three threads within Agile Programme Management. The vision should be stable; not static but broadly resistant to change. Despite Agilists desire to “Embrace Change” a radically changing vision suggests the programme is no longer aligned with strategy and hence raises the question of whether the programme should be shut down.
Continue reading →

Revisiting the Iterative Incremental Mona Lisa

Posted on by

In his brilliant post Don’t know what I want, but I know how to get it Jeff Patton used a sketch of Mona Lisa to illustrate the difference between Iterative and Incremental development.

Jeff points out that many Agile people use the word “Incremental” when they mean “Iterative”. I believe this is because, in reality, most Agile projects combine both approaches and become Iterative Incremental. In fact I can’t imagine delivering software in any other way.

To illustrate what Iterative Incremental means I’ve taken Jeff’s Mona Lisa illustrations and added a third showing a combined Iterative Incremental approach.
Continue reading →

When To Measure Lean-Agile Productivity, and When Not To

Posted on by

Lean-Agile offers two productivity measures: Velocity and Throughput. It is possible to improve both over time but there is little point in management demanding that a development team improve either because both metrics are very simple to fudge.

There is also little point in using either of these productivity measures in product development. The focus is discovery not churning stuff out.

Where a productivity measure is useful is in a project or programme. Where somebody is wanting to know when the team will be finished. Or, conversely, how much functionality will be delivered before the time and/or money has run out.

Continue reading →