All about OOPSI

The Problem with Agile

Agile software development practices have become popular in the last 15-20 years as a way for development teams to respond to business needs more quickly and with agility. However, many companies are having difficulty scaling these practices within their organisations or not availing of the benefits of agile despite investing heavily in transformation programs.

One of the common agile pitfalls is focusing on the mechanics of agile frameworks and technical tools, rather than on the underlying principles for success, such as collaboration. This often involves measuring success based on how well teams are following the framework, rather than the value they deliver or the speed they deliver it.

Another pitfall is the water-scrum-fall anti-pattern. This can manifest in two ways: 

• Development teams work in sprints, but analysis and testing activities are run as separate phases (like a waterfall project), meaning that the goals posts are constantly changing, and it takes a long time to get anything live. – This is particularly common in large corporate environments
• Teams are using Scrum, but there are still "waterfall-style" handovers between analysis, development, and testing. This means that testers can be twiddling their thumbs during the sprint, until a crazy panic at the end - which often leads to miscommunication and rework.

What if instead of implementing 'Agile' we set out to answer these questions:

• How do we deliver value earlier?
• How do we optimise for feedback and learning?
• How do we prioritise our work so that we are always working on the most important thing?
• How do we collaborate more effectively?

OOPSI Overview

OOPSI is a lightweight, adaptable, non-prescriptive collaboration framework for agile and product development teams which helps you break down complex problems, align to value and accelerate delivery.

OOPSI stands for Outcomes, Outputs, Process, Scenarios, Inputs. 

Following the OOPSI framework helps you break down work so that you can start on something small, but also make sure that you are still delivering something that is valuable. The different steps in the OOPSI framework help give structure to the discovery process and provide lightweight documentation that helps align everyone and avoid misunderstandings and rework. Following the framework gives you the confidence to collaborate and co-create, where everyone in a multifunctional team can contribute to their fullest.

To start working on something valuable as soon as possible, we need to be able to defer detailed examination of stuff that isn’t important until later. We want to find the highest value outcomes, then the highest value outputs that achieve those outcomes, then the highest value processes that deliver those outputs, then the highest value scenarios and examples that help clarify the required implementation.

Most Agile and Product Development teams I work with use User Stories.

Stories are written in a way that is supposed to help you understand the value from the point of view of the user or customer. The value is the 'so that' part. When a story or feature is first captured, it is lightweight representation of a user need, and is a token for future conversations.

Before we get into the details of the story or feature, it's important that we properly understand the value (the outcome) for the user. Having conversations and encouraging storytelling will help us understand the problems that need to be solved and hunt out where the most valuable opportunities are. We should be able to clearly describe the outcome we are trying to achieve and answer questions like 'What is changing? What will be possible that wasn't possible before? What is easier, faster, more accurate, less error prone than it was before? How will we know when we've delivered the benefit? How could we measure the value we are delivering?

When we're having conversations about value and outcomes it's useful to capture our conversations using a variety of rich techniques that help us play back our understanding and get feedback. This could be using sketches, story boards, user journey maps - anything that helps us collaborate with users and customers and achieves a joined-up understanding of the problem being solved and the outcomes we are seeking.

We don't want to end up like this...

Systems theory (started in the 1940s) is the study of systems in general, with the goal of discovering patterns that can be applied to all systems in physics, biology, and engineering.

One pattern described in systems theory is that the value of a system or process lies in its outputs. We can use this thinking to help us break down our stories or features and look for the most valuable things to focus on.

You can imagine the complexity behind the implementation of a new payroll system?... there could be thousands of processes and rules to consider... By hunting for the most important outputs - (and better still focusing on a specific example) - we can find a good place to start exploring a bit deeper. Discussions (and illustrations) around important outputs help deepen our understanding and spot challenges early.  

Looking at this payslip example, we might decide that our first sprint goal is to produce a payslip for a UK employee, without any overtime, commission, or bonus and without a student loan, pension or union fees. We could iterate in subsequent sprints to grow our capabilities to deal with more complicated outputs like the one above.

Let's take another example...

Starting with this feature:

We know that the value of a system normally lies in the outputs, so let's think about them first. What outputs are important in the withdraw cash feature?

Crikey, quite a lot.

Cash, receipts, returned bank cards, an updated balance on a bank statement, updated database values, and even some error messages.

Some of these outputs might be well understood, but some might benefit from a bit more exploration.

It’s helpful to illustrate outputs with examples. Draw them. Understand the data attributes that appear on the outputs. Use real world examples wherever possible. In this example we might choose to draw the receipt or mock up the error messages. This helps drive conversations and get to the important stuff.

Now let’s choose our most important output so we don’t get becalmed by analysis paralysis. If we were building and installing the ATM machine, our most important output would probably be cash, if we were re-designing the transaction database however, our most important output might be the updated account balance.

Some of the outputs might naturally go together. For a high-level happy path scenario (and this is often a good place to start) we would normally get cash, a receipt, updated database tables, our card returned and an updated statement (at a later date)

Narrowing down the outputs that we are focusing on helps us with the next step of OOPSI…

Process is important in helping you tell the whole story. It gives you narrative and context. It also helps you align the team to the bigger picture - particularly if you have UX work.

Having started by looking for the most important outputs we can now examine a more simplified process as the basis for splitting our feature or story out further. It is good practice to break down stories and features in this way. Jeff Patton's technique 'story mapping' is a similar technique to use here. Let's look at the process for our ATM Feature. We'd probably hold a collaborative workshop (using Miro perhaps?) to capture this... and we might not get it right straight away... Our goal here is to capture the most natural end to end process left to right like this...

All of these could be stories.

Notice the process is linear. The process stays simple because you are considering fewer outputs.

You should capture and keep the process. It’s valuable in helping the whole team understand how the system is expected to behave, and it’ll probably be useful beyond the delivery of the project. Take photos, write it up, put it on confluence as part of your living documentation system.

Once the process is mapped, you have a nice structure to start thinking about Acceptance Criteria and testing. Each process step (now broken out to a separate story) will have a set of Scenarios (Acceptance Criteria) which describe the different conditions that a story must meet in order to be accepted by the customer, user or other system. Well defined acceptance criteria and acceptance tests are used by Agile teams to specify behaviour and guide development. Agile teams often work collaboratively in a 3 Amigos workshop (technical expert, testing expert and business experts) to define these in advance of development so that everyone knows precisely what to build.

It's much more effective to brainstorm scenarios around a defined process to generate specific outputs and outcomes rather than consider everything at once. OOPSI helps us organise and rationalise our scenarios and examples around activities in the process, which makes them much easier to isolate and maintain.

Visualising the end-to-end process also helps us prioritise which steps in the process to start with. Some steps in the process will be more important than others, some will be more complex and have more uncertainty.

Let's start by looking at the 'Check Acc Balance' Story

The key scenarios for this one would be:

1. Customer has sufficient funds
2. Customer has insufficient funds

We could write them like this:

The reason that we often find lots of defects during the testing phase of a waterfall project is because it is the first time that the solution gets tested with real world data. An important part of Agile team working is collaborating around detailed examples (like test conditions) to support each scenario so that they are concrete and there is no room for misunderstandings or assumptions.

The practice of using examples to help specify how a story should be implemented is called Specification by Example. This technique is extremely valuable in removing handovers and dramatically reducing rework. The Examples (the inputs and pre-conditions to support the scenarios) serve as the specification AND the test and are worked on collaboratively before development starts.

Specification by example often uses tables of data containing pre-conditions of the test, input data and expected results (outputs) to define the expected behaviour. The value of the example is in the data used to drive the Coming up with the best (and fewest) set of examples to support the scenario is a skilful practice and testers tend to be naturally good at it.

Here is how the specification by example technique would be used to extend our ATM scenario

Scenario: Verify Customer has sufficient funds

This scenario, supported by the table of data serves as a really good target for development, and also works well as a functional unit test. It's the kind of example that could fit easily within a sprint and be demonstrated by the team. By using the OOPSI approach you can quickly cut through the detail of a story or feature and find a good place to start. The next step would be to start to extend the examples in subsequent sprints so that we are telling a more comprehensive story each time we iterate

Summary

The OOPSI framework can be applied in many ways, in the large and in the small:

• At the highest level, it can help guide conversations and give confidence to a facilitator who is helping a team explore a problem.
• For Product Managers and Product Owners, the different steps can guide discovery activities and allow for co-creation of lightweight documentation that raises shared understanding and facilitates fast feedback (even structured as a design sprint to rapidly kick off an initiative). 
• For Agile and Product Development teams, OOPSI can be used to help explore and split user stories as part of a 3 Amigos workshop, and help structure tests and promote good test design and automation strategy.

In all cases OOPSI helps teams quickly identify and focus on the most valuable work and align strongly to shared goals. The collaborative approach helps bridge communication gaps between product and engineering teams, resulting in less rework and happier more motivated teams.

OOPSI emerged as a thing after lots of brain wrangling with my good friend Pete Buckney and is heavily influenced by work from other awesome folks including Chris Matts and his work on Feature Injection , Jeff Patton's Story Mapping and Kent McDonald's work on 'analysis with an Agile Mindset' (particularly his book Beyond Requirements)

Thanks for reading. I’d love to tell you more about OOPSI. Please reach out to me for a chat.