As 2017 comes to a close, the number of models to scale-up Scrum has overtaken the number of organisations that actually need any of that crap. Surely that’s the final proof that agile has crossed the chasm. Of course, environments where scale is a badge of pride have their own set of problems, but the mechanics of grouping tasks into a release train are seldom the critical part of the solution. One of the key constraints in such situations is working with stakeholders that want fixed scope and fixed time, and ideally a fixed budget. Triple-fixed, just for good measure, is still an unfortunate reality for many people out there. So, for my last post of the year, here’s my take on that problem.

Stakeholders that have never experienced good iterative projects ask for commitment on features, because don’t know what else to ask for. Stakeholders that have only experienced bad iterative projects are even more problematic. They trust their delivery teams so little that they want all the details explicitly stated and tracked. Under the thick fog of triple-fixed delivery, most agile-by-the-book planning techniques just fail. Minimal viable slices end up being months of work. Attempts to prioritise the most important features lead to indifferent responses. Arguing against fixed scope is pointless, as this is baked into the demands of budget-holders. Debating the history of how people got into that mess might be amusing, but isn’t particularly helpful either. Instead, if you find yourself in a triple-fixed situation, embrace the only tool left to you: sequence.

Sequence is by far the most powerful, yet the most under-utilised lever for stakeholder management. The project might have fixed scope and time, even the price, but the sequence of delivery is still on the table even in horribly broken relationships. This is because triple-fixed stakeholders simply don’t believe that there will be any benefits from iterative delivery, so they don’t care about the sequence. And although the fake transparency of full task breakdown might sound like a quick fix, especially if they are all estimated to tiny story points, that’s not a good first step. Instead, make stakeholders care about the sequence! For that job, a picture is worth more than a thousand Jira tickets.

The picture you need to draw starts with a horizontal axis, which intuitively represents time. (Check Dan Roam’s Back of the Napkin for a more detailed explanation of this). Label the right end of the time axis with the expected final delivery date. Then, on the vertical axis, draw up some swim-lanes.

Most triple-fixed initiatives are large, and large initiatives require large investments. Large investments, on the other hand, often require a solid business case, with several major expected benefits. Ask the stakeholders to shout out those benefits, and fill in the swim-lanes. Make sure to move the discussion away from features and deliverables to outcomes and benefits. Then say something like “pretend it’s magic and we deliver everything on time, this means that by May next year you get all these benefits…” and wait for people to start nodding their heads in approval.

And then comes the punchline. “But imagine we rearrange the work a bit”, and I flip the whole stack by 90 degrees. “We could, for example, group all features that are important for one particular key outcome, so you achieve that in just two months.”

Make Christmas come early, and often!

This is where the options around sequence start to come into the play. Sequence of delivery is closely related to understanding the cost of delay, one of the key pillars of Donald Reinertsen’s ideas for product management, described in his seminal book The Principles of Product Development Flow. Understanding and managing the cost of delay is critical for effective product management, as it enables or supports most other good techniques. But the majority of people using this method apply it to features. Correctly estimating the cost of delay of features is practically impossible, especially for a large initiative that might consist of thousands of feature items. On the other hand, stakeholders have no problem juggling in their heads delaying benefits or getting them early. The cost of delay of a new report field is anyone’s guess, but judging the benefits of reducing fraud a month earlier or later should be much easier.

Sequence is an essential tool for survival in triple-fixed projects because it relieves the pressure on discussing whether some feature should be in scope or not. That game is already over anyway. Instead, we should figure out the right order of getting things out. Discussing options around sequence allows us to move beyond the choice between Yes and No, and instead make it a choice between Now or Not Now. (Or in horribly politically charged situations, Yes and Yes-But-Later). I’m sure this is not a particularly new idea, but the person that really nailed it into my head was Chris Matts, about 10 years ago, and since then I’ve been calling it Chris Matts Prioritisation. Earlier this year, in Singapore, one of the participants of my PO workshop misheard it because of my bad English accent, and wrote it down as Christmas Prioritisation. And it turns out to be a lovely metaphor. Why wait until the end of a project to get your present, when you can make Christmas to come early? Plus, why have only one Christmas at the end, when you can make Christmas come often, throughout the project. An argument I like to play with is “OK, this is your release 1.0 at the end, but what’s your release 0.1?”

Although triple-fixed stakeholders might say they care about features, they care about outcomes much more. For Christmas prioritisation, roughly evaluate the cost of delay for individual outcomes, and find something that would be significantly more valuable if it is achieved sooner. Of course, this is easier said than done. But here are three techniques that might help.

Partial victory

The first good idea is to present different options for a partial victory. Get the people around you to consider what would happen if you achieve one outcome, but fail to achieve another. Then try the same two outcomes, but reverse the roles. For example, ask questions like “How would it feel if next month we reduced fraud by 5%, but did not reduce operational costs at all?” and “How about if we reduced operational costs by 10%, but the level of fraud remained the same?” Compare the outcomes in pairs, and ignore the indifferent responses. If you hear something like “That would be pointless”, then the stakeholders actually value more the outcome you proposed to postpone. Test if that’s true by offering the inverted combination. If the response becomes “That would be amazing”, you have just discovered the first Christmas present. This technique works quite well when one outcome is the primary driver for an initiative and other stuff get added on because “it’s already a rewrite, so why not”.

Stages of growth

When there are genuinely several key drivers, a useful thinking model is the Stages of Growth sequence from the book Lean Analytics by Alistair Croll and Benjamin Yoskovitz. The stages of growth depict a typical progression of concerns for a product, from solving an important problem in a good way to making money and optimising operational costs. The terminology of the model is focused on startups and web, as that’s what sells books today, but the model makes sense in a much wider context if you just rename the stages a bit. If you’re working with a hipster mix of ninjas and rockstars and venture capital, use the original names. If your colleagues are allergic to all that terminology, use the names in brackets.

  • Empathy (usefulness): Is it solving an important problem? Does it solve it in a good way? Is it usable? Is it useful?
  • Stickiness (product/market fit, retention): Is it useful enough? Are people using the product enough? Is the target market right? Do users come back frequently enough?
  • Virality (cost of acquisition, conversion rates, user base growth): Are we growing the customer base at a sustainable pace and cost? Is the market big enough for growth?
  • Revenue (customer lifetime value): Do we make enough money from our customers?
  • Scale (operating costs): Can we deliver the same service cheaper or more efficiently?

The idea with the model is that at any given point, the product you’re building is in a particular part of that stairway, so it’s best to focus on improving outcomes related to that stage. For example, the model explains nicely why focusing on acquiring new users isn’t too helpful before focusing on improving retention. With a bad retention rate (this would relate to Stickiness in the model), bringing a million new people to the product (relating to Virality in the model) would result in a very small percentage of those people ever coming back. Focus on stickiness first, then on virality, and the impact is much better.

In the book, the authors go as far as suggesting to focus on a single metric at each stage — buzzworded to One Metric that Matters (OMM). I’ve never found a situation where only one thing is important, but from a partial victory perspective, agreeing on the current stage of your product will help to decide which outcomes you actively want to improve, and which you just want to control. For example, in the Virality stage, you might want to prioritise reducing cost of marketing and improving social sharing, while just making sure that the operational cost and profitability per customer do not fall too much.

This model is nice because it reinforces that all the outcomes are important, but some are more critical to improve now, and some become important later.

Replanning triggers

The third good technique is based on an informal psychological observation, for which I don’t have any scientific data to back up, but so far it’s served me quite well for working in IT. People can very rarely tell you what they actually want, but they can easily complain. By implication, a group of stakeholders representing different interests can rarely agree on a good target, but they’ll easily agree on a failure.

Get all their wishes for outcomes — stuff they would be happy individually if you achieve by the end of delivery. Then slice the period in half and ask them to imagine that halfway through the project, the numbers didn’t move enough. Imagine that the outcomes achieved halfway made stakeholders so uncomfortable to want to schedule a replanning meeting. Ask people to give you an estimate for what those numbers would be. That exposes assumptions around expected changes. Should operational costs drop linearly, or do we expect them to go down quicker? Should the number of active users rise on a hockey stick, or on a flatter curve? This discussion will expose time-critical outcomes, where a positive feedback loop creates a big difference between delivering in six months time or in a year.

For larger and longer initiatives, keep slicing the period in half. If you have six month constraints, discuss the first quarter. Then figure out what needs to happen in the next six weeks.

The magic of Christmas prioritisation

The great thing about discussing the sequence of delivery rather than the contents of the plan is that it avoids a lot of silly politics. Once a delivery is shipped, there are a few interesting options that open up.

The first option, quite likely in a triple-fixed mess, is that the features don’t actually deliver the outcome. This is a nice point in time to invoke a replanning trigger, if you used that method. Alternatively, get the stakeholders to decide if achieving the outcome is actually more important than obeying the plan, and if so, there’s a nice entry point into flexible scope and iterative delivery the right way.

The second option, slightly less likely, is that the key outcome got achieved. In many situation, the business case for the rest sometimes isn’t that strong, and you can offer to switch the rest of the plan for something more important. Again, a nice entry point into flexible scope and iterative delivery.

The third option, a real stretch in most situations, is that you end up delivering all the outcomes they want, according to the original plan. However, some of the key outcomes have been achieved a long time before anyone thought that was possible, so you’ve just proven the value of the whole iterative approach.

In either case, it’s a win-win. So if you find yourself thinking about how to do agile in a situation with a fixed plan, fixed scope, and fixed budget, make a New Year’s resolution to try out playing around with the sequence!