Claudio Lassala's Blog

I recently gave a talk at the Agile Leadership Network on AI and agile. The title was clickbait on purpose. AI First. The real message was People First. Every time I hear people say “we’re going with an AI-first approach,” I tune out. One of my pet peeves lately is this phrase “human in the loop.” It feels like we’re the pesky little thing that helps AI do its job every once in a while. Wrong perspective. We have our human loop. Our seasons, our days, our weeks. We’ve decided to let AI into our loop to help us.

The shift matters. If you’re leveraging AI, it’s because you’re compressing a lot of tasks you used to do manually. Now the AI is doing them. So you have to ask yourself: what am I going to do with all that time? Do more? How about build better relationships with the people you’re trying to serve?

The Real Bottleneck

I asked the audience if anyone was feeling overwhelmed with everything AI-related. Every day there’s a new model that will “destroy everything” or “change everything.” Everyone presents themselves like they have it all figured out. They don’t. The people building these technologies don’t have it all figured out. If we try to stay in sync with all of it, we get tired quickly.

I see this pattern a lot. The person who keeps looking for the shiniest new toy, polishing it up, showing it to others, but never really using that tool to its fullest capacity. Always chasing the new. Driving that beautiful fast car at ten miles an hour in somebody’s neighborhood, thinking they’re the bomb.

Instead, we should look at taking what we have, understanding what we’re using it for, and using it to the best of its ability. Because hardly ever are we really maximizing the potential of these tools—or our potential using them.

The Sprint Review Problem

I’ve been to so many sprint review sessions where the team does a cute presentation. “This sprint we created this screen. Click the button, shows this message.” And the stakeholders say, “No, that will not solve our problems. Back to the drawing board.”

You spend two weeks working hard, doing your best. You get there, and stakeholders say Nope, that’s not what we need. Sometimes the team misunderstood what the business stakeholders actually need. Other times, you give stakeholders exactly what they said they wanted. Once it’s in front of them, they say, “Sorry, you did exactly what we told you. Now that we see it, that will not solve our problem.”

You feel powerless. How can we prevent that? I got tired of rolling the boulder up the hill, getting to the top, then rolling back down. Sisyphus. Not fun. You want to keep making progress upward. Always additive progress.

Coding Faster Isn’t the Answer

The reaction I often see is, “All we need to do is code faster.” Coding faster hasn’t been the bottleneck in a long time. I learned to type on an old typewriter when I was eight or nine years old. I can type fast. Producing code hasn’t been the bottleneck. We created code generators years ago. Drag a table from the database, drop it somewhere, boom—CRUD application. We solved that problem a long time ago.

The friction is in the gap between a stakeholder’s idea and a deployable feature. That gap has been there for a long, long time.

What Are We Optimizing For?

I ask myself and others: what are we optimizing for? When I started using more AI, I wanted to optimize for something specific. Being in conversation with stakeholders and shortening the path from that conversation to them being happy with the solution.

Before AI, we had conversations, took notes, had meetings to make sure we understood, wrote stories and requirements, created mock-ups and prototypes, presented them for critique, refined the vision, made technical decisions, wrote code, and implemented things. By the time we got back to stakeholders, they said no. Then we had to reverse all that.

I wanted to be in the conversation and end with them happy. Whatever gets us from here to there—AI, multiple agents, humans, a mix—that’s what I’ve been doing.

Need, Problem, Solution

The framework I’ve been using is need, problem, solution. So many times we say, “What problem does that solve?” Or we get requirements that say, “This is the solution we need. Here are the requirements.” That’s a brave thing to say. If we build something and follow those requirements perfectly, we have solved something. We don’t know that until we put it in front of people and measure the outcome.

We have to take a step back and say, “What is the problem we’re trying to solve? What has been tried before?” For a while I’ve thought we need to go deeper. Not just what is the problem, but why is it a problem? What is the actual need?

When we understand the need, we might say, “You’re describing this need and saying there’s a problem. Have you tried turning it around and looking from this angle? From that perspective, it’s actually not a problem.” You don’t have a problem if you look from that perspective. But you have to poke around to really understand.

If there’s a need, and something is in the way for that person to fulfill that need, and you’ve looked through different lenses and it’s still a problem, then we understand the need. We can clarify why there’s a problem from that person’s perspective, from their context and circumstances.

It comes down to people. The business, the company, is nothing more than a group of people who have the same need.

Human Stories Over User Stories

I’ve been pushing back on the whole “user story” thing. That person, before being a user, is a human. I started talking about these as human stories. What is the human story you’re going to tell?

There are business stories, customer stories, user stories, even societal stories. Align them in terms of value. If you can hit as many of those as possible, you’ve got a winner. That’s what you should pursue.

I turn stories around and start with why. “In order to” becomes the business outcome. Outcome means a behavioral change. A human behavioral change that drives business results. The implementation of that story, that feature, that product, that service—what is the human behavior that’s going to change that will drive results? That’s the outcome. That’s what the story should be.

The Wrong Plane Analogy

With how fast we can build things now, if your idea is bad, you’re just going to build that really quickly. The analogy I’ve been using is this: we can go long distances really fast. Walking, bicycle, car, flying. Has anyone ever boarded the wrong plane? You get on the wrong plane, you end up at the wrong destination. Did it save you any time? No, you moved really, really fast in the wrong direction.

I actually boarded the wrong plane once. At the last minute, someone said, “I think you’re in the wrong plane.” How they let me make my way over there is still a mystery. But it happened. Because that thing moves really fast. You want to have safety gates along the way to make sure you’re not going in the wrong direction.

Hello AI and all the things we can build at light speed. Are we building the right thing? We need safety gates to make sure we don’t end up somewhere we didn’t mean to.

Recording Everything

We’ve been recording every single conversation the team has with stakeholders. Sprint planning, sprint retro, backlog refinement. We record all of those conversations. Why? So we can stay locked eyes, keep eye contact and say, “Let’s keep talking. Don’t worry about looking down and taking notes. We can prompt the transcription later and pull up that information.”

That keeps paying dividends. In discovery, fuzzy requirements are often the problem. People refer to stories as requirements. They’re not the same thing. When someone says, “The user stories don’t have enough requirements,” I say, “They’re stories. Nobody walks around and says, ‘Let me show you this product. It’s amazing. I will tell you some requirements.’ You tell stories.”

What we try to do is capture intent. When people say, “We want that,” I ask, “What do you actually need? What is the intent behind that?” Let’s make sure we understand that.

From Conversation to Prototype in Minutes

I gave a demo during the talk. I described a Brazilian card game called Truco that I learned as a child. I’ve never played it in the US, so I don’t even know how to explain that game in English. I described whatever came to mind, then asked AI to write user stories.

A lot of people use AI this way. Just say “write user stories” and it gives you the average of how everybody writes stories. That’s not the way I like writing stories. I have a skill in my AI tool that has my approach, my philosophy. It writes stories in a cinematic way. If that solution works, people will tell that story. They won’t recite requirements to others. They’ll say, “You have to try this thing out. Let me tell you a story.”

The story it generated: “In order to feel confident enough to join a game without slowing everyone down as a curious newcomer who has never played Truco, I want to learn the basic rules, card rankings, and betting terms at my own pace.” Nothing technical there. No “as a user.” Instead, “as a curious newcomer” with context.

Then I told it to create a prototype showing the main features—not fully featured, just something to show different people what this game is about, to get approval from stakeholders. I gave it the stories and the constraints. The goal is to demonstrate the core experience to stakeholders quickly, not to ship a full product.

While one AI tool was building that prototype, I copied the same prompt to a different AI tool. Why? To see the differences. To validate. You have two things to compare so people can say, “I like this one, I like that one, I want a mix of these two.” Now we know exactly what we think is going to solve the problem.

“When did that happen?”

I’ve used these agents (storywriter, prototype builder) sitting in meetings with people. We take a five-minute break, I feed the transcript into my tool, and by the time they come back, there’s something on the screen. They say, “Wait, what? When did that happen?” Then we continue the conversation. When we walk out, everybody feels like we’re on a really good track. We work for two weeks, deliver the actual implementation, and at Sprint Review they say, “That came out even better than what we had anticipated. Great. Let’s keep moving forward.”

“You Can Improve Something Bad, You Can’t Improve Nothing”

I got this from one of my favorite authors. “You can improve something bad, you can’t improve nothing”. Whatever you build—even if it sucks, it’s the wrong color, whatever—we can improve that. While it was nothing, just an idea in my head, we cannot improve that. Period.

Going from nothing to something we can iterate on is powerful. And to get to this level, it starts from those stories that started from the conversation with people.

The Shift in Thinking

Are stakeholders thinking more because of AI? They’re thinking more sharply. They’re thinking about what they should be thinking about. Instead of thinking, “I think we need a table in the database,” it’s, “No, you don’t need that.” They’re learning to think more about the problem they’re trying to solve for their clients. “Let me think about how they think and relay those stories to the team.”

I use this to prepare people for conversations. Stakeholders show up at Sprint Reviews not knowing what we’re going to be talking about. They lose productivity for the first 30 minutes getting everybody on the same page. I create content I can attach to the email invite that takes two to five minutes to review. They look at it and think, “Oh, that’s what we’re talking about. I have some feedback I’d like to bring up.”

Roles Are Changing to Accountabilities

The audience asked about roles changing. The Scrum Guide 2020 revision dropped calling product owners a role—they called it an accountability. Something that has to happen. I love that. I’ve played all those roles in many projects. I was the team lead, the scrum master, the product owner, the business analyst. I wasn’t those titles. I was doing those things.

The discovery has to happen. The business analysis has to happen. Who’s doing it? That’s why I’ve been coaching developers to learn to write stories. When we show up in front of stakeholders, don’t expect the product owner to say, “These are the problems we solved.” We want the developers saying, “Stakeholders, these are the problems we hope we have solved for you.” It comes from the developers. Now the stakeholders trust the development team—the entire team with that focus.

The product owner accountability hasn’t changed. You still need to do discovery and maximize the value of your product backlog. But if you’re leveraging AI for that, a lot of those tasks have been compressed.

Solution Developer, Not Software Developer

When people say, “Now we don’t need developers anymore because AI can write the code,” I don’t think of myself as a software developer. I think of myself as a solution developer. The solution may or may not involve code.

Those who are succeeding start from the conversations and collaborations. They understand the desired outcome, the needs, what we’re trying to solve. Then they ask, “How might AI help us with that?”

All of these things—product owner, business analyst, scrum master—they’re accountabilities. Something that has to happen. Whether it’s one person doing it, or an AI system saying, “In that conversation, the stakeholders raised the following thing. I’ve seen in the daily Scrum transcripts that so-and-so is blocked by that thing. Here’s a way to solve that problem.” It can be an AI Scrum Master or a human. It has to happen.

The sooner we realize that, the better.

What Matters

The points that seemed to resonate most with the audience were:

• People first, not AI first

• The need-problem-solution framework

• Human stories over user stories

• Recording conversations and using AI to process them

• Building prototypes during meeting breaks

• You can improve something bad, you can’t improve nothing

• Roles are changing to accountabilities

• Solution developer, not software developer

Not AI as the hero. You as the hero. AI helps you get there faster.

Focus on the people, the conversations, the needs. Let AI bridge the gaps between idea and prototype, and prototype and implementation. We stop rolling the boulder up the hill only to watch it roll back down. We start making additive progress. That feels a lot better.

I gave a version of this presentation as an Improving Talk in case you’d like to watch.