Options, Options, Options

I think the first time I’ve heard that we should consider that a project backlog is simply a set of (unexercised) options it’s been from Ellen Gottesdiener It took me some time though to translate this, otherwise attractive, concept to something more down-to-earth in my own context. The catalyst in this case was one of Kanban Leadership Retreat sessions that covered portfolio management.

Let’s imagine a company working on multiple projects. The organization size may vary, but let’s make it at least a couple hundred people strong. Such a company would have a bunch of project in progress but will also continuously work on selling more work to keep the business running.

Every now and then, one of ongoing projects will get finished. What typically happens then is the company has some free capabilities. At the same time sales department is busy closing the deals. If the organization is extremely lucky and we are living in a fairy tale the pace of project completion will be exactly equal to the pace of new project arrivals.

I have bad news though. We don’t live in a fairly tell. It’s even worse – most of the time we are not extremely lucky either.

What typically happens is one of two things: there either are some free capabilities and no work that can fill this gap or the opposite – there is more work that should be started than can be handled with available capabilities. In fact, the situation dynamically changes from one to the other and back again.

I want to focus here on a scenario with more incoming work that can naturally be absorbed by the org.

One, sadly very common, approach is taking whatever comes from sales funnel and then pushing hard to make it fit, no matter what available capabilities are. Guess what – wishful thinking that people would handle more concurrent work doesn’t work at all. Conversely it only makes the problem worse as it forces teams to multitask which never comes for free.

We can do better, can’t we?

The opposite approach would be taking available capabilities into account and committing only to whatever the organization can handle. In other words it means saying no to some of available projects.

It is like treating every incoming project not as a commitment by default but as an option. Well, it seems we have options again.

So let’s picture our portfolio backlog as a bunch of options.

Now, what happens when we start a project? Let’s keep it consistent with the Ellen’s concept. We fill the project backlog with a number of options. Except this time the options are more fine-grained. We may build these features or those features. Well, odds are we will build them all eventually, but the order is kind of important here.

By the way, I’m yet to see a project where the scope doesn’t change. This basically means that every time we decide to build a feature we exercise an option of building this very feature while keeping the options of building other features still open.

The option backlog will get replenished on occasions while we discover more and more details of the project. It will live and evolve the same way as our portfolio option backlog is alive and changing.

The interesting part here is that commitment on one level (launching a project) springs a bunch of new options on another level (features or stories).

In fact we can take this model even further. Once we as a team commit to build a feature we generate a bunch of options to build the feature in this or that way. We have an option to write tests. We have an option to write tests before the code. We have an option to write acceptance tests. We have an option to review code and so on. At the same we also have options to implement the feature in a few different ways functionality-wise. Some of them will be mutually exclusive, some of them won’t.

Basically, starting work on a feature springs a handful of options on yet another level of granularity.

If you imagine that building stuff in the company is happening on a few different levels – each of them dealing with more fine-grained stuff – this model will work throughout the board. Commitment on a higher level generates options on a lower level.

In fact, you can take the model way beyond the three levels I proposed here. For organizations that deal with product lines, programs and stuff it will be the same. There always is a commitment to more high-level stuff before we choose how to do low-level items. There simply will be more layers to take into account.

That’s why considering backlog as a set of options seems so attractive to me. It’s not only about a project or an iteration backlog. It’s about any backlog on any organizational level.

What’s more, having the Real Options theory at hand we may use the model to manage the stuff we build wiser. Again, it doesn’t matter whether we think about managing portfolio, prioritizing features or deciding on implementation details.

“Don’t commit early unless you know why” may as well apply to launching a new project or getting more work in progress than we really need to have. And knowing why should include understanding of all the costs attached. The bit that is too often forgotten.