Lean and Agile are still appropriate frameworks

A while ago, we tried to push back on the sprawl of tools. One target: meeting transcription. Different folks in the org had something like seven different tools in daily use. A discussion process followed, then an elimination process, and the number went down to three.

A couple of months later, before most of that reduction had even been rolled out, we were back to more than five: New vendors were being tried out. Vendors whose suites we already paid for had started offering meeting transcription.

So how do you set direction, and how do you lead a team, when things change this fast? I think the answer is almost boring: stick with the core ideas of Lean and Agile. At the core, they are all you need.

Built, then overtaken

Here’s another one. Earlier this year, my team decided that we wanted to and could do something about lots of folks suddenly using Claude Code and using it with --dangerously-skip-permissions. I mean, folks, it’s in the name… Yes, people loved that flag. We did not love the security implications.

So my team set out to build a safe way to use it: take a locked-down container, push the code base and a prompt into it, and let Claude run inside with dangerously skip permissions. We built it. We used it internally. We were about to roll it out.

The feedback was that it was way too restrictive: The container couldn’t reach the internet. Dang—that was the whole point! But more importantly: Anthropic released auto mode for Claude Code around the same time. Now the feedback became “auto mode is good enough, thank you very much!”

Lean is a practice, not a catalog

At its core, Lean is a practice.

You make your assumptions explicit. Then you validate the next assumption on the list—true or false—in the most efficacious way you can find: the smartest, cheapest way possible. Once it’s validated, you tick it off as a learning and move on.

The great thing is that the list is alive. You can keep changing it. The only moment it needs to hold still for a hot second is right after you validated the last assumption, because that’s when you pick the next one. With a large team, maybe you validate two or three at the same time. But that’s all it is.

Agile is small, correct increments

Once you’ve reached the stage of building software, agile is the practice of delivering it in small increments. Each increment retains the correctness of what’s already there and adds a little bit of functionality. The building of these increments is also one implementation of the Lean assumption validation cycle.

Put the two together. With Lean, you iterate on your assumptions. With Agile, you iterate on your product.

Let go of your ego

There’s one more thing I always need to add. It’s built into Lean already, but I’ll say it explicitly: let go of your ego.

The harness, model, or type of model that comes out next week might shatter a whole bunch of your assumptions—or the priorities you’ve assigned them. You cannot afford a lot of ego around knowing what comes next. You have to stay close to the news, and you have to keep updating your sense of priorities.

The meta problem

There is a subtler problem hiding here. What if the assumptions get disrupted so fast that the research agenda Lean produces is no longer cohesive?

Every time you arrive at the next question, it is a question of a totally different kind, because what you previously thought were the right assumptions no longer are. You keep thrashing. The iterative steps don’t add up to a direction.

If you find yourself there, you can deliberately slow down how quickly you allow yourself to update your priorities—what to validate next, what to build next—just to hold a cohesive theme for a while.

Maybe that’s the real trick. How long should that be? How long do you keep going in one direction when something new makes you at least question whether it’s still the right one?