#NoProjects: The Value of Scenarios

Lean continuous improvement & prioritisation in the enterprise, in a non-comprehensive way

The funny thing about some #No<Insert your favourite struggle here> hashtags or movement (or non-movements) is some of them have a lot of promise and deliver massively when applied correctly, whilst others seem to miss a point and get bogged down in the name. For me, this is what #NoEstimates and #NoProjects have felt like, though not in tat order.

Recently, a discussion started on twitter about the name #NoProjects. Allan Kelly, the main proponent and author of the book “#NoProjects: Correcting Project Myopia” (leanpub.com — yes, a plug, I’m not affiliated. Other books on stuff exist. Go read those too) engaged in a discussion about the “#BeyondProjects” versus “#NoProjects” name, pulling in folk like Dan North and of course, I stuck my big size 11’s into it too, like the typical thug that I am and as such, it went somewhere else.

Personally, after the fiasco and amount of wasted energy dissolving the black hole arguments about the #NoEstimates hashtag, I would have preferred to have a different name. #BeyondProjects sounded much better, but Alan informed me that it didn’t take off. OK, well the other counter to having a descriptive title is it spreading, so I get that, but to my surprise Alan also stated that Beyond Projects was even confused with “Programme Management”.

Internal Monologue: “OMFG! WTAF!?”

Whilst conventional and even lean wisdom is we should always drop everything to unblock a business, the question of whether it is blocked or just “mildly inconvenienced” is rarely approached and pure delivery contexts rarely account for assessing whether the business value was actually delivered against the business case that started it all.

I see #NoProjects on the Horizon…& All Around

For years now, I’ve seen the #NoProjects idea as a way to consider continual change in an enterprise, which counters the responsibility of “temporary organisations (read, teams) in charge of delivering one or more business products according to an agreed business case” (PRINCE2 definition) and introduces end-to-end, cradle-to-grave product responsibility.

“A Project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case.” — PRINCE2

“No it fucking isn’t!” - Ethar Alali

The biggest problem I have with this, is with two words. ‘Delivering’ and ‘temporary’. The reality is that 85% of a software or IT system’s life is in production.

Also, it seems only in IT and hard engineering that a “project” is temporary and the team finishes it’s responsibilities when the software and systems are out in the wild. This is certainly not the case in charities or some parts of public services around the world. To end your responsibilities after delivery, requires a huge knowledge transfer effort, which in practise leaves holes, and leaves the software system wide open to issues coming across to affect other projects the team move on to work through. It’s what we call “the long tail”. For example, bugs and enhancements appear from project p1 snap up members of the team who are on p2, which affects the throughput of p2 and thus the value p2 delivers, as well as the impact p1’s bugs have on blocking the business from capitalising on it.

This is important for a few reasons:

• Industries don’t stand still. Competitors are innovating and your business has to innovate.
• Some businesses, especially leisure and tourism, are highly seasonal. p2 missing a deadline, may miss its window for an entire year!
• Crucially, not everything in p1 is actually that valuable. Whilst conventional and even lean wisdom tells us we should always drop everything to unblock a business, the question of whether it is truly blocked or just “mildly inconvenienced” is still open and rarely approached in prioritisation. Furthermore, pure delivery contexts rarely account for assessing whether the business value was actually delivered against the business case that started it all.

It’s this last one which then led to a few more questions and a broader discussion, since an organisation without focus is different from a “projectless” organisation.

Recapping Features & Stories

For those of us who’ve worked with Behaviour Driven Development, Hypothesis Driven Development or even good old vanilla TDD (they’re all tests), they’ll recognise the existence of a few elements here. Not least:

pre-condition: What initial condition has to hold true before the action runs (Given)
action: what trigger, event or action occurs (When)
post-condition: What holds true after (Then)

These three statements together form scenarios of course and through conversations we elicit one or more of these in a feature and each feature, especially in Gherkin files, conventionally considers the position of one user/actor within the context of the system (and a system can be a business).

As a <something>
I want to <do/get/eat/swim/whatever something>
So I get <some important valuable thing from it>

There are several layers here. The main user story is broken down into one or more scenarios. Each scenario falls into two main classes:

1. Primary scenario — aka ‘Happy Path’. The scenario every single engagement goes through for that feature.
2. Secondary scenario — aka ‘Unhappy Path’. Some journeys will go through this, some will not.

Primary scenarios apply to everyone engaging with that feature and/or your business. For example, in retail every, single person walks through an entry to engage with the store, even online (search engine, landing page whatever). Every customer buys something and so goes to the checkout (online or IRL) and pays. These are by far your most valuable individual scenarios, since every customer goes through.

Secondary scenarios you can identify by the fact that only a fraction of users go through it and they almost always have to go through a primary scenario first. For example, when returning goods, customers have to have purchased them first.

Primary-1, Secondary-infinity

The problem is that secondary scenarios are each valid scenarios in and of themselves. From a business perspective, each of them has a different hypothetical value. That means this bold line is actually different.

As a <something>
I want to <do/get/eat/swim/whatever something>
So I get <some important valuable thing from it>

Let’s take the example of a lot of online clothing retailers.

As a teller
I want to process a customer request
So I get through serving all my customers and make a day’s wage

50% of what is bought is returned. Customers often buy two sizes of the same clothes, try one on, and then return the one that doesn’t fit. There are customers who may start credit agreements, there are others still, who want to close agreements and there are some who will cash-in vouchers. Each of those features of the business will have a primary scenario, and several secondary scenarios but all of them exist in a business context and any changing of these processes, or even the initial conditions, changes the business itself.

Notice, for each feature, each secondary scenario never breaches the value of the primary.

“Aha!” I hear you say. “What about regulation? Breach a rule like PCI-DSS and you’re borked!” and I reply

“Right! I see your argument and raise you this. That primary scenario is a saving of the regulatory fines or penalties. Take the company to a position as if the breach happened and add the value of the penalty forward.”

Now, this should already have sparked a light-bulb or two, and it goes back to another one of the things I’ve been ranting about since the early 2000’s. Methods of Agility do not adequately attribute value to the stories they define.

Hypothesis Driven Development & Lean-Startup

This is why I like the idea of Hypothesis Driven Development (O’Reilly) because it starts to come round to where I see it.

I won’t spend too long on this, but each hypothesis creates a tiny business case, embracing all the uncertainty within it. As with all business cases, which are experiments, they need validation. Hence, the HDD card of:

We believe <this capability>
Will result in <this outcome/value/micro-business case>
We will have confidence to proceed when <we see a measurable signal>

All the statistical words are there.

“believe” <- because it’s not proven fact
“confidence” <- yes, statistical confidence intervals to accept the hypothesis.

It can still be improved, but the card itself is not where the improvement need to be made in my experience. It is in the analysis to validate the hypothesis. Nevertheless, it’s a good start as it allows business folk to be first class citizens in the process. Something we’ve not allowed them to be.

Crucially, it enriched the prioritisation metrics no end! Lovely!

Segmentation: An Introduction

Suppose you have the following features on the backlog:

Features, each of which encapsulates primary and several secondary scernarios

The granularity [even using #NoEstimates], is a block of stories that are a certain number of “points” [or “cards”] in effort. The problem we have in there is that Feature 2 may have been valued as less than Feature 1 as a whole, but we don’t know enough about the granularity of the scenarios to know when to go for Feature 2’s primary. So people deliver all of Feature 1 and then start Feature 2. Seems sensible right?

My counter is that, suppose we break it up into primary and secondary scenarios and assign each to a story (read, ‘hypothesis’). What this allows us to do is determine the relative value of the stories to both secondary and primary scenarios across all features on the board.

As mentioned, these should be augmented with the business case associated with the scenario.

Using our retail example at the till above:

Primary 1 is online purchases=100% of physical income, 70% of total income
Secondary 1.1 is cancellations = 1% of total expenditure
Secondary 1.2 is Returns = 50% of online expenditure

Primary 2 is the in-store Cafe = 15% of total income
Secondary 2.1 is wasted food in the cafe = 10% of cafe expenditure

Primary 3 is online sales= 100% of in-store income, itself 15% of total income
Secondary 3.1 are Free delivery = 0.2% of all expenditure

What we now have is a way to order the most important aspects of the platform, with a perceived value associated with each.

Backlog Priority

Here, we have some primary scenarios which are worth more than the top end secondary scenario. This allows us to order the scenarios in value order.

Half Finished?

Nay. Here is where we take a leaf from Lean-Startup. It’s MVP time. You A/B-test that against the previous (or another current) incarnation of your enterprise vertical. Keep what works best, rinse and repeat. Each stage is a continual improvement over the previous one at vertical level. This also allows you to respond to changes in the market itself, all of which will happen whether you are paying attention or not.

For example, with a basic MVP at each stage, you’re giving them a generic error for anything not “caught” and having them call a human. This has several up-sides.

1. There are a lot less of these in throughput than primary scenarios meaning your call centre is sized appropriately to demand (note, there are more secondary scenarios in breadth).
2. You are focusing on the most valuable items first, the primaries. They are the ~80% plus, of value in each feature, and thus spring-boarding at the beginning of your endeavour.
3. You are not being distracted by much less valuable secondary scenarios, which cost a lot of money to do, but deliver a lot less value.
4. Your Definition of Done is driven by value, not comprehensive coverage.
5. Once you’re through some scenarios, and they’re living and flowing, revaluating them allows you to adjust according to demand and crucially, respond to change.
6. Fill in the rest when you have time. It improves the customer experience gradually.
7. You are aligning the value you deliver to the lower value at risk number. The cone of uncertainty is big at the beginning, so working to learn the most needs very thing, small experiments, which traverses the cone quickly and gives yo more certainty (which ties into some of the thinking behind #NoEstimates).

Epilogue

There is a lot to #NoProjects and this barely scratches the surface. It certainly wasn’t intended to be a comprehensive review of the topic. When I’ve used this to align multiple teams to value chains, this has more than proved it’s worth. Speeding up delivery sure, but crucially, keeping the knowledge within teams, allowing them to focus their energy on a cyclical, continually improving end-to-end benefit, and prioritise the most valuable parts of the business to change.

I’m Ethar, I have opinions on everything! Oh and I try to run a company and do stuff.