Identify the real problem
Almost every business struggles to solve business problems. Many cottage concepts have sprung up: Agile, Lean, and many others, to try and help with these challenges. Unfortunately, many of them overcomplicate what is a very simple situation; and I would argue that the real barrier is ego.
Let me explain with a scenario.
Given the photograph below, there's a problem. Can you identify at least one problem, just based on the photo?
Let's step through with various approaches.
"As a homeowner, I need a new vase because the previous one broke."
By and large, Agile relies on someone to craft "stories" designed to assist developers to solve the business problem. The stories are generally distilled versions of interviews performed with the affected business subject matter experts (SME's).
Agile is designed to get you to the desired outcomes quicker and more efficiently by focusing on those outcomes with a very targeted approach. It lends itself very well to an IT environment where resource constraints are a constant challenge. However, for most businesses, it falls short in one critical area: why.
The story I put above in quotes doesn't say anything about why we're doing this. The value of the operation. There may be a value proposition, but in most cases it's not shared with the developer. When tasks are built from the story, the tasks are assumptive; they don't give any additional information regarding the why.
Consider it this way: Why does the homeowner need the vase?
The default response (usually from whoever is serving as "voice of the customer") is that it doesn't matter. But it does if you want to add value. This is an ego situation; one person is making the decision for what does and doesn't matter to another person, and that's where Agile tends to fail. Not in getting work done, but in making sure that the work is valuable to everyone, not just to the "voice of the customer" or the customer themselves.
Suppose the customer wants the vase because it's their only way to water their plants. A developer might offer to build a different way to water plants that (A) won't shatter in the future, (B) will lessen the amount of time necessary and (C) will save them money in watering. Now, the whole story changes from a simple repair to potentially addressing the real need - getting the plants watered. This alternate strategy may even save time over a straight repair (thus valuing the developer's time).
The "voice of the customer" will have their ego kick in and get defensive, because the idea didn't come from them. Also, asking why slows down the process and tends to make business analysts and Scrum masters antsy; but Agile never intended that you rush the process, simply that you streamline it. The methodology actually welcomes making sure that everyone has every opportunity to contribute to the best possible outcome. It's just that many businesses only focus on resource savings and the 'rah rah' of a quickly completed project rather than getting the best outcome.
"Why is there glass on the floor?"
While Agile focuses on solving problems, Lean (which implements what's called Kaizen) focuses on distillation of the situation to identify the problem.
Distillation, put simply, is boiling something down to it key components. If you were to heavily boil tap water, you will end up with steam and residue in a pan. Kaizen works the same way; breaking down the situation until you get to what you believe are bare basic, solvable elements.
As an outsider, your brain and your eyes will automatically call out certain key things. It's clear and apparent that a vase (shape of components) was dropped (shattered glass) on a floor (flat surface underneath). You know from basic science that gravity is what caused it to fall, ultimately. You know from basic physics that the only way it could have gone down is (A) someone knocked it over or dropped it, OR (B) an earthquake (which you would have felt if it was strong enough to cause the vase to fall).
So when this question hits you, your answer likely is, "someone dropped it or knocked it over."
Kaizen will ask, "why did someone drop it or knock it over?"
If you weren't the one that did it, you won't have an answer. They will expect you to go find out who did and why.
Let's assume a pet did it.
Kaizen will ask, "why did the pet knock it over?"
Uh...they're an animal.
So now you've hit a point where you cannot answer why...and the flaw in Lean. You still haven't identified the true problem.
Kaizen will describe the problem as either the pet being in proximity to the vase or the vase being in proximity to the pet, because those are your only two logical outcomes. The solution might be a plastic vase or might be lock the pet up. Neither are really viable answers; a plastic vase falling will still spill its contents. Locking a pet up over a vase isn't ethical.
Lean has a tendency to focus on minutiae and low value things. Businesses will often implement Lean to try and improve everything, when there's very little value overall in doing so. Value gets lost in the conversation.
If you used Lean to streamline how many pens you bought because it was wasteful, that's fine, but if your streamlined process results in people having to bring their own pens from home because the ones you changed to don't work well, you just shifted waste from one place to another.
I'll give a real world example of this failure.
A large company on the West Coast sends the majority of its staff to the Epic conference. Their Accounting department wrote a general procedure for travel booking; two forms and you're done. Someone in IT had the brilliant idea of, rather than having every worker submit their own travel requests, centralize it through that person so it's consistent when submitted.
Sounds good, right?
The problem is, if you understand how conferences work, there are different considerations. Different locations, different hotels (discounts, proximity, etc), different rental car needs, different traveling companions, different flight needs, etc. It's extremely - EXTREMELY - difficult to create a one-size-fits-all strategy to booking travel beyond a single tool that gives whatever choices within the business rules.
In this situation, four employees needed to go to a different conference for a new tool that the company had never done travel for. This conference strongly recommends booking at certain hotels, and flights tend to be challenging if you don't know what you're looking for. The temptation of businesses is to book Frontier because it has a direct flight and it's always the cheapest.
💡 Frontier does not have a first class. This makes it difficult for anyone who is higher weight or taller/broader.
💡 Frontier nickel-and-dimes for everything else, including food and drinks. This means your cost is higher than the flight price.
💡 Frontier tends to overbook to frequent destinations, increasing the risk of missed flights.
Someone who has never flown it or traveled to that conference won't understand. Someone who has, will.
In the new process, the company would end up spending way more time and money accommodating this new conference trying to square-peg-round-hole from the existing Epic conference set up, instead of allowing employees who understand these nuances to book their own travel if they choose.
So, What's The Problem?
Let's go back to our vase and define the real problem, and a better way to get there. This is the process that MEGA Solutions will always take to try and help companies focus on the real problem, rather than creating more.
It's not that "a vase is broken", that's a cause.
It's not that "there's glass on the floor", that's a trigger.
The real problem...is danger. Danger creates risk.
Risk is always a problem worth evaluating, even if you choose not to act on it immediately.
✔️A person could step on the glass and damage their feet.
✔️A pet could injure themselves by walking on or ingesting shards of glass, especially the smaller ones you don't immediately see.
✔️An child, yours or otherwise, could injure themselves by walking on or ingesting shards of glass, especially the smaller ones you don't immediately see. As a person who as a kid almost lost a toe to this very situation, I speak from experience.
If you don't have a pet, the second one is less important to you.
If you don't have children or don't expect children in your house, the third is less important to you.
The first one depends on where the vase ended up. You can't tell from the photo. Is it on the floor or on a table? If it's on a table, the risk is very low; though you could still damage your fingers cleaning it up. If it's on the floor, the risk may be medium.
Now, I'll wrap this up with a comparison.
Suppose that at the same time this glass was discovered, someone else discovered spilled coffee grounds near the coffee maker. What is the risk there? Marginal, if any. At most you're talking about a bit of wasted money.
It's often easy to say "fix everything" - but you may not have the time or resources to do that. You will need to prioritize.
Prioritization should always consider factors such as the level of risk associated with doing or not doing the work, because always focusing on low value, low-to-near-no risk work has no value except to the person who is most annoyed. An employee with OCD may want to immediately clean up the grounds because it will only take a few seconds. But what happens when you have multiple "...a few seconds" work projects? At some point you will run out of resources.
Our goal is to do two main things.
First, help you identify the real problem, not the one that seems most apparent, but the one that should easily drive a value conversation.
Second, help you identify where workers are spending time on other situations that have little-to-no value, and work with you to determine a plan for prioritization.
We can do this even if you already practice Agile and/or Lean methodologies, where we see opportunities to improve. We don't want you to stop using them; they are strong methodologies, but we can help you find ways to use them more effectively, and gain real value from them.