Three Strategies when the Product Owner is Disengaged

Posted on by

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

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 →

Pain Driven Development

Posted on by

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

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 →

Correcting Overcommitment during a Sprint

Posted on by

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

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 →

Three Threads within Agile Programme Management

Posted on by

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 →

How to Manage a Vague or Dynamic Product Backlog

Posted on by

In response to my request for questions along the lines of what do I do when … ? Jo asked:

What do I do when the product backlog is not complete and we still want to deliver our product on the agreed date? It is hard for the Product Owner to prepare a complete feature backlog and for developers to estimate the required time in order to get a realistic burndown chart during the sprints. The product backlog is kind of dynamic.

In response I’m going to look at three states for the product backlog and strategies for managing backogs when in each of those states:

  1. Normally vague/dynamic
  2. Completely vague
  3. Massively dynamic

The first of these states is, well, normal. You never know everything about the scope. You just have to manage what you do know.

The other two states suggest something is going wrong in the product management space. And that is very much a product owner issue. The agile project manager / scrum master role is to help the product owner and/or organisation realise their problem.
Continue reading →