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

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

Pain Driven Development

Agilists love a good catch phrase. You Aren’t Gonna Need it (YAGNI), Do the Simplest Thing that Could Possibly Work, and Pain Driven Development are three of them. In fact these three are different ways to say the same thing.

All three phrases are about addressing a technical problem the team might face in the future. Immature teams will immediately attempt to solve the potential problem and thus add complexity to their product. More mature teams take a slower, more considered view.

In fact Agile teams should go through these stages when considering a potential problem/solution:

  1. Remember “YAGNI” i.e. point out the team don’t have a problem now, hence don’t need that solution now, so probably won’t need it in the future either.
  2. Wait until you feel some pain before accepting the problem is real.
  3. Once you feel the pain then do the simplest thing possible to solve the problem.
  4. Then wait until you feel more pain before trying anything else in that space.

That considered process is Pain Driven Development.
Continue reading

The Fallacy of Control within Project and Programme Management

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

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

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

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

Three Threads within Agile Programme Management

The way I see it Agile Programme Management weaves together three threads: Transformation, Alignment and Adaptation. These threads are present in traditional approaches to programme management however an Agile approach subtlety changes each and increases the focus on Adaptation.

In this, the first post in a new series on Agile Programme Management, I’ll explain the three threads within Agile Programme Management.
Continue reading

Go Deep on Agile Practices: Who, What, When, Where, Why and How

One of the interesting things about having an outsider look at my work is that I have an opportunity to gain a greater understanding of what I do and, specifically, what I do differently from others. Joanna Geraldi gave me such an opportunity when she came to interview me about my approach to project management for some research. After the interview Joanna characterised my approach as "’real’ principle-driven agile project management". That got me thinking because for a long time I was far more concerned about practices than principles. It seems that has changed.
Continue reading