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.
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.
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.
I’m a Scrumbut and I’m proud of it.
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.
Jim Highsmith proposed two simple strategies for successful software development: Build Less, Start Sooner.
Jim’s observation is genius, but I would add “Innovate Constantly”.
A senior manager in the operations area of my organisation recently commented:
There is no such thing as agile infrastructure
That got me thinking. I can imagine that adopting an agile approach to infrastructure might be inappropriate in certain circumstances, for example military or medical domains.
On the other hand my current programme needed a completely new infrastructure stack and I found a considerable amount of agility was possible through that exercise. To my way of (probably simplistic) thinking any changes needed from the infrastructure are to provide either more capability or faster capability. With that in mind I’ve found it is possible to architect for agility and deliver the infrastructure in an incremental and iterative manner.
In 2004 some people met to define what agile project management should mean. In February 2005 they published a statement called the “Declaration of Interdependence” (DOI). According to David Anderson (Kanban and the DOI), one of the signatories, the intent was to:
- define a value system by which modern 21st Century project managers should live and
- galvanise a community around general application of agile project management
The Toyota approach to lean is quite sophisticated and is based on a model called the Lean Thinking House (Larman & Vodde, 2009). The Toyota model includes two pillars:
- Respect for People
- Continuous Improvement
These pillars struck a cord with me. I’m normally more interested in what practices work than in values and principles however these two phrases seemed to nicely summarise my approach to work and are key themes in my career.
Larman, C., and Vodde, B. (2009). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley.