Ed 034: Forcing Someone Else to Make the Decision Using "The Spike"

Why make the decision, when the Spike can force someone else to make the decision for you!

Greetings from Spain! Here’s to another edition of The Unblockers. If you like what you’re reading, consider subscribing and sharing.

The Scenario 🙋🏻

Picture this scenario: you're going about your day, reviewing your portfolio of projects and programs, when someone approaches you with a “significant issue” and believes you can resolve it.

They put time on your calendar, you meet, and you listen to their harrowing and grievous problem that could destroy the world.

After taking some notes, the smart Program Manager in you realizes the following:

1. This problem may not actually be that big of a deal

2. This problem is solvable

3. I may not be the correct person to solve this problem

4. I may not be allowed to solve this problem (out of my scope)

5. This problem needs to be escalated to a decision-maker

So what are the next steps? How do I triage this problem correctly without making any false promises or incorrectly working on something you’re not supposed to?

Easy. Write a Spike and give it to someone who cares more than you do

---

What is a Spike? 👋🏽

A Scrum spike is a short, document focused on gathering information or solving a specific problem. It is typically used when there is uncertainty about a problem or solution and no clear answer is available.

Benefits

• Gather information and clearly define the problem

• Reduce risk by defining consequences

• Derive possible solutions for the decision-maker

• Fast and low-cost

• It helps identify the correct accountable party/person

• Makes you look responsible, lol

---

Like What you’re reading so far? Consider sharing

How to Create a Spike ✅

There are a bunch of different variations for creating spikes but this is my favorite structure geared toward my needs, my organization, and it’s short and hyper-focused. Try to make it no longer than 1 - 2 pages.

1. Problem Statement

   1. Define the problem. Short and sweet.

2. Anticipated Consequence (What if we do nothing)

   1. This is my favorite part. Paint the worst scenario possible. Many times, this will stop a problem in its tracks or help escalate.

3. Affected Services/Teams/Products/Projects/Programs

   1. This section is used for additional context or detail building

4. Possible Solutions

   1. A short list of possible solutions

5. Recommended Solution (just 1 and only 1)

   1. Your recommended best solution

6. Historical Context

   1. The key dates/details/meetings/chat messages that led up to this event

Next: Escalate 📈

After you’ve created your Spike it’s time to escalate. You generally have around 3 choices of different combinations:

1. Escalate to your manager

2. Escalate to the problem origin’s manager (the person who approached you with the problem in the first place)

3. Escalate to the managers of affected teams/programs/projects defined in the Spike

Et voila!

And that’s it. From there, leadership will provide guidance as to which solution is ideal and will assign ownership. It might be you, or it might not 🤷🏽.

See you next week 🙏

Thanks again for reading. Like what you read and feel like supporting? Consider subscribing, or better yet, come on over to the main website for more great content below! (It’s free btw.)