About Steven Thomas

Steven Thomas an independent Agile Programme Manager.

Benefits Map: Impact Mapping for Programme Managers

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

Three Strategies when the Product Owner is Disengaged

Karine doesn’t show up. She has a good reputation and was previously the product owner on a run away success. But on your project she seems quite distracted by other commitments. What she is working on is all good stuff and related to the wider programme but it means Karine often misses the important meetings with your development team. When she does turn up the team are very happy with the input she provides. They’d just like it more often. Much more often.

Phil doesn’t show up. He is a colleague of Karine and is product owner on another work stream within the same programme. Phil’s development team never sees him at all as he is entirely focussed on external communications.

Mike doesn’t show up. He’s the external customer and commissioned you and your company to build some software. He knows his business inside out but he’s never been involved in software development before. And Mike is quite busy and doesn’t often make it to your offices. When he does come in he talks to the CEO and not the developers.

I’m sure elements of these scenarios will sound familiar to you?

You’ve got a a big problem if the Product Owner does not show up to the key meetings of the Agile Heartbeat or is otherwise not engaged.

To address this problem you’ve got three options: Educate, Delegate, or Escalate.
Continue reading

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

Correcting Overcommitment during a Sprint

As I’ve said before the most common problem I’ve seen with software development teams is over commitment. If worse comes to worst you get to the end of the spring before realising the problem. But you don’t have to wait until the end of a sprint to take corrective action.

Taking Corrective Action mid-Sprint to address Over Commitment

Taking Corrective Action mid-Sprint to address Over Commitment


This post was prompted by a comment, by Chris, on the post where I described what to do when tasks in the Sprint Plan are not finished. My assumption in that post was the team only realises they are overcommitted at the end of the sprint. And for first time teams that is often exactly what happens.

What I didn’t mention is that more mature teams are likely to spot what is going on earlier.
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