SORT Canvas - Focusing change discussions

Often, everyone in the room has a different perspective on what could and should be done, and discussions go in circles. How do you facilitate the discussion to move forward?

I have created the SORT Canvas to discuss high-impact change initiatives. Its main area of applicability is complex, systemic long-term change, i.e. organizational change initiatives. 

It can also be used for Team Retrospectives, although that's not its main focus.

This simple canvas allows you to steer discussions about change initiatives towards agreement and first results. Plan 2 hours for a full canvas session.

An example use case for the canvas might be SAFe's "Inspect and Adapt Workshop", when the trains needs to discuss more than small changes.

Discussion Ground Rules

1. Have everyone in the room: Make sure that all parties contributing to the situation and the potential solution are in the room. This doesn't mean all people - representatives suffice.
2. Choose a topic: Pick a single topic, and focus on that topic. Agree to de-scope topics that are only borderline relevant or unrelated.
3. Use abstractions: Complex environments have a lot of nitty-gritty details. When discussions get into details that aren't relevant for the group as a whole, abstract.
4. Align perspectives: Every person has a different perspective when the discussion starts. Instead of having people elaborate their own perspective, focus the discussion on "What do others need to know?" and "Where is my perspective different from that of others?" in terms of the four topics.
5. Move sequentially: Explain the four segments of the discussion (Situation, Objectives, Roadmap, Tasks) - and decouple the steps. Do not pre-empt by jumping between the four sections. Have points in the discussion where you explicitly ask, "Can we move on to the next section?"
6. Write it down: As early as possible, write down a point. Move as quickly as possible to answer the question, "Can we all agree on this?" - if not, make sure disagreement is heard.
7. Stop circular discussion: When we return to a point that's already written down in the current section, stop.
8. Clarify the goal: The goal is to come up with a common understanding of what problem we currently have, what we are going to do about it - and how that will help us reach a better state.

S - Situation

The first step is to come to a common understanding of which situation we are currently facing. Especially in larger organizations, people have vastly different perspectives - more so if they come from different departments and experience a clash of interests.

Describing the situation usually starts with a short description of either the main problem we face or the main change we want to make.

For example:

• an initial problem description could be: "IT doesn't deliver high quality" versus "Business is too vague on Acceptance criteria". The conflict is obvious - the solution isn't.
• an initial change description could be: "We want to move from specialist teams to cross-functional teams."

Neither of these are workable, and there are typically a lot of reasons why the situation currently is like it is. Note down the key problems, such as unwanted side effects or unfortunate long-term outcomes along the way. The description of these will help us focus the discussion for later steps.

Techniques like Five Why, CLD or Fishbones could be used to guide this discussion, although that may already be method overkill. Most discussions are sufficiently focused.

Try to get the most critical 5-10 points written down before moving on.

After describing the situation, we can choose to limit our further discussion to a subset of the situation or problem statements before moving to the next section.

O - Objectives

Captain Obvious would state, "We don't want to have those problems any more" - although that is too generic. Let's be specific on what the future would look like: which problems are gone, and how is it instead?

For example:

• An objective describing the future state could be: "IT and business agree before implementation on what defines high quality" or "A single team has both all the competency and authority to deliver Working Software to Production"

As you noted in my example, they contain the words "and", so they are indeed more than one item, and should be separated out, for example the first item might turn into:

• "Business agrees that the solution is of high quality when the Acceptance Criteria are met",
• "Teams agree to deliver solutions that exactly match the Acceptance Criteria",
• "Teams will pro-actively communicate when AC's aren't clear",
• "Both parties will collaborate to finalize the AC's before the Sprint",
• "When teams feel AC's previously agreed upon no longer make sense, they will seek dialogue."

Point in case: specifying an objective without "And" or "Or" ensures that different perspectives are properly discriminated, conflations are resolved - and ambiguity is clarified.

It's entirely valid to have multiple objectives: it means that the change might be more complex, or that only a few of them would be pursued in the remaining discussion.

In some cases, a single change action will create progress on multiple objectives - in that case, it's good to be broad on the objectives. Otherwise, it might be a good time to pick a subset of objectives before moving to the next section.

R - Roadmap

When we know where we stand and where we want to go, it's a good time to start asking: "How do we get from here to there?"

During this stage of the discussion, we should try to find the most effective way to proceed from the current situation to where we want to go.

Simple changes mean that it's a single change, and that would also mean the roadmap is quick and easy. If all participants agree that no intermediate action is required, that's great - and we can move already to step 4.

More likely though, you'll have to iterate and make a series of incremental changes to achieve sub-goals. 

The purpose here, again, is not to make a comprehensive plan for perfection - it's to outline the major milestones on the road to success.

Returning to our example, the roadmap could look like this:

• "Align Definition of Done with Business"
• "Business people actively participate in Planning"
• "Everyone knows how to ask key questions in Planning"
• "Acceptance Criteria are robust"

While having SMART items on the roadmap is nice, it's much more important that participants agree on the roadmap items, their value and effectiveness. We also need to ask how fast the change would proceed. If we already know that it's going to be years until the objectives are achieved, it's not even important what the items further down in the plan are - what's important is that we agree that the first two or three points are actionable.

We will inspect and adapt anyways.

T - Tasks

Once we know the key milestones on our change journey, it's important to agree on the specific next steps.

To reiterate: the purpose is not to come up with a comprehensive change plan. The purpose of this activity is to get actionable outcomes of the meeting, clear next steps that we'll work on.

When we define tasks, we first need to agree on the most critical milestones on our roadmap - what we want to achieve first, as well as that which has the highest probability to "make or break" the change. 

Here are actions to consider:

• Moving forward quickly, i.e. "quick wins".
• Actions that minimize change risk, i.e. "pivoting".
• Building the groundwork for future change, i.e. "go slow to go fast".

For each action, make sure that everyone agrees they are clearly linked to the objectives and roadmap.

Once you have agreed on maybe a dozen potential actions, decide which are the first three you will tackle. Be specific on what you want to do, who will do it - and when. Ensure that people commit to taking ownership - never assign a responsible person!

The general rule applies that you can't assign tasks to people who are not in the room. What you can do is formulate tasks like "Get buy-in from <person> for <action>" and have an attendee take ownership. Once you have identified that the specific person is necessary part of the change process, they need to be part of further sessions.

Make sure there's follow-up after the meeting ends.

An approach that might come to mind for dealing with following up on the tasks might be the "POPCORN Flow".

Wrapping up

With all participants, agree that the meeting has described a relevant problem, a desirable objective, a feasible roadmap and important actions.

Agree to a future appointment to follow up for an Inspect and Adapt session where the SORT will be repeated - revisiting all four segments.

ART Design - and: Solving the wrong problems

It's amazing how good organizations are at solving the wrong problem, i.e. "doing the wrong thing righter". Here is a great example of how not to design an ART:

This was the outcome of a PI-Planning. Their planning Retrospective led people to conclude that "electronic tools are much better for developing a Program Board than physical boards, because the dependencies are way too difficult to correlate with all those strings floating around, falling off, getting intertwined and so on."

This Train operates based on the assumptions that they have the right ART, the right teams - and are working on the right things. Never did it cross anyone's minds that any of these assumptions might be wrong.

The wrong ART

The first question we need to ask ourselves: do we have the right Agile Release Train?
If there is an extensive dependence on people outside the Agile Release Train, or there's a massive capacity bottleneck within the ART, while people outside the ART do have capacity to do the blocked work, then we might want to slice the ART different.

The wrong teams

It's okay for teams to occasionally depend upon one another. It fosters learning and information exchange. Some Product Managers even go as far as to purposely define features in a way that "swarming" across teams allows the ART to generate value faster. When teams choose to split work  and collaborate in real time to maximize value generation, that's a plus.

What is not okay, and a clear indicator that we have the wrong teams: When no team can get any work done without relying on actions of other teams.

Even Component Teams should be able to release value straight into Production, when teams can only do piecemeal work, those are specialist teams that inhibit the flow of value.

I have seen more than once how teams, guided by experienced SPCs and insightful RTE's, have spontaneously used the PI-Planning to "disband and regroup" - reforming as teams capable of delivering end-to-end value: It's possible!

The wrong work

The above example is a clear example of what leads to doing the wrong work. With so many dependencies, "dependency management" is already a full-time job. It shouldn't be. It should be effortless.
The prime directive of dealing with dependencies is: "Minimize."

When I see two or three dependencies on a PI Planning board, I'm happy - it means, we have decent team constellations and the right skills in the teams.
When I see more than ten dependencies, I will express concerns about team constellation.
When I see more dependencies than features on the board, I would ask the ART to work on resolving their dependencies rather than figure out better ways to manage their dependencies.

The problem of Proxy Users

User Stories - what's a user story, what's even a user? And: Why is that important?

The definition of a "user"

User - a person who uses or operates something.
Sources: Oxford, Google

A "person" can be both an individual or a legal entity.
The specific mention of the term "person" is quite important. We will get back to that later.

There are other definitions out there, also - that have a different emphasis:

User - a person or thing that uses.
Sources: Dictionary.com, Collins Dictionary

This definition opens a different way of thinking - that "things" (physical and/or virtual objects) can be users s well.

Types of "users"

There are various types of users.

To explain them, let's take a look at this scenario:

Scenario:
A person has bank account without any deposit money.
The problem? Checks bounce on this empty account.

Here are some core types of potential users and their problems in this scenario:

Category	Description	Example
End user (Customer)	Someone whose problem is being addressed.	Bank client: Bouncing checks means there is unpaid debt.
Service Provider	Anyone who provides a service using the product.	Bank: May get calls from both their customer and the people their customer gave checks to, asking what's wrong.
Intermediary	Representative of the Service Provider towards the person whose problem is being addressed.	Bank clerk: The person at the counter, answering on behalf of the bank what's happening.
Proxy	Representative of the person whose problem is being addresed.	Bank account: A virtual entity that acts as a proxy on behalf of the customer both towards the bank and the customer's transaction partners.
Delegate	Acting on behalf of the person whose problem is addressed.	Accountant: Responsible for balancing the customer's finances.
Administrator	Responsible that the product or service can be used correctly.	Bank IT: Checks need to be rejected rather than processed.

Why is the discrimination between those "users" important?

Know your Users!

Users define success

For example, if you develop in-house business support software, your user is often a single company, which means you'll have an entirely different way of measuring success than if your user is a Customer on the free market (of whom there could potentially be a couple billion). And the value of your product may depend on two categories of users: the Service Provider, whose balance sheet ultimately determines whether you are building the right product - and the Intermediaries, whose use of the product determines whether you are building the product right.

Users want their problem solved

Especially in large corporations, it's easy to lose sight of what the product actually is - and who the users actually are. By solving the wrong user's problems, you run the risk of local optimization - potentially damaging the interests of your real users in the process!

For example, look at this rather typical "User Story":

As a Security Specialist, I want people to choose difficult passwords and short password renewal cycles, so that accounts stay secure.

Then, think of yourself: How would you like it if the engineering team of your favorite app would spend a month to create password rules so complex that you need a PhD in Cryptography just to be able to determine what's a valid password - and then being forced to choose a new, different password every time you log in!

Solving the right problem

Intermediaries, proxies and administrators pose requests on systems, and while their requests are undoubtedly important, they all don't help you to solve the right problem!

Compare, for example, the following two user stories:

As a bank clerk, I want to be able to see the customer's balance with a single click.

As a bank, I want to know why I'm losing customers!

And now, let's add another user story:

As a bank account, I want to let my customer know when I have no money!

Do you see the difference between those three stories?

Users who have no financial stake

The first story may have sprung up from a conversation with a real intermediary user, and it's fairly easy to know whether you are solving this problem. However, it's almost entirely disconnected from the real user's (the customer's or the bank's) problem.
Unless it just by happenchance occurs that seeing customer balance also addresses the second problem, there's a good chance that spending time with the concerns of intermediaries derails the team from relevant business objectives.

Users that don't have a voice

The second story is an existence-threatening problem. Yet the "bank" as the legal entity that gives employment to the engineering team, has no face or voice. Its true voice may be hidden behind layers of management and bureaucracy. It may be too far away from the engineers to give it relevance and too abstract to be worth touching.

Proxies have no real needs

The third story is all too common in large enterprises: Components, proxies - even API's become "users" - assuming that if we service them, we are solving a relevant problem!

There are no proxy problems

Here's an uncomfortable truth: the proxy has no problem.
It's never the proxies' problem - it's ultimately, a customer or provider problem.

Only when real users (end users and/or providers) interact in a way that requires interacting on a path that crosses the proxy, is there a real problem. And there are two ways of solving this problem: either helping the proxy to do their job better - or to eliminate the proxy's part of the process altogether.

Hidden assumptions

There are always hidden assumptions in proxy stories:

1. The voice of the proxy echoes the voice of the unheard real user
2. The proxy is on the critical path of transactions 
3. The proxy is the constraint to the performance of the system
4. A dependency on the proxy is inevitable
5. Solving the proxy's problem is the best solution to the real probem

By accepting the "story of the proxy", which most agile teams do with little pushback or thought, we run a massive danger of sub-optimizing a solution, and limit the solution space. While this can be valid in many cases to provide focus, this begs the question: When, if not during refinement or planning, does the team spend time to think of which solution is the best to solve the most pressing problem?

Working the Constraint

The reason why I harp so strongly on the point of "proxies" and "intermediaries" versus "real users" - is that while they are on the road to creating a higher-performing system, it's nowhere automatic that improving upon their bidding improves the performance of the system.

Theory of Constraints teaches us that:

1. Optimization outside the Constraint is - at best - ineffective.
2. Time spent optimizing outside the Constraint is Waste.
3. To work on the Constraint, you need to know how to optimize it.
4. When the Constraint is operating at its capacity - elevate it!

Here's what happens when you listen to the voices of Intermediaries or Proxies as if they were the real users:

1. You start to forget who the Real User is.
2. You remain oblivious of how the changes you are making affect overall performance.
3. You don't know if you're working the Constraint or somewhere else.
4. You may institute a new Constraint on the Critical Path, worsening the system.
5. You will miss solutions that elevate the constraint, especially if the constraint is of higher order.

Summary

It's not forbidden to have "proxies". It's just dangerous. 

To avoid the most common pitfalls, start asking:

• Do we understand the real customer behind the problem we are solving?
• Is the solution on the critical path to success?
• Are we working the Constraint?

If you can't answer these questions with a clear and resounding "Yes", you're definitely in dangerous territory - and if you can answer any them with a clear "No", you may want to reconsider implementing this story to begin with!

The problem isn't as much who your user is - it's that "fake users" make you lose sight of what value is and how to create it!