I once invested 35 person-years worth of effort on prototyping. From my perspective this was time and money well invested. By the end of that time we knew, really knew, what problems our customers were facing and how to solve them.
I’m a big fan of Lean-Agile coaches and have a list of folk that I trust to help me run transformation initiatives. But there are some cowboys out there and, at the extreme, folk who pitch themselves as coaches but are really organisational psychopaths. That is why I vet my coaches.
It is always interesting to see how other people approach a task that in other circumstances I would be doing. So I was quite interested to see the ERIC Grid used to shape a transformation initiative.
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.
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.
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.
For the last couple of years I’ve been running a lean startup within the BBC. No really, I mean it. It is indeed possible to have a successful lean startup inside a large publicly funded corporate. It is all about your outlook.
Some people view programme management as simply the management of multiple projects (see for example Johanna Rothman: Defining Program Management and How Agile Helps).
Although programmes often comprise multiple related projects this definition, for me, misses the real point. As I see it programme management involves three things: building capability, rolling it out and, most importantly, delivering business benefit.
Ever since I read "Made to Stick" by the Heath Brothers I’ve been a keen collector of success stories about my programme.
As the programme manager I have to report on the progress of my team. Risks, Issues, Budget, Milestones, Financial Benefits, Reach, etc, etc. Lots of numbers and facts. Terribly significant and rather dull.
So, to spice things up, I also report on success stories.
People don’t resist organizational change! – People resist being changed!
The Communication Toolbox
My current programme is using new, bespoke software to drive organisational change. So I need people to change what they’re doing. A lot of people. As a first step I need them to adopt our new software. So I am always looking for ways to push the software roll out. In an earlier post I described one approach we use for encouraging adoption: Foot in the Door Technique. In this post I look at two other methods – which we call "Side bets" and "Sweeties".