Recapping the "Five Simple Rules About Problems" From Agile2021

The title of my favorite talk at Agile2021 was Five Simple Rules About Problems. It was presented by Kevin Clark, a Delivery Lead at VMware Tanzu Labs (formerly Pivotal Labs). When I shared the five simple rules with the WWT Agile Coaches, our own Tony Fantozzi shared a rule that seems so important that I think it belongs on the list. I'm calling it "Rule #0," and I'll share it at the end of this article.

Kevin wanted each rule to be simple to understand and something upon which we would all agree. He wanted something that he could toss out during a team meeting that everyone can quickly agree with and use to steer a better path forward for the team. Kevin likened his five simple rules to Occam's Razor: a way to simplify things and allow us to look at what's really important.

Rule #1: Only solve problems that you have.

This rule is really easy to break. Have you ever heard someone say:

• "We should build this now in case we decide to do this other thing in the future." or
• "If the business decides to do X, we'll be glad we did this." or
• "This other thing is coming up soon, so let's get ahead of it now."

All of these lead to systems that are over-engineered and/or too complex and difficult to change. You think that you are proactive, but the needs of a product change. By the time you need that solution, the situation may be quite different than what you anticipated, rendering your solution insufficient or inaccurate.

Rule #2: Solve one problem at a time.

This rule is very familiar to those working in software delivery as we are always talking about limiting WIP (Work In Progress) to improve delivery time, reduce risk and increase responsiveness to change. Even though this rule is at the top of our minds, it's still easy to break. Two high-priority problems may arise simultaneously. It is important to determine which of those is a higher priority and work on that one. Humans aren't good at multitasking, even though we think we are.

Rule #3: Problems are things that people have.

This rule is focused on ensuring that we keep users in mind when identifying problems and looking for solutions. Consider the following:

• Only people have problems. Computers don't have problems. A broken computer isn't a problem for the computer. It's a problem for the person using the broken computer.
• The problems our team attempts to solve should revolve around eliminating pain for users of our software. We shouldn't be writing software because we think that software will be cool. We should be using software to eliminate pain for our users. This relates directly to user-centered design (UCD).
• If we can't frame a problem from the perspective of a person, it may not be an important problem to solve.

Rule #4: Solve a problem once at most.

This rule is interesting because the wording is such that we could break down the rule into two sub-rules.

1. Solve a problem zero times: Wait, when can you solve a problem zero times? Turns out, very often. Often the problem you are solving doesn't need to be solved. You may think something is a problem that doesn't cause any people pain (see the rule directly above). In that case, the problem doesn't need to be solved at all. Kevin asserts that a surprising number of things seem like they are bad, but don't really matter. This idea feeds directly into prioritization and solving one problem at a time. In software, the ability to say "no" when something doesn't actually need to be done is an important quality in a great Product Owner. This allows the team to stay focused and solve the problems that actually matter.
2. Solve a problem one time: When a defect is found in a piece of software, we respond by first writing a regression test that correctly replicates the defect. At the time we write that test, it will be failing. We then write code to fix the defect and ensure that the test will pass. The existence of the regression test ensures we will not solve (or even see) this problem again.

Rule #5: Only solve problems.

Hold on here — why would Kevin even state something so obvious? Isn't this like 1 + 1 = 2? Well, he claims it's easy for teams to build features that aren't needed. It's also easy to refactor code that won't make the team more efficient. Kevin asserts that this rule is the one that is most useful to him. He uses it in meetings when conversations go down rabbit holes, people start focusing on goals that diverge from the conversation's purpose, or when new work is suggested just because it sounds interesting. 

When this happens, he tosses out the phrase, "only solve problems," which pulls his team back to what's actually important. This works because people take it less personally. If he said, "that idea sounds like a waste of time," people would immediately get defensive, but when he says "only solve problems," people usually laugh and then have a conversation around if this thing is actually a problem, who it is causing pain for and does it need to be solved at all (see all the rules above).

Rule #0: Don't create problems while working on a problem.

This reminds me of the Hippocratic Oath taken by physicians. Part of the oath has been translated to "First Do No Harm." Tony explains several famous airplane cases where a pilot deployed landing gear, but the light on the console didn't illuminate, saying the action was successful. The pilot and co-pilot get so involved in working on this problem that the plane runs out of fuel or crashes into the ocean or the side of a mountain. Tony says it's important to remember that when working on a problem, you still must fly the plane. To do otherwise creates a new, potentially worse problem.

I hope you find Kevin's rules about problems (and Tony's addition) as useful as I do.