The kitchen-bin epiphany: why software (and homes) fail when we jump to solutions

I have a small confession: I have a moment of joy every time I use my kitchen bin.

It sits in a pull-out drawer right underneath my food chopping area. I can stand at the kitchen island, chop a pile of carrots, slide the drawer open, and scrape the peelings straight in without dropping a single stray bit on the floor. It is pure, effortless harmony. It didn’t happen by accident, it happened because I actually thought about how I want to use the space.

When I first entered the world of Lean Agile software development, I just so happened to be going through a home extension. Naturally, my brain made some neural connections. Now, whenever I’m trying to make sense of a complex software project, I can’t help but view it through the lens of bricks, mortar, and kitchen bins.

Because whether you’re building an app or adding a wrap-around kitchen extension, humans share a terrible habit: we jump straight to solutions before we’ve actually defined the problem.

The classic "waterfall" trap: a recipe for regret

Imagine you’ve decided you need more space. You hit a wall (literally) and decide: "Right, we need a loft conversion or a rear extension"

In the traditional way of doing things, what a software or project manager person might call "Waterfall" the process looks a bit like a relay race.

1. You consult an architect to draw up options of what the new space will look like.
2. You review the drawings, tweak a few visual bits ("Can we make that window bigger?", "Let's put a step down there to separate the room"), and sign them off.
3. The drawings are handed over to the builder, who crack on with construction.

Presto! Extension complete.

Except... six months later, your elderly relative comes to visit, and you suddenly realise the stylish "step down" you added to create a cozy zone makes getting their wheelchair into the living area an absolute nightmare. Or you sit down with your morning coffee only to discover that your shiny new picture window offers a panoramic view of your neighbour’s rotting compost bin while the solid brick wall next to it blocks what could have been a stunning sea view.

You spent thousands of pounds, hit every deadline, built exactly what was on the paper, and ended up with something that doesn't actually fit your life.

In tech, this happens every single day. Someone says: "We need to build a bespoke mobile app so customers can track their engineer's arrival live on a 3D map!" Missing the fact that customers just wanted a simple text message saying "Dave will be there between 2pm and 3pm."

Enter Lean Agile

Lean Agile isn't about rushing to lay bricks; it’s a process of slowing down to ask the right questions. It’s about uncovering the underlying goal, the why behind the what, before you spend a single penny on unnecessary concrete or code.

In Lean Agile, we start with Discovery

You might walk in saying, "I need a 4-meter rear extension." But a good Agile architect won't just say "Sure thing, where do I sign?" They will pause and work closely with you to really get under the skin of the problem.

Through observation and deep-dive questions, you realise that "needing more space" isn't the root issue. The real problems are:

• Your current kitchen is dark and cluttered.
• You have a hallway that takes up huge square footage but only serves as a dumping ground for shoes.
• You need somewhere to dry laundry that doesn't make your living room feel like a damp laundrette.
• You need a sanctuary to get peace and quiet when the kids are being noisy.
• You want to be able to cook without turning your back on guests.

Discovery uncovers User Needs beyond surface-level wants. And it doesn't stop at your needs either, it defines the needs of every other "user" in the house. That includes your kids, your pets, and your elderly relative who needs step-free access to the lounge.

In software development, Discovery stops us from spending £100k building an entire extra floor when knocking down one non-structural interior wall and adding a skylight would give you the light, flow, and joy you actually wanted for a fraction of the cost.

Phase 2: alpha (prototyping & reality checks)

Once your true needs are defined, you move into Alpha. This is where we start testing ideas quickly and cheaply before committing to permanent structures.

Instead of drawing fixed rooms, the architect draws shapes based on movement and needs. But here’s the beauty of Agile: you don't design in a vacuum. You bring together the user (you), the designer (the architect), and the team actually doing the work (the builders).

Imagine the architect gets carried away and says: "Let's put a massive, flush, floor-to-ceiling glass sliding door right here so your living room seamlessly flows straight onto the patio."

It looks stunning on paper. But because the builder is in the room during Alpha, they can pipe up with a reality check:

This is where the magic happens. What looks and feels amazing in theory might turn into a maintenance nightmare later on. By getting feedback from both the designer and the builder early, you get an informed choice. You can weigh up the trade-offs: aesthetic perfection versus long-term durability, before the concrete is poured.

In software, Alpha is where we build basic wireframes and "Spikes" (quick technical prototypes) to test if an idea actually works with real users and real code before committing weeks of development time.

Phase 3: beta (incremental building & live testing)

Now we enter Beta, where the vision turns into reality, incrementally.

Instead of building the entire house in one go and handing you the keys at the end, Beta relies on building in small, usable increments and gathering feedback along the way.

Some of this might involve temporary structures. Imagine the builder puts up temporary timber stud frames or cardboard cutouts in the space so you can walk through it. Suddenly, you realize: "Oh, if we put the door there, the sunlight in the afternoon is going to glare directly onto my laptop screen." Great! You move the door frame six inches to the left. Cost to fix? Ten minutes with a spirit level and a hammer. Cost to fix if you waited until the final build? Thousands.

In Beta, you start using parts of the space in real-time. You test the workflow. You check where the light lands. You figure out where the kitchen bin actually makes sense based on how you chop your veg, not just where it looked good on a floor plan.

You build, you test, you adjust, and then you make it permanent.

Stop Solutioneering, Start Uncovering

It is completely natural to jump to solutions. When our living space or our software feels frustrating, we want a quick fix: "Build an extension!" "Add a button!" "Buy a bigger sofa!"

But if there’s one lesson Lean Agile teaches us, it’s that the first solution you think of is rarely the best one.

By embracing Discovery, testing ideas in Alpha, and building incrementally in Beta, you protect yourself from expensive mistakes. You stop building extensions that look great on Instagram but fail in real life.

So next time you start a project, whether you're creating a digital solution for a complex problem or just trying to fix a cramped kitchen, take a breath, step back, and ask yourself: Where do I actually need my bin to be?